From w3c-dist-auth-request@w3.org Mon Nov 1 14:50:04 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22460 for ; Mon, 1 Nov 2004 14:50:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1COi9n-0004VY-5e for w3c-dist-auth-dist@listhub.w3.org; Mon, 01 Nov 2004 19:47:59 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1COi9m-0004V2-Mj for w3c-dist-auth@listhub.w3.org; Mon, 01 Nov 2004 19:47:58 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1COi9m-0001NS-9B for w3c-dist-auth@w3.org; Mon, 01 Nov 2004 19:47:58 +0000 Received: (qmail 2603 invoked by uid 65534); 1 Nov 2004 19:47:24 -0000 Received: from pD9FF0D88.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.13.136) by mail.gmx.net (mp023) with SMTP; 01 Nov 2004 20:47:24 +0100 X-Authenticated: #1915285 Message-ID: <418692B6.9020207@gmx.de> Date: Mon, 01 Nov 2004 20:47:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV CC: Brian Korver References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: comments on draft-ietf-webdav-quota-04.txt, was: Fwd: I-D ACTION:draft-ietf-webdav-quota-04.txt X-Archived-At: http://www.w3.org/mid/418692B6.9020207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8933 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 01 Nov 2004 19:47:59 +0000 Content-Transfer-Encoding: 7bit Brian, thanks for the new draft; getting rid of the authorability part greatly simplifies the spec. Below are my updated comments. Best regards, Julian Issues with draft-ietf-webdav-quota-04.txt Content 01-C01 Organization I think the draft could greatly benefit by a more clean separation of (a) terminology, (b) protocol (property/error code) definition and (c) examples. Proposal for a outline: 1 Introduction/Notation/Terminology 2 Additional live properties 3 Modification to behaviour of existing methods (error marshalling) 4...n Other standard RFC section A (Appendix) Examples of how servers may implement quota I'm happy to help restructuring the document if this is just an amount-of-work issue. 01-C03 quota vs disk space The spec says that servers may expose physical disk limits as quota. a) This is incompatible with NFS from which we're borrowing the semantics (it treats disk limits as a separate property, and so should we) Update -04: this still appears in the text, but is less critical now that authorability of the quota is gone. I'd still like to see the working group make an explicit decision to keep this, because it's IMHO clearly outside the scope of this spec (I'd prefer separate properties). 02-C01 Condition Name Use name of precondition, not failure description: instead of . 03-C01 spec organization/semantics Back when draft 02 was published, we had a mailing list discussion about using the term "quota space" to simplify the rest of the spec. Unfortunately, neither was the discussion was finished nor do I see a change in the spec. 04-C01, section 1.2, requirements "WebDAV servers based on [RFC2518] have been implemented and deployed with quota restrictions on collections and users, so it makes sense to standardize this functionality to improve user experience and client interoperability. This specification requires WebDAV because it requires PROPFIND support and relies on the WebDAV definition of collections and properties, including the definitions for live and protected properties." RFC2518 doesn't define "protected" property, so a reference to RFC3253, section 1.4.2 seems to be in order. 04-C02, section 1.2, requirements "o Sometimes the storage service is provided free, but the storage service provider has limited storage space (e.g. www.example.com and university-provided student accounts)" This used to refer to www.sharemation.com. As it now says "example.com" it seems to have lost it's meaning. Maybe replace by a generic description of a site that offers storage to registered users. 04-C03, section 1.2, requirements "In addition to displaying the quota-available and quota-used on collections, this specification does not forbid these properties on any resource." This sentence is a bit confusing, in particular as section 2 recommends supporting the property on all resources. Just remove it. 04-C04, section 2, solution overview "The approach to meeting the requirements and scenarios outlined above is to define three live properties." *Two* properties. 04-C05, section 2, solution overview "This specification can be met on a server by implementing both quota-available and quota-used on collections only. Implementing both quota-available and quota- used on all resources is RECOMMENDED." Fix whitespace ("quota- used") and property names. Also consider using the "DAV:propertname" syntax used in other specs. 04-C05, section 2, solution overview "The quota-available and quota-used definitions below borrow heavily from the quota definitions in the NFS [RFC3010] specification." Fix property names and NFS reference (occurs several additional times). 04-C06, section 3, DAV:quota-available-bytes "The DAV:quota-available-bytes property value is the value in octets representing the amount of additional disk space beyond the current allocation that can be allocated to this file or directory before further allocations will be refused. It is understood that this space may be consumed by allocations to other files or directories." Replace "file or directory" by "resource". Note that neither "file" or "directory" exist in WebDAV terminology. (same in section 4) 04-C07, section 3, DAV:quota-available-bytes "Support for this property is REQUIRED on collections, and OPTIONAL on other resources. A server SHOULD implement this property for each resource that has the DAV:quota-used-bytes property." What's the motivation for the distinction? (same in section 4) 04-C08, section 3, DAV:quota-available-bytes "The value of this property is protected. A 403 Forbidden response is RECOMMENDED for attempts to write a protected property." RFC3253 defines the precondition "DAV:cannot-modify-protected-property". 04-C09, section 5, Examples Bad XML in response (at least one missing namespace prefix, you may want to run the examples through a parser to check for more). 04-C10, section 6 "WebDAV [RFC2518] defines the status code 507 (Insufficient Storage). This status code SHOULD be used when a client request (e.g. a PUT, PROPFIND, MKCOL, MOVE or COPY) is forbidden because it would exceed their allotted quota." s/is forbidden/fails/ (to avoid confusion with ACLs) 04-C11, section 7 "The total size of a collection, DAV:quota-used-bytes, is not necessarily a sum of the DAV:getcontentlength properties for resources stored in the collection." Actually, it won't be in most cases I'm aware of. Please either rephrase it (so this doesn't sound like an edge case) or drop the point. 04-C12, section 8 "If a server chooses to make the DAV:quota-assigned-bytes writable by clients with sufficient authorization, then it is opening up a certain amount of near-administration functionality to clients. However, it is not required for the DAV:quota-assigned-bytes property to be writeable by any clients, so a server can easily avoid this consideration." Right now it's a SHOULD-level requirement to make the property protected, so I wouldn't expect the spec to discuss the case where a server breaks that requirement. Editorial: 03-E02 outdated reference to NFS spec (3010 -> 3530) Update -04: the reference has been updated, but only partly (wrong date, and still using the ID "RFC3010"). Replace by: [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. 04-E01 Abstract s/This Internet-Draft discusses/This document discusses/ 04-E02 References Reference to RFC2026 doesn't seem to be used anywhere. From w3c-dist-auth-request@w3.org Fri Nov 5 14:47:18 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10502 for ; Fri, 5 Nov 2004 14:47:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CQA1E-0005Yp-Az for w3c-dist-auth-dist@listhub.w3.org; Fri, 05 Nov 2004 19:45:08 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CQA1D-0005YD-Ri for w3c-dist-auth@listhub.w3.org; Fri, 05 Nov 2004 19:45:07 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CQA1D-0003ru-IT for w3c-dist-auth@w3.org; Fri, 05 Nov 2004 19:45:07 +0000 Received: (qmail 6181 invoked by uid 65534); 5 Nov 2004 19:44:34 -0000 Received: from p548561C3.dip.t-dialin.net (EHLO [192.168.0.3]) (84.133.97.195) by mail.gmx.net (mp025) with SMTP; 05 Nov 2004 20:44:34 +0100 X-Authenticated: #1915285 Message-ID: <418BD81E.8090705@gmx.de> Date: Fri, 05 Nov 2004 20:44:30 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <8D96EDA0AC04D31197B400A0C96C14800E2C69E8@corp.webb.net> In-Reply-To: <8D96EDA0AC04D31197B400A0C96C14800E2C69E8@corp.webb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV at IETF 61 X-Archived-At: http://www.w3.org/mid/418BD81E.8090705@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8934 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 05 Nov 2004 19:45:08 +0000 Content-Transfer-Encoding: 7bit Hi, for those who didn't notice (I haven't seen an announcement here): the meeting is scheduled for November 11, 1pm (2004-11-11T18:00Z). For instructions how to particate using text conferencing, check . I'll not be able to attend the meeting, but I'll try to be on-line (see above). Here's a status summary for the drafts I'm currently editing: 1) BIND Basically, no change for a long time, see summary in my previous status summary: . The authors are waiting for the draft to be last-called, and as far as I am concerned, there are no open issues wth it. The current draft (with minor editorial changes) is , the issues list can be found at . 2) REDIRECT There are only a few issues left (see latest message , current draft , latest edits , issues list http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-issues.html>). We probably can resolve the remaining issues once BIND is done. 3) WebDAV property datatypes The latest draft () has been submitted to the RFC Editor for publication as an Experimental RFC (see status at ). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Nov 6 10:43:34 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16074 for ; Sat, 6 Nov 2004 10:43:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CQSgJ-0004JX-5c for w3c-dist-auth-dist@listhub.w3.org; Sat, 06 Nov 2004 15:40:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CQSgI-0004J2-Lv for w3c-dist-auth@listhub.w3.org; Sat, 06 Nov 2004 15:40:46 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CQSgD-0004SC-EF for w3c-dist-auth@w3.org; Sat, 06 Nov 2004 15:40:41 +0000 Received: (qmail 23438 invoked by uid 65534); 6 Nov 2004 15:40:13 -0000 Received: from p54856735.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.103.53) by mail.gmx.net (mp010) with SMTP; 06 Nov 2004 16:40:13 +0100 X-Authenticated: #1915285 Message-ID: <418CF055.7000603@gmx.de> Date: Sat, 06 Nov 2004 16:40:05 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: BIND: references to RFC2396 X-Archived-At: http://www.w3.org/mid/418CF055.7000603@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8935 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 06 Nov 2004 15:40:47 +0000 Content-Transfer-Encoding: 7bit Hi, now that RFC2396bis has been accepted for publication, I have changed the references inside the document accordingly (see ). Note: for BIND this was a very simple change; other specs may need more work as lots of grammar production and also terminlogy changed in comparison to RFC2396 (for instance, the term "relative URI reference" isn't used anymore). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Nov 11 20:27:11 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23093 for ; Thu, 11 Nov 2004 20:27:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CSQAV-0000nC-RL for w3c-dist-auth-dist@listhub.w3.org; Fri, 12 Nov 2004 01:24:03 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CSQAV-0000me-7a for w3c-dist-auth@listhub.w3.org; Fri, 12 Nov 2004 01:24:03 +0000 Received: from cats-mx4.ucsc.edu ([128.114.125.37]) by bart.w3.org with esmtp (Exim 4.34) id 1CSQAU-0002gu-Ts for w3c-dist-auth@w3.org; Fri, 12 Nov 2004 01:24:03 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx4.ucsc.edu (8.10.1/8.10.1) with ESMTP id iAC1MsG29254 for ; Thu, 11 Nov 2004 17:22:55 -0800 (PST) Message-Id: <200411120122.iAC1MsG29254@cats-mx4.ucsc.edu> Reply-To: From: "Jim Whitehead" To: Date: Thu, 11 Nov 2004 17:22:47 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTIVh1zgv6pZUhxRDSrXQprIU4AlQ== X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Comment on UNBIND language in BIND specification X-Archived-At: http://www.w3.org/mid/200411120122.iAC1MsG29254@cats-mx4.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8936 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 12 Nov 2004 01:24:03 +0000 Content-Transfer-Encoding: 7bit I'm reading through the BIND specification, and the description of the REBIND method's operands is a bit unclear to me. I'm assuming the intent is similar to BIND and UNBIND, each of which clearly state in the first sentence what role the Request-URI, segment, and href fields play. In my reading I just jumped right into the spec. at this method (typical reference reading pattern), and hence I didn't initially see the similarity with the BIND and UNBIND method operands. - Jim From w3c-dist-auth-request@w3.org Thu Nov 11 20:43:57 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24277 for ; Thu, 11 Nov 2004 20:43:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CSQSs-0007yC-KO for w3c-dist-auth-dist@listhub.w3.org; Fri, 12 Nov 2004 01:43:02 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CSQSs-0007xi-BF for w3c-dist-auth@listhub.w3.org; Fri, 12 Nov 2004 01:43:02 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by bart.w3.org with esmtp (Exim 4.34) id 1CSQSs-0000EE-2L for w3c-dist-auth@w3.org; Fri, 12 Nov 2004 01:43:02 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iAC1meeR004957 for ; Thu, 11 Nov 2004 17:48:40 -0800 (PST) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Thu, 11 Nov 2004 17:42:58 -0800 Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id iAC1gSQu020715 for ; Thu, 11 Nov 2004 17:42:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v679) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: w3c-dist-auth@w3.org From: Jim Luther Date: Thu, 11 Nov 2004 17:42:26 -0800 X-Mailer: Apple Mail (2.679) Received-SPF: pass (bart.w3.org: domain of luther.j@apple.com designates 17.254.13.23 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Property size limitations X-Archived-At: http://www.w3.org/mid/ED71B4E7-E887-4585-AEFC-3ABFD78C83A0@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8937 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 12 Nov 2004 01:43:02 +0000 Content-Transfer-Encoding: 7bit PROPPATCH can fail with 507 (Insufficient Storage). Does anyone know what the maximum size for properties is on common WebDAV server implementations? Thanks, Jim From w3c-dist-auth-request@w3.org Fri Nov 12 09:39:26 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07029 for ; Fri, 12 Nov 2004 09:39:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CScWW-0007lf-P1 for w3c-dist-auth-dist@listhub.w3.org; Fri, 12 Nov 2004 14:35:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CScWW-0007l6-7K for w3c-dist-auth@listhub.w3.org; Fri, 12 Nov 2004 14:35:36 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CScWV-00068D-Sv for w3c-dist-auth@w3.org; Fri, 12 Nov 2004 14:35:36 +0000 Received: (qmail 2001 invoked by uid 65534); 12 Nov 2004 14:33:30 -0000 Received: from p508249EC.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.73.236) by mail.gmx.net (mp018) with SMTP; 12 Nov 2004 15:33:30 +0100 X-Authenticated: #1915285 Message-ID: <4194C9B9.1040009@gmx.de> Date: Fri, 12 Nov 2004 15:33:29 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: w3c-dist-auth@w3.org References: <200411120122.iAC1MsG29254@cats-mx4.ucsc.edu> In-Reply-To: <200411120122.iAC1MsG29254@cats-mx4.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comment on UNBIND language in BIND specification X-Archived-At: http://www.w3.org/mid/4194C9B9.1040009@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8938 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 12 Nov 2004 14:35:36 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > I'm reading through the BIND specification, and the description of the > REBIND method's operands is a bit unclear to me. I'm assuming the intent is > similar to BIND and UNBIND, each of which clearly state in the first > sentence what role the Request-URI, segment, and href fields play. In my > reading I just jumped right into the spec. at this method (typical reference > reading pattern), and hence I didn't initially see the similarity with the > BIND and UNBIND method operands. Agreed. Would replacing "The REBIND method removes a binding to a resource from one collection, and adds a binding to that resource into another collection. It is effectively an atomic form of a MOVE request." by "The REBIND method removes a binding to a resource from the collection identified by the Request-URI, and adds a binding to that resource into another collection. It is effectively an atomic form of a MOVE request." be sufficient? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Nov 12 11:24:29 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17179 for ; Fri, 12 Nov 2004 11:24:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CSeBi-0004EJ-FA for w3c-dist-auth-dist@listhub.w3.org; Fri, 12 Nov 2004 16:22:14 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CSeBh-0004Dp-Tk for w3c-dist-auth@listhub.w3.org; Fri, 12 Nov 2004 16:22:13 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CSeBh-0004gh-Jb for w3c-dist-auth@w3.org; Fri, 12 Nov 2004 16:22:13 +0000 Received: (qmail 12761 invoked by uid 65534); 12 Nov 2004 16:21:37 -0000 Received: from p508249EC.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.73.236) by mail.gmx.net (mp019) with SMTP; 12 Nov 2004 17:21:37 +0100 X-Authenticated: #1915285 Message-ID: <4194E30D.3030408@gmx.de> Date: Fri, 12 Nov 2004 17:21:33 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: ejw@cs.ucsc.edu, w3c-dist-auth@w3.org References: <200411120122.iAC1MsG29254@cats-mx4.ucsc.edu> <4194C9B9.1040009@gmx.de> In-Reply-To: <4194C9B9.1040009@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comment on UNBIND language in BIND specification X-Archived-At: http://www.w3.org/mid/4194E30D.3030408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8939 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 12 Nov 2004 16:22:14 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Jim Whitehead wrote: > >> I'm reading through the BIND specification, and the description of the >> REBIND method's operands is a bit unclear to me. I'm assuming the >> intent is >> similar to BIND and UNBIND, each of which clearly state in the first >> sentence what role the Request-URI, segment, and href fields play. In my >> reading I just jumped right into the spec. at this method (typical >> reference >> reading pattern), and hence I didn't initially see the similarity with >> the >> BIND and UNBIND method operands. > > > Agreed. > > Would replacing > > "The REBIND method removes a binding to a resource from one collection, > and adds a binding to that resource into another collection. It is > effectively an atomic form of a MOVE request." > > by > > "The REBIND method removes a binding to a resource from the collection > identified by the Request-URI, and adds a binding to that resource into > another collection. It is effectively an atomic form of a MOVE request." > > be sufficient? > > Best regards, Julian I expanded the replacement further to: The REBIND method removes a binding to a resource from the collection identified by the Request-URI, and adds a binding to that resource into another collection. The request body specifies the segment to be removed and the new binding to be created (href element). It is effectively an atomic form of a MOVE request. (Issue tracked as and currently marked as "closed"). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Nov 12 13:22:38 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27883 for ; Fri, 12 Nov 2004 13:22:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CSg1n-00032D-D1 for w3c-dist-auth-dist@listhub.w3.org; Fri, 12 Nov 2004 18:20:07 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CSg1m-00031f-Ra for w3c-dist-auth@listhub.w3.org; Fri, 12 Nov 2004 18:20:06 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1CSg1m-0007cP-Jq for w3c-dist-auth@w3.org; Fri, 12 Nov 2004 18:20:06 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.10.1/8.10.1) with ESMTP id iACIJQP13963; Fri, 12 Nov 2004 10:19:26 -0800 (PST) Message-Id: <200411121819.iACIJQP13963@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" Cc: Date: Fri, 12 Nov 2004 10:19:19 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTI07AFt9/TmUmQTS6/Ymq1JJ9GBQAD955A In-Reply-To: <4194E30D.3030408@gmx.de> X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comment on UNBIND language in BIND specification X-Archived-At: http://www.w3.org/mid/200411121819.iACIJQP13963@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8940 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 12 Nov 2004 18:20:07 +0000 Content-Transfer-Encoding: 7bit Julian, > I expanded the replacement further to: > > The REBIND method removes a binding to a resource from the collection > identified by the Request-URI, and adds a binding to that resource > into another collection. The request body specifies the segment to > be removed and the new binding to be created (href element). It is > effectively an atomic form of a MOVE request. I like this language, though I suggest the following tweak for the second sentence to fix the fact that we're not removing a segment, we're removing a binding: The request body specifies the binding to be removed (segment) and the new binding to be created (href). - Jim From w3c-dist-auth-request@w3.org Fri Nov 12 14:11:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03078 for ; Fri, 12 Nov 2004 14:11:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CSgnz-0000oJ-KB for w3c-dist-auth-dist@listhub.w3.org; Fri, 12 Nov 2004 19:09:55 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CSgnz-0000ni-16 for w3c-dist-auth@listhub.w3.org; Fri, 12 Nov 2004 19:09:55 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CSgny-0000BD-KL for w3c-dist-auth@w3.org; Fri, 12 Nov 2004 19:09:54 +0000 Received: (qmail 24431 invoked by uid 65534); 12 Nov 2004 19:08:58 -0000 Received: from pD9535E7D.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.94.125) by mail.gmx.net (mp019) with SMTP; 12 Nov 2004 20:08:58 +0100 X-Authenticated: #1915285 Message-ID: <41950A47.2020400@gmx.de> Date: Fri, 12 Nov 2004 20:08:55 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: w3c-dist-auth@w3.org References: <200411121819.iACIJQP13963@cats-mx1.ucsc.edu> In-Reply-To: <200411121819.iACIJQP13963@cats-mx1.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comment on UNBIND language in BIND specification X-Archived-At: http://www.w3.org/mid/41950A47.2020400@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8941 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 12 Nov 2004 19:09:55 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Julian, > > >>I expanded the replacement further to: >> >> The REBIND method removes a binding to a resource from the collection >> identified by the Request-URI, and adds a binding to that resource >> into another collection. The request body specifies the segment to >> be removed and the new binding to be created (href element). It is >> effectively an atomic form of a MOVE request. > > > I like this language, though I suggest the following tweak for the second > sentence to fix the fact that we're not removing a segment, we're removing a > binding: > > The request body specifies the binding to be removed (segment) and the new > binding to be created (href). Good catch. I'll make that change. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Nov 13 06:31:16 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01134 for ; Sat, 13 Nov 2004 06:31:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CSw4E-0003tA-9N for w3c-dist-auth-dist@listhub.w3.org; Sat, 13 Nov 2004 11:27:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CSw4D-0003sb-KW for w3c-dist-auth@listhub.w3.org; Sat, 13 Nov 2004 11:27:41 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CSw48-0006M4-1R for w3c-dist-auth@w3.org; Sat, 13 Nov 2004 11:27:36 +0000 Received: (qmail 5743 invoked by uid 65534); 13 Nov 2004 11:27:07 -0000 Received: from pD9535E7D.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.94.125) by mail.gmx.net (mp003) with SMTP; 13 Nov 2004 12:27:07 +0100 X-Authenticated: #1915285 Message-ID: <4195EF88.7040509@gmx.de> Date: Sat, 13 Nov 2004 12:27:05 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200409291930.PAA02253@ietf.org> <415BAE53.6070306@gmx.de> <416F7B53.6010807@gmx.de> <7FD1E16B-1EBB-11D9-B361-000A95B2BB72@osafoundation.org> <416FEA93.4080905@gmx.de> <13B4F2CD-1EC5-11D9-B361-000A95B2BB72@osafoundation.org> <416FF81C.2050603@gmx.de> <5A388280-1ECE-11D9-B361-000A95B2BB72@osafoundation.org> <417018FA.3030203@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D ACTION:draft-ietf-webdav-bind-07.txt X-Archived-At: http://www.w3.org/mid/4195EF88.7040509@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8942 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 13 Nov 2004 11:27:42 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > On Oct 15, 2004, at 11:37 AM, Julian Reschke wrote: > >> >> >> I'm not sure why you don't want to discuss those though. IETF working >> groups by definition do their work on their respective mailing lists; >> whether or not a supporting bug tracking system (which will have to >> send change notifications to the mailing list anyway) is in place >> should not be relevant (although this probably will be helpful). >> > I am quite willing to discuss these on the list, what I said was that I > wasn't interested in discussing them on the list now (not until Joe's > ready to monitor the issue discussions and track issues and declare > consensus.) OK, as far as I can tell (mentioned during the WG meeting [0]), the Issues Tracker has been set up (although I haven't seen it CCing the mailing list like it should). So this should mean that we can get back to do actual work on the spec. IMHO the right way to proceed is to review the author's issues list ([1]) and to verify that issue resolutions match the WG consensus back when the issue was discussed. If the originator of an issue is *not* satisfied, I'd expect him/her to continue the discussion here on the mailing list. Raising the issue once and then not replying to answers indicates (to me) that the answer/resolution was OK, though. Best regards, Julian [0] [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Nov 13 06:42:22 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01653 for ; Sat, 13 Nov 2004 06:42:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CSwGp-0006mD-60 for w3c-dist-auth-dist@listhub.w3.org; Sat, 13 Nov 2004 11:40:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CSwGo-0006lj-TE for w3c-dist-auth@listhub.w3.org; Sat, 13 Nov 2004 11:40:42 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CSwGj-0007pN-8o for w3c-dist-auth@w3.org; Sat, 13 Nov 2004 11:40:37 +0000 Received: (qmail 14615 invoked by uid 65534); 13 Nov 2004 11:40:08 -0000 Received: from pD9535E7D.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.94.125) by mail.gmx.net (mp022) with SMTP; 13 Nov 2004 12:40:08 +0100 X-Authenticated: #1915285 Message-ID: <4195F294.9050209@gmx.de> Date: Sat, 13 Nov 2004 12:40:04 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: REDIRECT issue "13_allprop": allprop behaviour X-Archived-At: http://www.w3.org/mid/4195F294.9050209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8943 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 13 Nov 2004 11:40:43 +0000 Content-Transfer-Encoding: 7bit Hi, I just noticed that the draft wasn't consistent with all post-RFC2518 drafts in that new live properties should not be returned upon PROPFIND/allprop. I'll add this as issue "13_allprop" and resolve it by adding A PROPFIND/allprop request SHOULD NOT return any of the properties defined in this document. to the introduction of section 13. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Nov 13 12:51:58 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20090 for ; Sat, 13 Nov 2004 12:51:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CT20s-0002De-Va for w3c-dist-auth-dist@listhub.w3.org; Sat, 13 Nov 2004 17:48:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CT20s-0002Cu-BT for w3c-dist-auth@listhub.w3.org; Sat, 13 Nov 2004 17:48:38 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CT20m-00084a-N6 for w3c-dist-auth@w3.org; Sat, 13 Nov 2004 17:48:32 +0000 Received: (qmail 21548 invoked by uid 65534); 13 Nov 2004 17:48:03 -0000 Received: from pD9FF04A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.4.162) by mail.gmx.net (mp007) with SMTP; 13 Nov 2004 18:48:03 +0100 X-Authenticated: #1915285 Message-ID: <419648C7.3060507@gmx.de> Date: Sat, 13 Nov 2004 18:47:51 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: w3c-dist-auth@w3.org References: <8D96EDA0AC04D31197B400A0C96C14800E2C69E8@corp.webb.net> In-Reply-To: <8D96EDA0AC04D31197B400A0C96C14800E2C69E8@corp.webb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV at IETF 61 X-Archived-At: http://www.w3.org/mid/419648C7.3060507@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8944 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 13 Nov 2004 17:48:38 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > I've just asked for a slot for us in DC. > > Does anyone want to propose agenda items? Here are a couple that I'd like > to propose: > > - Final discussion on BIND. Let's push this out. > - Redirect: any discussion needed > - 2518bis: status report > - Status of drafts of note for the working group: > + PATCH > + Quota > + Property datatyping > + SEARCH > + CalDAV > + WebDAV-events > > If possible, I'd like for authors of the outstanding documents to attend, so > that anything that is discussed can be incorporated into his/her thought > process. Hi, looking at the text conferencing log, I can't seem to find any mention of RFC2518bis' status. Was it discussed at all? Wondering, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Nov 15 04:43:02 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11517 for ; Mon, 15 Nov 2004 04:43:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CTdL4-0006V5-3v for w3c-dist-auth-dist@listhub.w3.org; Mon, 15 Nov 2004 09:39:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CTdL3-0006UL-Ht for w3c-dist-auth@listhub.w3.org; Mon, 15 Nov 2004 09:39:57 +0000 Received: from rndf-137-167.telkomadsl.co.za ([165.165.137.167] helo=INTERNET201.com) by bart.w3.org with smtp (Exim 4.34) id 1CTdL2-00036B-RD for w3c-dist-auth@w3.org; Mon, 15 Nov 2004 09:39:57 +0000 Date: Mon, 15 Nov 2004 11:39:49 +0200 To: "W" From: "Paf" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------iapxdugerpfzxlfjytve" Received-SPF: neutral (bart.w3.org: 165.165.137.167 is neither permitted nor denied by domain of paf@cisco.com) X-Original-To: w3c-dist-auth@w3.org Subject: Re: X-Archived-At: http://www.w3.org/mid/smbxvoldebwvxwbwjmq@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8945 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 15 Nov 2004 09:39:58 +0000 ----------iapxdugerpfzxlfjytve Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------iapxdugerpfzxlfjytve Content-Type: application/octet-stream; name="Joke.exe" Content-Disposition: attachment; filename="Joke.exe" Content-Transfer-Encoding: base64 ----------iapxdugerpfzxlfjytve-- From w3c-dist-auth-request@w3.org Mon Nov 15 13:13:39 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16465 for ; Mon, 15 Nov 2004 13:13:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CTlJp-0005eg-S9 for w3c-dist-auth-dist@listhub.w3.org; Mon, 15 Nov 2004 18:11:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CTlJo-0005dW-9l; Mon, 15 Nov 2004 18:11:12 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CTlJi-0007Jt-LS; Mon, 15 Nov 2004 18:11:06 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAFIA0Ze016777 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 15 Nov 2004 10:10:01 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D137B52-3731-11D9-A8FA-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg From: Lisa Dusseault Date: Mon, 15 Nov 2004 10:09:54 -0800 To: HTTP working group , webdav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Review of XCAP -- extensions to HTTP for configuration access X-Archived-At: http://www.w3.org/mid/8D137B52-3731-11D9-A8FA-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8946 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 15 Nov 2004 18:11:13 +0000 Content-Transfer-Encoding: 7bit I haven't seen XCAP announced or discussed on these lists. I'll try to give an overview, but please forgive me if there are any inaccuracies. I haven't had the bandwidth to follow the SIMPLE list and this is not in my job scope so while I've been meaning to invest some time in understanding it better, I haven't found much of that time. XCAP is being developed in the SIMPLE working group. (I have a problem with this process, because XCAP is a substantial extension to HTTP, and this feels like it's being buried in a group working on mostly non-HTTP protocols -- thus I'm hoping to see some discussion on HTTP lists.) XCAP is intended to provide access to configuration documents stored in XML on an HTTP server. These configuration documents might be buddy lists, virtual conference room configuration, presence documents (for more complex presence than "online/offline"), or really anything. The XCON working group is already looking at XCAP in addition to SIMPLE, and one could imagine SIP and SIPPING working groups using it next or spreading outside the SIP area. The requirement to extend HTTP came from the observation that configuration documents often undergo small changes, or applications may be interested only in small pieces of the document. For example, an application might change the buddy list document by adding a single buddy to a list of 200, or an even smaller change might be to change the buddy's email address element value. A client in a conference might want to retrieve the video policy from the policy configuration document without downloading all the floor control information. To achieve this partial access, XCAP changes HTTP URLs and (depending on your outlook) the semantic of the PUT body. Each configuration document has a HTTP URL, such as "http://xcap.example.com/users/lisa/buddylist.xml". XCAP also allows URLs to address XML elements or attributes inside the XCAP document, by putting XPATH-based syntax on the URL -- turning every XML element into an addressable resource. E.g. http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ resource-lists/list%5b@name=%22friends%22%5d/entry In this URL, the ~~ separator indicates the end of the regular meaning of the HTTP URl, and the beginning of the XPATH-like parsing which leads to a certain entry where name = "friends" (I think). XCAP servers support GET, PUT and DELETE against these new types of URLs; these operations modify parts of the configuration document. Also note "an XCAP server MUST maintain entity tags for all resources". Current status: - Document formats for XCAP are defined in separate drafts, e.g. - XCAP itself finished Working Group Last Call in August, thus the SIMPLE working group believes it is complete. I'm concerned about two main areas myself: - The behavior of these resources on intermediaries, particularly caches and write-through caches. - The interaction or compatibility between XCAP and other HTTP extensions. To take WebDAV for an example, is a server supposed to be able to lock every one of these new resources? Is there any chance that two independent servers that support XCAP and WebDAV could do so in the same way? I wouldn't be surprised if members of these lists can come up with other problems, because I feel this approach is headed straight at a deployment/interoperability minefield. If, on the other hand, people review XCAP and do not find problems, it would be a service to let me, Jonathan, or this list, know of positive reviews by HTTP experts. Lisa From w3c-dist-auth-request@w3.org Mon Nov 15 15:33:24 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29917 for ; Mon, 15 Nov 2004 15:33:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CTnUh-00027q-Bk for w3c-dist-auth-dist@listhub.w3.org; Mon, 15 Nov 2004 20:30:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CTnUg-00027I-HF; Mon, 15 Nov 2004 20:30:34 +0000 Received: from ithilien.qualcomm.com ([129.46.51.59]) by lisa.w3.org with esmtp (Exim 4.34) id 1CTnUa-0002Yv-RR; Mon, 15 Nov 2004 20:30:29 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id iAFKToeD017495; Mon, 15 Nov 2004 12:29:50 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id iAFKTmba025816; Mon, 15 Nov 2004 12:29:48 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <8D137B52-3731-11D9-A8FA-000A95B2BB72@osafoundation.org> References: <8D137B52-3731-11D9-A8FA-000A95B2BB72@osafoundation.org> Date: Mon, 15 Nov 2004 12:29:47 -0800 To: Lisa Dusseault , HTTP working group , webdav From: Ted Hardie Cc: Jonathan Rosenberg Content-Type: text/plain; charset="us-ascii" ; format="flowed" Received-SPF: none (lisa.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Review of XCAP -- extensions to HTTP for configuration access X-Archived-At: http://www.w3.org/mid/p06200700bdbebdc592d3@%5B129.46.227.161%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8947 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 15 Nov 2004 20:30:35 +0000 At 10:09 AM -0800 11/15/04, Lisa Dusseault wrote: >I haven't seen XCAP > >announced or discussed on these lists. I'll try to give an >overview, but please forgive me if there are any inaccuracies. I >haven't had the bandwidth to follow the SIMPLE list and this is not >in my job scope so while I've been meaning to invest some time in >understanding it better, I haven't found much of that time. > >XCAP is being developed in the SIMPLE working group. (I have a >problem with this process, because XCAP is a substantial extension >to HTTP, and this feels like it's being buried in a group working on >mostly non-HTTP protocols -- thus I'm hoping to see some discussion >on HTTP lists.) The intent of this was not to create a substantial extension to HTTP, but a profile. That is, rather than doing a full XPATH-based application protocol, they chose instead to limit the structures of resources to pure hierarchies so that standard HTTP mechanisms could be applied. >To achieve this partial access, XCAP changes HTTP URLs and >(depending on your outlook) the semantic of the PUT body. Each >configuration document has a HTTP URL, such as >"http://xcap.example.com/users/lisa/buddylist.xml". XCAP also >allows URLs to address XML elements or attributes inside the XCAP >document, by putting XPATH-based syntax on the URL -- turning every >XML element into an addressable resource. E.g I don't think it changes the HTTP URI scheme. I also believe that its model for how resources relate is within the HTTP mechanism. It is parallel in many ways to HTTP driven by relational databases rather than files. It takes a bit of head-twisting to see relational database resources (especially view-based ones) as HTTP resources, but there is nothing to rule it out; that some resources may also be stored in XML documents doesn't mean that they can't be resources in their own right. >http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d/entry > >In this URL, the ~~ separator indicates the end of the regular >meaning of the HTTP URl, and the beginning of the XPATH-like parsing >which leads to a certain entry where name = "friends" (I think). > >XCAP servers support GET, PUT and DELETE against these new types of >URLs; these operations modify parts of the configuration document. >Also note "an XCAP server MUST maintain entity tags for all resources". > >Current status: > - Document formats for XCAP are defined in separate drafts, e.g. > > - XCAP itself finished Working Group Last Call in August, thus the >SIMPLE working group believes it is complete. > >I'm concerned about two main areas myself: > - The behavior of these resources on intermediaries, particularly >caches and write-through caches. > - The interaction or compatibility between XCAP and other HTTP >extensions. To take WebDAV for an example, is a server supposed to >be able to lock every one of these new resources? Is there any >chance that two independent servers that support XCAP and WebDAV >could do so in the same way? It was a goal of the SIMPLE working group (at least one point) to move to a locking mechanism based on WebDAV over time. That requires resource level locking that looks at least initially to be within WebDAV's protocol scope. Many current implementations won't work (since their locking granularity is file-based, rather than seeing files as "XML databases" of resources), but that isn't a protocol problem. Obviously, we can't really answer that question long term until there is a draft, but it was within the goals of the group as I understand them. >I wouldn't be surprised if members of these lists can come up with >other problems, because I feel this approach is headed straight at a >deployment/interoperability minefield. If, on the other hand, >people review XCAP and do not find problems, it would be a service >to let me, Jonathan, or this list, know of positive reviews by HTTP >experts. > Reviews are good, and careful thought on it will be much appreciated. Please do start from the idea that XCAP's intent is *not* to change HTTP, though, and highlight places where the drafts are unclear on whether or not it proposes a change or where the drafts do present incompatible changes. The working group is aware that the e-tags requirement is not present in HTTP, but sees it as appropriate for its profile. regards, Ted Hardie From w3c-dist-auth-request@w3.org Mon Nov 15 19:46:42 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01899 for ; Mon, 15 Nov 2004 19:46:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CTrQw-00011W-Ju for w3c-dist-auth-dist@listhub.w3.org; Tue, 16 Nov 2004 00:42:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CTrQv-00010x-Ty for w3c-dist-auth@listhub.w3.org; Tue, 16 Nov 2004 00:42:57 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by bart.w3.org with esmtp (Exim 4.34) id 1CTrQv-0002B7-Hp for w3c-dist-auth@w3.org; Tue, 16 Nov 2004 00:42:57 +0000 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VGBDGPDK; Mon, 15 Nov 2004 17:37:33 -0700 In-Reply-To: <419648C7.3060507@gmx.de> References: <8D96EDA0AC04D31197B400A0C96C14800E2C69E8@corp.webb.net> <419648C7.3060507@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F33B99E-3768-11D9-A37D-000A959A17A6@jabber.com> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Joe Hildebrand Date: Mon, 15 Nov 2004 17:42:19 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) Received-SPF: none (bart.w3.org: domain of jhildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV at IETF 61 X-Archived-At: http://www.w3.org/mid/5F33B99E-3768-11D9-A37D-000A959A17A6@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8948 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 16 Nov 2004 00:42:58 +0000 Content-Transfer-Encoding: 7bit Not as I recall. Here's the agenda, as-built: - Agenda Bash - Process - Bugzilla issue tracking: http://ietf.webdav.org:8080/bugzilla/ - Closing issues - BIND - Redirect - QUOTA - CalDAV - WebDAV events (http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify -00.html) - PATCH We'll be sending in notes, soon. Philip, did you end up getting a dump of the jabber room? -- Joe Hildebrand Denver, CO, USA On Nov 13, 2004, at 10:47 AM, Julian Reschke wrote: > > Joe Hildebrand wrote: >> I've just asked for a slot for us in DC. >> Does anyone want to propose agenda items? Here are a couple that I'd >> like >> to propose: >> - Final discussion on BIND. Let's push this out. >> - Redirect: any discussion needed >> - 2518bis: status report >> - Status of drafts of note for the working group: >> + PATCH >> + Quota + Property datatyping >> + SEARCH + CalDAV >> + WebDAV-events >> If possible, I'd like for authors of the outstanding documents to >> attend, so >> that anything that is discussed can be incorporated into his/her >> thought >> process. > > Hi, > > looking at the text conferencing log, I can't seem to find any mention > of RFC2518bis' status. Was it discussed at all? > > Wondering, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Nov 16 18:45:43 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11402 for ; Tue, 16 Nov 2004 18:45:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CUCz7-0005YL-1U for w3c-dist-auth-dist@listhub.w3.org; Tue, 16 Nov 2004 23:43:41 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CUCz4-0005Wx-03 for w3c-dist-auth@listhub.w3.org; Tue, 16 Nov 2004 23:43:38 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by bart.w3.org with esmtp (Exim 4.34) id 1CUCz3-0002gU-Oi for w3c-dist-auth@w3.org; Tue, 16 Nov 2004 23:43:37 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.10.1/8.10.1) with ESMTP id iAGNh9P17820 for ; Tue, 16 Nov 2004 15:43:09 -0800 (PST) Message-Id: <200411162343.iAGNh9P17820@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "WebDAV \(WebDAV WG\)" Date: Tue, 16 Nov 2004 15:43:03 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcTMBMkoJCwYH65uQVm1YG5H3OsDQwAMSUpA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WebDAV at IETF 61 X-Archived-At: http://www.w3.org/mid/200411162343.iAGNh9P17820@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8949 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 16 Nov 2004 23:43:41 +0000 Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added "stpeter@jabber.org" to the accept2 list. - Jim -----Original Message----- From: news [mailto:news@sea.gmane.org] On Behalf Of Peter Saint-Andre Sent: Tuesday, November 16, 2004 9:46 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: WebDAV at IETF 61 In article <5F33B99E-3768-11D9-A37D-000A959A17A6@jabber.com>, Joe Hildebrand wrote: > We'll be sending in notes, soon. Philip, did you end up getting a > dump of the jabber room? Should be here: http://www.xmpp.org/ietf-logs/webdav@ietf.xmpp.org/2004-11-11.html /psa From w3c-dist-auth-request@w3.org Thu Nov 18 05:23:25 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09639 for ; Thu, 18 Nov 2004 05:23:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CUjPD-0004ja-IM for w3c-dist-auth-dist@listhub.w3.org; Thu, 18 Nov 2004 10:20:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CUjOW-0004OL-0Y; Thu, 18 Nov 2004 10:20:04 +0000 Received: from [80.92.98.67] (helo=67-98-st.zelcom.ru) by bart.w3.org with smtp (Exim 4.34) id 1CUjOQ-0004zr-Cl; Thu, 18 Nov 2004 10:20:03 +0000 Reply-To: From: "Òèïîãðàôèÿ" To: Date: Thu, 18 Nov 2004 12:49:32 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0216_01C4CD6D.0CBED9A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Received-SPF: none (bart.w3.org: domain of paret.cl@wanadoo.fr does not designate permitted sender hosts) Message-ID: X-Original-To: w3c-dist-auth@w3.org Subject: =?windows-1251?B?UmU6IO7y4uXyIO3gIOfg7/Du8Q==?= X-Archived-At: http://www.w3.org/mid/E1CUjOW-0004OL-0Y@frink.w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8950 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 18 Nov 2004 10:20:47 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_0216_01C4CD6D.0CBED9A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0217_01C4CD6D.0CBED9A0" ------=_NextPart_001_0217_01C4CD6D.0CBED9A0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable =CC=CE=D1=CA=CE=C2=D1=CA=C0=DF =F2=E8=EF=EE=E3=F0=E0=F4=E8=FF = "ASD-PRINT" =20 =C2=E0=F8=E8 =F4=E8=F0=EC=E5=ED=ED=FB=E5 =CA=C0=D0=CC=C0=CD=CD=DB=C5 =CA=C0=CB=C5=CD=C4=C0=D0=C8 =F4. 70=F5100 =EC=EC, 4+4,=20 =E1=F3=EC=E0=E3=E0 300 =E3. =EC=E5=EB.,=20 =E3=EB=FF=ED=F6. =EB=E0=EC=E8=ED=E0=F6=E8=FF 32 =EC=EA=F0. (1+1),=20 =EA=F0=F3=E3=EB=E5=ED=E8=E5 =F3=E3=EB=EE=E2. =D1=EF=E5=F6=EF=F0=E5=E4=EB=EE=E6=E5=ED=E8=E5! 500 =FD=EA=E7. - 53$ 5000 =FD=EA=E7. - 179$=20 =F2=E5=EB=E5=F4=EE=ED: (095) 785-66-57 (=EC=ED=EE=E3=EE=EA=E0=ED=E0=EB=FC=ED=FB=E9) =20 e-mail: info@asd-print.ru =E2=E5=E1 =F1=E0=E9=F2: = www.asd-print.ru =20 ------=_NextPart_001_0217_01C4CD6D.0CBED9A0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
=CC=CE=D1=CA=CE=C2=D1=CA=C0=DF = =F2=E8=EF=EE=E3=F0=E0=F4=E8=FF=20  "ASD-PRINT"  

=C2=E0=F8=E8 = =F4=E8=F0=EC=E5=ED=ED=FB=E5
=CA=C0=D0=CC=C0=CD=CD=DB=C5=20 =CA=C0=CB=C5=CD=C4=C0=D0=C8

=F4. 70=F5100 =EC=EC, 4+4, =
=E1=F3=EC=E0=E3=E0 300 =E3. =EC=E5=EB.,=20
=E3=EB=FF=ED=F6. =EB=E0=EC=E8=ED=E0=F6=E8=FF 32 =EC=EA=F0. = (1+1),
=EA=F0=F3=E3=EB=E5=ED=E8=E5 =F3=E3=EB=EE=E2.

=D1=EF=E5=F6=EF=F0=E5=E4=EB=EE=E6=E5=ED=E8=E5!
500 = =FD=EA=E7. - 53$
5000 =FD=EA=E7. -=20 179$

=F2=E5=EB=E5=F4=EE=ED:
(095)=20 = 785-66-57
(=EC=ED=EE=E3=EE=EA=E0=ED=E0=EB=FC=ED=FB=E9)
<= /B>
e-mail: info@asd-print.ru  = ;     =E2=E5=E1=20 =F1=E0=E9=F2: www.asd-print.ru=20
------=_NextPart_001_0217_01C4CD6D.0CBED9A0-- ------=_NextPart_000_0216_01C4CD6D.0CBED9A0 Content-Type: image/jpeg; name="k1.jpg" Content-Transfer-Encoding: base64 Content-Location: http://wlastas.narod.ru/k1.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAMgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMDBgkAABJ6AAAuEgAAR8D/2wCEAAgGBgYGBggGBggMCAcIDA4KCAgKDhANDQ4NDRARDA4NDQ4M EQ8SExQTEg8YGBoaGBgjIiIiIycnJycnJycnJycBCQgICQoJCwkJCw4LDQsOEQ4ODg4REw0NDg0N ExgRDw8PDxEYFhcUFBQXFhoaGBgaGiEhICEhJycnJycnJycnJ//CABEIAZAAiAMBIgACEQEDEQH/ xAEGAAACAwEBAQEAAAAAAAAAAAAABgQFBwMIAgEBAAEFAQEAAAAAAAAAAAAAAAQAAQIDBQYHEAAC AgIBAgUDAwMEAwAAAAACAwEEAAUREgYQICETFDEiMzIVFkEjNUA0JQdCQxcRAAIBAgQCBQcIBwYF BQEAAAECAwARITESBEEiUWFxMhMggZGxQnIjEKHB0dIzFAVSYoKSsqM08OGiQ1OzQGODk9PCcyRk dBUSAAEDAgMGAwcDBAMAAAAAAAEAEQIhMRBBEiBRYXEiA4GRofCxwdEyQhNA4VJicoIjssJTEwEB AAICAQMEAwEBAQEAAAABEQAhMUFRYXGBECCRofCxwdHh8UD/2gAMAwEAAhEDEQAAAN/ASrV7Ic82 qfUP55fsLo+kDCVOK9RdfOl9TLbPrBllP6/kJp5trPBy69hngDsAJeZE3T5+1VkzN2qyq2ioW4sm dudPFBI+qy3cR7dP/Pv88Z2W/vx7eo4oBbEASwzsp0O1VerlpxvjHhyrPKLsF2/gc7pquzZG9HAa 2fn75lptvbj29QxgC2IAl56vONZmasS1YOIdcZSn35daAzzrzJ1/vK5dr0mFqZF+vNdF07ce3peS AWxAEvMdPoHfG3bSGtRi8ukkt9HqVPtble+YlvmT0Bib5fY7den1yk9D7ce3aAAFrACWDQba8zTc s0Og03oclHlKNXym3P1HJanYD2KYksGIfafnSJi16b25de0zwC1gBLP41Ln4pd52UnTUFV7DS8Fw TmZ67wNAR5rctZcUtpi9uWDLSuvLr24ABbEASwpN0mhyuizNi0bNZgXHbr3z7NhQLqyHH8tO0e01 dPTCTC5jN0jry69uAAWsAJItHqKjlG18i9taI+QL7ffzUfN7TQvwKzDLfVrR71iK9dMsP7+w6YQA kgjZxQbqBi7AlpBkMBltp56qZw9NnmO6mN6CPPDSn14y9Qjfv55pjvD08VBOronNWchbtwxZLLrm 4KtuvtmonBhr4dBXypl84VWvvKPfz21ZRqKTabnVa3UUCPRJxCM1xyfUUkB8vu/2GYS9wVGm1+ec 4yl836UuwiQgZTVz5rB4aRJU7AkamlQm/n+r1QtAzMkYxsmJ6eFYWMTp1WRyo7f8k9p1sOnO6NSt SYOhWsw+tSGdY9vqILOZpKVpmU72SSxCM7qIu9RU2h1miCsWybJ0shrkxa6iEpbu4UpYxFue4hMz 4X7MlMrEofgoXokglJzSjaCmZ3QVfETBjGpMmwj+SarbNevRC3+e2ShCdhN6QRVVRba0q0amoa41 kd4JgOtKrrMi6R8vNEo0XO4jzrX+rH+ydUlMUyLrFJo40s9+9ClpZp10sduJ2GQAksedPQflCu5p /Fv5evQvvOWKbu1xVXdR/CLY91BNaqW1tB16fRXrMAOgBJOwXe8oVi/+31jXflFHdUcR5HWN9qLW 2Z5ewK1P4WmiUtHuqa5uBAHcASTMo1TJZSs58D7gVifDj1gJ9/v10ZX+gI2r0aUC3rqyVG13FNck iADsAJJeSbBlqu7QbhSqJyr9PyWd99rV+aSfsqO9D6nNSekKwHbmZTbL6AB3AElhC0JGYqOkaLk9 N6/+1UeQG1655C3xrHVR1FMGNpE50WSc/VGhVarawB3AEkbKNsyKF4vKjOKZnXJp435sDQ1fZXml O2XMNJsy8rrKEH5kpLswAAk4AkiY/o3nam70NXK9MMTohhnxGG6wMa6J3lVi/s4331Od52aSx0N8 UCAOwAlmGG7zg7V1Os5b0pstavac3jL60xfnxn0hWNYp2OX6Wv2ka+2KzTaAAOwAlTefPTgzeYI3 qghDzLoerit83y/Qop4lN2ATY/K1YlKsswlUAJf/2gAIAQIAAQUBxVQSGaiowKqSw0KGfjrkB2jO YnmPD5XQMM90PZKMltYSPZIX4L/R4QiIxMyUXgiMR1zYKuTrGL/R4WnuPJs2yz2nJAmnJayTQ6QP lf6PB7oiF0WhXRsQI7lca1hgySwmOhf6PCegZvuMlwJSL1G2qRlGK46F/o8IricMNKkVp+UxrMYr B6/bX+jwmZgxaLJ9z+7WIoNhzkcyC/0eDK3WcVDEuiYwa0jBpb0jSfkRxGGwQyGROe7HEHE5zkzE QRQM9XgwhgoPDngRkZyS4hJf24WRxBZ/R0ckqqxgxriPP20Rj4iiz2oXIYyeD5/tVVAx/HrzxjGM IkqBQu6CMx6RJcSzpjgmkDI2TYyLCmjI/wB+XHGcYTOROInPTHRPVC5nAGYkhGcZ9h4MSZGM9eTE TnEZHpnVMzz5p+vM5z4RPqU+njGTkePPpHkL6eE/qyPp4c+Sf1ZHjMenhPGTxhZH08JnP/LqHPSY IRjImeI+ngWSOdMZ0jkSORMeSYiYmIyOMnpznJOPL05050xkDxkxz4//2gAIAQMAAQUBySzrnJKY yCnOqeZRHk6Oc44nqyFtnIrlPhP18OecPgMrHzjogRk4Acn6+CFqiOF4Brk2EA5ajrDmMn6+Htj7 cMAjbW4xZ9Q/1nJ+vhz9qRiC4wI/ue1k/Wfr4DI9UgRML7BHB5z05n6+AyHtFAxnT6GPGLWMR/Wf r4C70lkZ7sZLQmCsLnJMfFNc24dcwmK5yRpMMmJjBjqkVSWSEx4VQMltRxFFvvPaLAwh6pYXLScC 8Nfrx9yr512XLgkFZsIZOwYczcZGRj/UU+qv/e+JjJmZyIyIHpMyYS+YHnnPmGCuovbUsTUWuCc9 ogL19gExOe5ETAesqKZ6C6K0x0E0Qhzes4g4kPuHiSyYgFxx7f8AWCmMnks6IzpjOnPp5YKYHnIn 0jjghyA+7x/oI84f6siS4jjyr+vgv8RFxk+Ijzk+kZETOJ56GzzkeK5wv0zOQXOJP1Z9PERnjqiV yJYAlyoz6rS+Y8RmcmZzqLPvzpPOkuJ+vhJEOA2eWdQ4KXnkVWc/GPjxn1jp9BniJM5zqLmDmI8P /9oACAEBAAEFAfC7sKeuV/LO38/lnb+fyzt/P5Z2/n8s7fz+WdvzjO6NEph90aJZK7n0T2/Mr4LV n5u8nMZu/D4TRh+oiD5zUgr5dOuNe1a1gITXnpsz9YmYlZSS/J3Z678VMOEPKuWp1b7jqAUXvGqn 4zbOsmrZvsQDtjYeS44dP1xP4fJtdfOy7rrNL2N3SUEOmaurC1KqgG8hq6jZtOx8OG0p1j7A66j1 eCfxeTZu4399C7S9/dS0grW7ce3QTk7LYZ2x7yLm9pija6z7L/2L8U/i8ndn+fErtzP7Fdjja0hr nDHLD2VtDX2O4rte5Z16jK/s7MOf/TFfi8ncFMrXcKfgUa86tz2/tlb256JlurtgHxqyh12gB0DR SkTGV2PpGK/F5O4tlXXu0urWH/XCmYF+x5c9dHb19ZqDhmxvpo1f5VFi3vKBV3y5agKwkSV+Lyd2 IE+4O31f8qwoWLm1LFU2PtFaZ8O5r9uNqO5ax2dems6V1GDsdZe+0HSXuq/F5N5WN+/qa2UztLov OpY5HV0qynb97VPTdcFqyn5FfYGVKz2tsBitZGHQ6Tglfi8nc1u6va9u7FrGqSxkazTygNtV2NtW vQ6lV7j1aqR6Sx8nT7Xtejs7VXVanTKskGNPpsK/F5O4KxP7hodo1aj9sgtduBt1yncI17Xr26KY bLYFbpKs34ra2/3GYO1ty2Fzo6zAflK/F5NyFONlY7poKza7Rmyxd5A1b9R1+yupSpAX7ZGavtv+ 0AgEWzUs7NdzXLrtNqvxeTdUG29pXeIN+ULLVVNabYTWfBWGe327pfg1t7sDor0OzK9asbAQs3ZY LlG6GK/F5O4rJ1t2NSHzbrNRmrf8ipIHrL/wkfyhjhjO5acW9RT9yHPkXWri5K2KWsBX4/J3FTY3 ZKV9v7A6zGwoHodlq6FWyO/CQau2uVcKsAnXsr2uGnj4H5azaL1/j8m01jLN52y1dDKF3XX52WuV sqKLdqnlU/m5avDUjV32SxLRddpBYvYS2y9NWyNkI4HyMWDQntTQFiNNra2QhQy/tnR2XK7Y0SSb pNY/B0esCB7e04yrX00B8dOCpYf6Ww4a6bO7v8s3m4yjY3T4u7ncjLN9ulA3ubeRhd2dxDn8u3+I 7n3FiGdydwVmH3A1tS9f3FalPdG46Xd270Ir9574W6zYK2lHYRE1QSyDZY+xnWdZybDQ7gk/aI+M 6hnJFc5VXPubR5qz3EMPj5GqsVzGbAzg8xPZBc6TaTxVLYMTL71j3tbtHfIOwwwvoI2MpzxGvaUx RkM1dXrftwH3WrUEa+YLU0GQwrKYwl52Lz+zbWBmvfqkOMYQZqVS0Xce1ct1PaLa65cF3EmIdunG VHf2k5a3i7T7Fj3R7eepg0i9zEuNyxTnZo9Or3U9NUWRm2Gp10mX/aemzMFMTja5CKaD7rI7dt/N v6VlBiUOt2vcgh7as2VW12HBV14yWJVE522AhQ30xFO3bbB1telQnYZMErqK0BJcntsvjMsinL18 wu2COwy2kIgPdZR0b11rbyJg1ZlL6VOGToQJdTuBRNpCPsWwPnC5jPvxAj81m2NDh/5C684iyxhF mxeKcFypJquqfUTrVjaNQ0ijUHB19vx8Z9WvfgtPZThtKsqLdrXI1221uur074VoowlpWxQ9x/Bq S0yaXrE1L7GqCFEeqtkAViake1pmdfuR6qocLyX8RZBFsbtOxWs19iinuqexS20zZasLzA2Lg2W1 Fvb1avE5YUuRU0kFFjrhbIrSe1CJ7LbDtVtf9tM84Zc5zAZ8gCy5wzAYoapWVjR1sXa9fZtFCgmO lYTOXP8AcRETjSTxz6/9ff4TYB7iCrcZZeqtDLTLtgjngz68DbDXP90o2NjuGfZCOMSgohtz2So9 DHEin1kNRcs+IU9iplOkmIKDopPH9ra+wS+1darJ7U105PaOtmI7F0/M9k6mZHsPTAUdlaiMPtDW kv8A+eaTA/6/0oT/AALT8l2HpzhXYukVKlKQrxfutXXk+4NOvI7n0c5/INR0fv8Aqcjf6gpja6+c DY0WL/cdfnzqWAxbI8u+aa6J7ao5Y7dDBrWESiq0GD7Re+pMA3rJLBKde7ZUvbfWDqzX81hpOKxV 8ncf+PFE9Pxiz2CxVhtSa+zUKNftKlxabamV59iSq/dFpJImkM5py69d5O5SiNeNeCxdXrKavrtV ClgnHhBFGDsrPT81ciwA2NRSQQvUq9nX+TuQYLX9Exi5aJrCGjtz678RkTnVlYfciVEIaN76sMQd WNUXVQ8nc3+PGGBiyfMocJTZZLbHrnGRmnjqf7EMTQ9pK67c1YEuj5O6PXXt6yxMgOWWymrz4Rxk cZoeJ2Vbn2nBPJEXvap02KHk7ngZoT18qlhhuX9Go8Y+mmPo2KYgJITy1zJdvn7mn8ncXPwuHRMH Cp7kZ1UZGY8KOqtXZR2ysQdpBqEz809Rr2UmWdtR06Tyb3/aMqmZfG9e4ZWFiOkp6KqWaizWYxdF fTc1wmDB6JT6xsPcazt2YnTeTdc/DEwiZfAB3KU+8DYyWckFg4LtXeOtSLAPN0gF5X6Czacrf23A jpfJ3Xd+DrU9wU3STq9pO89idfJwUjzydaEjRXXo6tHcFP3HXBtUNVaGva2lcisaFYq1Xk3blIq7 XR/Lp1W3KLrmsffgtFsQwdPs1maLRtRs6kUq1CCHV9aDs1hgVW/nq1MBGv8AJ3YaF6vXbmzOPgLC h6s9c5mJlhjjNjWXlnZaWxjbKfcG9d6NfZNFnQkBanyd/wAc6YUjxo9kOb3Wft7Puz0mfbicCvHM 1ywKz+qh+6yx/dluiWmvFstb5O+x6tR09NdLuGau0na1tlRfr3o6jwdc106qlSBmziJsEY2VaYiR l2GXrHbIwGj8nesHOqrL+wqyoKrYKlaA6fcFBdV2ruE0qtQtmWuRasGnY07ZOqjeOxq0NXdjtz/D eTaVJu1J0WyTajt+7Jx23e616ne02Hr53VJutvoNCNq2QVdRlGm6xNhe0ZsXUdpYjX0x19L/AEf/ 2gAIAQICBj8BQlImu5VlL0+SpKXp8kQ8qD13WUpRJcDwf4rqhEjg4T78R24R1yjCJNQAHtU5laoD RKR0l6kb/SqJ1UDXsQBwyTfk1tfT1/8AHkjEdudtw+eEeQxHd1CIMYmT8Is/kv8AS0Y/+khfJ4j5 qBJPdfORccGFvJEgdM4+DxUIR+kReZGQf34R5DERIaEKCO/T9xZRGvTEU0x6QBuog5MYSuD1GJyl ouF+Ptkkm9U3cNO70/5Cy+km/oo8hjOO8FR75EtYaQFGEPnVDtfjoxe0YOcmXa7sG0927fSJC7cF LzHgu2P7n59SjyGJJAd3su2IHp7vysgI+TAeqgT06SKnxVTQbqqN7S/7KPIY9zufkMzCv4xQ+dUO 13BI6Y6+kv1fxdaa9uL1Gbc0e12pylEG5Lu1tIsPBN9WpwOeSDGP0nfYO/io8hiSOmt3Wl3K0RLS 0mJNq5KqpZRZqRJqOfzUeQxcy6dyeBFN9/ctUWEt/FZPmugxfitJlAAjSWclk27Cqo6eqpg5TY12 DV1pUSMhXy2H0sN5oqmh+C+oDmujq5Jh6ocj6IhPwXVXSHZVR4B1o7sSQQXNojggIfO602NiUAcj 6FAyGXmtOSeJ0tmuppehVYl5Vp9xGSkdMhqiHOQ/pTdvq0nTJvtXFdVTZASeJC4YhlGPdd4DV43A REQ2oOTvdOmbi5siCwYXq3LCqZUTvX9I36IbQGOoGyfZclXwojBDZvj+2xVUVsGQA2HV1fa//9oA CAEDAgY/AdqhOw5LKtQrL6dPOnvTmcfXA46WdddT/EfEo/Y26h87ocE5vk+Bxcmpr+yPSHOZqU7P x+D5rpambe1U4vGvhnsxL1b4OtBIY0zd0Wlu3koxN4+5Ao7AD5IveKqmFV1SA4Zo7EImN/uNh4Ba 4MAS1st63lOzHgjwqdmNpUs3DMrp8tx5quGos5FjuR2Gll5LNMQ4VXVAfgs8eluZTFvgtDgEquDB XA54nTvzstVKV8moiLXI9vFPQhAsyJzfJS1ZkM3Eth4prw3L/VP6xUbuaj3IlzF+VcNMi3Blq3ph /Ie8IErxWpqemP5YSYxLAbytUr+SdqJx7EI9uBz8QtbnUzvmmlXgnhT3JntSuS06gdMrAVK6+lw4 4rSi1AjKABEs1pzbCqMkZdtgJUKBmXY04MqISfgwvzQIJNWbPnhQsnNVZWVtqmeDKi9rrlsDAtg6 eVH2Rj4oA2tsnljN+e0ZNuwYLRLNMdhwtIjVWVMl1vTetcKvkq40yTgY2+CuB47FCyrZOCSEDcSt 1bqoTypV/wCVApE/bfYZMmuh1ypatk+o+abH/9oACAEBAQY/Afk8bezCJMhfEnsAuT5q/rP5cv2K /rP5cn2K/rP5cn2K/rP5cn2K/rP5cn2K/rP5cn2KaKTdaXQ6XUxyXBGY7laJN0Ub9FopQfQUpIYt 2DI50qNEguT1la7/AMx+quRgfKkjc3SFEWMdGpdZ+c/KHnK7dTiPFNiexBdvmpNpt5EbeRw+JuIi WBZreJZLi3KlsM/k/ETi8G0U7mUdOjuL53IFSb/e3l3EEf41owLJqexi1MeJZxgBUu43sjQ7huaL bd9mY46WY2N+LWFh24VCeiRP4hRq4zpWOZAPk7v/AKf+0lO6IWWMapCBgoyu3RRdFUvayOwvoP6S jK/bX/8AR3eO1jJlkaQ4y+HmAWzxsCSa3biZ5N28E8k+8YgRxXzK4YnG3ZlUMmw23izTMybdpcbL HbxJ5AeRcTyg90Z3o7ZJFXn28W6lVbeJFEC0kigDEFj8wNPu7W3G+mTcIjjuwQm8IK9BPzCpWAWI zX8V1uXYH2dblm09QqP3l9fyx+6PV5O7hLaIlCPM44KIk6emmX8v223h2DPpV95J4azEYcosS3np p0g/CTxMF3O2BunPfRLERmptaoYNR8TeHx5F6IkusS/tG7eip9si2bcMmuS/sJc6LdbYmvw6M5Rj cxKTYnp0igUj0MuI15/u4+qmbeb155T3/DQnH3ntSwCKVtWTOwHXktC0C3BGGpr59vyp7o9Xk/m2 zuFfewLFExNhr8JdK3/WyrYvt2i0JCiNBNIsXhaAQ3fHSebspdrA5kWGJIDLwbSxkJF+AwAoSNhG AF8aU2UKuAAJzsOih3t22X+ml/4jWmALAt9PhxrYec5/PTvI2LjHj6aljNyko1Lb02+a1ba36YHp w+mviNojA0ljf2jpx6flT3R6vJ3f/T/20rwFYy3sTqscsLljlSiYfiZyeeRu4LYcoPet14VqlbUe vIdnCjDIpV2XkUjja49VNy6S3gbuID9Fj4ctv2hetUzCMZXNbeXatdkQXYdPe41tiFNjKvrvXgqL xwn0txPmyofInuj1eTursIoh4euVsvu1wHSa8LYQ/iZs/EI5b8CWamn3Ut3bGy4+a5rQUsPaN8aX Ut9IDLxscQKMfjRybVSfDEgIK3z5ly8xrJM9JZRc3tfvOWNHcSJphx0DJ5OvHIGiNvEkLWz7z/vU 8JOTWv25GrfInuj1eT+EWJJNwLc8uCpdAc7E3tUcEu88eVsPCh7gIxz6MKvkoIu2XTemV7KbENjk RgfMKC7GMT5Emx0ZsdPC+DUJbiHeotzEvNYXtay3uL9FF96nw4W5Iz7TG3N2Ud7uwzJq0Rwpxv0+ ioYxto4NuzBWcYuAcNWrAYdlNOra1B0ufp8+dReIba9IU2NrnhcUiM1mkJVB0kGxt2Unuj1eTvGO fw7D/pJUbEZLIfmtWpzaNeZichYW+mj4oOmZfF28mm51i5syjAi98KRDJrJICrkov6KR9k5TwVXw 3XqvdvOc6Xbbr4W9Cg6LWDAjVcdBtmK0KBpVtTN0YXBHmvU0tvhwm0o49dvNUXi2YvF4MnvR4A+d SDW0DDVaxC6gNTCwtiycCa24UkEytqHLius4HVj6KT3R6vJ3PhhtWhcQMO4uZ6a28p+9TWHwvcOO ocDX4dReOI4m/eb6hS7Z30ot2jst2JNrqpJ42qXc+E0gACRrpsBbN8TbLDOo5V2vhjSAkpUN14Zr Ue9Zy0gfUWbE4Z381MgGoSpyXy/SWp4ttJeOYfEw83HI2Pz1uIHzjCyp0n/La3mK1t5BGslhrsza LDD2gfoNQFcPjNqOqwxYgi2pbnzGk90erydxEk3hxLo0gDHuKcz11uvy2ecsd5Cfw+ok2lAI0i+V PpGMSl3XjZc7dlLuJ49czYqrYBfeONGCfewwq3+RAh5upmZgbVDtNxplAOkk4qQ5wXSeFCbbJaKX nA/R4Ef26K2srZxqFP7B0/8Appd28jR8oDpGBzacjfhhTzpEF0RsGlc3axGOJwxrbagvOOUOStu6 3DMdVbcWuWkddWTDm6da4dIsaT3R6vJXakhPxWjw3YXHd04+daXczTvJKh1Lo5FBwPWeFM6DAt48 V8rHMem4rbwObfjFZYm4E4Mosbi9umh4ocXGfiD6SQKEOyRzGD35HZrHK6rlWyjlxc65JUvkGwA+ mpdlArsjKugqbBCH1k+e1eFyy2yst/Sw5a8T8yl5F5jCMjbGxtW21iNiTya8w2GK4G5twqN1zZzq Go2NpDmAwAtnljSe6PJ2u8mdVk21+8f2hh21aENK3oHz1E0sQjC38JhfHpF620OoCaALJHI2IVw9 7HowApngjZNo/wAXwidSCRjeTwyo7pPTV5xEhcW1uNR6wq+fjUcpSXcmZii2wysLBcOnChJ+acqg 6l2ynzjxnGfYK8HbvHHEDgI+A6Oqm2/O8pUN4htpsfX3TlUDgK0KFSVw1jpIZgerIiknUIFDElwb O1mbBsCCKT3R5O6aFtLLpOPUi0yS4EXDZG2nE2NLLN3AcF6BwFLuGsVmknjC2GlWjIZRj0ob0+3R lLOpUY3sTlTbKT/KlZx1Xwt5qX8w3a6twVLwx/6akXwH6TUG3ASTcuRjJdootVzpjjHeKgYk/wB1 NHvdJdrCF0RU8MnJuW1xfMVrkxbQYXGYunNhfLG4BraMsrRozBGAyN+nEVt1WQaGuWiHe77XY8pw 84pPdHkzGNnViEt4d790DhhQ+HoaRiqnrGZwv00GOMZ7r2I9dbrathIoG4jPElOR/wDA3zUmli0f KyScGU4GxHXUfii0Evx9PSc7fvV03zqaUXLxhWAAuboSnqbGo5IfvFNwKO5IwJHKctRxPnvetqeT ShBOpdRHMACDpNr5Zitq6MuhCGYEc2ZyOPowpPdHkl4x3gguSLY3A688KjigJkkIJawsV1WwbouB WrfukCadPhLzYdHACo5YyZNqTeKT9JO7Ih67G1eI8hbSSPD4YH6a2W6TNG0ddr3+mgZMGt21PtHP I66WP6ri1/pp9vptPq0S48oN7Z9FQhhcAXiItbTqONx1k51Axty5XTVYk271xa/nrbRrMBHoXVD7 RvdrgWy6TfCk7B5JlaTw9syJrI7xMZYgL0Z14MUmhfbVBck9JbprlJZhjZ73qbZaR4iXaA9DcPTl TJFI0WJDAWz89BJZefNmN3c+c5ClQI0szDljHRxLHIVBNum0o8bKV9kaGOk+i1eJNe13mIGbPYvc 1HFCirHHcSE30hDbSmBFzn6aD6UZAQVc99RxUC3HtpXZwUUaQAx6LW02tnSjoHklJBdTmKu20uen xJL/AMdfAg0ftN9Jq4XHLM08820DSSHU51uLnpsrAVqj2mk+/J9qviwav23Hps1WWE2ta3iSWsTf ItV121jiO+/EWPtUsUUQVFyAJ+uu785rlW3/AArzPkoq8TBAfZCg+sGgEnt+wn2a8SXdcoyXQlz/ AIaYbYm64aQgY9vdoeJLpe2N41HrWuTcf4I/s1/U/wAuP7Ff1P8ALj+zVvxOh/cj+laUS7jUh4iO Phn7NFtpvrz/AKyR3Hm01HOm41Na7nQn1VhPb9hPs1huv5cf2aV3nEqjONkQA9V0UGot7ELCQYqf ZYYMvmNMpyNvXRO3OjDnkOQHXetxNtwWlh8GIyhbMQSSzW4XpmS6zmJcRg2JqBnknjl8PnMH3h5j YN1WrYg6/uj9997n7fyYisKULQi0ZWIag33b34ULn2bVhlVvk7JpB6j9NftCiInKXztRnjndZDgz BjcjorRK7HVm9ze/bRfUQxNs7YUrtiXXjjV6wFc1X4LWkjhVnOm39hS3YKgGJPDzmt3r5o4gdJ6i DjWrprCnB4Tv/ChpQ2Wvh2GtSHUvT9fyPORe3Kv01HUfxl1IeZQbn5q9uVugCw9LVaPaH97+6rrA APPTadh4o9rQWv6jRMkTRXOWf1U7suHdVuAJxFx02q+7lLxopCRynkEl+XQOJ09Nfm0p4i2PUrdN AH01c1L/AO+38CUp/wCYPUav018IgN/mIMl8/wBFeDtAfDz1Ktv8TVq3D+Ykk1pjz6/otQMhK383 roR7VWkJNhnahsJ7RyFDIpzBANjleguvnzwz6vTS7ObcJGWuFabu3AuBfhe1qtJEp0qY1YDSQb31 EjvHtqSPbsOdCWV72w44ca/MmOnnvqNze55cPTTJ0AGrGnC/6p/hWkubfEHqavwsHePeIz90UJNz zvwT2R9dBUGnoHVQv8WU8DkOs0DCdUluYjh7oofmG+kUORqEL+kAkcahTZIDNBI2qMA27uKX4cvb W3mSLTPAGDAtmrriuA6bU0sjWJxNhl5zRW1yea3V0noqaKKVUij0yzQyWBdwSoMWGNgRTPLg2kqn acMamhBtqkViOwGh0EWProeKTcjUsa52/WPCpFb/AFWtbostKq5+IDj2NUusWcdPC9ajieFcvNK3 o/sK8JDa/eP0mtCxNKUxEYudRHGS3s0m+3HxIxyyG3c1ZeGnCx85pN/syqroIknf2uIbT+qL51NJ NPqN8C+FxwtlhQEYtf2zaw/Z40NvHj7UrcSeuk1YD2mzpd1eZ5pCTLKy8pS2DAnG4407ZsCrDTkV OGFJvY1uoudPEWPmrUrg6vvG4scwi+mpBaxSTS3RfSpIHZe1IT/qD1GlD3VlydcDbo7KlkicOo+6 jx1kXy4C4FCfcgKz/wCXcFhbJSuYqRZodMm4AJaQY48Ev20+4Op/zDcYPHbiO6L8Fp5NyAVfmaZF LaCT93YDC9bn8xsV2srAiDAXdRpxH6RPCmaeM378sgGFjgFX++pDuIn8NQ2gnUFZlFwoa1jdr3pp G7zG/p+QbVmJc4C50rbM382FC58PUWBY5Y3bE8fRUkZXBMQBnzdWedailnOK3x09nXUpOfjN/CtK P+YPUfl0yqD0HjUTxXnVTeNH5h2aaTcbmEQhBzpGuvnODEAnDPzVufzFIWaB3siqtyn/ADNA4nqy o7iMyLFfS/e0GRs3KHBTwqbfbcrLtCR8HHWyx31FOHmqeBwBuCqKLYqwLcxXrGk3rVIbCvhjHpo3 HmNWsBfC1vmr4gVdWAaEhrHiHFYam6eFSOL/AH7Z+6lD3x6j8lhRLGvFXsU/SKYsuPCvy+fbL4Ek waKSJb6QVt8THjY41utrJEkW38MxwOh1X14DWueq+Jobfbzg7bdExRRsOYMxC6g3RSflyTJO0Rbx JorlDc3AUm1AVjTA8LZV1caXw2LFRpxULhwvbM/JL/8Apf8Agjq3QwPycxx6KEYuIs3t0CrYWrDO lkeFZ/BUxbaJu7qvqZ3tnia8XeRPDs2zgjNyHK2LcOUHGoo4J/EVCdLLcXscGFY5nIVldjwrSvMw z6AaYzaTgTd8Re4pjqXE8oFwMujtoMtsb3viPQb0dEdybnVkOqwBo4WEkzsPQq/RVjiDWbDsP11q eSa/vL9K0dLy4i3eX7NfeTfvL9ireJOP2l+xQPi7g2yGtfsUW8Se5/WT7FavE3B7WT7FYNN+8v2K MYlnS+bqy6uzFDX325/fT/x1cTbn99P/AB1fxtz++n/jqxl3FveT/wAdAkzSW4M4t/hVaWGFQkaC yqMgPIZZtyoK961zbtKg1z7kDL2X45ezRtur2/Uk+zXifieW+m+h887d2gPxGeXI/wBmtI3Iv7r/ AGaa045Bds8Ba/RRlSdDGM2vhX9VF++v11f8TFb31+utUbBx0qb+rytC4eMwjZuIWxY2/dtSh0sC VEijPSpv89P46Mtzgq83KNJUG9ug408psJIxq09JFqcjuBkcddzl6KVMeYXbp81+yvhEEKNWOF8L /TaoZe9A/KSeAa5GXWDWs2aCVtEq42DcbdTY0JYsYZuZb8D7XziiijAZefjTNCbN1dINvXUcr95h zdow8m/QxI/7b0vZWVZVdRxxQ5VeUM04PpU45+anT7mSPusxGOogDDtphdT4fLY+xiSqkfs/PU6S I2kgTW4lCLOMeKtTflO6b4i88Mp9ocG89XA5lbRp6O3stXiX5LWt2cahb3/428kX4vb/AAPVjhwv lRVbHTf09Vcy5cR89qjXiRqP0fLga28ga77fUoJx1Bsw3VbCoZbqsq8Fv7Vm0nz+ivxC/eqPjAZl R7XaBWfJf5jxqKPo1H0sT9PkjqkHzqwPzGrA6lHz0ALXOdE6eXpBtnU3Qtk9HkMo4WP0Vq44UsxH wWYpf5rEeej4HxdtLzJqPcyuh6gMqiIy5reZiPJWxt8UZ+61B8FHBTft+mtSryenKliKgHjYEVNJ +m7H5/kx+SRemNiP2SDWVx19WGBo7eRbgtcjp1AZ1L+XzPgfu3PR7Jv66iRxZl1Aj9o+SnH4oy91 6s2oZDFbejCmIzwAHzHpqee3Msb83XbDyD2VEpyKsDbHhRXgLpYjj10jKtgCA4zx7akfVbTYxE5X yt58qhmObA/MxH0eTHq/1Rbt0tRWJytsQDegLX4knI9Ix7KnIIHiaUC+8cfIvW2PS2n97lp425ce 9586J021XBb1GjqwjTE9fRW2fp1/xt5Mdv8AWW9/datQS+k2IDYAftVbwbfrcMezCoFUfeSa7di/ Way+TkGlf0m+ijrOo5ihuIr3QqVHZj9FMw6AfSOHoqy5CzKfmtTRnDhW1HRr/wBxvJTm0nxBbDVw PCjcoynjYrl0dFWMTR/qq2rDsN620Ry0MzA4YkgcOyjgAOvGgxAfiBwpIS4TUMAcK6L+ujhhao1Z b8ulx2G3zXpgLg2vpPV206gAFczW204jn/jbycP0voONX1NzAYH+3XTSyS2Vb34dnqrayk4vCOzA m9Ek+ar0GviMqfb7mTXZbp09d6wNR7pRbEq/Rj6qDodSvfSeu3G9jRUCysMa2wTu89v+43kpL4bS apQllzxV8fmoCR/Aw5tYPeAA9i9TLG4nR78egAccvqrZhz8aBQt8LMLarX7DhVhYCtIxpfFf4rf5 KYsL5aqj/M/Dlh1Eh5AxZiBgMLBVuauNzuYV4q4EnophG/jJddJIxIOOWFqbbP8Adu2Bbg2GN6Qt jGQf7GoEXIa/9xj5KtMWUF7BlNrHSxx9FGdR429jQuJYxYyqrW0svFgpzrxYY2uMGRlax4YjqpZo 7xqyqfCwwYCzWxHGjoTV14fXQk/DMbG+H91JJLC8cgOL6CR24Y4VLtyhcOhTQ6946bC+eedCGeEf DudakG5sLLgemnXdho9Z+ERjcdHKaO4UWPHrIwJHopLOvjR8sqyG1wcFK2HmqHwzdeY37WJPkh52 0qJOUfpHQ401EFF/Bje7HoYC/wA4r8ZAb3+8tlkMax0+g17Pz1blv0Vw9P118SWNT0Flq0iXYe3G NLdHeW1L4Mk7xA3tIbEe6bn1UZhqZpDoYsC4OFszhenmnDbg2IO30a1Y5Wktl5q27JCdup1WhbNe dunHyYR/9lP4JKuceqn2bLylX+GxvqBUAi5t0Gg8MZTay/cuHYnK+hrnMV3n/fNXu3VzGsr+eraO F6vpHprUmBHEUgHj7lYzhFdyvovavw88KQyAd0qb/Mag3rZy6uFsmK5ebyYbED/5KZ+49HRZitam wIyK0+w3dn1WB6eVLK69BGmngcBgMUcXsynJhXdDW4WqN41CJ7YNahBGZAMWsD661qgVRkABwrSc NPRW4lA5VFyeyp984wLXA6hh6q2irlZ7ed2PkwhBidwo9KSCmjduokdWFEeKLjOkmhbuHm6xxFDb SMUdQpjcZo1rEY5jpo7TeLoY4hs1ZTky145EbXNkhuSze7YVC34e0+6wEbnBLYcx897VFsN1Gkvj LcPFe4z9kk9FbzcxLFEu2yjkBJOF8SGW3RlQRIDFLujYsEZkVVOLYDjwFS7fw7JFYKwHetquznhf orbDo8QeiRvJMQxbMDpwKkHzGmH4SbTf2EZhbouL0z/hJ79cbfVRb8LOP2G+qhPDt5Wsb6NDY281 LHu9vJDOATFK8ZDIQb27DRD/AJdLO6HSXCOwNuKkcKXbt+WyDb/oSQtpHpFSGP8AL5BN3fEETXt2 2NCXdfl5EvtGSHHt5hWkbWU7eIYNpwJP1V4UMGi/tPZVHbx9FQ7RTq8MYt0sTqY+cn/hP//aAAgB AgMBPxDLGRsgg8cjk+C8V29sA32qhnT6HrHYm2CVXH+mDZ3cxme2l8OTvMNz9rgAOAJ8/WUsxw3E +IWYYoj50ywingRjzgikg37NdO0mat2pCutaIVHL6YAvt6DXA7v6fx3j6iDwOYPNfDWuPXFYAKu0 5WjrXKPZw0GaPI5Qw/DrAuHZQ04MblEwaIgXVcYkU9c/jvH1JaHBZwdhsu5P3g5KILG1py+bk2AX WA3Bit3+s7FSaHsYgPMq1N13zUxSQCwhbtfxM/jvH1WbsJ5HZ+MFXfhGrstrbjXHnIivy+a7E7l9 80sJnbhntJLhAaT3x2xiAUZKciNX/M/jvH1lyUoKt7wPQdU57XlK9NdK8cH/ALiEiq4HXD8GPzSb qIf384GqbJvY6HnQHPrn8d4+qmoodV4GVMTysTQ2ofi8yYxt0ITiUdJzOssxBXNV0BB2xcU2KGxw zCMxRNCaNmlTn85/HePq2jC0jvHCkLfJ3MXuFMHRUGLF6pf6/rFKVDyG1PD1gJYXWgm71z0c/jvH 1V3nIHN7wPLVKdPDMUaXsgf2N4gi3yV37a1+MSihqp1+DDm1U9QJQ3gAOAB8fSJur0YfRt1N41Qg Z1/3C7X+4H298d6gwwq0onGAS7y6uEPT1zkaNRJeNb2fnB4FEK/9/GHzY4BK07wIRbzd84ggV29K 1+MKTLz9MP1gMO8lybHkOUwZDADXnwzfoDlU49sviL7XjmfwykKJqDz+c7k0/pOSjXGvf6A4iolw p5PnNex9cWNtaBN+m/PGM2OByzWv/wBw2pTbVVXVxhaFoTT0Pt3i6koU4f8AHDIQpvHh75+ufGBl IGmnHAn7po9zIEBcs4A+U6/GTAyobeMHmmG7iIJv/wAZTVatr64AC0sSs/7kzg2J5yTMKoOjGadc vWdyBp78mBNiNvR7HIPeWHcBR8j6zWaBo9seiCdD23ExcGNvUO1cnWcAHACADxiVdI3FxJXnFPL9 L1irt+ovsmQybeMWu8hpxgbGHB9Rz8ZNnEzhOcTKCrHivecD2+odmPb/AHOMHPh1kjrfnOD2PrqT GIerkxQ5ZjNO7rEjPOcD2+rOiZwq81mA3BFeO8ITkBnzkSfHOcHsfVRk1i+H6zxD85dxN6c6zXw+ cUyiSPpl7uYfVhvhcBbZ8Z5P0/8Ac8j+pguHXi3KK2dNOHBPH1rBZiPB8YODtjAkiTrAkRUt+N44 u3v84cHt9ZuFKRyrRZ6lgXRvnXOCl5LZNGCq/X//2gAIAQMDAT8QxxQDWC8BnLBiQdbcgBCL8zId B9d4kU8fXZoFQ749MdZQKThyGGy3jzgF5uLPn2yJoHz/AMfT9x+tqEhQDvdmUGzdsD+HBisgeA+5 f9HAgd6c3HcRIQds59jBufuP1QJlTN73+H7xFQ1F23y8YDVBCNUeejAEPpQ88T+zg7hfR5V5YSNn BnJ7v1gcEVPNh/zFMOV5fE1P3lTjNOVOX09sa1EJeXycs5HT85z8dZye79UrFIP1iyL5P7zQsN9b gCsmwCsphAQPy/GX8hnJ7v1rcEil1Xof3iaIDYvVHr75bqQNeMDdCHGnPnzgTHXQcmNrl2POcnu/ VZRpFnScvcwgo3tGwODyw08jq+HAJLTDFFikB8aObnFLyGcnu/UAksQCHufLjePy4HCNCETr9ORR 78BDWpvNlwwBkc1l9c5YJt3i1v0TdQMpC+NXGLuco/6wzCNVZ7UHHYT3LP6zoF9t4x76W9YepBqV /wAxyKPtkbMM5atbdeTNNgYrt0paNafzxnGrE/oXR+2NCqxJOeZiHUED4Hp3moFHepyPzmw9Z041 ZY33r2OIvXgSXkXnBB8ZOBjd5dKvoGsQpWmvwyVe21H51he0j+cDzLkvtkNM7SqNM5e+d5m4ZbrY z314yEUhe0O5mhbEsiGIlFbP+/ONXZwg4aRlYoVew8Z+cA5ebkiSqVxhqC+i4vaG0eXswVBDnqPb kBeNxAaNXoxIGm7ZvGtDsNFM6XqnrgpXdc3xPB24qWroPAdZxGDTny5dWNPwBlkGu3IAu+9x6eMY fC6ye6Nay8s5u9jjSivLvFeR85o8M23tgIgQyvnDXH1BEcrTLWoPxgNOed4Y2besJEbH9YSL7vb7 Kberjiy56BGfjLiu4Tv01mvgCL6OBALZ39R1vAW+UOgy1V7biacIol2N+pkp9v4cEU8M+sA05/rE 7tmnzrK5xQuAAEkxJ6G71nA9vqZpM3MNRT1cCDC4/Rep3iKKJS/Dpyjjb4wIB6fVFhfDnE4c18+u C5X4yilo1740TC5Hj1yKuzhyemAgHI0+/wBdc4bZEUedyZ4D94KkP9xpXb0MKV6gSfPrgiLY8mz6 7xq8YS2q0j/eJlh4jka2EgOxTzx68Yd0WKtGuDnkwMYiQDXTL4lx5fqd/pt7x0BkxGWj05vkHQp0 8eM86SLWzGA7+v8A/9oACAEBAwE/EPpSTtKR4Or2Z/8ARgh0xegxenxenxCAAqwO1xdXwShEOw46 EQUCEpQOGAWvoAjC+rlchuK+B3+Pu8PUhAfK/wBGLnBvjvJo3We50HE4dctBdCic+15CrhGzj/MV v3nfDwZJsH86CLZXgk9XjDEvVwGnbdToFwYXVn4wH5HACQbE6c5lme6D9pUjxM+T/cvw0Zp2jhXl zlf8L5D8KGcm8BWsK2C9lSkb5wD9UaMQNTcmihLxfQvEjCT2oUUpiMdeSIjoM3FEZPGmIdeyMh3X sx2hqjFVHtuQMpLw3pxw7L5cnefwPh9rBo3tZ06CtV98sHbstEBOBs+c2Sb4gqaErSb6zsPP6ZA8 fh8OkhOOJ1cIbOjH9xCfMaF+MAWgKdjd1ae+K/BWz0i41xxm3FJaoaRvB5wDsYpDoCj5TEVuI5/G +H2kOABQui0cvdlQ/ZvA6WQBsdus2UlULyILKO944aCwQNwAoFZDyK1URxrg/GGibqbJqcvBoIU1 VFRT3vOB8G20j3XB1UCRuzfXDFkboCyetvX59c7riXP43w+00HYmICTIdAATeBqr6YDh54/Oh+XR hd5cK0ToaHtigaKAzw3zpigNRCiByeKPGBrQpZr0DbmoIeI7woBEynFZp4NX6yKKBazhkT0PnC/A f19P53w+3VbVICvs6OjBUmDifHTHblFBsVR30D4MGrp2lk2HjvNZqklMjOYscTKgKraIbdkHmYqK Apu8FxEHpMTlsNQCyt+ou8LhqHzAmlU67MuIWHOiqfDgQqwC+xkz+V8PtQDZvE7lBA0fnxc/AVAb FG9h5wZ1DToJsvbUyWJedIvRKNVmsZiWolCY6oLQ98BivZVW8E3ItyNxM2jbLyQJ65PEyQLqNoSJ 8GcooCd0oLev7ZqzBCRCmngnyysJNQREQIW94HVQxsp07c+m+M/lfD7UPWHG8bIVcWqASiVHR+cO bX8RRfXp+sPUbcbyWgFcCeZk6yMeIQh99cZMpEqKya+sjjeDkMZQ+RQ2L+C5AZbjZF+JU9si07v3 g6E6pyVJB2KBnWtT2BCzJztjftvCVahqDILe/HP4Xw+31gkLjgujwO+8pjFIhqKwFPbHLlQ0A6sO 3R8uJdsSnUaxOnX5x3I43q9axyd4GGwYgukTN+Lh7FJU1DXlz2wBuyFsJS9UschjcKNsag2Wp1gT xBliDK+/0sU4HWCDvF5kk8aypygmhEdi/wCGfwvh9s6aRfJlp5dY0ihoLbVS1PbCXfUQEiTy1s8Y Zg96MLYRKaBXOB66eiTbxzoMblPDuMRgUBG4gY51Fa3vnChN1XbT+Xrl2sEJCGjsB1lYSaMxFfwG NEFGyp5CJBt9zDDKNRS2bCvUP1n8J4fakFNYOnF3YDJDf8EtNU3XOR2HTZLZeNg8ZHR5OkiCrbTX ziqglL92z4NMlpQcFBwfuYFk9A1bSdlB1l8P2Buv3o5wdE5dIbDSFTziTR7dTVqE+XKEICa08fkn Xz1iFFM5cwTIJVUBn8B4PtGLwAuEqHdO0xp3dACx5dod6zdlncBQVc9P/wBwAWxysLj5w6xUSQno QFFEXeL99qcNtPyS/wBY2mOJRfek4t1x0c0EGVRFReoO700gdIoEAGtCenWL3fxAVAK1PANd5Jxo Ag3QDlEa7xmrShUVMXRp9TP4Dwfac0ZTRdPzPKH+4ToWvZrYR7kd4MpS02D/AL7Z65MmFueCGal9 8nOKggRc63MmyB1tAtvhGsJCcKu+00dz1x5yUBEWoNRdcvXmFjRXJU0pYE/7nC3EEAFsqX+Yw9Cz 1ZQ9k7RDJpGSvgqPEqGpy5/AeD7dEm8cPiAea4W0AHLDRsNHjN+vPBubP4+cJ+f6diO5Z1gvaCXK dIQF9NYghR2dOfhdn0ycXojw4c+xYGn5jjblMBmjmvROcYK7BoD5NgwBckeiAGmnZh7HFcDunkM/ Z1n8R4PtjnXwNSpw0MEBKDkHoXSyu7MAZSGyT3YDoL+d4uQuvfwXRejcKMzAgCZvdgHUw/IjXwBP TDKslDTzeDDflAaK0X9HO5J6EK49D537YjkbQCn2Gxwx10RQKHSq2uPhiN9oaw7gcwP5rwfb5OEb VV9WuOWhey+8x9S50CxpKvWjvrGcrraqK6cFVlpwAKBpKGImHaQ0Ax8sDxZgqmOiA1DRyYn9NBKc 9VvWEk7wBVDx/hoy4Ing4moKMPKXF4ov0gLXmcxzldrGWcdaNO+riO8gPwT7R2niU/ZsxlpFVKl8 uzj4hEkXgC7fGPJkCeQOO8WIUI05gl9DIrRlG1R7fjJ9IE7QtdC/OFCii0FEEhXB0gAnC3zRc/35 LhtL6ufz/wDTGKS88v5f/wAtcG6HK8Ae7nhakEe7MqAayUvxhoLxF7k0w5poXIxhWsAXkS1+MKSJ 6W/vKG9cxKpeMs361GFxKmu7hNgTlMc2gRAvZx4GqbllOZxxiRXmuKgD+PeUB/T78gfuOMOcuqhY 9w5zk1C/g4YgnAb/ACg/rDQ8QB2wUaF8Zd7DuGr1sYYB6u6UtXeFsLl8hK/4x2mCpkfpHPPtJms7 uhwn/TWEAgFdB3gS0snk0Yp8fXGUK5w1zEMXqPFcBsrKB+3/ADOA7G5ZxcOUoDCcJHZhKqFRkOtr jbMUiTWtjjhIDUwmnm4zRt6zhQHPOcG4zhVwuiYDftigS43s7GMWwLAHlgGFCLUEsSX9YrlrY9sk pp6ZDpsez/oynND1GdGzqAiegyzbW/jL7i0+e2FvorHrgyb20gQni+82wF0/yB/WWxvApP6eUpnS qelhjS3VUg+M0W0BJKdOn+sC8CU1CGhIO9mWxEEv9P2O2+MVd6BpyV/TNsMPlkHkfOTvlv056LYd QHwR2PxhOafKPLwP2wQAKxqXlS/qZdyh016mwLhASNaA46jymBFOAyvyJ8GUFqL8ihMUxfoRQHmF 2Zsjkji3O3uy6Ejss0bthvEK61tB8S7PRk93eJeI6D2waLg4AYmbvliXCA+/DjYJTp7wAIK68wzl QGPrk+RGDhF4Xq9uDGFu/P5O395KIImBR6cB6uEIuyajl0dYC7oyeAujnN1IueEELl4DL7ZDJVuh t22yRGp4FpbgIfRwpCVWT0ZJtbLQTzdw4R/ywdFEwyUcpdWXQbRihB5SE3946rVp+mL5fMC2PAf3 h7hO4HSj3jekmFLNR6498yznC/z0zaS2i9vWvXG6aHd2A1dYLaeV+U8vfoZKtYgFnBUrmehj8EJ6 TdJ0NzR7ZEV7O4g6OAXq8TKwGWiPlZt9CZ2/KaUctbW9dZYcLY3wV4uA6SIRQemzEqsqJRzgBz1M ml2E0Ske8/OUcYG1Jb0GS5VhcO6sN70uGELCDG7H/wAGMcAJmeKZeeU6Nw3tlLYcix7GPrJI3LM0 aqpMNa8KRUI74byiABByshpr6vpgStlntCQ2jyvPWBmAXDj1vJWh9d4JcdKhIq74/C9uKJuCJFLu DhJkSBTDquAOjE5U+OcX+HGLavyjG4K/miRqgNRAYjBbQoUATtcNWMQVX6NYaFUyu3flxAvI+2aU waXF6DkdB9HnHGBCJI21pG8d5ubasBSTbTpfAyk/oZgBjXZdmr24zuNQ8fwA2WLXXePaw5HgpnnF zMF/obiHhwB185p51Dy4rqk1gWHZEKN85zwAIB8PGOQ7YqOwFSnhzdrcIIPauL+hB73j5ccXBFNb 5xLDAoQHnBAt06lCoh6ususrekaN1D0wRc8Is6bctduGHBoDDb0tSt5y48UaoZslV/WV3PISBNS7 f7yDEQseXFqvadYDSKA+ELMYFXjpzLuY7W4IoeFXk24prt4xrXoMovRD8J/uEmfjF0XphBBV+U6z 34wyAuIHAHjE32DB8Y7Y0i2AlrXXevGExVxjXOhKDxrI83wjU1BPP4ywdpeA8rlzpII2r4wWjSA4 GtveR5UgbCVg7lms5JKRABFBJ+WJQIqNqHAzuzWJgu+KbAAB3iCpFvZvny8enwEcESF8GvwcQX22 S/bgm1ZrSP8A5wOMMWpJxr/VYJsEEiTfXd5xaHyzDIGcAoPbO75Ve3DYnQLHEID4MA48+OiRk3iX 5DF8V9mKpIZy9Gz94a9x8B0fYDHa4emgD6Z+9RefBc5HHosbnO1CfSM0GzrB3ReJG/nDFQsSW/nF CuWvYivswAqiIgeLckgivAlgcjoXV4x1N2Qfmvuq9BsojSvJ+TGYhNi1GoPn41jZYZCkRch+hhEG Q2iAGzu7584URU2tQfHab64qpWqGQKfgXPplldoLGNj9h5xhCfYu2Zzhfky/A24uSj7Tw4RMPRWR /YPzigxV42oTlyeH/uNAss4RSNeBgDBxHFF/s+2TTWQ8mKWLWkmg13kSvsxmJTHZzkHEeXUghY9W mGIl6mwNHsTT945hDX2gDpvGc5SoSogjURKWTw84eEhm8uSei404Zks8Iu7enTMQvJg0Brt1sTzc Rxo4gbT0856yP6B9oL2z7v8AngRErSvLh9JihvKcIE8OtmEJFS6GR1+TeEDadHTD3aMQx14cq8T3 ypQu3abwFmWTyIHn9DDmX22ECmzevOzkB8H4APKF1wHjC+zc1OILewfHWbKvKt+31xKwH8NTI3j4 UNHtMoNg9IXQp/uNeAAkdV47pgCNqE0al11twT/MQ1c053ieeXvS/wDeCyLoU1zD34xEiQG5x6FY MlBAhsS1pyGuZMA8mgKrBufb7WkRMagxZ8zBXWbga8G4dAU7AHs8875zgjxAHB17eMevPw65nC3b mhtcENb7yhBpTxf6MzkCfQBiqHdxXs7OjAHXExoZcDQpaCbFmLV94pD16ev2lGCrgBfa3xy44KI8 TnPQbesA0Cr0F4NvLbvzjeVwvg8x5qcGcpg99HxiWnDW3bjDVJoOCzjJajA8TqtO+5gZAEdAUTwR wG+pxOFK6h/KYLsBRtGDv7VKpHZzHH8Y0IOJ229ipAM2oBXDVYGxvxx6gvTKmJbPHpjzg4O/GNqL NJkR8tsktekuS8Yg8pAVIAJ3hBGEgmw/uDrBvbvfGLBNVr7aSxrwER6TvBVJ5FrzsbAkcaUUu7Fb 5nbdyy3LGwpZB/LjUUOA9bw1t98AlmCF/bniJkjTUiWO3NwAhpvLNHY8+7GmCxM1oXsxZmzR5x1+ QPtRSKN7c3mx1vNjFvUCh2rzXeG/UhmEcbYfb+ssVwgaBjXXMwtO50wTxecFwDQ2rEY4WN0IC86c GtVyhs4fGB3AgQs64zTXboqm5ycKzRO1W3YeDa/+4YkB5CYkrQKeQn9/bpSOtVkN9emEOspe43Xl zqGXzJUwhpbT0G/xj6qFfBCddYQ24IA5vRkDnNFcA70adTxjF4r7cd1+MIpPzjbSpCkHVl5HPnJn Ns0ihg0TuYeQZfMMWSjceq/bSAsvoO0jcWDkGr2Aadd4EgwJ6plq0u3EZ3XcAbW908sRAngSb9Hc yk1LCFb6YK8SwlHkhfGPQC9DBI3JMErTvZ9WWYr1rpB2diMXKileojaST/zNkYCGx4dsY+tL7/6v tGy9otniUiJh2SDAQOGY19uMuQJSvQE30x/l9DKJsA1DHA5ZBC/F4R0FIGJ6Jw3XNYtpqKxrAFkN 4UC2uLBsaCIjwIuzIaEoS048Fe+MrzFa9Di66I8fGQ5qBUitBe/rheTgAm6Q6RW/bIefLvBfAbVX o85qWhZOKRd3Xq4DM03trSbr1mDSm9nZ+cl8A77ZJo8itp2yYKqT7z+mAMh/CuNqmO0KX0LxtMAI vZ1cXnPcYfYQKXHKOxujvGSuv0CAPsQtMJ3Dp7gYIXYu59rDKW0ykXL2Ax4Emnn30P6nEe7EeKGS SmvJvLqMjv8A9cShQolGPVcj2vCpcUwKwuvc3h9PipxwZdqlM5DMnvfCGTRUrAEounJEybEPPl+2 hkBOe9MJzz+M0lCjbzz6YAbNVRL3u4sAtU0Kk8qv/MitEIbDY/J04ewbTy/ePVCRWnzZ+cfHgM3+ 4X0xEqIGJpwB3hMgLcQ1hA07OIL34MXKt4dbQuFgEoj+Nv7XQKCdFR063lQCs6xsH4364MGTReJl vCEHHF+Hj1yGDtl6QVsIO8DxpfYEV2M/7lpUl3TOk63x85YJ2oKjWL04Gc4WQAUso3UPflHvML1N gZE5ZzztVe9lg/8ADDhFQ4jw+2Ej0zTyH4H9ojgKvivehcCIuh0lwMafXGXZdBPi4lm5q/8AfkiZ LaKswMF48zYgvcd8mPtUT7Q0D4ZsGpAOV1wNec6FQfQmhpPnEDB2gk7Rr65K8IaJ9RdJwwaxeFTC w8OdMYOHH0tQ9VP/AOT/2Q== ------=_NextPart_000_0216_01C4CD6D.0CBED9A0-- From w3c-dist-auth-request@w3.org Mon Nov 22 12:00:08 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17252 for ; Mon, 22 Nov 2004 12:00:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CWHVf-0002TU-Ix for w3c-dist-auth-dist@listhub.w3.org; Mon, 22 Nov 2004 16:57:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CWHVe-0002Sk-Tj for w3c-dist-auth@listhub.w3.org; Mon, 22 Nov 2004 16:57:50 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CWHVY-00033d-Kg for w3c-dist-auth@w3.org; Mon, 22 Nov 2004 16:57:44 +0000 Received: (qmail 7115 invoked by uid 65534); 22 Nov 2004 16:57:17 -0000 Received: from p50825237.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.82.55) by mail.gmx.net (mp001) with SMTP; 22 Nov 2004 17:57:17 +0100 X-Authenticated: #1915285 Message-ID: <41A21A69.9010809@gmx.de> Date: Mon, 22 Nov 2004 17:57:13 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200411121819.iACIJQP13963@cats-mx1.ucsc.edu> <41950A47.2020400@gmx.de> In-Reply-To: <41950A47.2020400@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comment on UNBIND language in BIND specification X-Archived-At: http://www.w3.org/mid/41A21A69.9010809@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8951 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 22 Nov 2004 16:57:51 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Jim Whitehead wrote: > >> Julian, >> >> >>> I expanded the replacement further to: >>> >>> The REBIND method removes a binding to a resource from the collection >>> identified by the Request-URI, and adds a binding to that resource >>> into another collection. The request body specifies the segment to >>> be removed and the new binding to be created (href element). It is >>> effectively an atomic form of a MOVE request. >> >> >> >> I like this language, though I suggest the following tweak for the second >> sentence to fix the fact that we're not removing a segment, we're >> removing a >> binding: >> >> The request body specifies the binding to be removed (segment) and the >> new >> binding to be created (href). > > > Good catch. I'll make that change. > > Best regards, Julian OK, the current edits are at (issues list: ) -- www.webdav.org seems to be down right now, so I can't update it. Again, as far as I can tell, there are no issues left that haven't been discussed here on the mailing list before. Note that I assume that if an issue is raised and discussed here without any feedback from the original poster, I can assume it's resolved. I therefore plan to submit this version as draft 08 which then should get it's working group last call. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Nov 24 04:03:42 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01031 for ; Wed, 24 Nov 2004 04:03:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CWt1g-0006yw-Su for w3c-dist-auth-dist@listhub.w3.org; Wed, 24 Nov 2004 09:01:24 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CWt1g-0006yM-5v for w3c-dist-auth@listhub.w3.org; Wed, 24 Nov 2004 09:01:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CWt1f-0002nL-NV for w3c-dist-auth@w3.org; Wed, 24 Nov 2004 09:01:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAO91Na4002074; Wed, 24 Nov 2004 01:01:23 -0800 Date: Wed, 24 Nov 2004 01:01:23 -0800 Message-Id: <200411240901.iAO91Na4002074@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/200411240901.iAO91Na4002074@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8952 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 24 Nov 2004 09:01:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 ------- Additional Comments From julian.reschke@greenbytes.de 2004-11-24 01:01 ------- (mailing list CC test) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:05:47 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08524 for ; Sat, 27 Nov 2004 06:05:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0MY-0008TD-Eo for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:03:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0MY-0008Sj-95 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:03:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0MY-0001Ms-1i for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:03:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARB3WU2014789; Sat, 27 Nov 2004 03:03:32 -0800 Date: Sat, 27 Nov 2004 03:03:32 -0800 Message-Id: <200411271103.iARB3WU2014789@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200411271103.iARB3WU2014789@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8955 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:03:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org Summary|extend production |Section 9.1: extend | |production ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:05:47 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08522 for ; Sat, 27 Nov 2004 06:05:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0M9-0008Kw-90 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:03:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0M9-0008KN-33 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:03:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0M2-00060N-JN for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:03:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARB38Up014773; Sat, 27 Nov 2004 03:03:08 -0800 Date: Sat, 27 Nov 2004 03:03:08 -0800 Message-Id: <200411271103.iARB38Up014773@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 7] Example for PROPFIND/allprop missing X-Archived-At: http://www.w3.org/mid/200411271103.iARB38Up014773@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8954 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:03:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=7 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:06:26 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08592 for ; Sat, 27 Nov 2004 06:06:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0On-0001xK-EF for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:05:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0On-0001wp-8Z for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:05:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0Og-0006t8-N5 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:05:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARB5q6N014815; Sat, 27 Nov 2004 03:05:52 -0800 Date: Sat, 27 Nov 2004 03:05:52 -0800 Message-Id: <200411271105.iARB5q6N014815@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/200411271105.iARB5q6N014815@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8956 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:05:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:07:48 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08696 for ; Sat, 27 Nov 2004 06:07:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0Q8-0002Rf-Ml for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:07:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0Q8-0002Qv-FP for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:07:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0Q1-0007N2-V9 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:07:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARB7Fu4014840; Sat, 27 Nov 2004 03:07:15 -0800 Date: Sat, 27 Nov 2004 03:07:15 -0800 Message-Id: <200411271107.iARB7Fu4014840@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200411271107.iARB7Fu4014840@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8957 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:07:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:09:25 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08870 for ; Sat, 27 Nov 2004 06:09:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0Rf-00038e-Hw for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:08:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0Rf-000385-C2 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:08:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0RY-0007jG-Rb for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:08:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARB8oSF014866; Sat, 27 Nov 2004 03:08:50 -0800 Date: Sat, 27 Nov 2004 03:08:50 -0800 Message-Id: <200411271108.iARB8oSF014866@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/200411271108.iARB8oSF014866@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8958 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:08:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:10:59 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08956 for ; Sat, 27 Nov 2004 06:10:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0TC-0003z6-Ja for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:10:26 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0TC-0003yc-Du for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:10:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0TC-0003mS-5E for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:10:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBAP22014894; Sat, 27 Nov 2004 03:10:25 -0800 Date: Sat, 27 Nov 2004 03:10:25 -0800 Message-Id: <200411271110.iARBAP22014894@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200411271110.iARBAP22014894@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8959 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:10:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:11:58 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09047 for ; Sat, 27 Nov 2004 06:11:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0U9-0004Lk-JO for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:11:25 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0U9-0004LE-DG for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:11:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0U9-0004AQ-0A for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:11:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBBO3d014918; Sat, 27 Nov 2004 03:11:24 -0800 Date: Sat, 27 Nov 2004 03:11:24 -0800 Message-Id: <200411271111.iARBBO3d014918@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 13] new ETag requirements X-Archived-At: http://www.w3.org/mid/200411271111.iARBBO3d014918@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8960 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:11:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:13:37 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09155 for ; Sat, 27 Nov 2004 06:13:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0Vm-00058X-GX for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:13:06 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0Vm-000583-B4 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:13:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0Vm-0004pN-3I for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:13:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBD5Ko014943; Sat, 27 Nov 2004 03:13:05 -0800 Date: Sat, 27 Nov 2004 03:13:05 -0800 Message-Id: <200411271113.iARBD5Ko014943@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 14] new requirements on ETags vs property changes X-Archived-At: http://www.w3.org/mid/200411271113.iARBD5Ko014943@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8961 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:13:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:14:55 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09227 for ; Sat, 27 Nov 2004 06:14:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0Wt-0005b9-LH for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:14:15 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0Wt-0005aR-FQ for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:14:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0Wt-0005Ae-50 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:14:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBEEnF014967; Sat, 27 Nov 2004 03:14:14 -0800 Date: Sat, 27 Nov 2004 03:14:14 -0800 Message-Id: <200411271114.iARBEEnF014967@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 15] DAV:error description inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200411271114.iARBEEnF014967@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8962 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:14:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:18:22 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09495 for ; Sat, 27 Nov 2004 06:18:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0aI-0007Jy-Qj for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:17:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0aI-0007JT-Ky for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:17:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0aC-0001t6-58 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:17:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBHjdV014996; Sat, 27 Nov 2004 03:17:45 -0800 Date: Sat, 27 Nov 2004 03:17:45 -0800 Message-Id: <200411271117.iARBHjdV014996@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 16] Trailing slash required in collection names? X-Archived-At: http://www.w3.org/mid/200411271117.iARBHjdV014996@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8963 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:17:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:20:10 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09625 for ; Sat, 27 Nov 2004 06:20:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0c4-000815-M7 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:19:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0c4-00080M-G9 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:19:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0c3-00073A-Tv for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:19:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBJZRX015020; Sat, 27 Nov 2004 03:19:35 -0800 Date: Sat, 27 Nov 2004 03:19:35 -0800 Message-Id: <200411271119.iARBJZRX015020@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/200411271119.iARBJZRX015020@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8964 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:19:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=17 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:22:20 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09825 for ; Sat, 27 Nov 2004 06:22:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0eD-0000ar-Qo for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:21:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0eD-0000aN-Kt for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:21:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0e7-0002vi-58 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:21:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBLnNZ015044; Sat, 27 Nov 2004 03:21:49 -0800 Date: Sat, 27 Nov 2004 03:21:49 -0800 Message-Id: <200411271121.iARBLnNZ015044@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 18] no record of consensus for force-authenticate X-Archived-At: http://www.w3.org/mid/200411271121.iARBLnNZ015044@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8965 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:21:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:23:03 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10009 for ; Sat, 27 Nov 2004 06:23:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0ev-0000qt-89 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:22:33 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0ev-0000qL-26 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:22:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0eu-0007m3-R2 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:22:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBMWeI015069; Sat, 27 Nov 2004 03:22:32 -0800 Date: Sat, 27 Nov 2004 03:22:32 -0800 Message-Id: <200411271122.iARBMWeI015069@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200411271122.iARBMWeI015069@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8966 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:22:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:24:04 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10092 for ; Sat, 27 Nov 2004 06:24:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0fs-0001Ln-4q for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:23:32 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0fr-0001LD-V0 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:23:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0fr-000868-O5 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:23:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBNVK4015093; Sat, 27 Nov 2004 03:23:31 -0800 Date: Sat, 27 Nov 2004 03:23:31 -0800 Message-Id: <200411271123.iARBNVK4015093@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 20] lock token example X-Archived-At: http://www.w3.org/mid/200411271123.iARBNVK4015093@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8967 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:23:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:25:29 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10196 for ; Sat, 27 Nov 2004 06:25:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0hC-0001nW-EJ for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:24:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0hC-0001mr-7k for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:24:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0h5-0003rS-MQ for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:24:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBOrIa015117; Sat, 27 Nov 2004 03:24:53 -0800 Date: Sat, 27 Nov 2004 03:24:53 -0800 Message-Id: <200411271124.iARBOrIa015117@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 21] XML element definitions X-Archived-At: http://www.w3.org/mid/200411271124.iARBOrIa015117@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8968 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:24:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=21 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:28:03 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10404 for ; Sat, 27 Nov 2004 06:28:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0jk-0002zy-EU for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:27:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0jk-0002zU-8g for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:27:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0jd-0004dS-Ox for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:27:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBRV7j015140; Sat, 27 Nov 2004 03:27:31 -0800 Date: Sat, 27 Nov 2004 03:27:31 -0800 Message-Id: <200411271127.iARBRV7j015140@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 22] New: attributes on properties X-Archived-At: http://www.w3.org/mid/200411271127.iARBRV7j015140@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8969 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:27:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=22 Summary: attributes on properties Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 04. Data Model for Resource Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Section 4.5: "Attributes on the property name element may convey information about the property, but are not considered part of the value." As far as I can tell, we haven't reached consensus on this. The latest discussion I'm aware of is at . ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:29:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10525 for ; Sat, 27 Nov 2004 06:29:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0lR-0003Oe-UW for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:29:17 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0lR-0003Ni-OP for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:29:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0lR-0001sm-Ey for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:29:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBTHiB015160; Sat, 27 Nov 2004 03:29:17 -0800 Date: Sat, 27 Nov 2004 03:29:17 -0800 Message-Id: <200411271129.iARBTHiB015160@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] New: lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200411271129.iARBTHiB015160@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8970 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:29:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 Summary: lock discovery vs shared locks Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Section 6.3: "Finally, the lockdiscovery property can be queried using PROPFIND and the token can be discovered that way. Each lock has only one unique lock token." - the token can only be discovered this way if there aren't multiple tokens (due to shared locks) - clarify "has only one" by "has exactly one" ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:31:23 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10657 for ; Sat, 27 Nov 2004 06:31:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0mv-0004Nn-Ux for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:30:49 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0mv-0004NJ-PW for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:30:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0mv-0002M9-HY for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:30:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBUn5x015176; Sat, 27 Nov 2004 03:30:49 -0800 Date: Sat, 27 Nov 2004 03:30:49 -0800 Message-Id: <200411271130.iARBUn5x015176@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 24] New: lost-update vs collections X-Archived-At: http://www.w3.org/mid/200411271130.iARBUn5x015176@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8971 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:30:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=24 Summary: lost-update vs collections Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 07. Write Lock AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Section 7.4, p2 "The lost-update problem is not an issue for collections because MKCOL can only be used to create a collection, not to overwrite an existing collection. In order to immediately lock a collection upon creation, clients may attempt to pipeline the MKCOL and LOCK requests together." There's no guarantee that this will be atomically, thus in the best case, it just makes a race condition less likely. As you can't rely on this to always succeed, I'd recommend not to say anything at all. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:32:28 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10731 for ; Sat, 27 Nov 2004 06:32:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0o1-0004tG-Q4 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:31:57 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0o1-0004sg-KI for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:31:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0o1-0002fL-71 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:31:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBVuFc015192; Sat, 27 Nov 2004 03:31:56 -0800 Date: Sat, 27 Nov 2004 03:31:56 -0800 Message-Id: <200411271131.iARBVuFc015192@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] New: lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200411271131.iARBVuFc015192@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8972 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:31:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 Summary: lock to unmapped URL Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 07. Write Lock AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 7.4, p3 "A lock request to an unmapped URL should result in the creation of a resource that is locked. A subsequent PUT request with the correct lock token should normally succeed, and provides the content, content-type, content-language and other information as appropriate." If this is supposed to be normative text, it should use "SHOULD" instead of "should" (same problem with many places where text was added). Besides, what is "should normally succeed" supposed to mean? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:33:44 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10789 for ; Sat, 27 Nov 2004 06:33:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0pC-0005Ln-Ow for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:33:10 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0pC-0005LF-Im for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:33:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0pC-0003F9-Bo for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:33:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBX9LG015213; Sat, 27 Nov 2004 03:33:09 -0800 Date: Sat, 27 Nov 2004 03:33:09 -0800 Message-Id: <200411271133.iARBX9LG015213@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200411271133.iARBX9LG015213@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8973 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:33:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 ------- Additional Comments From julian.reschke@greenbytes.de 2004-11-27 03:33 ------- Update -06: Still says "should normally succeed". Recommend leaving this out; it just behaves like any other empty resource. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:36:33 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10992 for ; Sat, 27 Nov 2004 06:36:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0rl-0006lD-Q1 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:35:49 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0rl-0006kb-K7 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:35:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0rl-0004NS-D6 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:35:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBZnX1015229; Sat, 27 Nov 2004 03:35:49 -0800 Date: Sat, 27 Nov 2004 03:35:49 -0800 Message-Id: <200411271135.iARBZnX1015229@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 26] New: URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/200411271135.iARBZnX1015229@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8974 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:35:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26 Summary: URL syntax in PROPFIND Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org "Clients expect the fully-qualified URLs of members of a collection to have a common prefix which is the fully-qualified URL of the parent collection itself." If this is meant to define a normative requirement on server behaviour, it should be worded accordingly. "URLs in a PROPFIND response body MAY be represented as fully-qualified URLs, in which case they must all contain the full parent collection URL (scheme, host, port, and absolute path). Alternatively, these URLs MAY be absolute paths (not containing scheme, host or port), but in this case they must all still contain the full parent collection path." I'd strongly suggest to remove all of this and to clearly state using the RFC2396(bis) productions what is allowed. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:37:30 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11130 for ; Sat, 27 Nov 2004 06:37:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0ss-00079D-Vv for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:36:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0ss-00078i-OY for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:36:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0sm-0007lO-8S for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:36:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBawkd015245; Sat, 27 Nov 2004 03:36:58 -0800 Date: Sat, 27 Nov 2004 03:36:58 -0800 Message-Id: <200411271136.iARBawkd015245@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 27] New: COPY vs live properties X-Archived-At: http://www.w3.org/mid/200411271136.iARBawkd015245@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8975 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:36:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=27 Summary: COPY vs live properties Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: critical Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.9.2, Copy for properties "If a property cannot be copied live, then its value MUST be duplicated, octet-for-octet, in an identically named, dead property on the destination resource." No! That would be a desaster. Make this "SHOULD NOT". Otherwise clients will see the dead property (such as DAV:checked-in) and make wrong assumptions about the resource. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:40:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11365 for ; Sat, 27 Nov 2004 06:40:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0w6-0000cZ-UC for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:40:18 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0w6-0000c5-OY for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:40:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY0w6-0005vl-Ek for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:40:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBeIUh015262; Sat, 27 Nov 2004 03:40:18 -0800 Date: Sat, 27 Nov 2004 03:40:18 -0800 Message-Id: <200411271140.iARBeIUh015262@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] New: MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200411271140.iARBeIUh015262@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8976 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:40:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 Summary: MOVE vs live properties Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.10.1 "Live properties described in this document MUST be moved along with the resource, such that the resource has identically behaving live properties at the destination resource, but not necessarily with the same values. If the live properties will not work the same way at the destination, the server MUST fail the request (the client can perform COPY then DELETE if it wants a MOVE to work that badly). This can mean that the server removes a live property if that's the most appropriate behavior for that live property at the destination." The second sentence implies that the MOVE must fail if the live properties can't be moved as well, while the last sentence says that the server may remove the live properties. Update -05: this now reads: "This can mean that the server reports the live property as "Not Found" if that's the most appropriate behavior for that live property at the destination, as long as the live property is still supported with the same semantics." I'm not sure I understand what that means. The contradiction is still there. "A MOVE can be a rename operation, so it's not appropriate to reset live properties which are set at resource creation. For example, the creationdate property value SHOULD remain the same." So can a MOVE be something else then a rename operation? If yes, how does the second sentence then applies? If it doesn't apply always, and the client won't know, why are we mentioning it? Update -06: this has been reworded again, but I still think it's misleading. MOVE may or may not create a new resource (as RFC2518 explicitly allows COPY/DELETE semantics). When it does, the creationdate will change. When it doesn't, it won't. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:43:38 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11551 for ; Sat, 27 Nov 2004 06:43:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0yk-0001bR-T7 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:43:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0yk-0001at-NM for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:43:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0ye-0001Xx-7W for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:42:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBh2v8015279; Sat, 27 Nov 2004 03:43:02 -0800 Date: Sat, 27 Nov 2004 03:43:02 -0800 Message-Id: <200411271143.iARBh2v8015279@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 29] New: refreshing locks X-Archived-At: http://www.w3.org/mid/200411271143.iARBh2v8015279@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8977 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:43:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=29 Summary: refreshing locks Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.11.1, refreshing LOCKs "A lock is refreshed by sending a new LOCK request to the resource which is the root of the lock. A LOCK request to refresh a lock must specify which lock to refresh by using the Lock-Token header with a single lock token (only one lock may be refreshed at a time). This request does not contain a body, but it may contain a Timeout header." Replace by "A lock is refreshed by applying a LOCK request to the URL which is the root of the lock. This request must specify which lock to refresh by using the Lock-Token header with a single lock token (only one lock may be refreshed at a time) and does not contain a body, but it may contain a Timeout header." ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:45:17 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11656 for ; Sat, 27 Nov 2004 06:45:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY10Q-00026r-GR for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:44:46 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY10Q-00026I-9L for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:44:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY10Q-0007R2-0K for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:44:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBijIj015295; Sat, 27 Nov 2004 03:44:45 -0800 Date: Sat, 27 Nov 2004 03:44:45 -0800 Message-Id: <200411271144.iARBijIj015295@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 30] New: incorrect XML in example X-Archived-At: http://www.w3.org/mid/200411271144.iARBijIj015295@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8978 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:44:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=30 Summary: incorrect XML in example Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.11.7 Fix the XML response by replacing http://example.com/workspace/webdav /proposal.doc by something like http://example.com/workspace/webdav/proposal.doc< /D:href> (similar changes required throughout) ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:51:11 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08523 for ; Sat, 27 Nov 2004 06:05:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY0Lu-0008Hf-SJ for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:02:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY0Lu-0008H3-7d for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:02:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY0Ln-0005vc-Iu for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:02:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARB2qZe014757; Sat, 27 Nov 2004 03:02:52 -0800 Date: Sat, 27 Nov 2004 03:02:52 -0800 Message-Id: <200411271102.iARB2qZe014757@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 6] Collection Lock vs MOVE with Overwrite X-Archived-At: http://www.w3.org/mid/200411271102.iARB2qZe014757@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8953 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:02:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=6 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sat Nov 27 06:51:17 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11978 for ; Sat, 27 Nov 2004 06:51:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY165-0004GH-1M for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:50:37 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY164-0004Fn-Rw for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:50:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY164-0000hQ-Ea for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:50:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBoZuD015366; Sat, 27 Nov 2004 03:50:35 -0800 Date: Sat, 27 Nov 2004 03:50:35 -0800 Message-Id: <200411271150.iARBoZuD015366@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 32] New: DAV:displayname handling X-Archived-At: http://www.w3.org/mid/200411271150.iARBoZuD015366@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8979 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:50:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=32 Summary: DAV:displayname handling Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 14.2, displayname "It MAY be attempted to be set in remote COPY operation." I'd say: it MUST NOT. "This property is live and MAY be protected." What's the use case for it being protected? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:52:12 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12091 for ; Sat, 27 Nov 2004 06:52:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY176-0004Tt-2y for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:51:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY175-0004TN-TM for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:51:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY16z-00046I-6y for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:51:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBpd9w015382; Sat, 27 Nov 2004 03:51:39 -0800 Date: Sat, 27 Nov 2004 03:51:39 -0800 Message-Id: <200411271151.iARBpd9w015382@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 33] New: Terminology in properties section X-Archived-At: http://www.w3.org/mid/200411271151.iARBpd9w015382@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8980 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:51:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=33 Summary: Terminology in properties section Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Uses the term "remote COPY operation" and "cross-server copy". I think we need to define what this means. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:55:32 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12372 for ; Sat, 27 Nov 2004 06:55:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1AJ-0005RG-6F for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:54:59 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1AJ-0005Qm-0N for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:54:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY1AI-00022E-Pg for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:54:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARBswrW015403; Sat, 27 Nov 2004 03:54:58 -0800 Date: Sat, 27 Nov 2004 03:54:58 -0800 Message-Id: <200411271154.iARBswrW015403@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 33] Terminology in properties section X-Archived-At: http://www.w3.org/mid/200411271154.iARBswrW015403@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8981 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:54:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=33 ------- Additional Comments From julian.reschke@greenbytes.de 2004-11-27 03:54 ------- I think discussions of "remote COPY" (such as in 14.5) belong into the *definitions* of properties. It may make sense to have a non-normative discussion about servers that do support that in some place, but the property definitions definitively aren't the right place for that. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 06:57:30 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12482 for ; Sat, 27 Nov 2004 06:57:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1CC-0006G6-M5 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 11:56:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1CC-0006FX-G0 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 11:56:56 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY1C5-0005Tg-NR for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 11:56:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARButLv015419; Sat, 27 Nov 2004 03:56:55 -0800 Date: Sat, 27 Nov 2004 03:56:55 -0800 Message-Id: <200411271156.iARButLv015419@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 34] New: property "URI" X-Archived-At: http://www.w3.org/mid/200411271156.iARButLv015419@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8982 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 11:56:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=34 Summary: property "URI" Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 18. Internationalization Considerations AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org "It is only in the case where the set of properties is not known ahead of time that an application need display a property name URI to a user" There is no such thing as a "property name URI", unless we define it. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:00:55 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12687 for ; Sat, 27 Nov 2004 07:00:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1FY-0007Xj-3y for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:00:24 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1FX-0007XD-U6 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:00:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY1FX-0003iy-Mk for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:00:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARC0Ndg015436; Sat, 27 Nov 2004 04:00:23 -0800 Date: Sat, 27 Nov 2004 04:00:23 -0800 Message-Id: <200411271200.iARC0Ndg015436@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 35] New: RFC2606 compliance X-Archived-At: http://www.w3.org/mid/200411271200.iARC0Ndg015436@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8983 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:00:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=35 Summary: RFC2606 compliance Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: minor Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Make sure the draft doesn't use host names outside the set reserved by RFC2606. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:02:21 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12834 for ; Sat, 27 Nov 2004 07:02:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1Go-0007ve-7N for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:01:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1Go-0007v0-1H for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:01:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY1Gn-00044x-L8 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:01:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARC1fo6015462; Sat, 27 Nov 2004 04:01:41 -0800 Date: Sat, 27 Nov 2004 04:01:41 -0800 Message-Id: <200411271201.iARC1fo6015462@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 36] New: Appendix numbering X-Archived-At: http://www.w3.org/mid/200411271201.iARC1fo6015462@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8984 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:01:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=36 Summary: Appendix numbering Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: minor Priority: P2 Component: Appendix B. Appendices AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Each appendix should have it's own section number (character). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:04:58 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13008 for ; Sat, 27 Nov 2004 07:04:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1JC-0000Id-9H for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:04:10 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1JC-0000I9-3N for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:04:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY1JB-0004rR-SO for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:04:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARC49Ep015672; Sat, 27 Nov 2004 04:04:09 -0800 Date: Sat, 27 Nov 2004 04:04:09 -0800 Message-Id: <200411271204.iARC49Ep015672@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 37] New: Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200411271204.iARC49Ep015672@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8985 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:04:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 Summary: Sentence lost in introduction Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: minor Priority: P2 Component: 01. Introduction AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Draft -04: "WebDAV employs the property mechanism to store information about the current state of the resource. For example, when a lock is taken out on a resource, a lock information property describes the current state of the lock. Section 13.28 defines the properties used within the WebDAV specification." The sentence with the broken reference was removed. Why not keep it and just fix the reference? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:06:17 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13106 for ; Sat, 27 Nov 2004 07:06:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1Kg-0000wE-ST for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:05:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1Kg-0000vj-MU for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:05:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY1Kf-0005Hl-HP for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:05:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARC5eOp015692; Sat, 27 Nov 2004 04:05:40 -0800 Date: Sat, 27 Nov 2004 04:05:40 -0800 Message-Id: <200411271205.iARC5eOp015692@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 38] New: RFC2396bis update X-Archived-At: http://www.w3.org/mid/200411271205.iARC5eOp015692@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8986 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:05:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=38 Summary: RFC2396bis update Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org At some point, the spec needs to do the transition from RFC2396 to RFC2396bis (which has been approved in Septemer 2004). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:07:24 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13197 for ; Sat, 27 Nov 2004 07:07:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1Ll-0001CR-Ic for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:06:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1Ll-0001Bx-Cl for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:06:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY1Le-0007pJ-Sk for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:06:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARC6mkf015708; Sat, 27 Nov 2004 04:06:48 -0800 Date: Sat, 27 Nov 2004 04:06:48 -0800 Message-Id: <200411271206.iARC6mkf015708@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 39] New: Syntax of property names in text content X-Archived-At: http://www.w3.org/mid/200411271206.iARC6mkf015708@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8987 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:06:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=39 Summary: Syntax of property names in text content Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org I think we should try to use a consistent syntax when referring to DAV: properties. Currently we have a mix between "foo" and "DAV:foo". ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:11:00 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13532 for ; Sat, 27 Nov 2004 07:11:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1PE-0002fT-Vs for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:10:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1PE-0002et-Pt for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:10:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY1P8-0000Lb-9y for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:10:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARCAOl9015725; Sat, 27 Nov 2004 04:10:24 -0800 Date: Sat, 27 Nov 2004 04:10:24 -0800 Message-Id: <200411271210.iARCAOl9015725@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 40] New: Definition of "null resource" gone X-Archived-At: http://www.w3.org/mid/200411271210.iARCAOl9015725@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8988 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:10:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=40 Summary: Definition of "null resource" gone Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: critical Priority: P2 Component: 03. Terminology AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org The definition of "null resource" is gone, yet is still used in later sections. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:12:32 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13592 for ; Sat, 27 Nov 2004 07:12:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY1Qk-00033C-73 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:11:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY1Qk-00032e-14 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:11:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY1Qd-0000jI-HN for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:11:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARCBvFL015741; Sat, 27 Nov 2004 04:11:57 -0800 Date: Sat, 27 Nov 2004 04:11:57 -0800 Message-Id: <200411271211.iARCBvFL015741@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 41] New: Paragraph numbering/nesting broken in Section 13 X-Archived-At: http://www.w3.org/mid/200411271211.iARCBvFL015741@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8989 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:11:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 Summary: Paragraph numbering/nesting broken in Section 13 Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 13. XML Element Definitions AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org For instance (!), 13.2 should be a subsection of 13.1. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:58:10 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15935 for ; Sat, 27 Nov 2004 07:58:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY28d-0000Nu-Tm for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:57:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY28d-0000NI-5L for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:57:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY28c-0003ty-Tx for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:57:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARCvIvH015772; Sat, 27 Nov 2004 04:57:18 -0800 Date: Sat, 27 Nov 2004 04:57:18 -0800 Message-Id: <200411271257.iARCvIvH015772@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 42] New: Consider deprecating text/xml for XML request/response bodies X-Archived-At: http://www.w3.org/mid/200411271257.iARCvIvH015772@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8990 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:57:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=42 Summary: Consider deprecating text/xml for XML request/response bodies Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Looking at the current W3 TAG discussion about XML media types and a possible revision of RFC3023, we may want to consider deprecating "text/xml" and making "application/xml" a SHOULD. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 07:59:37 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16292 for ; Sat, 27 Nov 2004 07:59:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2AL-0000hs-6h for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 12:59:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2AL-0000hO-0W for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 12:59:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY2AK-0004S9-Pf for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 12:59:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARCx4tf015789; Sat, 27 Nov 2004 04:59:04 -0800 Date: Sat, 27 Nov 2004 04:59:04 -0800 Message-Id: <200411271259.iARCx4tf015789@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 43] New: "ill-formed" XML X-Archived-At: http://www.w3.org/mid/200411271259.iARCx4tf015789@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8991 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 12:59:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=43 Summary: "ill-formed" XML Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: minor Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.1.1 Replace "ill-formed" by "non-wellformed" ("ill-formed" isnt formally defined anywhere as far as I know). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:01:43 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16551 for ; Sat, 27 Nov 2004 08:01:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2CP-0001cy-43 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:01:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2CO-0001cL-0l for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:01:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY2CH-0005e3-Gl for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:01:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARD1BmK015815; Sat, 27 Nov 2004 05:01:11 -0800 Date: Sat, 27 Nov 2004 05:01:11 -0800 Message-Id: <200411271301.iARD1BmK015815@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] New: OPTIONS * X-Archived-At: http://www.w3.org/mid/200411271301.iARD1BmK015815@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8992 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:01:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 Summary: OPTIONS * Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: critical Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 9.1: This header must also appear on responses to OPTIONS requests to the special '*' Request-URI as defined in HTTP/1.1. In this case it means that the repository supports the named features in at least some internal namespaces. 1) I don't remember this being discussed anywhere. 2) This is impossible to implement with the Java Servlet API, so it's unlikely to be implemented 3) This clearly contradicts RFC2616, section 9.2 (): "If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof)." ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:03:42 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16665 for ; Sat, 27 Nov 2004 08:03:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2ED-0002Ay-3N for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:03:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2EC-0002AU-Tg for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:03:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY2E6-00068f-DL for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:02:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARD34Qg015834; Sat, 27 Nov 2004 05:03:04 -0800 Date: Sat, 27 Nov 2004 05:03:04 -0800 Message-Id: <200411271303.iARD34Qg015834@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 45] New: DAV request header X-Archived-At: http://www.w3.org/mid/200411271303.iARD34Qg015834@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8993 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:03:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=45 Summary: DAV request header Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 9.1 Thanks for adding it, however I think we need to do some more work: As an optional request header, this header allows the client to advertise compliance with named features. Clients need not advertise 1, 2 or bis because a WebDAV server currently doesn't need that information to decide how to respond to requests defined in this specification or in HTTP/1.1. However, future extensions may define client compliance codes. When used as a request header, the DAV header MAY affect caching so this header SHOULD NOT be used on all GET requests. 1) Just say generally that only those feature names are allowed where the spec explicitly defines what it means (in a request!). For RFC2518bis this means that none of the feature names defined here may be used. 2) "When used as a request header, the DAV header MAY affect caching so this header SHOULD NOT be used on all GET requests." - this is misleading. Either it is allowed on GET, or it isn't. If the request header affects a cacheable GET result, the origin server MUST specify that in the "Vary" header. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:05:12 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16783 for ; Sat, 27 Nov 2004 08:05:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2FW-0002Xb-W8 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:04:27 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2FW-0002X2-Po for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:04:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY2FW-0006F8-Hp for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:04:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARD4PVS015850; Sat, 27 Nov 2004 05:04:25 -0800 Date: Sat, 27 Nov 2004 05:04:25 -0800 Message-Id: <200411271304.iARD4PVS015850@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] New: URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200411271304.iARD4PVS015850@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8994 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:04:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 Summary: URLs in Multistatus Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 12. Multi-Status Response AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Section 12: When a Multi-Status body is returned in response to a PROPFIND or another request with a single scope, all URLs appearing in the body must be equal to or inside the request-URI, thus the URLs MAY be absolute or MAY be relative. What is a "single" scope. Ans what does it mean for a URI to be "inside" another? It continues saying: When a Multi-Status body is returned in response to MOVE or COPY, relative URIs resolution is ambiguous (the request had both a source and a destination URL). Thus, URLs appearing in the responses to MOVE or COPY SHOULD be absolute and fully-qualified URLs. What is a "fully-qualified" URL? If this is meant to say that the URI, when relative, MUST start with a "/", then it should be more clear about that. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:06:44 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16867 for ; Sat, 27 Nov 2004 08:06:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2HC-0003Pl-UY for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:06:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2HC-0003PG-Og for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:06:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY2H6-0006zi-7y for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:06:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARD69Bo015866; Sat, 27 Nov 2004 05:06:09 -0800 Date: Sat, 27 Nov 2004 05:06:09 -0800 Message-Id: <200411271306.iARD69Bo015866@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] New: 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200411271306.iARD69Bo015866@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8995 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:06:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 Summary: 3xx in multistatus Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 12. Multi-Status Response AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take a Location header to indicate where the client should make the request. The Multi-Status response syntax as defined in RFC2518 did not allow for the Location header information to be included in an unambiguous way, so servers MAY choose not to use these status codes in Multi-Status responses. If a clients receives this status code in Multi-Status, the client MAY reissue the request to the individual resource, so that the server can issue a response with a Location header for each resource. Additionally, this specification defines a new element that servers MAY use in the response element to provide a location value in Multi-Status (see section 13.29). I think we can improve that: - "not to use" -- be clear what this means -- is it using a "200" status element instead? - when the server chooses not to return the 3xx code, should it include the location element nevertheless (I think it should) ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:08:14 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16991 for ; Sat, 27 Nov 2004 08:08:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2Ie-0003iV-5T for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:07:40 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2Id-0003hu-M7 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:07:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY2Id-00074F-Ez for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:07:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARD7cCL015882; Sat, 27 Nov 2004 05:07:38 -0800 Date: Sat, 27 Nov 2004 05:07:38 -0800 Message-Id: <200411271307.iARD7cCL015882@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] New: XML extensibility description X-Archived-At: http://www.w3.org/mid/200411271307.iARD7cCL015882@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8996 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:07:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 Summary: XML extensibility description Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: major Priority: P2 Component: 13. XML Element Definitions AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org I still think we should make statements about extensibility once. The current notation (adding verbose text to each and every element description) just makes the spec less readable and harder to maintain. Note that already the descriptions are partly broken (for instance in 13.18). In particular: Extensibility: MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized. s/SHOULD/MUST/ ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:09:44 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17112 for ; Sat, 27 Nov 2004 08:09:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2K7-00046i-88 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:09:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2K6-00046E-PV for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:09:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY2K6-0007TA-Fa for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:09:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARD99YN015899; Sat, 27 Nov 2004 05:09:09 -0800 Date: Sat, 27 Nov 2004 05:09:09 -0800 Message-Id: <200411271309.iARD99YN015899@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 49] New: propfind XML description incorrect X-Archived-At: http://www.w3.org/mid/200411271309.iARD99YN015899@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8997 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:09:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=49 Summary: propfind XML description incorrect Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 13. XML Element Definitions AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Says: Should be: ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:10:58 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17180 for ; Sat, 27 Nov 2004 08:10:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2LM-0004sO-6a for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:10:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2LK-0004rb-CW for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:10:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY2LK-0007lJ-3n for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:10:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARDAP4l015915; Sat, 27 Nov 2004 05:10:25 -0800 Date: Sat, 27 Nov 2004 05:10:25 -0800 Message-Id: <200411271310.iARDAP4l015915@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] New: Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200411271310.iARDAP4l015915@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8998 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:10:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 Summary: Property teminology inconsistent with RFC3253 Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Some property values are calculated by the server and it is not appropriate to allow client changes, thus they are protected. Existing server implementations already have different sets of RFC2518 properties protected, but clients can have some expectations which properties are normally protected. The value of a protected property may not be changed even by a user with permission to edit other properties. The value of an unprotected property may be changed by some users with appropriate permissions. This definition seems to slightly differ from what RFC3253 says. That seems to be a bad idea (here is seems to identify "calculated" with "protected"; in RFC3253 there's a clear difference between "protected" and "computed"). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:12:26 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17295 for ; Sat, 27 Nov 2004 08:12:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2Mk-0005NJ-HM for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:11:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2Mj-0005Mp-WA for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:11:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY2Md-0008IX-FZ for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:11:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARDBqtf015931; Sat, 27 Nov 2004 05:11:52 -0800 Date: Sat, 27 Nov 2004 05:11:52 -0800 Message-Id: <200411271311.iARDBqtf015931@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 51] New: Property behaviour upon COPY vs "remote COPY" X-Archived-At: http://www.w3.org/mid/200411271311.iARDBqtf015931@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8999 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:11:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=51 Summary: Property behaviour upon COPY vs "remote COPY" Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org This somehow combines statements about how the property behaves upon COPY and MOVE and some statements about what happens in "remote" operations. I think the latter is very confusing. Either a copy is done using COPY, or it isn't. If a server decides to emulate a copy operation using PROPPATCH and PUT, the standard considerations for these methods apply. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:14:45 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17437 for ; Sat, 27 Nov 2004 08:14:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2Ov-00064M-M0 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:14:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2Ou-00063p-NK for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:14:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY2Ou-0000mh-G7 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:14:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARDE8Sr015948; Sat, 27 Nov 2004 05:14:08 -0800 Date: Sat, 27 Nov 2004 05:14:08 -0800 Message-Id: <200411271314.iARDE8Sr015948@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 52] New: "mandatory" properties X-Archived-At: http://www.w3.org/mid/200411271314.iARDE8Sr015948@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9000 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:14:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=52 Summary: "mandatory" properties Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0154.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org This is actually an old issue. For instance: Description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created (i.e., the moment it had non-null state). Basically this says that the property should be there, unless it isn't. Just say that it's optional in these cases. (The current language is known to have caused incorrect implementations that (client-side) assume that the property will always be present or (server-side) return the value as found with either empty or "best-guess" value). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 08:16:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17584 for ; Sat, 27 Nov 2004 08:16:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY2R1-0006pL-4h for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 13:16:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY2R0-0006oi-NJ for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 13:16:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY2R0-0001Ni-AI for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 13:16:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARDGHUl015964; Sat, 27 Nov 2004 05:16:17 -0800 Date: Sat, 27 Nov 2004 05:16:17 -0800 Message-Id: <200411271316.iARDGHUl015964@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] New: DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200411271316.iARDGHUl015964@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9001 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 13:16:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 Summary: DAV:responsedescription content model Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0155.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 13. XML Element Definitions AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Section 13.19 states: "Extensibility: MAY be extended with attributes which SHOULD be ignored." However: RFC3253, section 1.6 *already* does extend it with a child element (DAV:error). (added for -06) Bottom line: RFC2518bis should properly copy RFC3253's definition of precondition/postcondition, DAV:error element and it's usage in DAV:multistatus. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:24:47 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22130 for ; Sat, 27 Nov 2004 09:24:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3Sf-0003u3-Bw for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:22:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3Se-0003tI-CA for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:22:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY3Se-0003pb-4Z for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:22:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREM3xl016020; Sat, 27 Nov 2004 06:22:03 -0800 Date: Sat, 27 Nov 2004 06:22:03 -0800 Message-Id: <200411271422.iAREM3xl016020@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] New: Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200411271422.iAREM3xl016020@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9002 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:22:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 Summary: Locks vs multiple bindings Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org I appreciate the clarification on locking. Currently it says: 6.8 Locks and Multiple Bindings A resource may be made available through more than one URI. However locks apply to resources, not URIs. Therefore a LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable. This is a bit misleading as indeed the lock is on the resource, but it *protects* the URL through which the lock was created. Thus given URLs "a" and "b" identifying the same resource which was locked through "a", I can apply DELETE to "b" without needing the lock token. This seems to be another example why it would be A Good Thing to completely import GULP (see for instance ) into the spec. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:24:47 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22131 for ; Sat, 27 Nov 2004 09:24:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3To-0004Ke-2B for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:23:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3Tn-0004KA-Rb for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:23:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3Th-0001xU-B6 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:23:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARENEJf016036; Sat, 27 Nov 2004 06:23:14 -0800 Date: Sat, 27 Nov 2004 06:23:14 -0800 Message-Id: <200411271423.iARENEJf016036@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 55] New: Multistatus format (empty) X-Archived-At: http://www.w3.org/mid/200411271423.iARENEJf016036@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9003 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:23:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=55 Summary: Multistatus format (empty) Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.2 Multistatus Format The multistatus contains one response element for each resource in the scope of the request (in no required order) or may be empty if no resources match the request. Although this is correct, I find it confusing that it's stated for PROPFIND where this condition never occur. It should be mentioned in the definition of the multistatus element instead. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:25:34 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22208 for ; Sat, 27 Nov 2004 09:25:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3VW-0005HF-B7 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:25:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3VV-0005BT-Vt for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:25:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3VP-0002OP-66 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:24:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREP1DD016053; Sat, 27 Nov 2004 06:25:01 -0800 Date: Sat, 27 Nov 2004 06:25:01 -0800 Message-Id: <200411271425.iAREP1DD016053@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 56] New: 423 Locked in Multistatus for PROPPATCH? X-Archived-At: http://www.w3.org/mid/200411271425.iAREP1DD016053@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9004 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:25:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=56 Summary: 423 Locked in Multistatus for PROPPATCH? Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Why would we ever return a 423 in a 207 response body to a *PROPPATCH*? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:27:07 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22324 for ; Sat, 27 Nov 2004 09:27:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3X2-00060b-2I for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:26:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3X1-000607-RL for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:26:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY3X1-0005Yi-KK for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:26:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREQZEk016069; Sat, 27 Nov 2004 06:26:35 -0800 Date: Sat, 27 Nov 2004 06:26:35 -0800 Message-Id: <200411271426.iAREQZEk016069@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 57] New: incorrect section reference X-Archived-At: http://www.w3.org/mid/200411271426.iAREQZEk016069@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9005 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:26:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=57 Summary: incorrect section reference Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Section 8.9.3 refers to 8.7.2 for "namespace consistency". That's in 5.1, though. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:28:16 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22392 for ; Sat, 27 Nov 2004 09:28:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3Y4-0006OI-7P for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:27:40 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3Y4-0006No-09 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:27:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY3Y3-0005px-P5 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:27:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARERdTW016086; Sat, 27 Nov 2004 06:27:39 -0800 Date: Sat, 27 Nov 2004 06:27:39 -0800 Message-Id: <200411271427.iARERdTW016086@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 58] New: MOVE status 403 description X-Archived-At: http://www.w3.org/mid/200411271427.iARERdTW016086@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9006 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:27:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=58 Summary: MOVE status 403 description Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.10.4 Speaking of MOVE...: 403 (Forbidden) - The source and destination resources are the same. This is a very good example for why we need to go through *all* response code examples in the document. A 403 upon MOVE can mean a lot of things, and the only way to distinguish these is by using proper condition codes. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:29:19 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22463 for ; Sat, 27 Nov 2004 09:29:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3Z9-0006gy-DS for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:28:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3Z9-0006gU-62 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:28:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY3Z8-00068H-V7 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:28:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iARESk6Q016103; Sat, 27 Nov 2004 06:28:46 -0800 Date: Sat, 27 Nov 2004 06:28:46 -0800 Message-Id: <200411271428.iARESk6Q016103@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 59] New: failed LOCK response body X-Archived-At: http://www.w3.org/mid/200411271428.iARESk6Q016103@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9007 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:28:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=59 Summary: failed LOCK response body Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.11.6 423 (Locked) - The resource is locked already. For consistency's sake, this response SHOULD contain the 'missing-lock-token' precondition element. I find this misleading. We have a strict separation between LOCK creation (with request body) and LOCK refresh (without). If a LOCK creation request fails because the resource is already exclusively locked, providing the lock token in the If header will not help at all. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:30:35 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22542 for ; Sat, 27 Nov 2004 09:30:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3aN-0007hG-7q for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:30:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3aN-0007dF-02 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:30:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3aG-0003xl-Dg for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:29:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREU2vF016119; Sat, 27 Nov 2004 06:30:02 -0800 Date: Sat, 27 Nov 2004 06:30:02 -0800 Message-Id: <200411271430.iAREU2vF016119@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 60] New: If header evaluation when? X-Archived-At: http://www.w3.org/mid/200411271430.iAREU2vF016119@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9008 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:30:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=60 Summary: If header evaluation when? Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.12 The If header is not needed to provide the lock token although servers SHOULD still evaluate the If header and treat it as a conditional header. I agree with that, but I'm confused it's mentioned here. Doesn't it apply to *all* HTTP methods? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:31:46 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22596 for ; Sat, 27 Nov 2004 09:31:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3bX-0008CF-56 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:31:15 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3bW-0008Bi-V0 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:31:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY3bW-0006jP-Nj for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:31:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREVEws016137; Sat, 27 Nov 2004 06:31:14 -0800 Date: Sat, 27 Nov 2004 06:31:14 -0800 Message-Id: <200411271431.iAREVEws016137@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 61] New: invalid lock token in example X-Archived-At: http://www.w3.org/mid/200411271431.iAREVEws016137@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9009 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:31:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=61 Summary: invalid lock token in example Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: minor Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 9.5.4, lock token syntax Uses an invalid lock token (: "locktoken" is not a registered URI scheme). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:32:59 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22654 for ; Sat, 27 Nov 2004 09:32:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3cd-0000LJ-U7 for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:32:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3cd-0000Kp-O7 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:32:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3cX-00051G-7T for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:32:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREWN19016153; Sat, 27 Nov 2004 06:32:23 -0800 Date: Sat, 27 Nov 2004 06:32:23 -0800 Message-Id: <200411271432.iAREWN19016153@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] New: href format X-Archived-At: http://www.w3.org/mid/200411271432.iAREWN19016153@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9010 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:32:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 Summary: href format Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: critical Priority: P2 Component: 13. XML Element Definitions AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Purpose: Identifies the content of the element as a URI. In many situations, this URI MUST be a HTTP URI, and furthermore, it MUST identify a WebDAV resource. There is one exception to this general rule in the lockdiscovery property, where the lock token (which is a URI but may not be a HTTP URI) is inside the href element. Other specifications SHOULD be explicit if the href element is to contain non-HTTP URIs. Wow? Since when? May it refer to a null resource? Is a null resource a WebDAV resource? What about location/href, for instance? Unless there's consensus for this incompatible change to RFC2518, please remove it. Value: URI (See section 3.2.1 of RFC2616 [8]) No. URIs are defined in RFC2396(bis). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:34:31 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22736 for ; Sat, 27 Nov 2004 09:34:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3e1-0000mY-Tw for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:33:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3e1-0000lt-Mp for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:33:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3dv-0005Rl-6J for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:33:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREXndg016170; Sat, 27 Nov 2004 06:33:49 -0800 Date: Sat, 27 Nov 2004 06:33:49 -0800 Message-Id: <200411271433.iAREXndg016170@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 63] New: typo in 13.16 "name" line X-Archived-At: http://www.w3.org/mid/200411271433.iAREXndg016170@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9011 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:33:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=63 Summary: typo in 13.16 "name" line Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 13. XML Element Definitions AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Says "locktype", should say "response". ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:35:14 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22795 for ; Sat, 27 Nov 2004 09:35:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3es-0001HG-VB for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:34:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3es-0001Gg-PE for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:34:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY3es-0007ZT-IA for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:34:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREYgq3016186; Sat, 27 Nov 2004 06:34:42 -0800 Date: Sat, 27 Nov 2004 06:34:42 -0800 Message-Id: <200411271434.iAREYgq3016186@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 64] New: Incorrect IETF boilerplate X-Archived-At: http://www.w3.org/mid/200411271434.iAREYgq3016186@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9012 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:34:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=64 Summary: Incorrect IETF boilerplate Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org The front page should refer to RFC3667, not RFC2026. In xml2rfc source code, do this using ipr="full3667" on the root element. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:36:07 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22905 for ; Sat, 27 Nov 2004 09:36:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3fj-00021p-Kb for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:35:35 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3fj-00021K-EV for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:35:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CY3fi-0007qK-UF for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:35:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREZYJU016202; Sat, 27 Nov 2004 06:35:34 -0800 Date: Sat, 27 Nov 2004 06:35:34 -0800 Message-Id: <200411271435.iAREZYJU016202@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (bart.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 65] New: Table of Contents missing X-Archived-At: http://www.w3.org/mid/200411271435.iAREZYJU016202@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9013 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:35:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=65 Summary: Table of Contents missing Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org The TOC is gone. Please bring it back in the next draft. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:36:53 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22997 for ; Sat, 27 Nov 2004 09:36:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3gU-0002Mn-4l for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:36:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3gT-0002MB-Us for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:36:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3gN-0006RK-4A for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:36:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREaKVG016219; Sat, 27 Nov 2004 06:36:20 -0800 Date: Sat, 27 Nov 2004 06:36:20 -0800 Message-Id: <200411271436.iAREaKVG016219@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 66] New: references style X-Archived-At: http://www.w3.org/mid/200411271436.iAREaKVG016219@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9014 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:36:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=66 Summary: references style Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org References now use numerical names instead of symbolic ones. Is there a reason for this change? (use in xml2rfc source code). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:37:44 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23057 for ; Sat, 27 Nov 2004 09:37:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3hH-0002pJ-No for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:37:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3hH-0002ol-GW for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:37:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3hB-0006qT-0R for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:37:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREbAoS016235; Sat, 27 Nov 2004 06:37:10 -0800 Date: Sat, 27 Nov 2004 06:37:10 -0800 Message-Id: <200411271437.iAREbAoS016235@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 67] New: non-ASCII characters X-Archived-At: http://www.w3.org/mid/200411271437.iAREbAoS016235@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9015 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:37:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=67 Summary: non-ASCII characters Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org In section 7.6, 8.1.6, 8.2, 8.7.2 and probably some more places. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:38:20 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23106 for ; Sat, 27 Nov 2004 09:38:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3hs-0003Cd-GH for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:37:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3hs-0003C5-A7 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:37:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3hl-000702-Q7 for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:37:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREblVD016251; Sat, 27 Nov 2004 06:37:47 -0800 Date: Sat, 27 Nov 2004 06:37:47 -0800 Message-Id: <200411271437.iAREblVD016251@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 68] New: Reference to XML spec X-Archived-At: http://www.w3.org/mid/200411271437.iAREblVD016251@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9016 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:37:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=68 Summary: Reference to XML spec Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Please update XML reference to "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC-xml-20040204, February 2004. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Sat Nov 27 09:39:14 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23159 for ; Sat, 27 Nov 2004 09:39:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CY3ik-0003cV-Sm for w3c-dist-auth-dist@listhub.w3.org; Sat, 27 Nov 2004 14:38:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CY3ik-0003bX-M4 for w3c-dist-auth@listhub.w3.org; Sat, 27 Nov 2004 14:38:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CY3ie-0007AD-4Z for w3c-dist-auth@w3.org; Sat, 27 Nov 2004 14:38:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id iAREcfYO016268; Sat, 27 Nov 2004 06:38:41 -0800 Date: Sat, 27 Nov 2004 06:38:41 -0800 Message-Id: <200411271438.iAREcfYO016268@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 69] New: Formatting lost in appendix B.2 X-Archived-At: http://www.w3.org/mid/200411271438.iAREcfYO016268@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9017 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 27 Nov 2004 14:38:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=69 Summary: Formatting lost in appendix B.2 Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0156.html OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: Appendix B. Appendices AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org Formatting of list was lost. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@w3.org Mon Nov 29 05:55:27 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05083 for ; Mon, 29 Nov 2004 05:55:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CYj9O-0006Mj-DR for w3c-dist-auth-dist@listhub.w3.org; Mon, 29 Nov 2004 10:52:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CYj9N-0006M6-Em for w3c-dist-auth@listhub.w3.org; Mon, 29 Nov 2004 10:52:57 +0000 Received: from [67.15.60.3] (helo=mail.aftek.com) by bart.w3.org with esmtp (Exim 4.34) id 1CYj9N-0002tb-7c for w3c-dist-auth@w3.org; Mon, 29 Nov 2004 10:52:57 +0000 Received: (qmail 29188 invoked by uid 510); 29 Nov 2004 04:00:29 -0600 Received: from johnv@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. spamassassin: 2.63. Clear:RC:0(61.11.16.124):SA:0(-102.0/3.0):. Processed in 2.446651 secs); 29 Nov 2004 10:00:29 -0000 X-Antivirus-MYDOMAIN-Mail-From: johnv@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(61.11.16.124):SA:0(-102.0/3.0):. Processed in 2.446651 secs Process 29176) Received: from ppp16-124.dsl-pun.eth.net (HELO john) (johnv@aftek.com@61.11.16.124) by mail.aftek.com with SMTP; 29 Nov 2004 04:00:26 -0600 Message-ID: <003601c4d601$93b26570$6500000a@john> From: "John Varghese" To: Date: Mon, 29 Nov 2004 16:22:35 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C4D62F.A2846890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Received-SPF: none (bart.w3.org: domain of johnv@aftek.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Estimate for developing a WebDav server X-Archived-At: http://www.w3.org/mid/003601c4d601$93b26570$6500000a@john Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9018 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 29 Nov 2004 10:52:58 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C4D62F.A2846890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Friends, For the initial phase, I need to make an estimate of developing a = WebDav server. Can anybody help Regards John Varghese Software Engineer Aftek Infosys Ltd. 9422308285(M) , 242718478/9 Exnt: 317 (B) www.aftek.com ------=_NextPart_000_0033_01C4D62F.A2846890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Friends,
  For the initial phase, I need = to make an=20 estimate of developing a WebDav server. Can anybody help
 
Regards
 
John Varghese
Software = Engineer
Aftek=20 Infosys Ltd.
9422308285(M) , 242718478/9 Exnt: 317 (B)
www.aftek.com
------=_NextPart_000_0033_01C4D62F.A2846890-- From w3c-dist-auth-request@w3.org Mon Nov 29 15:18:51 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27348 for ; Mon, 29 Nov 2004 15:18:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CYrxh-0000Mm-9o for w3c-dist-auth-dist@listhub.w3.org; Mon, 29 Nov 2004 20:17:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CYrxe-0000M0-PZ for w3c-dist-auth@listhub.w3.org; Mon, 29 Nov 2004 20:17:26 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by lisa.w3.org with esmtp (Exim 4.34) id 1CYrxX-0006KB-RZ for w3c-dist-auth@w3.org; Mon, 29 Nov 2004 20:17:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27198; Mon, 29 Nov 2004 15:17:22 -0500 (EST) Message-Id: <200411292017.PAA27198@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Date: Mon, 29 Nov 2004 15:17:22 -0500 Received-SPF: none (lisa.w3.org: domain of rbunch@cnri.reston.va.us does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-bind-08.txt X-Archived-At: http://www.w3.org/mid/200411292017.PAA27198@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9019 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 29 Nov 2004 20:17:29 +0000 --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 : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) Author(s) : G. Clemm, et al. Filename : draft-ietf-webdav-bind-08.txt Pages : 35 Date : 2004-11-29 This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-bind-08.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-bind-08.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: <2004-11-29152440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152440.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Mon Nov 29 15:44:20 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01328 for ; Mon, 29 Nov 2004 15:44:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CYsMr-0001nK-TD for w3c-dist-auth-dist@listhub.w3.org; Mon, 29 Nov 2004 20:43:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CYsMq-0001mN-LJ for w3c-dist-auth@listhub.w3.org; Mon, 29 Nov 2004 20:43:28 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CYsMj-0006sk-QT for w3c-dist-auth@w3.org; Mon, 29 Nov 2004 20:43:22 +0000 Received: (qmail 11685 invoked by uid 65534); 29 Nov 2004 20:42:56 -0000 Received: from pD953599E.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.89.158) by mail.gmx.net (mp017) with SMTP; 29 Nov 2004 21:42:56 +0100 X-Authenticated: #1915285 Message-ID: <41AB89C9.2010706@gmx.de> Date: Mon, 29 Nov 2004 21:42:49 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200411292017.PAA27198@ietf.org> In-Reply-To: <200411292017.PAA27198@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D ACTION:draft-ietf-webdav-bind-08.txt X-Archived-At: http://www.w3.org/mid/41AB89C9.2010706@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9020 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 29 Nov 2004 20:43:29 +0000 Content-Transfer-Encoding: 7bit Hi, as announced last week, this draft closes all open issues I was aware of. Joe, Lisa, could you please either have this draft (working group) last-called, or ensure that possibly remaining issues are raised here in a timely manner? Thanks, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Nov 29 17:08:24 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17936 for ; Mon, 29 Nov 2004 17:08:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CYtfz-0002pJ-C2 for w3c-dist-auth-dist@listhub.w3.org; Mon, 29 Nov 2004 22:07:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CYtfy-0002op-Lw for w3c-dist-auth@listhub.w3.org; Mon, 29 Nov 2004 22:07:18 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CYtfy-0006RY-DY for w3c-dist-auth@w3.org; Mon, 29 Nov 2004 22:07:18 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id iATM45vm026136 for ; Mon, 29 Nov 2004 14:04:08 -0800 (PST) Message-Id: <200411292204.iATM45vm026136@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "WebDAV \(WebDAV WG\)" Date: Mon, 29 Nov 2004 14:03:57 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTWX0yINWg/eY8xR3Ola/dMgmDF4g== X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200411292204.iATM45vm026136@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9021 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 29 Nov 2004 22:07:19 +0000 Content-Transfer-Encoding: 7bit I gave the latest WebDAV Bindings Protocol specification a careful read today, and was generally very impressed by the solidity of the specification. I have a number of comments (below) which mostly seek to clarify the intent of the specification. I'm fine with these being considered last-call comments if the WG wants to proceed with a WG last call on the -08 specification -- IMO, the specification is certainly ready for such a review. Also, I'm not sure whether current WG practice is for those submitting comments to directly enter them into the issue tracking system. If so, let me know, and I'll enter these in. OK, the comments: * Terminology section (1.1): There is a reference to draft-fielding-rfc2396bis here, and also in Section 3.2 (perhaps it occurs elsewhere in the specification as well). References in RFCs need to be to documents of RFC level stability (or equivalent). If draft-fielding-rfc2396bis hasn't yet been approved by the IESG, we should just revert back to RFC 2396. * Section 2, paragraph 3. The language here would preclude the future definition of a DESTROY method which had the semantics of removing the state of a resource from a server, irregardless of any containment relationships that may hold it. Such a method could be quite useful for records management functionality, in order to implement a records disposition policy that specified deletion at a certain time. My recommended tweak to the language of section 2 is minor: add the following sentence to the end of the paragraph: "It is permissible, however, for future method definitions (e.g., a DESTROY method) to have semantics that remove all bindings and/or immediately reclaim system resources." * Section 2.1. I think it would be more clear to separate out the discussion of loops and bindings, and make it a separate section (say, 2.2) This issue comes up frequently enough that it would be good to make it easy to find this issue in the TOC. Also, a mention of the Already Reported status code would be good to have here, since it also mentions 506. * Section 2.3. This section doesn't clearly address the semantics of COPY with Depth infinity. My recommendation is to add, after paragraph 3, text like this: "As specified in [RFC2518], a COPY with Depth infinity causes the collection resource to be duplicated, all of its bound children to be duplicated, and their children's bound children, and so on, to the bottom of the containment hierarchy. All of the segments of the bindings of the destination collection are the same as for the destination collection. However, the destination resource for all bindings in the destination collection are different from those of the source collection, since all resources have been duplicated, creating new resources with distinct DAV:resource-id properties." * There should also be some text addressing COPY depth infinity and loops -- in some instances during a COPY with Depth infinity, the server really wants to recreate the binding that causes the loop, rather than continuing to make duplicate resources. This is somewhat addressed by the final paragraph in Section 2.3, but not exactly. * One gap in the current COPY semantics is the ability to copy a collection and its bindings. COPY depth 0 says copy all non-binding state. COPY depth infinity copies all bindings and makes duplicates of all bound resources. But, there's no single atomic operation (call it BINDDUP) that duplicates the collection and its bindings, but doesn't duplicate the bound resources. That is, there is no operation that does a COPY Depth 0 plus BIND for all members. So, two questions. Is there a compelling scenario for having a BINDDUP method? I confess I'm having a hard time coming up with one. Second, assuming there is a compelling scenario, can it be accomplished just using COPY, LOCK, and BIND, rather than having a special purpose method. Also unclear. * It might make sense to create an example covering the situation described in the final paragraph of Section 2.3. I'm not 100% sure I know what scenario this paragraph addresses, other reading the spec. for the first time would presumably have a tougher time. * Section 2.4, second paragraph. "MUST NOT" is used in the text of an example -- seems like it should be lower case here instead. * Section 2.6 -- there needs to be some discussion on the interactions of DAV:resource-id and versioning. As near as I can tell, the intent is that every revision will have a unique DAV:resource-id value. * Section 2.6 -- I think it would help clarify the text to say that one possible implementation technique is to use a GUID for the unique identifier, and then reference the same GUID document as is referenced in RFC 2518. * Section 2.6, final paragraph, last two sentences. Change "must not" to "MUST NOT" (and eliminate the "For example" at the start of the sentence -- perhaps change to "Specifically," * Section 2.6. Need to add a note indicating that REBIND does not affect the value of DAV:resource-id. * Section 3.2, final sentence -- delete the word "either", add a comma after "or". * Section 3.2. I think it would be helpful to have an example of this property. I'd be happy to help develop such an example. * Section 4. The intent of the BIND method is for its behavior to be atomic. However, this is never actually stated explicitly in the specification. Seems like it should be. * Section 4. Need a new condition to cover the case where the BIND half-succeeded, and then needed to be rewound. This condition would address the case where Overwrite is true, the destination binding has been removed, but the new binding couldn't be created. * Section 4.1, final sentence. Remove comma after the URI. * Section 5. Same comment as for BIND. The intent of UNBIND is that it's supposed to be atomic, but that's never explicitly stated. * Section 5. I think we need a condition for a cross-server UNBIND failure. * Section 6. Same comment as for BIND, UNBIND. The intent of REBIND is to be atomic, but this is not explicitly stated. * Section 6. Should precondition DAV:rebind-into-collection be named DAV:rebind-from-collection, to mirror the similar precondition for UNBIND? * Section 6. Precondition DAV:rebind-source-exists is incorrect. The DAV:href element identifies the destination binding to be created, not the source. Seems like this precondition, and the previous one, reflect an older marshalling of the arguments. * Section 6.2. I think it would be helpful to have an example including REBIND and locks, showing submission of one or more lock tokens in the If header. * Section 7.1.1. Might just be a personal preference, but I'd rather see plain GUIDs rather than opaqulocktoken URI GUIDs in the example. That's it. - Jim From w3c-dist-auth-request@w3.org Mon Nov 29 18:00:54 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23636 for ; Mon, 29 Nov 2004 18:00:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CYuUb-0004GT-0H for w3c-dist-auth-dist@listhub.w3.org; Mon, 29 Nov 2004 22:59:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CYuUa-0004Fq-1i for w3c-dist-auth@listhub.w3.org; Mon, 29 Nov 2004 22:59:36 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CYuUT-0006zn-0k for w3c-dist-auth@w3.org; Mon, 29 Nov 2004 22:59:29 +0000 Received: (qmail 21160 invoked by uid 65534); 29 Nov 2004 22:59:00 -0000 Received: from pD953599E.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.89.158) by mail.gmx.net (mp023) with SMTP; 29 Nov 2004 23:59:00 +0100 X-Authenticated: #1915285 Message-ID: <41ABA9AB.2000803@gmx.de> Date: Mon, 29 Nov 2004 23:58:51 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "WebDAV (WebDAV WG)" References: <200411292204.iATM45vm026136@cats-mx3.ucsc.edu> In-Reply-To: <200411292204.iATM45vm026136@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41ABA9AB.2000803@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9022 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 29 Nov 2004 22:59:37 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > I gave the latest WebDAV Bindings Protocol specification a careful read > today, and was generally very impressed by the solidity of the > specification. I have a number of comments (below) which mostly seek to > clarify the intent of the specification. I'm fine with these being > considered last-call comments if the WG wants to proceed with a WG last call > on the -08 specification -- IMO, the specification is certainly ready for > such a review. Thanks. > Also, I'm not sure whether current WG practice is for those submitting > comments to directly enter them into the issue tracking system. If so, let > me know, and I'll enter these in. I don't have any preference. At the end of the day, discussion needs to take place on the mailing list anyway. > OK, the comments: > > * Terminology section (1.1): There is a reference to > draft-fielding-rfc2396bis here, and also in Section 3.2 (perhaps it occurs > elsewhere in the specification as well). References in RFCs need to be to > documents of RFC level stability (or equivalent). If > draft-fielding-rfc2396bis hasn't yet been approved by the IESG, we should > just revert back to RFC 2396. It has been approved in September and is on in the RFC Editor's publication queue. If it get's published before we are done we'll update the draft ourselves, otherwise it'll be part of the publication process anyway. > * Section 2, paragraph 3. The language here would preclude the future > definition of a DESTROY method which had the semantics of removing the state > of a resource from a server, irregardless of any containment relationships > that may hold it. Such a method could be quite useful for records management > functionality, in order to implement a records disposition policy that > specified deletion at a certain time. My recommended tweak to the language > of section 2 is minor: add the following sentence to the end of the > paragraph: > > "It is permissible, however, for future method definitions (e.g., a DESTROY > method) to have semantics that remove all bindings and/or immediately > reclaim system resources." I'm fine with stating that it's possible to define a method that *explicitly* has that semantics (affecting other bindings). How about...: "It is permissible, however, for future method definitions (e.g., a DESTROY method) to have semantics that explicitly remove all bindings and/or immediately reclaim system resources." > * Section 2.1. I think it would be more clear to separate out the discussion > of loops and bindings, and make it a separate section (say, 2.2) This issue > comes up frequently enough that it would be good to make it easy to find > this issue in the TOC. Also, a mention of the Already Reported status code > would be good to have here, since it also mentions 506. The last sentence of the first paragraph already mentions the 506 status. Would adding a new subsection ("Bind Loops") and moving the first paragraph of 2.1 into that subsection be what you have in mind? > * Section 2.3. This section doesn't clearly address the semantics of COPY > with Depth infinity. My recommendation is to add, after paragraph 3, text > like this: > > "As specified in [RFC2518], a COPY with Depth infinity causes the collection > resource to be duplicated, all of its bound children to be duplicated, and > their children's bound children, and so on, to the bottom of the containment > hierarchy. All of the segments of the bindings of the destination collection > are the same as for the destination collection. However, the destination > resource for all bindings in the destination collection are different from > those of the source collection, since all resources have been duplicated, > creating new resources with distinct DAV:resource-id properties." As far as I understand, the depth:infinity semantics for COPY follow from what's being said about depth:0 and the RFC2518 infinity semantics (just checking...). Thus, I'm not convinced that we need to say this, but it probably wouldn't hurt either. Feedback appreciated. > * There should also be some text addressing COPY depth infinity and loops -- > in some instances during a COPY with Depth infinity, the server really wants > to recreate the binding that causes the loop, rather than continuing to make > duplicate resources. This is somewhat addressed by the final paragraph in > Section 2.3, but not exactly. I thought it was. Could you be more specific. Maybe expand that statement so that it becomes clear that this applies to loop situations as well? > * One gap in the current COPY semantics is the ability to copy a collection > and its bindings. COPY depth 0 says copy all non-binding state. COPY depth > infinity copies all bindings and makes duplicates of all bound resources. > But, there's no single atomic operation (call it BINDDUP) that duplicates > the collection and its bindings, but doesn't duplicate the bound resources. > That is, there is no operation that does a COPY Depth 0 plus BIND for all > members. So, two questions. Is there a compelling scenario for having a > BINDDUP method? I confess I'm having a hard time coming up with one. Second, > assuming there is a compelling scenario, can it be accomplished just using > COPY, LOCK, and BIND, rather than having a special purpose method. Also > unclear. I do agree we don't have that. I have no idea whether anybody needs it. If it's needed, you can get very close to it using MKCOL, LOCK, n * BIND and UNLOCK. > * It might make sense to create an example covering the situation described > in the final paragraph of Section 2.3. I'm not 100% sure I know what > scenario this paragraph addresses, other reading the spec. for the first > time would presumably have a tougher time. Agreed. I'll give it a try. > * Section 2.4, second paragraph. "MUST NOT" is used in the text of an > example -- seems like it should be lower case here instead. Agreed. > * Section 2.6 -- there needs to be some discussion on the interactions of > DAV:resource-id and versioning. As near as I can tell, the intent is that > every revision will have a unique DAV:resource-id value. That's correct. I'm not sure why we would need to state this -- a version resource clearly is not the same resource as it's VCR, so it seems clear they'll never have the same DAV:resource-id. > * Section 2.6 -- I think it would help clarify the text to say that one > possible implementation technique is to use a GUID for the unique > identifier, and then reference the same GUID document as is referenced in > RFC 2518. That's in section 3.1 (definition of DAV:resource-id property), isn't it? > * Section 2.6, final paragraph, last two sentences. Change "must not" to > "MUST NOT" (and eliminate the "For example" at the start of the sentence -- > perhaps change to "Specifically," I agree for PUT/COPY, but things get unclear when we talk about MOVE (as RFC2518 allows this to be implemented in terms of COPY/DELETE). REBIND, on the other hand, has that property. Feedback appreciated. > * Section 2.6. Need to add a note indicating that REBIND does not affect the > value of DAV:resource-id. See :-) > * Section 3.2, final sentence -- delete the word "either", add a comma after > "or". OK. > * Section 3.2. I think it would be helpful to have an example of this > property. I'd be happy to help develop such an example. Agreed. > * Section 4. The intent of the BIND method is for its behavior to be atomic. > However, this is never actually stated explicitly in the specification. > Seems like it should be. Yes. Probably the same for UNBIND (REBIND already mentions it). Text suggestion welcome. > * Section 4. Need a new condition to cover the case where the BIND > half-succeeded, and then needed to be rewound. This condition would address > the case where Overwrite is true, the destination binding has been removed, > but the new binding couldn't be created. But then it wouldn't be atomic, right? > * Section 4.1, final sentence. Remove comma after the URI. OK. > * Section 5. Same comment as for BIND. The intent of UNBIND is that it's > supposed to be atomic, but that's never explicitly stated. 200. > * Section 5. I think we need a condition for a cross-server UNBIND failure. Could you please describe that situation in more detail? > * Section 6. Same comment as for BIND, UNBIND. The intent of REBIND is to be > atomic, but this is not explicitly stated. Last sentence of first paragraph, but I do agree it could be improved. As you said, same as for BIND and UNBIND. > * Section 6. Should precondition DAV:rebind-into-collection be named > DAV:rebind-from-collection, to mirror the similar precondition for UNBIND? Agreed. Not sure why it was inconsistent. > * Section 6. Precondition DAV:rebind-source-exists is incorrect. The > DAV:href element identifies the destination binding to be created, not the > source. Seems like this precondition, and the previous one, reflect an older > marshalling of the arguments. Agreed. I think we should keep the precondition, but it needs to say: "The Request-URI plus the DAV:segment in the request body element MUST identify a non-null resource." > * Section 6.2. I think it would be helpful to have an example including > REBIND and locks, showing submission of one or more lock tokens in the If > header. Such as one involving locked source and destination collections? That may be useful. What do others think? > * Section 7.1.1. Might just be a personal preference, but I'd rather see > plain GUIDs rather than opaqulocktoken URI GUIDs in the example. A plain GUID isn't a legal URI. And unfortunately, there's still (!) no registered URI scheme except "opaquelocktoken" that's based on UUIDs (== GUIDs) -- "urn:uuid" seems to be dead. > That's it. Thank you very much for the review. I'll do the editorial changes right away and add the other points to the issues list on a case-by-case once we agree that we should change the current text. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Nov 29 20:32:24 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06751 for ; Mon, 29 Nov 2004 20:32:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CYwr4-0007Z1-6K for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 01:30:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CYwr2-0007Ws-Qc for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 01:30:56 +0000 Received: from cats-mx1.ucsc.edu ([128.114.125.34]) by lisa.w3.org with esmtp (Exim 4.34) id 1CYwqw-0007qd-1w for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 01:30:50 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx1.ucsc.edu (8.13.1/8.13.1) with ESMTP id iAU1UIiv021516; Mon, 29 Nov 2004 17:30:22 -0800 (PST) Message-Id: <200411300130.iAU1UIiv021516@cats-mx1.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Julian Reschke'" Cc: "'WebDAV \(WebDAV WG\)'" Date: Mon, 29 Nov 2004 17:30:11 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTWZwXFgRUkocVrQxKAHsNkAnlORAAE3U8A In-Reply-To: <41ABA9AB.2000803@gmx.de> X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/200411300130.iAU1UIiv021516@cats-mx1.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9023 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 01:30:58 +0000 Content-Transfer-Encoding: 7bit > I'm fine with stating that it's possible to define a method that > *explicitly* has that semantics (affecting other bindings). > How about...: > > "It is permissible, however, for future method definitions > (e.g., a DESTROY method) to have semantics that explicitly > remove all bindings and/or immediately reclaim system resources." Fine with me. > > > * Section 2.1. I think it would be more clear to separate out the > > discussion of loops and bindings, and make it a separate > section (say, > > 2.2) This issue comes up frequently enough that it would be good to > > make it easy to find this issue in the TOC. Also, a mention of the > > Already Reported status code would be good to have here, > since it also mentions 506. > > The last sentence of the first paragraph already mentions the > 506 status. Right -- it should mention 208 Already Reported as well. > Would adding a new subsection ("Bind Loops") and moving the > first paragraph of 2.1 into that subsection be what you have in mind? Yes. > > * There should also be some text addressing COPY depth infinity and > > loops -- in some instances during a COPY with Depth infinity, the > > server really wants to recreate the binding that causes the loop, > > rather than continuing to make duplicate resources. This is > somewhat > > addressed by the final paragraph in Section 2.3, but not exactly. > > I thought it was. Could you be more specific. Maybe expand > that statement so that it becomes clear that this applies to > loop situations as well? Maybe that would do it. I think the current language may actually address loops, but since loops aren't explicitly discussed, it's not straightforward. > > * Section 2.6 -- there needs to be some discussion on the > interactions > > of DAV:resource-id and versioning. As near as I can tell, > the intent > > is that every revision will have a unique DAV:resource-id value. > > That's correct. I'm not sure why we would need to state this > -- a version resource clearly is not the same resource as > it's VCR, so it seems clear they'll never have the same > DAV:resource-id. I think it's worth explicitly mentioning this. > > * Section 2.6 -- I think it would help clarify the text to say that > > one possible implementation technique is to use a GUID for > the unique > > identifier, and then reference the same GUID document as is > referenced > > in RFC 2518. > > That's in section 3.1 (definition of DAV:resource-id > property), isn't it? Ah, yes, I see it there now. > > * Section 2.6, final paragraph, last two sentences. Change > "must not" > > to "MUST NOT" (and eliminate the "For example" at the start of the > > sentence -- perhaps change to "Specifically," > > I agree for PUT/COPY, but things get unclear when we talk > about MOVE (as > RFC2518 allows this to be implemented in terms of > COPY/DELETE). REBIND, on the other hand, has that property. > Feedback appreciated. Maybe the language needs to be SHOULD? > > * Section 4. Need a new condition to cover the case where the BIND > > half-succeeded, and then needed to be rewound. This condition would > > address the case where Overwrite is true, the destination > binding has > > been removed, but the new binding couldn't be created. > > But then it wouldn't be atomic, right? Well, what status element would you return in the case where the method half-succeeded, and then needed to re rewound? > > * Section 5. I think we need a condition for a cross-server > UNBIND failure. > > Could you please describe that situation in more detail? Well, what I had in mind was this; Resource R has two bindings C1(B1->R) and C2(B2->R). C1 and C2 are on different servers. The servers were both up and communicating when binding C2 was created. The server with C2 is temporarily down when the UNBIND comes in to server with C1. However, in this case, the server with C1 can still do the UNBIND without any problems, though it wouldn't be able to communicate about the UNBIND to the other server. Is this a problem the client wants to know about? Unsure. > > * Section 6.2. I think it would be helpful to have an example > > including REBIND and locks, showing submission of one or more lock > > tokens in the If header. > > Such as one involving locked source and destination > collections? That may be useful. What do others think? Yes, that's what I had in mind. > > > * Section 7.1.1. Might just be a personal preference, but > I'd rather > > see plain GUIDs rather than opaqulocktoken URI GUIDs in the example. > > A plain GUID isn't a legal URI. And unfortunately, there's > still (!) no registered URI scheme except "opaquelocktoken" > that's based on UUIDs (== > GUIDs) -- "urn:uuid" seems to be dead. Ah, hadn't caught that the value had to be an HREF. What are the benefits of the HREF formatting? - Jim From w3c-dist-auth-request@w3.org Mon Nov 29 22:59:43 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16923 for ; Mon, 29 Nov 2004 22:59:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CYz9i-00018j-CX for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 03:58:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CYz9h-000185-AG for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 03:58:21 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.34) id 1CYz9a-0002L2-JT for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 03:58:14 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iAU3vmNO015212 for ; Mon, 29 Nov 2004 22:57:48 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAU3vlYm288740 for ; Mon, 29 Nov 2004 22:57:47 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAU3vldE002342 for ; Mon, 29 Nov 2004 22:57:47 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAU3vl4c002339 for ; Mon, 29 Nov 2004 22:57:47 -0500 In-Reply-To: <41ABA9AB.2000803@gmx.de> To: "WebDAV (WebDAV WG)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 29 Nov 2004 22:57:46 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 11/29/2004 22:57:47, Serialize complete at 11/29/2004 22:57:47 Content-Type: multipart/alternative; boundary="=_alternative 0015C48585256F5C_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OF6C60684A.3D865178-ON85256F5C.0013354A-85256F5C.0015C487@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9024 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 03:58:22 +0000 This is a multipart message in MIME format. --=_alternative 0015C48585256F5C_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 11/29/2004 05:58:51 PM: > Jim Whitehead wrote: > > * Section 2.3. This section doesn't clearly address the semantics of COPY > > with Depth infinity. My recommendation is to add, after paragraph 3, text > > like this: > > > > "As specified in [RFC2518], a COPY with Depth infinity causes the collection > > resource to be duplicated, all of its bound children to be duplicated, and > > their children's bound children, and so on, to the bottom of the containment > > hierarchy. All of the segments of the bindings of the destination collection > > are the same as for the destination collection. However, the destination > > resource for all bindings in the destination collection are different from > > those of the source collection, since all resources have been duplicated, > > creating new resources with distinct DAV:resource-id properties." > > As far as I understand, the depth:infinity semantics for COPY follow > from what's being said about depth:0 and the RFC2518 infinity semantics > (just checking...). Thus, I'm not convinced that we need to say this, > but it probably wouldn't hurt either. Feedback appreciated. Jim: I'm OK with adding the paragraph, but what was the possible misunderstanding that this additional text was intended to clear up? How else could a Depth=infinity COPY work? > > * One gap in the current COPY semantics is the ability to copy a collection > > and its bindings. COPY depth 0 says copy all non-binding state. COPY depth > > infinity copies all bindings and makes duplicates of all bound resources. > > But, there's no single atomic operation (call it BINDDUP) that duplicates > > the collection and its bindings, but doesn't duplicate the bound resources. > > That is, there is no operation that does a COPY Depth 0 plus BIND for all > > members. So, two questions. Is there a compelling scenario for having a > > BINDDUP method? I confess I'm having a hard time coming up with one. Second, > > assuming there is a compelling scenario, can it be accomplished just using > > COPY, LOCK, and BIND, rather than having a special purpose method. Also > > unclear. > > I do agree we don't have that. I have no idea whether anybody needs it. > If it's needed, you can get very close to it using MKCOL, LOCK, n * BIND > and UNLOCK. I do not thing we need to special case this particular scenario, so I would vote not to add anything to handle it. > > * Section 2.6 -- there needs to be some discussion on the interactions of > > DAV:resource-id and versioning. As near as I can tell, the intent is that > > every revision will have a unique DAV:resource-id value. > > That's correct. I'm not sure why we would need to state this -- a > version resource clearly is not the same resource as it's VCR, so it > seems clear they'll never have the same DAV:resource-id. I agree with Julian. A version is a new resource created by the CHECKIN method. According to section 2.6, a new resource must be assigned a new resource-id, so each new version needs to be assigned a new, distinct resource-id. > > * Section 2.6, final paragraph, last two sentences. Change "must not" to > > "MUST NOT" (and eliminate the "For example" at the start of the sentence -- > > perhaps change to "Specifically," > > I agree for PUT/COPY, but things get unclear when we talk about MOVE (as > RFC2518 allows this to be implemented in terms of COPY/DELETE). REBIND, > on the other hand, has that property. Feedback appreciated. I'd vote to take Jim's suggested changes here. A UUID that is not preserved by the MOVE implementation for a repository should not be a candidate for a DAV:resource-id implementation. > > * Section 6.2. I think it would be helpful to have an example including > > REBIND and locks, showing submission of one or more lock tokens in the If > > header. > > Such as one involving locked source and destination collections? That > may be useful. What do others think? I continue to believe that the right place for locking examples is in a locking spec, and that the binding spec just needs to make clear which resources and which URL mappings are being modified by an operation, since this is all you need to know which locks are required. I believe this information is well-defined in the pre-conditions of the methods introduced by the binding spec. So I'd vote not to add such an example, but I could live with it, if a majority is for it. Cheers, Geoff --=_alternative 0015C48585256F5C_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 11/29/2004 05:58:51 PM:

> Jim Whitehead wrote:

> > * Section 2.3. This section doesn't clearly address the semantics of COPY
> > with Depth infinity. My recommendation is to add, after paragraph 3, text
> > like this:
> >
> > "As specified in [RFC2518], a COPY with Depth infinity causes the collection
> > resource to be duplicated, all of its bound children to be duplicated, and
> > their children's bound children, and so on, to the bottom of the containment
> > hierarchy. All of the segments of the bindings of the destination collection
> > are the same as for the destination collection. However, the destination
> > resource for all bindings in the destination collection are different from
> > those of the source collection, since all resources have been duplicated,
> > creating new resources with distinct DAV:resource-id properties."
>
> As far as I understand, the depth:infinity semantics for COPY follow
> from what's being said about depth:0 and the RFC2518 infinity semantics
> (just checking...). Thus, I'm not convinced that we need to say this,
> but it probably wouldn't hurt either. Feedback appreciated.

Jim: I'm OK with adding the paragraph, but what was the possible misunderstanding
that this additional text was intended to clear up?  How else could a Depth=infinity
COPY work?

> > * One gap in the current COPY semantics is the ability to copy a collection
> > and its bindings. COPY depth 0 says copy all non-binding state. COPY depth
> > infinity copies all bindings and makes duplicates of all bound resources.
> > But, there's no single atomic operation (call it BINDDUP) that duplicates
> > the collection and its bindings, but doesn't duplicate the bound resources.
> > That is, there is no operation that does a COPY Depth 0 plus BIND for all
> > members. So, two questions. Is there a compelling scenario for having a
> > BINDDUP method? I confess I'm having a hard time coming up with one. Second,
> > assuming there is a compelling scenario, can it be accomplished just using
> > COPY, LOCK, and BIND, rather than having a special purpose method. Also
> > unclear.
>
> I do agree we don't have that. I have no idea whether anybody needs it.
> If it's needed, you can get very close to it using MKCOL, LOCK, n * BIND
> and UNLOCK.

I do not thing we need to special case this particular scenario, so I would vote
not to add anything to handle it.

> > * Section 2.6 -- there needs to be some discussion on the interactions of
> > DAV:resource-id and versioning. As near as I can tell, the intent is that
> > every revision will have a unique DAV:resource-id value.
>
> That's correct. I'm not sure why we would need to state this -- a
> version resource clearly is not the same resource as it's VCR, so it
> seems clear they'll never have the same DAV:resource-id.

I agree with Julian.  A version is a new resource created by the CHECKIN method.
According to section 2.6, a new resource must be assigned a new resource-id,
so each new version needs to be assigned a new, distinct resource-id.

> > * Section 2.6, final paragraph, last two sentences. Change "must not" to
> > "MUST NOT" (and eliminate the "For example" at the start of the sentence --
> > perhaps change to "Specifically,"
>
> I agree for PUT/COPY, but things get unclear when we talk about MOVE (as
> RFC2518 allows this to be implemented in terms of COPY/DELETE). REBIND,
> on the other hand, has that property. Feedback appreciated.

I'd vote to take Jim's suggested changes here.  A UUID that is not preserved
by the MOVE implementation for a repository should not be a candidate for a
DAV:resource-id implementation.

> > * Section 6.2. I think it would be helpful to have an example including
> > REBIND and locks, showing submission of one or more lock tokens in the If
> > header.
>
> Such as one involving locked source and destination collections? That
> may be useful. What do others think?

I continue to believe that the right place for locking examples is in a
locking spec, and that the binding spec just needs to make clear which resources
and which URL mappings are being modified by an operation, since this is all
you need to know which locks are required.  I believe this information is
well-defined in the pre-conditions of the methods introduced by the binding
spec.  So I'd vote not to add such an example, but I could live with it,
if a majority is for it.

Cheers,
Geoff

--=_alternative 0015C48585256F5C_=-- From w3c-dist-auth-request@w3.org Tue Nov 30 08:13:02 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15448 for ; Tue, 30 Nov 2004 08:13:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZ7m8-0008Bt-H0 for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 13:10:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZ7m7-0008Av-3Z for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 13:10:35 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZ7m0-0006am-6B for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 13:10:28 +0000 Received: (qmail 7382 invoked by uid 65534); 30 Nov 2004 13:10:02 -0000 Received: from p5082459B.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.69.155) by mail.gmx.net (mp006) with SMTP; 30 Nov 2004 14:10:02 +0100 X-Authenticated: #1915285 Message-ID: <41AC712A.30205@gmx.de> Date: Tue, 30 Nov 2004 14:10:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: "WebDAV (WebDAV WG)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41AC712A.30205@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9025 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 13:10:36 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > As far as I understand, the depth:infinity semantics for COPY follow > > from what's being said about depth:0 and the RFC2518 infinity semantics > > (just checking...). Thus, I'm not convinced that we need to say this, > > but it probably wouldn't hurt either. Feedback appreciated. > > Jim: I'm OK with adding the paragraph, but what was the possible > misunderstanding > that this additional text was intended to clear up? How else could a > Depth=infinity > COPY work? Yes, I'd like to understand that as well before adding additional text. > ... > > > * Section 2.6, final paragraph, last two sentences. Change "must > not" to > > > "MUST NOT" (and eliminate the "For example" at the start of the > sentence -- > > > perhaps change to "Specifically," > > > > I agree for PUT/COPY, but things get unclear when we talk about MOVE (as > > RFC2518 allows this to be implemented in terms of COPY/DELETE). REBIND, > > on the other hand, has that property. Feedback appreciated. > > I'd vote to take Jim's suggested changes here. A UUID that is not > preserved > by the MOVE implementation for a repository should not be a candidate for a > DAV:resource-id implementation. I disagree here. We spent a lot of time discussing whether we can change the semantics for MOVE, and in the end we agreed to leave MOVE alone and to add REBIND. Section 2.5 specifies that a server MAY implement MOVE as REBIND (atomic), but that it doesn't have to. We should leave it at that. > > > * Section 6.2. I think it would be helpful to have an example including > > > REBIND and locks, showing submission of one or more lock tokens in > the If > > > header. > > > > Such as one involving locked source and destination collections? That > > may be useful. What do others think? > > I continue to believe that the right place for locking examples is in a > locking spec, and that the binding spec just needs to make clear which > resources > and which URL mappings are being modified by an operation, since this is > all > you need to know which locks are required. I believe this information is > well-defined in the pre-conditions of the methods introduced by the binding > spec. So I'd vote not to add such an example, but I could live with it, > if a majority is for it. I agree (preferring not to add an example). On the other hand, adding just an example is way better than adding new normative text (which really belonsg into the base spec or a specific locking spec). If we want to add an example, it would be good to if we could agree exactly what the example should show. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Nov 30 10:00:07 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24905 for ; Tue, 30 Nov 2004 10:00:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZ9TA-0001qV-OA for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 14:59:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZ9T9-0001q1-NT for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 14:59:07 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZ9T3-0001il-26 for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 14:59:01 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iAUEwvF7013264 for ; Tue, 30 Nov 2004 09:58:57 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAUEwvGZ273360 for ; Tue, 30 Nov 2004 09:58:57 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAUEwvsF022301 for ; Tue, 30 Nov 2004 09:58:57 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAUEwvMr022295 for ; Tue, 30 Nov 2004 09:58:57 -0500 In-Reply-To: <41AC712A.30205@gmx.de> To: "WebDAV (WebDAV WG)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 30 Nov 2004 09:58:55 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 11/30/2004 09:58:57, Serialize complete at 11/30/2004 09:58:57 Content-Type: multipart/alternative; boundary="=_alternative 00524C3985256F5C_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OF18526917.D8283D75-ON85256F5C.0050E573-85256F5C.00524C3F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9026 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 14:59:08 +0000 This is a multipart message in MIME format. --=_alternative 00524C3985256F5C_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 11/30/2004 08:10:02 AM: > Geoffrey M Clemm wrote: > > > > * Section 2.6, final paragraph, last two sentences. Change "must not" to > > > > "MUST NOT" (and eliminate the "For example" at the start of the sentence -- > > > > perhaps change to "Specifically," > > I'd vote to take Jim's suggested changes here. A UUID that is not > > preserved > > by the MOVE implementation for a repository should not be a candidate for a > > DAV:resource-id implementation. > I disagree here. We spent a lot of time discussing whether we can change > the semantics for MOVE, and in the end we agreed to leave MOVE alone and > to add REBIND. Section 2.5 specifies that a server MAY implement MOVE as > REBIND (atomic), but that it doesn't have to. We should leave it at that. I wasn't suggesting that we change the semantics for MOVE (and I agree that we cannot do so). What we can do is define the semantics for DAV:resource-id, since that is a new property that is being introduced by this spec. So what I was suggesting was that we state that a server cannot implement DAV:resource-id in a way that it is modified during a MOVE operation. This just means that a server cannot use some existing custom property to implement DAV:resource-id if that custom property is not preserved during a MOVE. Cheers, Geoff --=_alternative 00524C3985256F5C_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 11/30/2004 08:10:02 AM:

> Geoffrey M Clemm wrote:

> >  > > * Section 2.6, final paragraph, last two sentences. Change "must not" to
> >  > > "MUST NOT" (and eliminate the "For example" at the start of the sentence --
> >  > > perhaps change to "Specifically,"

> > I'd vote to take Jim's suggested changes here.  A UUID that is not
> > preserved
> > by the MOVE implementation for a repository should not be a candidate for a
> > DAV:resource-id implementation.

> I disagree here. We spent a lot of time discussing whether we can change
> the semantics for MOVE, and in the end we agreed to leave MOVE alone and
> to add REBIND. Section 2.5 specifies that a server MAY implement MOVE as
> REBIND (atomic), but that it doesn't have to. We should leave it at that.
I wasn't suggesting that we change the semantics for MOVE (and I agree that
we cannot do so).  What we can do is define the semantics for DAV:resource-id,
since that is a new property that is being introduced by this spec.  So
what I was suggesting was that we state that a server cannot implement
DAV:resource-id in a way that it is modified during a MOVE operation.  This
just means that a server cannot use some existing custom property to implement
DAV:resource-id if that custom property is not preserved during a MOVE.

Cheers,
Geoff


--=_alternative 00524C3985256F5C_=-- From w3c-dist-auth-request@w3.org Tue Nov 30 11:49:42 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06011 for ; Tue, 30 Nov 2004 11:49:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZBAr-0007Zv-8O for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 16:48:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZBAq-0007ZH-89 for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 16:48:20 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZBAj-0002AR-AA for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 16:48:13 +0000 Received: (qmail 14486 invoked by uid 65534); 30 Nov 2004 16:47:47 -0000 Received: from p50824688.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.70.136) by mail.gmx.net (mp016) with SMTP; 30 Nov 2004 17:47:47 +0100 X-Authenticated: #1915285 Message-ID: <41ACA432.70806@gmx.de> Date: Tue, 30 Nov 2004 17:47:46 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: "WebDAV (WebDAV WG)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41ACA432.70806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9027 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 16:48:21 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > I wasn't suggesting that we change the semantics for MOVE (and I agree that > we cannot do so). What we can do is define the semantics for > DAV:resource-id, > since that is a new property that is being introduced by this spec. So > what I was suggesting was that we state that a server cannot implement > DAV:resource-id in a way that it is modified during a MOVE operation. This > just means that a server cannot use some existing custom property to > implement > DAV:resource-id if that custom property is not preserved during a MOVE. Understood. However, that makes it impossible to implement a server that indeed does support DAV:resource-id and REBIND while keeping MOVE's old semantics (and, as a matter of fact, this is what we want to do). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Nov 30 12:34:30 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10404 for ; Tue, 30 Nov 2004 12:34:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZBsL-00007S-O8 for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 17:33:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZBsJ-00006p-Su for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 17:33:15 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZBsD-0008BP-2D for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 17:33:09 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAUHXAaa027356 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 30 Nov 2004 09:33:11 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "WebDAV (WebDAV WG)" From: Lisa Dusseault Date: Tue, 30 Nov 2004 09:32:58 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/E0996999-42F5-11D9-B57F-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9028 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 17:33:17 +0000 Content-Transfer-Encoding: 7bit Weighing in... On Nov 29, 2004, at 7:57 PM, Geoffrey M Clemm wrote: > Julian wrote on 11/29/2004 05:58:51 PM: > >> Jim Whitehead wrote: > >>> * Section 2.3. This section doesn't clearly address the semantics of >>> COPY >>> with Depth infinity. My recommendation is to add, after paragraph 3, >>> text >>> like this: >>> >>> "As specified in [RFC2518], a COPY with Depth infinity causes the >>> collection >>> resource to be duplicated, all of its bound children to be >>> duplicated, and >>> their children's bound children, and so on, to the bottom of the >>> containment >>> hierarchy. All of the segments of the bindings of the destination >>> collection >>> are the same as for the destination collection. However, the >>> destination >>> resource for all bindings in the destination collection are >>> different from >>> those of the source collection, since all resources have been >>> duplicated, >>> creating new resources with distinct DAV:resource-id properties." >> >> As far as I understand, the depth:infinity semantics for COPY follow >> from what's being said about depth:0 and the RFC2518 infinity >> semantics >> (just checking...). Thus, I'm not convinced that we need to say this, >> but it probably wouldn't hurt either. Feedback appreciated. > > Jim: I'm OK with adding the paragraph, but what was the possible > misunderstanding > that this additional text was intended to clear up? How else could a > Depth=infinity > COPY work? I agree with Jim that we should add clearer wording here. The ingenuity of implementors is great, and that includes a surprising ability to come to different conclusions than the writers of a specification. > >>> * Section 2.6 -- there needs to be some discussion on the >>> interactions of >>> DAV:resource-id and versioning. As near as I can tell, the intent is >>> that >>> every revision will have a unique DAV:resource-id value. >> >> That's correct. I'm not sure why we would need to state this -- a >> version resource clearly is not the same resource as it's VCR, so it >> seems clear they'll never have the same DAV:resource-id. > > I agree with Julian. A version is a new resource created by the > CHECKIN method. > According to section 2.6, a new resource must be assigned a new > resource-id, > so each new version needs to be assigned a new, distinct resource-id. Great -- so we agree on what should happen. As Jim suggests, let's put it in the spec. > >>> * Section 6.2. I think it would be helpful to have an example >>> including >>> REBIND and locks, showing submission of one or more lock tokens in >>> the If >>> header. >> >> Such as one involving locked source and destination collections? That >> may be useful. What do others think? > > I continue to believe that the right place for locking examples is in a > locking spec, and that the binding spec just needs to make clear which > resources > and which URL mappings are being modified by an operation, since this > is all > you need to know which locks are required. I believe this information > is > well-defined in the pre-conditions of the methods introduced by the > binding > spec. So I'd vote not to add such an example, but I could live with > it, > if a majority is for it. An example with locks and REBIND would be great. Other examples with locks and bound resources (and requirements about what URL must be used/supported in the requests) would also be great. Lisa From w3c-dist-auth-request@w3.org Tue Nov 30 12:56:55 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14206 for ; Tue, 30 Nov 2004 12:56:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZCDL-0000iw-M1 for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 17:54:59 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZCDK-0000iS-KJ for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 17:54:58 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by bart.w3.org with esmtp (Exim 4.34) id 1CZCDK-0001Mh-FR for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 17:54:58 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iAUHsRkO017315 for ; Tue, 30 Nov 2004 12:54:27 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAUHsRfu273166 for ; Tue, 30 Nov 2004 12:54:27 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAUHsRdr011487 for ; Tue, 30 Nov 2004 12:54:27 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAUHsPns011367 for ; Tue, 30 Nov 2004 12:54:27 -0500 In-Reply-To: <41ACA432.70806@gmx.de> To: "WebDAV (WebDAV WG)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 30 Nov 2004 12:54:26 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 11/30/2004 12:54:26, Serialize complete at 11/30/2004 12:54:26 Content-Type: multipart/alternative; boundary="=_alternative 00625DBA85256F5C_=" Received-SPF: none (bart.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OFAE044EA0.7593B5AD-ON85256F5C.006210C7-85256F5C.00625DBB@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9029 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 17:54:59 +0000 This is a multipart message in MIME format. --=_alternative 00625DBA85256F5C_= Content-Type: text/plain; charset="US-ASCII" OK, since I don't feel strongly about this, I'm happy to defer to Julian's preference. Cheers, Geoff Julian wrote on 11/30/2004 11:47:46 AM: > > Geoffrey M Clemm wrote: > > > I wasn't suggesting that we change the semantics for MOVE (and I agree that > > we cannot do so). What we can do is define the semantics for > > DAV:resource-id, > > since that is a new property that is being introduced by this spec. So > > what I was suggesting was that we state that a server cannot implement > > DAV:resource-id in a way that it is modified during a MOVE operation. This > > just means that a server cannot use some existing custom property to > > implement > > DAV:resource-id if that custom property is not preserved during a MOVE. > > Understood. However, that makes it impossible to implement a server that > indeed does support DAV:resource-id and REBIND while keeping MOVE's old > semantics (and, as a matter of fact, this is what we want to do). > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 00625DBA85256F5C_= Content-Type: text/html; charset="US-ASCII"
OK, since I don't feel strongly about this, I'm happy to defer to
Julian's preference.

Cheers,
Geoff

Julian wrote on 11/30/2004 11:47:46 AM:

>
> Geoffrey M Clemm wrote:
>
> > I wasn't suggesting that we change the semantics for MOVE (and I agree that
> > we cannot do so).  What we can do is define the semantics for
> > DAV:resource-id,
> > since that is a new property that is being introduced by this spec.  So
> > what I was suggesting was that we state that a server cannot implement
> > DAV:resource-id in a way that it is modified during a MOVE operation.  This
> > just means that a server cannot use some existing custom property to
> > implement
> > DAV:resource-id if that custom property is not preserved during a MOVE.
>
> Understood. However, that makes it impossible to implement a server that
> indeed does support DAV:resource-id and REBIND while keeping MOVE's old
> semantics (and, as a matter of fact, this is what we want to do).
>
> Best regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 00625DBA85256F5C_=-- From w3c-dist-auth-request@w3.org Tue Nov 30 13:19:21 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16311 for ; Tue, 30 Nov 2004 13:19:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZCZU-0000xc-4B for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 18:17:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZCZS-0000wf-8T for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 18:17:50 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZCZL-0005zI-D8 for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 18:17:43 +0000 Received: (qmail 27056 invoked by uid 65534); 30 Nov 2004 18:17:17 -0000 Received: from p50824688.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.70.136) by mail.gmx.net (mp009) with SMTP; 30 Nov 2004 19:17:17 +0100 X-Authenticated: #1915285 Message-ID: <41ACB92B.3030108@gmx.de> Date: Tue, 30 Nov 2004 19:17:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , "WebDAV (WebDAV WG)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41ACB92B.3030108@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9030 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 18:17:52 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >> Jim: I'm OK with adding the paragraph, but what was the possible >> misunderstanding >> that this additional text was intended to clear up? How else could a >> Depth=infinity >> COPY work? > > > I agree with Jim that we should add clearer wording here. The ingenuity of > implementors is great, and that includes a surprising ability to come to > different conclusions than the writers of a specification. I'd still like to know how it is clearer... >> I agree with Julian. A version is a new resource created by the >> CHECKIN method. >> According to section 2.6, a new resource must be assigned a new >> resource-id, >> so each new version needs to be assigned a new, distinct resource-id. > > > Great -- so we agree on what should happen. As Jim suggests, > let's put it in the spec. Again, before we put additional spec into the spec, it should be clear what problem it solves. I understand that you lean to "more is better", but please acknowledge that many people writing specs disagree. >>>> * Section 6.2. I think it would be helpful to have an example including >>>> REBIND and locks, showing submission of one or more lock tokens in >>>> the If >>>> header. >>> >>> >>> Such as one involving locked source and destination collections? That >>> may be useful. What do others think? >> >> >> I continue to believe that the right place for locking examples is in a >> locking spec, and that the binding spec just needs to make clear which >> resources >> and which URL mappings are being modified by an operation, since this >> is all >> you need to know which locks are required. I believe this information is >> well-defined in the pre-conditions of the methods introduced by the >> binding >> spec. So I'd vote not to add such an example, but I could live with it, >> if a majority is for it. > > > An example with locks and REBIND would be great. Other examples with locks > and bound resources (and requirements about what URL must be used/supported > in the requests) would also be great. I'm not sure how locking examples for REBIND are going to help much. REBIND is just like MOVE, except for slightly different marshalling. I'm not against adding an example per se, but if we do it it should really contain something that's not available elsewhere. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Nov 30 13:35:55 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17772 for ; Tue, 30 Nov 2004 13:35:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZCqD-0008Mu-DC for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 18:35:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZCqC-0008Ly-43; Tue, 30 Nov 2004 18:35:08 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.34) id 1CZCq5-0003wC-DJ; Tue, 30 Nov 2004 18:35:01 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iAUIZ6Cl023552; Tue, 30 Nov 2004 13:35:06 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAUIZ6GZ273366; Tue, 30 Nov 2004 13:35:06 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAUIZ6ou022739; Tue, 30 Nov 2004 13:35:06 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAUIZ67l022732; Tue, 30 Nov 2004 13:35:06 -0500 In-Reply-To: <41ACB92B.3030108@gmx.de> To: Julian Reschke Cc: Lisa Dusseault , "WebDAV (WebDAV WG)" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 30 Nov 2004 13:35:04 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 11/30/2004 13:35:05, Serialize complete at 11/30/2004 13:35:05 Content-Type: multipart/alternative; boundary="=_alternative 0066162685256F5C_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/OFF55FF746.BE162DCC-ON85256F5C.00656690-85256F5C.00661628@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9031 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 18:35:09 +0000 This is a multipart message in MIME format. --=_alternative 0066162685256F5C_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian. A new section of text or example can do more harm than good (a classic being the "MOVE is logically a COPY/DELETE" section from 2518). So I think it is a reasonable criteria to require that any proposed addition be motivated by at least one example of a misunderstanding that may arise with the current text. Cheers, Geoff Julian wrote on 11/30/2004 01:17:15 PM: > > Lisa Dusseault wrote: > >> Jim: I'm OK with adding the paragraph, but what was the possible > >> misunderstanding > >> that this additional text was intended to clear up? How else could a > >> Depth=infinity > >> COPY work? > > > > > > I agree with Jim that we should add clearer wording here. The ingenuity of > > implementors is great, and that includes a surprising ability to come to > > different conclusions than the writers of a specification. > > I'd still like to know how it is clearer... > > >> I agree with Julian. A version is a new resource created by the > >> CHECKIN method. > >> According to section 2.6, a new resource must be assigned a new > >> resource-id, > >> so each new version needs to be assigned a new, distinct resource-id. > > > > > > Great -- so we agree on what should happen. As Jim suggests, > > let's put it in the spec. > > Again, before we put additional spec into the spec, it should be clear > what problem it solves. I understand that you lean to "more is better", > but please acknowledge that many people writing specs disagree. > > >>>> * Section 6.2. I think it would be helpful to have an example including > >>>> REBIND and locks, showing submission of one or more lock tokens in > >>>> the If > >>>> header. > >>> > >>> > >>> Such as one involving locked source and destination collections? That > >>> may be useful. What do others think? > >> > >> > >> I continue to believe that the right place for locking examples is in a > >> locking spec, and that the binding spec just needs to make clear which > >> resources > >> and which URL mappings are being modified by an operation, since this > >> is all > >> you need to know which locks are required. I believe this information is > >> well-defined in the pre-conditions of the methods introduced by the > >> binding > >> spec. So I'd vote not to add such an example, but I could live with it, > >> if a majority is for it. > > > > > > An example with locks and REBIND would be great. Other examples with locks > > and bound resources (and requirements about what URL must be used/supported > > in the requests) would also be great. > > I'm not sure how locking examples for REBIND are going to help much. > REBIND is just like MOVE, except for slightly different marshalling. I'm > not against adding an example per se, but if we do it it should really > contain something that's not available elsewhere. > > Julian > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0066162685256F5C_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian.  A new section of text or example can do more
harm than good (a classic being the "MOVE is logically a COPY/DELETE"
section from 2518).

So I think it is a reasonable criteria to require that any proposed
addition be motivated by at least one example of a misunderstanding
that may arise with the current text.

Cheers,
Geoff

Julian wrote on 11/30/2004 01:17:15 PM:

>
> Lisa Dusseault wrote:
> >> Jim: I'm OK with adding the paragraph, but what was the possible
> >> misunderstanding
> >> that this additional text was intended to clear up?  How else could a
> >> Depth=infinity
> >> COPY work?
> >
> >
> > I agree with Jim that we should add clearer wording here.  The ingenuity of
> > implementors is great, and that includes a surprising ability to come to
> > different conclusions than the writers of a specification.
>
> I'd still like to know how it is clearer...
>
> >> I agree with Julian.  A version is a new resource created by the
> >> CHECKIN method.
> >> According to section 2.6, a new resource must be assigned a new
> >> resource-id,
> >> so each new version needs to be assigned a new, distinct resource-id.
> >
> >
> > Great -- so we agree on what should happen.  As Jim suggests,
> > let's put it in the spec.
>
> Again, before we put additional spec into the spec, it should be clear
> what problem it solves. I understand that you lean to "more is better",
> but please acknowledge that many people writing specs disagree.
>
> >>>> * Section 6.2. I think it would be helpful to have an example including
> >>>> REBIND and locks, showing submission of one or more lock tokens in
> >>>> the If
> >>>> header.
> >>>
> >>>
> >>> Such as one involving locked source and destination collections? That
> >>> may be useful. What do others think?
> >>
> >>
> >> I continue to believe that the right place for locking examples is in a
> >> locking spec, and that the binding spec just needs to make clear which
> >> resources
> >> and which URL mappings are being modified by an operation, since this
> >> is all
> >> you need to know which locks are required.  I believe this information is
> >> well-defined in the pre-conditions of the methods introduced by the
> >> binding
> >> spec.  So I'd vote not to add such an example, but I could live with it,
> >> if a majority is for it.
> >
> >
> > An example with locks and REBIND would be great.  Other examples with locks
> > and bound resources (and requirements about what URL must be used/supported
> > in the requests) would also be great.
>
> I'm not sure how locking examples for REBIND are going to help much.
> REBIND is just like MOVE, except for slightly different marshalling. I'm
> not against adding an example per se, but if we do it it should really
> contain something that's not available elsewhere.
>
> Julian
>
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0066162685256F5C_=-- From w3c-dist-auth-request@w3.org Tue Nov 30 14:19:21 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22167 for ; Tue, 30 Nov 2004 14:19:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZDVx-0008IG-Pz for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 19:18:17 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZDVx-0008Hh-IP for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 19:18:17 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CZDVx-0007l2-9K for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 19:18:17 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAUJGBaa005577 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 30 Nov 2004 11:16:11 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4446EDB0-4304-11D9-B57F-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , WebDAV (WebDAV WG) From: Lisa Dusseault Date: Tue, 30 Nov 2004 11:15:58 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/4446EDB0-4304-11D9-B57F-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9032 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 19:18:17 +0000 Content-Transfer-Encoding: 7bit I would say that the absence of text more often causes problems than additional text. We shouldn't let one example scare us. In fact one could argue that we needed *more* text to explain what MOVE was about so that people understood what the authors had in mind. lisa On Nov 30, 2004, at 10:35 AM, Geoffrey M Clemm wrote: > I agree with Julian. A new section of text or example can do more > harm than good (a classic being the "MOVE is logically a COPY/DELETE" > section from 2518). > > So I think it is a reasonable criteria to require that any proposed > addition be motivated by at least one example of a misunderstanding > that may arise with the current text. > > Cheers, > Geoff > > Julian wrote on 11/30/2004 01:17:15 PM: > >> >> Lisa Dusseault wrote: >>>> Jim: I'm OK with adding the paragraph, but what was the possible >>>> misunderstanding >>>> that this additional text was intended to clear up? How else could >>>> a >>>> Depth=infinity >>>> COPY work? >>> >>> >>> I agree with Jim that we should add clearer wording here. The > ingenuity of >>> implementors is great, and that includes a surprising ability to come > to >>> different conclusions than the writers of a specification. >> >> I'd still like to know how it is clearer... >> >>>> I agree with Julian. A version is a new resource created by the >>>> CHECKIN method. >>>> According to section 2.6, a new resource must be assigned a new >>>> resource-id, >>>> so each new version needs to be assigned a new, distinct >>>> resource-id. >>> >>> >>> Great -- so we agree on what should happen. As Jim suggests, >>> let's put it in the spec. >> >> Again, before we put additional spec into the spec, it should be clear >> what problem it solves. I understand that you lean to "more is >> better", >> but please acknowledge that many people writing specs disagree. >> >>>>>> * Section 6.2. I think it would be helpful to have an example > including >>>>>> REBIND and locks, showing submission of one or more lock tokens in >>>>>> the If >>>>>> header. >>>>> >>>>> >>>>> Such as one involving locked source and destination collections? > That >>>>> may be useful. What do others think? >>>> >>>> >>>> I continue to believe that the right place for locking examples is >>>> in > a >>>> locking spec, and that the binding spec just needs to make clear > which >>>> resources >>>> and which URL mappings are being modified by an operation, since >>>> this > >>>> is all >>>> you need to know which locks are required. I believe this > information is >>>> well-defined in the pre-conditions of the methods introduced by the >>>> binding >>>> spec. So I'd vote not to add such an example, but I could live with > it, >>>> if a majority is for it. >>> >>> >>> An example with locks and REBIND would be great. Other examples with > locks >>> and bound resources (and requirements about what URL must be > used/supported >>> in the requests) would also be great. >> >> I'm not sure how locking examples for REBIND are going to help much. >> REBIND is just like MOVE, except for slightly different marshalling. >> I'm > >> not against adding an example per se, but if we do it it should really >> contain something that's not available elsewhere. >> >> Julian >> >> >> >> -- >> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >> From w3c-dist-auth-request@w3.org Tue Nov 30 14:25:06 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22693 for ; Tue, 30 Nov 2004 14:25:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZDbt-00029m-Ib for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 19:24:25 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZDbt-00029I-Bp for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 19:24:25 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CZDbs-0001FU-Ur for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 19:24:25 +0000 Received: (qmail 31444 invoked by uid 65534); 30 Nov 2004 19:23:52 -0000 Received: from pD9535451.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.84.81) by mail.gmx.net (mp021) with SMTP; 30 Nov 2004 20:23:52 +0100 X-Authenticated: #1915285 Message-ID: <41ACC8C5.6040001@gmx.de> Date: Tue, 30 Nov 2004 20:23:49 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "'WebDAV (WebDAV WG)'" References: <200411300130.iAU1UIiv021516@cats-mx1.ucsc.edu> In-Reply-To: <200411300130.iAU1UIiv021516@cats-mx1.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41ACC8C5.6040001@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9033 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 19:24:25 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >>I'm fine with stating that it's possible to define a method that >>*explicitly* has that semantics (affecting other bindings). >>How about...: >> >>"It is permissible, however, for future method definitions >>(e.g., a DESTROY method) to have semantics that explicitly >>remove all bindings and/or immediately reclaim system resources." > > > Fine with me. >>>* Section 2.1. I think it would be more clear to separate out the >>>discussion of loops and bindings, and make it a separate >> >>section (say, >> >>>2.2) This issue comes up frequently enough that it would be good to >>>make it easy to find this issue in the TOC. Also, a mention of the >>>Already Reported status code would be good to have here, >> >>since it also mentions 506. >> >>The last sentence of the first paragraph already mentions the >>506 status. > > > Right -- it should mention 208 Already Reported as well. >>Would adding a new subsection ("Bind Loops") and moving the >>first paragraph of 2.1 into that subsection be what you have in mind? > > > Yes. (see above) >>>* There should also be some text addressing COPY depth infinity and >>>loops -- in some instances during a COPY with Depth infinity, the >>>server really wants to recreate the binding that causes the loop, >>>rather than continuing to make duplicate resources. This is >> >>somewhat >> >>>addressed by the final paragraph in Section 2.3, but not exactly. >> >>I thought it was. Could you be more specific. Maybe expand >>that statement so that it becomes clear that this applies to >>loop situations as well? > > > Maybe that would do it. I think the current language may actually address > loops, but since loops aren't explicitly discussed, it's not > straightforward. (to be discussed) >>>* Section 2.6 -- there needs to be some discussion on the >> >>interactions >> >>>of DAV:resource-id and versioning. As near as I can tell, >> >>the intent >> >>>is that every revision will have a unique DAV:resource-id value. >> >>That's correct. I'm not sure why we would need to state this >>-- a version resource clearly is not the same resource as >>it's VCR, so it seems clear they'll never have the same >>DAV:resource-id. > > > I think it's worth explicitly mentioning this. I'm still not convinced. Can you explain how a reader of both RFC3253 and BIND would come to the conclusion that a version can be the "same" resource as the VCR? > ... >>>* Section 4. Need a new condition to cover the case where the BIND >>>half-succeeded, and then needed to be rewound. This condition would >>>address the case where Overwrite is true, the destination >> >>binding has >> >>>been removed, but the new binding couldn't be created. >> >>But then it wouldn't be atomic, right? > > > Well, what status element would you return in the case where the method > half-succeeded, and then needed to re rewound? That depends on why the new binding couldn't be created....? >>>* Section 5. I think we need a condition for a cross-server >> >>UNBIND failure. >> >>Could you please describe that situation in more detail? > > > Well, what I had in mind was this; Resource R has two bindings C1(B1->R) and > C2(B2->R). C1 and C2 are on different servers. The servers were both up and > communicating when binding C2 was created. The server with C2 is temporarily > down when the UNBIND comes in to server with C1. However, in this case, the > server with C1 can still do the UNBIND without any problems, though it > wouldn't be able to communicate about the UNBIND to the other server. Is > this a problem the client wants to know about? Unsure. I'm not seeing a problem (yet). C1 would be removed, while C2 wouldn't. It's the server's job to ensure that resource R isn't negatively affected. >>>* Section 6.2. I think it would be helpful to have an example >>>including REBIND and locks, showing submission of one or more lock >>>tokens in the If header. >> >>Such as one involving locked source and destination >>collections? That may be useful. What do others think? > > > Yes, that's what I had in mind. Could you be more specific about which case you think would need to be clarified? Is this about the specific marshalling of REBIND, or about locking semantics in face of multiple bindings? >>>* Section 7.1.1. Might just be a personal preference, but >> >>I'd rather >> >>>see plain GUIDs rather than opaqulocktoken URI GUIDs in the example. >> >>A plain GUID isn't a legal URI. And unfortunately, there's >>still (!) no registered URI scheme except "opaquelocktoken" >>that's based on UUIDs (== >>GUIDs) -- "urn:uuid" seems to be dead. > > > Ah, hadn't caught that the value had to be an HREF. What are the benefits of > the HREF formatting? It's way "everybody" does it (WebDAV lock tokens, WebDAV ordering, Atom IDs, XML namespaces). Also, UUIDs may not always be the best identifier available. For instance, for lock tokens a server may be using a single UUID + a counter (as allowed in the opaquelockoken syntax) -- why shouldn't it do the same for resource IDs? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Nov 30 14:40:10 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24917 for ; Tue, 30 Nov 2004 14:40:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZDqG-0007Cr-TL for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 19:39:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZDqC-0007BM-LP for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 19:39:12 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CZDq5-0006mw-PT for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 19:39:06 +0000 Received: (qmail 15574 invoked by uid 65534); 30 Nov 2004 19:38:40 -0000 Received: from pD9535451.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.84.81) by mail.gmx.net (mp030) with SMTP; 30 Nov 2004 20:38:40 +0100 X-Authenticated: #1915285 Message-ID: <41ACCC3C.2040006@gmx.de> Date: Tue, 30 Nov 2004 20:38:36 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: "WebDAV (WebDAV WG)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41ACCC3C.2040006@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9034 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 19:39:16 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > OK, since I don't feel strongly about this, I'm happy to defer to > Julian's preference. OK, partial fix that takes care of most of Jim's problems -- (): On the other hand, any method that affects an existing resource must not change the value of its DAV:resource-id property. Specifically, a PUT or a COPY that updates an existing resource must not change the value of its DAV:resource-id property. A REBIND, since it does not create a new resource, but only changes the location of an existing resource, must not change the value of the DAV:resource-id property. I'm not sure whether we need to change more (such as say something about MOVE for which it's hard to make any prediction because of RFC2518's semantics). Feedback appreciated. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Nov 30 15:16:50 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29783 for ; Tue, 30 Nov 2004 15:16:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZEPn-0003tT-0J for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 20:15:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CZEPl-0003jk-Bs for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 20:15:57 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CZEOy-0000mI-Bs for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 20:15:08 +0000 Received: (qmail 23637 invoked by uid 65534); 30 Nov 2004 20:14:40 -0000 Received: from pD9535451.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.84.81) by mail.gmx.net (mp013) with SMTP; 30 Nov 2004 21:14:40 +0100 X-Authenticated: #1915285 Message-ID: <41ACD4AB.8070207@gmx.de> Date: Tue, 30 Nov 2004 21:14:35 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@cs.ucsc.edu CC: "WebDAV (WebDAV WG)" References: <200411292204.iATM45vm026136@cats-mx3.ucsc.edu> In-Reply-To: <200411292204.iATM45vm026136@cats-mx3.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41ACD4AB.8070207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9035 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 20:15:59 +0000 Content-Transfer-Encoding: 7bit OK, I'm going back to Jim's original issues list to ensure that we are on the page re: answers, fixes, issues and open questions (that are not yet on the issues list). Jim Whitehead wrote: > ... > * Terminology section (1.1): There is a reference to > draft-fielding-rfc2396bis here, and also in Section 3.2 (perhaps it occurs > elsewhere in the specification as well). References in RFCs need to be to > documents of RFC level stability (or equivalent). If > draft-fielding-rfc2396bis hasn't yet been approved by the IESG, we should > just revert back to RFC 2396. I think this answered. > * Section 2, paragraph 3. The language here would preclude the future > definition of a DESTROY method which had the semantics of removing the state > of a resource from a server, irregardless of any containment relationships > that may hold it. Such a method could be quite useful for records management > functionality, in order to implement a records disposition policy that > specified deletion at a certain time. My recommended tweak to the language > of section 2 is minor: add the following sentence to the end of the > paragraph: > > "It is permissible, however, for future method definitions (e.g., a DESTROY > method) to have semantics that remove all bindings and/or immediately > reclaim system resources." Fixed: > * Section 2.1. I think it would be more clear to separate out the discussion > of loops and bindings, and make it a separate section (say, 2.2) This issue > comes up frequently enough that it would be good to make it easy to find > this issue in the TOC. Also, a mention of the Already Reported status code > would be good to have here, since it also mentions 506. Fixed: > * Section 2.3. This section doesn't clearly address the semantics of COPY > with Depth infinity. My recommendation is to add, after paragraph 3, text > like this: > > "As specified in [RFC2518], a COPY with Depth infinity causes the collection > resource to be duplicated, all of its bound children to be duplicated, and > their children's bound children, and so on, to the bottom of the containment > hierarchy. All of the segments of the bindings of the destination collection > are the same as for the destination collection. However, the destination > resource for all bindings in the destination collection are different from > those of the source collection, since all resources have been duplicated, > creating new resources with distinct DAV:resource-id properties." Issue opened , but unclear whether we really need additional text. Feedback to Geoff's and my question appreciated. > * There should also be some text addressing COPY depth infinity and loops -- > in some instances during a COPY with Depth infinity, the server really wants > to recreate the binding that causes the loop, rather than continuing to make > duplicate resources. This is somewhat addressed by the final paragraph in > Section 2.3, but not exactly. Issue opened: . > * One gap in the current COPY semantics is the ability to copy a collection > and its bindings. COPY depth 0 says copy all non-binding state. COPY depth > infinity copies all bindings and makes duplicates of all bound resources. > But, there's no single atomic operation (call it BINDDUP) that duplicates > the collection and its bindings, but doesn't duplicate the bound resources. > That is, there is no operation that does a COPY Depth 0 plus BIND for all > members. So, two questions. Is there a compelling scenario for having a > BINDDUP method? I confess I'm having a hard time coming up with one. Second, > assuming there is a compelling scenario, can it be accomplished just using > COPY, LOCK, and BIND, rather than having a special purpose method. Also > unclear. I think we have consensus that we don't need to consider this case as important enough to require special discussion or even a new method. > * It might make sense to create an example covering the situation described > in the final paragraph of Section 2.3. I'm not 100% sure I know what > scenario this paragraph addresses, other reading the spec. for the first > time would presumably have a tougher time. Issue opened (see above): . Q: would an example involving a COPY of a BIND loop resolve both issues? > * Section 2.4, second paragraph. "MUST NOT" is used in the text of an > example -- seems like it should be lower case here instead. Fixed: . > * Section 2.6 -- there needs to be some discussion on the interactions of > DAV:resource-id and versioning. As near as I can tell, the intent is that > every revision will have a unique DAV:resource-id value. IMHO still unclear. Awaiting feedback explaining why a reader of both specs would come to the conclusion that a version is the "same resource" as the VCR. > * Section 2.6 -- I think it would help clarify the text to say that one > possible implementation technique is to use a GUID for the unique > identifier, and then reference the same GUID document as is referenced in > RFC 2518. Answered (it's a URI). > * Section 2.6, final paragraph, last two sentences. Change "must not" to > "MUST NOT" (and eliminate the "For example" at the start of the sentence -- > perhaps change to "Specifically," Issue tracked as: . Do we need additional changes? > * Section 2.6. Need to add a note indicating that REBIND does not affect the > value of DAV:resource-id. See above. > * Section 3.2, final sentence -- delete the word "either", add a comma after > "or". Fixed: > * Section 3.2. I think it would be helpful to have an example of this > property. I'd be happy to help develop such an example. Issue opened: . > * Section 4. The intent of the BIND method is for its behavior to be atomic. > However, this is never actually stated explicitly in the specification. > Seems like it should be. Issue opened and resolved: > * Section 4. Need a new condition to cover the case where the BIND > half-succeeded, and then needed to be rewound. This condition would address > the case where Overwrite is true, the destination binding has been removed, > but the new binding couldn't be created. Still under discussion. > * Section 4.1, final sentence. Remove comma after the URI. Fixed: > * Section 5. Same comment as for BIND. The intent of UNBIND is that it's > supposed to be atomic, but that's never explicitly stated. Issue opened and resolved: > * Section 5. I think we need a condition for a cross-server UNBIND failure. Still under discussion. > * Section 6. Same comment as for BIND, UNBIND. The intent of REBIND is to be > atomic, but this is not explicitly stated. Issue opened and resolved: > * Section 6. Should precondition DAV:rebind-into-collection be named > DAV:rebind-from-collection, to mirror the similar precondition for UNBIND? Fixed: > * Section 6. Precondition DAV:rebind-source-exists is incorrect. The > DAV:href element identifies the destination binding to be created, not the > source. Seems like this precondition, and the previous one, reflect an older > marshalling of the arguments. Rewritten as: (DAV:rebind-source-exists): The Request-URI plus the DAV:segment in the request body element MUST identify a resource. > * Section 6.2. I think it would be helpful to have an example including > REBIND and locks, showing submission of one or more lock tokens in the If > header. Still discussing this... > * Section 7.1.1. Might just be a personal preference, but I'd rather see > plain GUIDs rather than opaqulocktoken URI GUIDs in the example. Still discussing this. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Nov 30 16:00:46 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05750 for ; Tue, 30 Nov 2004 16:00:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZF6C-0006kd-KR for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 20:59:48 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZF6B-0006jQ-DN for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 20:59:47 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CZF6B-0007uq-2y for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 20:59:47 +0000 Received: (qmail 6355 invoked by uid 65534); 30 Nov 2004 20:59:13 -0000 Received: from pD9535451.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.84.81) by mail.gmx.net (mp020) with SMTP; 30 Nov 2004 21:59:12 +0100 X-Authenticated: #1915285 Message-ID: <41ACDF1A.4050102@gmx.de> Date: Tue, 30 Nov 2004 21:59:06 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "WebDAV (WebDAV WG)" CC: ejw@cs.ucsc.edu References: <200411292204.iATM45vm026136@cats-mx3.ucsc.edu> <41ACD4AB.8070207@gmx.de> In-Reply-To: <41ACD4AB.8070207@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: BIND issue 3.2_example, was: Comments on bind-08 X-Archived-At: http://www.w3.org/mid/41ACDF1A.4050102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9036 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 20:59:48 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: >> * Section 3.2. I think it would be helpful to have an example of this >> property. I'd be happy to help develop such an example. > > > Issue opened: > . OK, resolved (for now) by rewriting the sections as: 3.2 DAV:parent-set Property The DAV:parent-set property is an OPTIONAL property that enables clients to discover what collections contain a binding to this resource (i.e. what collections have that resource as an internal member). It contains an of href/segment pair for each collection that has a binding to the resource. The href identifies the collection, and the segment identifies the binding name of that resource in that collection. A given collection MUST appear only once in the DAV:parent-set for any given binding, even if there are multiple URI mappings to that collection. 3.2.1 Example for DAV:parent-set property For example, if collection C1 is mapped to both /CollX and /CollY, and C1 contains a binding named "x.gif" to a resource R1, then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set of R1, but not both. But if C1 also had a binding named "y.gif" to R1, then there would be two entries for C1 in the DAV:binding-set of R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, both [/CollY, x.gif] and [/CollY, y.gif]). +-------------------------+ | Root Collection | | bindings: | | CollX CollY | +-------------------------+ | / | / | / +-----------------+ | Collection C1 | | bindings: | | x.gif y.gif | +-----------------+ | | | | | | +--------------+ | Resource R1 | +--------------+ In this case, one possible value for DAV:parent-set property on "/CollX/x.gif" would be: /CollX x.gif /CollX y.gif ...Feedback appreciated. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Nov 30 16:09:52 2004 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07329 for ; Tue, 30 Nov 2004 16:09:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CZFFI-0002vC-3G for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Nov 2004 21:09:12 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CZFFH-0002ui-SR for w3c-dist-auth@listhub.w3.org; Tue, 30 Nov 2004 21:09:11 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CZFFH-00031C-KP for w3c-dist-auth@w3.org; Tue, 30 Nov 2004 21:09:11 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id iAUL97aa010643 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 30 Nov 2004 13:09:08 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <0B9AD7E7-4314-11D9-B57F-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDAV (WebDAV WG) From: Lisa Dusseault Date: Tue, 30 Nov 2004 13:08:55 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Bindings and permissions X-Archived-At: http://www.w3.org/mid/0B9AD7E7-4314-11D9-B57F-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9037 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Nov 2004 21:09:12 +0000 Content-Transfer-Encoding: 7bit I think I've discussed this before but it's come up again in a use case I'm working on. In Chandler we want a user to be able to share the same item (for example, a calendar event) in multiple collections. For example, I might want to show the "OSAF holiday party" in both my work calendar share and my home calendar share, so that other users who view either my work or my home calendar will see the event regardless (and users who share both won't see the event twice). The natural way to do this if the server supports bindings would be to create the event in one collection, let's say the client will create it in my work share where permissions are inherited so that all OSAF people can view the event. Then BIND the event to the other collection, where the inherited permissions normally would automatically make it so that my family and friends can view the event. Do we leave it unspecified what happens in this case? Do I end up with a resource that is bound into my home calendar but only work people can see it unless my client fixes up the ACLs? Or do I end up with a resource that is bound into both and has the sum permissions of both? If the client has to fix up the ACLs, now what happens when I add a person to the permissions of my home calendar share, and then apply that new permission to all the resources in my home calendar share? Does my client have to go through each one and ACL each one or can the server calculate the appropriate permissions for resources that are bound into both collections? I can imagine a server implementing it either way depending on what they think the common use cases are; what can the client predict or require here? Lisa