From w3c-dist-auth-request@frink.w3.org Tue Nov 01 04:35:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWsYO-0001Ly-5o for webdav-archive@megatron.ietf.org; Tue, 01 Nov 2005 04:35:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23950 for ; Tue, 1 Nov 2005 04:35:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWsWM-0001W2-NN for w3c-dist-auth-dist@listhub.w3.org; Tue, 01 Nov 2005 09:33:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWsWI-0001VI-Df for w3c-dist-auth@listhub.w3.org; Tue, 01 Nov 2005 09:33:30 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EWsWE-0006Mc-Ac for w3c-dist-auth@w3.org; Tue, 01 Nov 2005 09:33:29 +0000 Received: (qmail invoked by alias); 01 Nov 2005 09:33:24 -0000 Received: from p508F9C03.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.156.3] by mail.gmx.net (mp010) with SMTP; 01 Nov 2005 10:33:24 +0100 X-Authenticated: #1915285 Message-ID: <4367364C.7090900@gmx.de> Date: Tue, 01 Nov 2005 10:33:00 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , WebDav , Cullen Jennings References: <436689A9.4060304@gmx.de> <8d2dc10867f989a1244c5ee4fe5672cd@osafoundation.org> <43669523.2010708@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EWsWE-0006Mc-Ac 07fabbe7a1eac5387b26a35672fc5fed X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/4367364C.7090900@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10304 X-Loop: w3c-dist-auth@w3.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, 01 Nov 2005 09:33:34 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Sept 15, 2002, mail from me entitled "*Issues from Interop/Interim WG > Meeting".* > > > "- Clients get confused if host names change; Clients expect > full/relative URLs? Dealt with in text on multistatus response" > > The Location header was what the server was using to indicate the host > name redirection in this case, which I didn't mention in this brief > summary unfortunately. > > The full details of the Interop -- e.g which client this was, and which > server -- were never published, a decision we made in order to get > broader participation in the Interop. Lisa, it would be really helpful if you could just add the URL to the archive message, to save people the trouble to look it up. That being said, I indeed found a better summary in "Notes for Sept 9 WG meeting (by Dennis Hamilton)" (): which says: > 5.2.1.4 PropFind Responses for Collections > > > Are relative URLs allowed in propfind responses? > > Jim W: So is this a spec language issue or is something needed in the > protocol? > > Brotsky: Servers must not be confusing to clients and we need to see how > to do that. We probably ought to do relatives more, it needs to be > relative to the URI in the request: relative, absolute, or fully > qualified (anything not fully qualified is considered a relative URI in > the specification) -- we have to be really careful about the > specification language > > Difficulties are with the client handling the different cases of what > comes back. > > Brotsky says that servers must use proper internal URIs, and it is > strictly defined, in terms of internal member URI. The question is can > the top level URI be different than the one the client offered. > > Lots of discussion on prefixes of URIs, how to get around this. And > whether servers are allowed to optimize the client's future behavior. > Brotsky wants the server to be gentle with the client. In the case at > hand, the client is asking "tell me what the internal members of this > collection are." If the server can return whatever it wants, the client > is under a terrible burden. > > Lisa has some language for a MUST to add to the specification based on > presence of a content location header. > > In the absence of a content location header, there is discussion about > not having the same level of MUST-ness for the request URL. > > Conversation about what a client is, and Brotsky says that HTTP says. > Needs more discussion, and RFC 2518 may need to be more emphatic that it > is relying on the HTTP 1.1 definition of client and have people be clear > about the implications. So from what I can see here, the issue was about a server that was using URLs in PROPFIND responses that weren't descendants of the Request-URI. This is a server bug, and if RFC2518 needs to be clearer about this, I'm +1 on doing that. Anyway: I'm not aware of any current server with that bug (it would affect our client in the same way), so I'd really like to know whether this is just an academic discussion, or whether the problematic server is still doing that. Finally, the meeting notes say that what was dicussed was "Content-Location", not "Location". That's of course something completely different, and it's already mentioned in RFC2518 <(http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.5.2.p.6>): "There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names." Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Nov 01 07:15:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWv2s-0002Hu-RS for webdav-archive@megatron.ietf.org; Tue, 01 Nov 2005 07:15:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15980 for ; Tue, 1 Nov 2005 07:14:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWv1c-0006Mo-DC for w3c-dist-auth-dist@listhub.w3.org; Tue, 01 Nov 2005 12:14:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWv1Y-0006MD-F5 for w3c-dist-auth@listhub.w3.org; Tue, 01 Nov 2005 12:13:56 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWv1U-0000o0-P3 for w3c-dist-auth@w3.org; Tue, 01 Nov 2005 12:13:55 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jA1CDmbe027488 for ; Tue, 1 Nov 2005 07:13:48 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jA1CDm5c119224 for ; Tue, 1 Nov 2005 07:13:48 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jA1CDmZ1004712 for ; Tue, 1 Nov 2005 07:13:48 -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 jA1CDme7004709 for ; Tue, 1 Nov 2005 07:13:48 -0500 In-Reply-To: <4367364C.7090900@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 1 Nov 2005 07:13:50 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/01/2005 07:13:47, Serialize complete at 11/01/2005 07:13:47 Content-Type: multipart/alternative; boundary="=_alternative 00433040852570AC_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EWv1U-0000o0-P3 a63f8d5515ce62700a61f7bd84e7627a X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/OFE1EBF602.3F88FB1D-ON852570AC.00419B0D-852570AC.0043317C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10305 X-Loop: w3c-dist-auth@w3.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, 01 Nov 2005 12:14:00 +0000 This is a multipart message in MIME format. --=_alternative 00433040852570AC_= Content-Type: text/plain; charset="US-ASCII" Julian Reschke wrote on 11/01/2005 04:33:00 AM: > > So from what I can see here, the issue was about a server that was using > URLs in PROPFIND responses that weren't descendants of the Request-URI. > This is a server bug, and if RFC2518 needs to be clearer about this, I'm > +1 on doing that. I agree. If we do need to be clearer on this, we could add a sentence to the following paragraph from section 8.1 (PROPFIND) of 2518: "Consequently, the multistatus XML element for a collection resource with member URIs MUST include a response XML element for each member URI of the collection, to whatever depth was requested. Each response XML element MUST contain an href XML element that gives the URI of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URIs are returned as a flat list whose order of entries is not significant." I'd be happy to add a sentence to the effect that: "Note that the URI in the response XML element must consist of the request-URI of the collection resource extended by a sequence of 0 or more slash separated pathname segments." Cheers, Geoff --=_alternative 00433040852570AC_= Content-Type: text/html; charset="US-ASCII"

Julian Reschke <julian.reschke@gmx.de> wrote on 11/01/2005 04:33:00 AM:

>
> So from what I can see here, the issue was about a server that was using
> URLs in PROPFIND responses that weren't descendants of the Request-URI.
> This is a server bug, and if RFC2518 needs to be clearer about this, I'm
> +1 on doing that.
I agree.  If we do need to be clearer on this, we could add a sentence to
the following paragraph from section 8.1 (PROPFIND) of 2518:

"Consequently, the multistatus XML element for a collection resource with member URIs MUST
 include a response XML element for each member URI of the collection, to whatever depth was
 requested. Each response XML element MUST contain an href XML element that gives the URI of the
 resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a
 collection resource with internal member URIs are returned as a flat list whose order of entries is not
 significant."

I'd be happy to add a sentence to the effect that:

"Note that the URI in the response XML element must consist of
 the request-URI of the collection resource extended by a sequence
 of 0 or more slash separated pathname segments."

Cheers,
Geoff
 --=_alternative 00433040852570AC_=-- From wkronert@tlcfan.com Wed Nov 02 10:20:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKPU-0007hB-LC for webdav-archive@megatron.ietf.org; Wed, 02 Nov 2005 10:20:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12018 for ; Wed, 2 Nov 2005 10:19:59 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKe6-0006If-Cm for webdav-archive@ietf.org; Wed, 02 Nov 2005 10:35:26 -0500 Received: from [211.203.117.42] (helo=137678032) by mx2.foretec.com with smtp (Exim 4.24) id 1EXKPM-0007CO-Ga for webdav-archive@ietf.org; Wed, 02 Nov 2005 10:20:14 -0500 Received: from tlcfan.com (-1210382976 [-1209193424]) by lopezclub.com (Qmailv1) with ESMTP id F4D7A62B0C for ; Wed, 02 Nov 2005 10:21:35 -0500 Date: Wed, 02 Nov 2005 10:21:35 -0500 From: Doctor X-Mailer: The Bat! (v2.00.1) Personal X-Priority: 3 Message-ID: <3123075066.20051102102135@tlcfan.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------6D971BC0D5E7E09" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Score: 2.6 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------6D971BC0D5E7E09 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlacgra $3.3 Levimtra $3.3 Ciaqlis $3.7 Imiturex $16.4 Flomgax $2.2 Ultrtam $0.78 Viorxx $4.75 Ambiien $2.2 Valmium $0.97 Xanagx $1.09 Sooma $3 Meriqdia $2.2 visit our website http://awore.info/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals ghnsdfsagbbv RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------6D971BC0D5E7E09 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlagira - $3.3
Leqvitra - $3.3
Cialiys - $3.7
Imditrex - $16.4
Flromax - $2.2
Ulktram - $0.78
Vihoxx - $4.75
Amubien - $2.2
Vavlium - $0.97
Xasnax - $1.09
Skoma - $3
Mkeridia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

ghnsdfsagbbv RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------6D971BC0D5E7E09-- From w3c-dist-auth-request@frink.w3.org Wed Nov 02 12:57:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMrN-0004wS-O7 for webdav-archive@megatron.ietf.org; Wed, 02 Nov 2005 12:57:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26685 for ; Wed, 2 Nov 2005 12:56:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXMph-0001Uv-7d for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Nov 2005 17:55:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EXMpd-0001UN-7I for w3c-dist-auth@listhub.w3.org; Wed, 02 Nov 2005 17:55:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EXMpY-0003DB-Rp for w3c-dist-auth@w3.org; Wed, 02 Nov 2005 17:55:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jA2HtLZ0006529; Wed, 2 Nov 2005 09:55:21 -0800 Date: Wed, 2 Nov 2005 09:55:21 -0800 Message-Id: <200511021755.jA2HtLZ0006529@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EXMpY-0003DB-Rp ef01a6ff88c23dfd3959ab161f060420 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511021755.jA2HtLZ0006529@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10306 X-Loop: w3c-dist-auth@w3.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, 02 Nov 2005 17:55:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- 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@frink.w3.org Wed Nov 02 12:59:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMtR-0006qW-Ap for webdav-archive@megatron.ietf.org; Wed, 02 Nov 2005 12:59:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26794 for ; Wed, 2 Nov 2005 12:59:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXMss-0001xM-8D for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Nov 2005 17:58:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EXMsr-0001wi-Ja for w3c-dist-auth@listhub.w3.org; Wed, 02 Nov 2005 17:58:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EXMsj-0003sw-Jd for w3c-dist-auth@w3.org; Wed, 02 Nov 2005 17:58:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jA2Hwbfa006552; Wed, 2 Nov 2005 09:58:37 -0800 Date: Wed, 2 Nov 2005 09:58:37 -0800 Message-Id: <200511021758.jA2Hwbfa006552@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EXMsj-0003sw-Jd b838ee6fdf6b6474bdcd48b740039f41 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511021758.jA2Hwbfa006552@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10307 X-Loop: w3c-dist-auth@w3.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, 02 Nov 2005 17:58:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 ------- Additional Comments From lisa@osafoundation.org 2005-11-02 09:58 ------- Geoff proposed text which didn't take into account the possibility of relative URLs, which Apache does. Here's a modification proposed: If the server uses absolute URLs in response XML elements, then the URI MUST consist of the request-URI of the collection resource extended by a sequence of 0 or more slash separated pathname segments. Alternatively, the server MAY use relative URLs beginning with a slash, which the client MUST resolve using the host information in the Request-URI. ------- 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@frink.w3.org Wed Nov 02 13:03:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMxZ-0002oH-Mw for webdav-archive@megatron.ietf.org; Wed, 02 Nov 2005 13:03:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27694 for ; Wed, 2 Nov 2005 13:03:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXMwu-00057s-IZ for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Nov 2005 18:03:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EXMwt-00055t-Vg for w3c-dist-auth@listhub.w3.org; Wed, 02 Nov 2005 18:03:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EXMwn-0004iq-J3 for w3c-dist-auth@w3.org; Wed, 02 Nov 2005 18:02:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jA2I2qFX006603; Wed, 2 Nov 2005 10:02:52 -0800 Date: Wed, 2 Nov 2005 10:02:52 -0800 Message-Id: <200511021802.jA2I2qFX006603@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EXMwn-0004iq-J3 0894df6193653973ff3b45640644fb98 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511021802.jA2I2qFX006603@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10308 X-Loop: w3c-dist-auth@w3.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, 02 Nov 2005 18:03:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-11-02 10:02 ------- Julian's modified text is fine with me. ------- 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@frink.w3.org Wed Nov 02 13:06:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMzz-0004K6-2X for webdav-archive@megatron.ietf.org; Wed, 02 Nov 2005 13:06:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27869 for ; Wed, 2 Nov 2005 13:05:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXMzL-0005lV-NZ for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Nov 2005 18:05:31 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EXMzK-0005kw-Na for w3c-dist-auth@listhub.w3.org; Wed, 02 Nov 2005 18:05:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EXMzG-0004aF-F8 for w3c-dist-auth@w3.org; Wed, 02 Nov 2005 18:05:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jA2I5O5u006633; Wed, 2 Nov 2005 10:05:24 -0800 Date: Wed, 2 Nov 2005 10:05:24 -0800 Message-Id: <200511021805.jA2I5O5u006633@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EXMzG-0004aF-F8 a505977ad912f6f8890761e32c31aecc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511021805.jA2I5O5u006633@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10309 X-Loop: w3c-dist-auth@w3.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, 02 Nov 2005 18:05:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-02 10:05 ------- Another proposed change: Alternatively, the server MAY use relative URIs in which case the Base URI used for computation MUST be the Request-URI. Additionally, only relative URIs beginning with a slash are permitted. ------- 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@frink.w3.org Wed Nov 02 13:10:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXN4P-0007RC-RS for webdav-archive@megatron.ietf.org; Wed, 02 Nov 2005 13:10:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28059 for ; Wed, 2 Nov 2005 13:10:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXN3g-00068H-JU for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Nov 2005 18:10:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EXN3g-00067j-4h for w3c-dist-auth@listhub.w3.org; Wed, 02 Nov 2005 18:10:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EXN3c-000614-M3 for w3c-dist-auth@w3.org; Wed, 02 Nov 2005 18:09:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jA2I9tvf006662; Wed, 2 Nov 2005 10:09:55 -0800 Date: Wed, 2 Nov 2005 10:09:55 -0800 Message-Id: <200511021809.jA2I9tvf006662@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EXN3c-000614-M3 259e5603553e231cfaa951a3be8665b2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511021809.jA2I9tvf006662@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10310 X-Loop: w3c-dist-auth@w3.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, 02 Nov 2005 18:10:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-11-02 10:09 ------- Another tweak to replace "are permitted" with "MUST": If the server uses absolute URLs in response XML elements, then the URI MUST consist of the request-URI of the collection resource extended by a sequence of 0 or more slash separated pathname segments. Alternatively, the server MAY use relative URIs in which case the Base URI used for computation MUST be the Request-URI and the relative URIs MUST begin with a slash. ------- 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@frink.w3.org Wed Nov 02 13:11:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXN4q-0007dQ-Al for webdav-archive@megatron.ietf.org; Wed, 02 Nov 2005 13:11:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28080 for ; Wed, 2 Nov 2005 13:10:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXN4G-0006e5-2u for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Nov 2005 18:10:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EXN4F-0006dN-Hu for w3c-dist-auth@listhub.w3.org; Wed, 02 Nov 2005 18:10:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EXN48-0005JH-WA for w3c-dist-auth@w3.org; Wed, 02 Nov 2005 18:10:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jA2IAR2H006686; Wed, 2 Nov 2005 10:10:27 -0800 Date: Wed, 2 Nov 2005 10:10:27 -0800 Message-Id: <200511021810.jA2IAR2H006686@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-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EXN48-0005JH-WA e9927ead71a152186abe86f1434b243e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511021810.jA2IAR2H006686@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10311 X-Loop: w3c-dist-auth@w3.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, 02 Nov 2005 18:10:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-02 10:10 ------- We also need to come up with language forbidding dot "." or dot-dot ".." within the relative URI. Perhaps, "Servers MUST NOT return "." or ".." within an absolute or relative URI returned within a Multistatus response." ------- 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@frink.w3.org Wed Nov 02 14:49:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXObv-0005aR-97 for webdav-archive@megatron.ietf.org; Wed, 02 Nov 2005 14:49:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04526 for ; Wed, 2 Nov 2005 14:49:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXOar-0004wt-RP for w3c-dist-auth-dist@listhub.w3.org; Wed, 02 Nov 2005 19:48:21 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EXOan-0004vz-Uv for w3c-dist-auth@listhub.w3.org; Wed, 02 Nov 2005 19:48:18 +0000 Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EXOae-00007B-5p for w3c-dist-auth@w3.org; Wed, 02 Nov 2005 19:48:17 +0000 Received: from [192.168.1.3] (H045e.h.pppool.de [85.72.4.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 6FABB11C79 for ; Wed, 2 Nov 2005 20:48:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'webdav' WG" From: Stefan Eissing Date: Wed, 2 Nov 2005 20:47:59 +0100 X-Mailer: Apple Mail (2.623) Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EXOae-00007B-5p c3eecbd68eb8bd4d8f86685e4772b4ff X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 18] no record of consensus for force-authenticate X-Archived-At: http://www.w3.org/mid/b9067abff5b7f4803cbc3a2dfb68a86c@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10312 X-Loop: w3c-dist-auth@w3.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, 02 Nov 2005 19:48:21 +0000 Content-Transfer-Encoding: 7bit > Am 31.10.2005 um 17:52 schrieb Jim Luther: > >> >> On Oct 29, 2005, at 1:22 AM, Julian Reschke wrote: >> >>>> More generally, it's not actually a WebDAV problem alone. If a >>>> client does a GET to a dynamically generated page, they could >>>> easily see different results based on whether they're authenticated >>>> or not. Since browsers today often cache authentication >>>> information, this means that the browser could inform the server >>>> that they'd like the challenge to save the user the step of first >>>> going to the site, seeing the anonymous page version, then choosing >>>> to login. Of course some sites use cookies for this but cookies are >>>> sometimes disabled, expired, etc. >>> >>> In which case I would recommend to >>> >>> - update Jim's description of the problem accordingly and >>> >>> - do this in a separate draft, optimally discussed on the HTTP WG's >>> mailing list. >> >> I agree with those who have said this is not a WebDAV specific issue. >> It should be discussed as a separate HTTP issue. +1. Stefan From w3c-dist-auth-request@frink.w3.org Thu Nov 03 15:46:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXlym-0006KR-AN for webdav-archive@megatron.ietf.org; Thu, 03 Nov 2005 15:46:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25608 for ; Thu, 3 Nov 2005 15:46:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXlwu-0002Sb-Kk for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Nov 2005 20:44:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EXlws-0002S3-Jr for w3c-dist-auth@listhub.w3.org; Thu, 03 Nov 2005 20:44:38 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EXlwf-0007A4-AT for w3c-dist-auth@w3.org; Thu, 03 Nov 2005 20:44:37 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 37B0A1422BC for ; Thu, 3 Nov 2005 12:44:23 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32445-02 for ; Thu, 3 Nov 2005 12:44:23 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7741F1422A7 for ; Thu, 3 Nov 2005 12:44:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDav WG From: Lisa Dusseault Date: Thu, 3 Nov 2005 12:44:16 -0800 X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EXlwf-0007A4-AT b96deb6882ea257ad42848aba63515b8 X-Original-To: w3c-dist-auth@w3.org Subject: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/b2db0759eab094f470a3e6adc0b97a9d@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10313 X-Loop: w3c-dist-auth@w3.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, 03 Nov 2005 20:44:40 +0000 Content-Transfer-Encoding: 7bit Lately we've been talking about what parts of a property value the server must preserve, and what parts it can lose. Some examples: - Whitespace in values (TEXT or Mixed) must be preserved, we all agreed on this - Whitespace within element tags might be insignificant, e.g. extra spaces between attribute declarations - Exact prefixes used to declare namespaces (can the server replace the "C:" prefix for a namespace with "ns-1" or other when it reconstructs the value) - Attributes and values on the property element itself... Rather than attack these questions piecemeal, Julian suggested a more principled approach of using XML InfoSet. So I went off to read the spec: http://www.w3.org/TR/xml-infoset/ While it would indeed be great to refer to another standard, I wanted to raise a few issues. 1. It's hard to read. There are no examples. While some things are clear -- e.g. for an element, it states that the namespace name and local name of the element are part of the InfoSet -- I don't find that the "negative space" is clearly defined. As a client implementor, it's hard for me to read this and determine what the server might legally change in the property value I might provide. 2. InfoSet requires the prefixes of namespaces to be preserved. Some WebDAV servers today do not do this so this would make them non-compliant. Similarly, if I'm reading it correctly, it requires that namespace declarations be preserved as part of the element where the client declared them -- another requirement that existing servers don't meet. 3. It doesn't deal with the boundary that WebDAV defines between property name and property value. We still ought to specify that stuff ourselves. For example, are attributes on the property name element considered part of the property value. Has anybody besides Julian and myself read this spec? Does anybody have thoughts on whether this approach is still advisable? thanks, Lisa From w3c-dist-auth-request@frink.w3.org Thu Nov 03 16:02:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXmEY-0001b1-KH for webdav-archive@megatron.ietf.org; Thu, 03 Nov 2005 16:02:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26170 for ; Thu, 3 Nov 2005 16:02:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXmDq-0007Tw-H9 for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Nov 2005 21:02:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EXmDj-0007TA-8Q for w3c-dist-auth@listhub.w3.org; Thu, 03 Nov 2005 21:02:03 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EXmDW-0004pm-Ju for w3c-dist-auth@w3.org; Thu, 03 Nov 2005 21:02:03 +0000 Received: (qmail invoked by alias); 03 Nov 2005 21:01:47 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 03 Nov 2005 22:01:47 +0100 X-Authenticated: #1915285 Message-ID: <436A7A81.5050706@gmx.de> Date: Thu, 03 Nov 2005 22:00:49 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: WebDav WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EXmDW-0004pm-Ju 1a55d24d28239267b55181da1b759c48 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/436A7A81.5050706@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10314 X-Loop: w3c-dist-auth@w3.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, 03 Nov 2005 21:02:10 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > ... > 2. InfoSet requires the prefixes of namespaces to be preserved. Some > WebDAV servers today do not do this so this would make them > non-compliant. Similarly, if I'm reading it correctly, it requires that > namespace declarations be preserved as part of the element where the > client declared them -- another requirement that existing servers don't > meet. > ... You're confusing the terminology (that we can re-use) with the question what parts of the Infoset WebDAV wants to make reound-trippable. Those do not need to be the same. The XML Infoset spec just helps in talking about these things. > 3. It doesn't deal with the boundary that WebDAV defines between > property name and property value. We still ought to specify that stuff > ourselves. For example, are attributes on the property name element > considered part of the property value. Yes, we need to define that. > Has anybody besides Julian and myself read this spec? Does anybody have > thoughts on whether this approach is still advisable? Alternate approaches would be to use DOM or XPath terminology. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 03 17:47:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXnrV-0004es-Tb for webdav-archive@megatron.ietf.org; Thu, 03 Nov 2005 17:47:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02784 for ; Thu, 3 Nov 2005 17:46:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EXnqD-000561-9O for w3c-dist-auth-dist@listhub.w3.org; Thu, 03 Nov 2005 22:45:53 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EXnpn-0004Va-Hb for w3c-dist-auth@listhub.w3.org; Thu, 03 Nov 2005 22:45:27 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EXnpj-0001Bk-Uj for w3c-dist-auth@w3.org; Thu, 03 Nov 2005 22:45:26 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 339B71422C2; Thu, 3 Nov 2005 14:45:21 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15824-07; Thu, 3 Nov 2005 14:45:21 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E32961422BC; Thu, 3 Nov 2005 14:45:20 -0800 (PST) In-Reply-To: <436A7A81.5050706@gmx.de> References: <436A7A81.5050706@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <80384a06c24ed28e1e638bc41e62b04e@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav WG From: Lisa Dusseault Date: Thu, 3 Nov 2005 14:45:17 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EXnpj-0001Bk-Uj e7a92f605abfe68e380c9c528c5210dc X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/80384a06c24ed28e1e638bc41e62b04e@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10315 X-Loop: w3c-dist-auth@w3.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, 03 Nov 2005 22:45:53 +0000 Content-Transfer-Encoding: 7bit On Nov 3, 2005, at 1:00 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> ... >> 2. InfoSet requires the prefixes of namespaces to be preserved. >> Some WebDAV servers today do not do this so this would make them >> non-compliant. Similarly, if I'm reading it correctly, it requires >> that namespace declarations be preserved as part of the element where >> the client declared them -- another requirement that existing servers >> don't meet. > > ... > > You're confusing the terminology (that we can re-use) with the > question what parts of the Infoset WebDAV wants to make > reound-trippable. Those do not need to be the same. The XML Infoset > spec just helps in talking about these things. Fair enough, I think the terminology does make things clear and we can define our own list about what's round-tripped. On those terms I'm perfectly in favour of using InfoSet terminology. So does this boil down to saying something like: "All Information Items as defined in XML InfoSet [ref] MUST be round-tripped as part of the property value, with the exception of the following - On an element information item: the prefix and namespace attributes - On an attribute information item: the prefix - On a namespace information item: the prefix Anything that is not part of the Information Set does not need to be preserved by the server." > >> 3. It doesn't deal with the boundary that WebDAV defines between >> property name and property value. We still ought to specify that >> stuff ourselves. For example, are attributes on the property name >> element considered part of the property value. > > Yes, we need to define that. > >> Has anybody besides Julian and myself read this spec? Does anybody >> have thoughts on whether this approach is still advisable? > > Alternate approaches would be to use DOM or XPath terminology. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Nov 06 15:07:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqnQ-00069G-MY for webdav-archive@megatron.ietf.org; Sun, 06 Nov 2005 15:07:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17545 for ; Sun, 6 Nov 2005 15:06:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EYqlQ-0005VN-Ac for w3c-dist-auth-dist@listhub.w3.org; Sun, 06 Nov 2005 20:05:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EYqlM-0005Ul-PK for w3c-dist-auth@listhub.w3.org; Sun, 06 Nov 2005 20:05:12 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EYqlJ-0002Xz-Pa for w3c-dist-auth@w3.org; Sun, 06 Nov 2005 20:05:12 +0000 Received: (qmail invoked by alias); 06 Nov 2005 20:05:05 -0000 Received: from p508F9EA3.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.158.163] by mail.gmx.net (mp003) with SMTP; 06 Nov 2005 21:05:05 +0100 X-Authenticated: #1915285 Message-ID: <436E61BA.4040808@gmx.de> Date: Sun, 06 Nov 2005 21:04:10 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDav WG References: <436A7A81.5050706@gmx.de> <80384a06c24ed28e1e638bc41e62b04e@osafoundation.org> In-Reply-To: <80384a06c24ed28e1e638bc41e62b04e@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EYqlJ-0002Xz-Pa 05ee867243a561a6a8c9b9052efe0447 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/436E61BA.4040808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10316 X-Loop: w3c-dist-auth@w3.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: Sun, 06 Nov 2005 20:05:16 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >... >> You're confusing the terminology (that we can re-use) with the >> question what parts of the Infoset WebDAV wants to make >> reound-trippable. Those do not need to be the same. The XML Infoset >> spec just helps in talking about these things. > > Fair enough, I think the terminology does make things clear and we can > define our own list about what's round-tripped. On those terms I'm > perfectly in favour of using InfoSet terminology. So does this boil down > to saying something like: > > "All Information Items as defined in XML InfoSet [ref] MUST be > round-tripped as part of the property value, with the exception of the > following > - On an element information item: the prefix and namespace attributes > - On an attribute information item: the prefix > - On a namespace information item: the prefix Why would we need any Namespace Information Items anyway? I thought namespace declarations weren't considered important, as long as namespace names are preserved for each item? > Anything that is not part of the Information Set does not need to be > preserved by the server." > ... So are comments, processing instructions, unparsed entities and so on in? Probably not. Looking at the large set of information items, it's probably simpler if we just list the items we want to be round-tripped, such as: 1) On the property element itself: [namespace name], [local name], [children] of type element or character, plus [attributes] named "xml:lang" present on the element itself or it's closest ancestor 2) On all children of the property element: [namespace name], [local name], [attributes] and [children] of type element or character. Regarding the issue that started the whole discussion: we IMHO should encourage servers to preserve the [prefix} on all but the property element itself, and warn clients about information loss for those servers that don't. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Nov 06 15:11:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqrc-0007df-EF for webdav-archive@megatron.ietf.org; Sun, 06 Nov 2005 15:11:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17892 for ; Sun, 6 Nov 2005 15:11:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EYqqz-0006Rw-6i for w3c-dist-auth-dist@listhub.w3.org; Sun, 06 Nov 2005 20:11:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EYqqy-0006RO-LH for w3c-dist-auth@listhub.w3.org; Sun, 06 Nov 2005 20:11:00 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EYqqv-0007hm-6s for w3c-dist-auth@w3.org; Sun, 06 Nov 2005 20:11:00 +0000 Received: (qmail invoked by alias); 06 Nov 2005 20:10:54 -0000 Received: from p508F9EA3.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.158.163] by mail.gmx.net (mp006) with SMTP; 06 Nov 2005 21:10:54 +0100 X-Authenticated: #1915285 Message-ID: <436E6317.1000101@gmx.de> Date: Sun, 06 Nov 2005 21:09:59 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> <8eaf9241d62055518696cf3f434114e1@osafoundation.org> <43639C2E.3040109@gmx.de> <43639F63.4090000@gmx.de> In-Reply-To: <43639F63.4090000@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EYqqv-0007hm-6s c18cb575b4f9204a9ec12b44bc2b06fc X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/436E6317.1000101@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10317 X-Loop: w3c-dist-auth@w3.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: Sun, 06 Nov 2005 20:11:01 +0000 Content-Transfer-Encoding: 7bit For the record, I don't think that the recent discussion has brought up any new points that need to be said here, so I'd like to again recommend to close the issue with the following change (as seen in ). Proposed resolution for : [...] NEW: A lock token is a type of state token, represented as a URI, which identifies a particular lock. Each lock has exactly one unique lock token, which is returned upon a successful LOCK creation operation in the "Lock-Token" response header defined in Section 9.6. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Nov 06 15:15:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqus-0000fu-2p for webdav-archive@megatron.ietf.org; Sun, 06 Nov 2005 15:15:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18059 for ; Sun, 6 Nov 2005 15:14:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EYquI-0006cW-BJ for w3c-dist-auth-dist@listhub.w3.org; Sun, 06 Nov 2005 20:14:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EYquH-0006bt-SZ for w3c-dist-auth@listhub.w3.org; Sun, 06 Nov 2005 20:14:25 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EYquF-0008GP-HV for w3c-dist-auth@w3.org; Sun, 06 Nov 2005 20:14:25 +0000 Received: (qmail invoked by alias); 06 Nov 2005 20:14:22 -0000 Received: from p508F9EA3.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.158.163] by mail.gmx.net (mp007) with SMTP; 06 Nov 2005 21:14:22 +0100 X-Authenticated: #1915285 Message-ID: <436E63E7.8080603@gmx.de> Date: Sun, 06 Nov 2005 21:13:27 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Elias Sinderson CC: w3c-dist-auth@w3.org References: <200510152337.j9FNbOgl001456@ietf.cse.ucsc.edu> <4361083D.3040507@cse.ucsc.edu> In-Reply-To: <4361083D.3040507@cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EYquF-0008GP-HV c87734de6ae1c876f845098a5b6ad24b X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/436E63E7.8080603@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10318 X-Loop: w3c-dist-auth@w3.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: Sun, 06 Nov 2005 20:14:26 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > > bugzilla@soe.ucsc.edu wrote: > >> ------- Additional Comments From lisa@osafoundation.org 2005-10-15 >> 16:37 ------- >> Proposed text for -08: >> >> When trying to lock a collection upon creation, clients may >> attempt to increase the likelihood of this by pipelining the >> MKCOL and LOCK requests together (but because this doesn't >> convert two separate operations into one atomic operation there's >> no guarantee this will work). > I have no problems with the proposed text. I'd prefer the spec not to say anything at all here (meaning the spec not to change from what RFC2518 said), but at least it's now technically correct, so just -0.5 on it. Best regards, Julian From dietmar@norika-fujiwara.com Mon Nov 07 02:27:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ1Px-00061b-Pa for webdav-archive@megatron.ietf.org; Mon, 07 Nov 2005 02:27:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21150 for ; Mon, 7 Nov 2005 02:27:23 -0500 (EST) Received: from 188.sub-70-195-127.myvzw.com ([70.195.127.188] helo=-1216091704) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZ1fU-0002hc-AK for webdav-archive@ietf.org; Mon, 07 Nov 2005 02:43:54 -0500 Received: from norika-fujiwara.com (-1212085576 [-1211564144]) by 188.sub-70-195-127.myvzw.com (Qmailv1) with ESMTP id 97018366EA for ; Mon, 07 Nov 2005 02:27:54 -0500 Date: Mon, 07 Nov 2005 02:27:54 -0500 From: "Fain O. Viewed" X-Mailer: The Bat! (v2.00.4) Personal X-Priority: 3 Message-ID: <9018917082.20051107022754@norika-fujiwara.com> To: Webdav Subject: Software MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. X-Spam-Score: 1.4 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Looking for cheap high-quality software? some software u need! New software on our site: Creative Suite Standard (3 CD) - $129.95 Picture It Premium 9 - $59.95 Photoshop 7 - $69.95 Extensis Portfolio 7.0 - $59.95 WordPerfect Office 10 - $69.95 Windows Millenium - $59.95 Windows NT 4.0 Terminal Server - $49.95 Windows NT 4.0 Terminal Server - $49.95 Director MX 2004 - $69.95 Windows 2000 Advanced Server - $69.95 Acrobat 6 Professional - $79.95 Painter 8 - $59.95 Dreamweaver MX 2004 $69.95 Windows NT 4.0 Server - $49.95 Our site: http://hfyau.p9dwc4cpv9vk8p7kcppkup7p.oportoal.com From w3c-dist-auth-request@frink.w3.org Tue Nov 08 09:45:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZUie-0007kF-2M for webdav-archive@megatron.ietf.org; Tue, 08 Nov 2005 09:45:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09402 for ; Tue, 8 Nov 2005 09:44:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EZUgq-0000BV-DE for w3c-dist-auth-dist@listhub.w3.org; Tue, 08 Nov 2005 14:43:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EZUgm-0000AB-KS for w3c-dist-auth@listhub.w3.org; Tue, 08 Nov 2005 14:43:08 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EZUge-0003YB-TZ for w3c-dist-auth@w3.org; Tue, 08 Nov 2005 14:43:08 +0000 Received: (qmail invoked by alias); 08 Nov 2005 14:42:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 08 Nov 2005 15:42:58 +0100 X-Authenticated: #1915285 Message-ID: <4370B93D.4020607@gmx.de> Date: Tue, 08 Nov 2005 15:42:05 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200511021810.jA2IAR2H006686@ietf.cse.ucsc.edu> In-Reply-To: <200511021810.jA2IAR2H006686@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EZUge-0003YB-TZ 1ed80fdfb3d7d2053977d17ec7eff163 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/4370B93D.4020607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10319 X-Loop: w3c-dist-auth@w3.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, 08 Nov 2005 14:43:12 +0000 Content-Transfer-Encoding: 7bit Hi, trying to summarize what we discussed in last week's call: - discussion about relation with "Location" header needs to go (revert back to what RFC2518 said) - we want to restrict what type of hrefs can occur in PROPFIND responses, relying on grammar definitions in RFC3986 - clients can expect that servers return URIs ("URI" as per ) or relative references consisting of just a path starting with a "/" (). - segments of "." or ".." are forbidden - me to make proposal for actual spec language (will need to check what part applies to PROPFIND and what part applies to the multistatus response format). Best regards, Julian From davej@grungecafe.com Wed Nov 09 07:10:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZomX-0006XN-4V for webdav-archive@megatron.ietf.org; Wed, 09 Nov 2005 07:10:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02658 for ; Wed, 9 Nov 2005 07:09:57 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZp2V-0001Yo-0y for webdav-archive@ietf.org; Wed, 09 Nov 2005 07:26:57 -0500 Received: from 85.58.broadband3.iol.cz ([85.70.58.85] helo=137828592) by mx2.foretec.com with smtp (Exim 4.24) id 1EZomO-0008CY-A5 for webdav-archive@ietf.org; Wed, 09 Nov 2005 07:10:17 -0500 Received: from grungecafe.com (140766424 [136853400]) by 85.58.broadband3.iol.cz (Qmailv1) with ESMTP id 432A501B1F for ; Wed, 09 Nov 2005 20:06:25 -0600 Date: Wed, 09 Nov 2005 20:06:25 -0600 From: "Buyouts M. Thunderbolt" X-Mailer: The Bat! (v2.00.7) Personal X-Priority: 3 Message-ID: <9127932475.20051109200625@grungecafe.com> To: Webdav Subject: Software MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-RAV-Antivirus: This e-mail has been scanned for viruses on host: 85.58.broadband3.iol.cz X-Spam-Score: 4.8 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Understanding 0EM software some software u need! New software on our site: Plus! XP - $59.95 Studio MX 2004 with Director MX 2004 - $139.95 WordPerfect Office 10 - $69.95 InDesign CS PageMaker Edition (2CD) - $69.95 Creative Suite Standard (3 CD) - $129.95 Windows XP Professional With SP2 Full Version - $79.95 Windows XP Professional With SP2 Full Version - $79.95 Windows XP Professional - $69.95 Norton System Works 2003 - $59.95 FreeHand MX - $69.95 Office 2000 Premium Edition PE (2CD) - $59.95 PhotoRetouch Pro 3.0 - $59.95 Office 2003 Professional (1 CD Edition) - $89.95 WordPerfect Office 10 - $69.95 Our site: http://ifmxltl.26q07lq8858flk2xpk2xpkkk.segolatelf.com From darin.sipedhzj@all-pak.com Thu Nov 10 16:18:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJoL-0004HT-6a for webdav-archive@megatron.ietf.org; Thu, 10 Nov 2005 16:18:21 -0500 Received: from axg62.internetdsl.tpnet.pl (axg62.internetdsl.tpnet.pl [83.18.84.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13265 for ; Thu, 10 Nov 2005 16:17:45 -0500 (EST) Received: from deliverance.all-pak.com by axg62.internetdsl.tpnet.pl (Postfix) with ESMTP id 02B31D4D62 for ; Thu, 10 Nov 2005 16:20:13 -0500 Received: from unknown (dsnat [251.26.28.116]) by deliverance.all-pak.com (8.12.3 da nor stuldap/8.12.3) with SMTP id Ftr0y4vRrHoT for ; Thu, 10 Nov 2005 16:20:13 -0500 Reply-To: "Britney Dean" From: "Britney" Message-ID: <8384534612.20051110162013@lwamfqjruqrj> Date: Thu, 10 Nov 2005 16:20:13 -0500 To: Subject: Microsoft Special Deals MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Available for instant download Microsoft Office XP Professional $49.95 Adobe Photoshop CS V 8.0 PC $49.95 Autodesk AutoCAD Electrical 2005 $99.95 Macromedia Director MX v9.0 $49.95 http://druisoft.com We need only travel enough to give our intellects an airing. From w3c-dist-auth-request@frink.w3.org Sun Nov 13 12:01:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbLEl-0000x0-JS for webdav-archive@megatron.ietf.org; Sun, 13 Nov 2005 12:01:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18874 for ; Sun, 13 Nov 2005 12:01:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EbLCt-0004Ja-P5 for w3c-dist-auth-dist@listhub.w3.org; Sun, 13 Nov 2005 16:59:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EbLCl-0004Gu-Aq for w3c-dist-auth@listhub.w3.org; Sun, 13 Nov 2005 16:59:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EbLCh-0005GS-6I for w3c-dist-auth@w3.org; Sun, 13 Nov 2005 16:59:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jADGxffK010224; Sun, 13 Nov 2005 08:59:41 -0800 Date: Sun, 13 Nov 2005 08:59:41 -0800 Message-Id: <200511131659.jADGxffK010224@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EbLCh-0005GS-6I e9ff598373ee15bda29419b2238dffb1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 20] lock token example X-Archived-At: http://www.w3.org/mid/200511131659.jADGxffK010224@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10321 X-Loop: w3c-dist-auth@w3.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: Sun, 13 Nov 2005 16:59:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-13 08:59 ------- *** Bug 61 has been marked as a duplicate of this bug. *** ------- 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@frink.w3.org Sun Nov 13 12:01:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbLEl-0000x1-JU for webdav-archive@megatron.ietf.org; Sun, 13 Nov 2005 12:01:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18875 for ; Sun, 13 Nov 2005 12:01:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EbLCm-0004Ik-Ru for w3c-dist-auth-dist@listhub.w3.org; Sun, 13 Nov 2005 16:59:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EbLCj-0004Dh-55 for w3c-dist-auth@listhub.w3.org; Sun, 13 Nov 2005 16:59:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EbLCf-0000ik-GG for w3c-dist-auth@w3.org; Sun, 13 Nov 2005 16:59:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jADGxebD010214; Sun, 13 Nov 2005 08:59:40 -0800 Date: Sun, 13 Nov 2005 08:59:40 -0800 Message-Id: <200511131659.jADGxebD010214@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-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EbLCf-0000ik-GG baf98fe4d7982c1ac5597d000c37c33f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 61] invalid lock token in example X-Archived-At: http://www.w3.org/mid/200511131659.jADGxebD010214@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10320 X-Loop: w3c-dist-auth@w3.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: Sun, 13 Nov 2005 16:59:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=61 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-13 08:59 ------- *** This bug has been marked as a duplicate of 20 *** ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From som@malaysia.net Mon Nov 14 13:01:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebide-0001wI-IC for webdav-archive@megatron.ietf.org; Mon, 14 Nov 2005 13:01:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09310 for ; Mon, 14 Nov 2005 13:00:35 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebiui-0005Rf-93 for webdav-archive@ietf.org; Mon, 14 Nov 2005 13:18:45 -0500 Received: from m141.net85-168-126.noos.fr ([85.168.126.141] helo=-1215614928) by mx2.foretec.com with smtp (Exim 4.24) id 1Ebidb-0000Po-EY for webdav-archive@ietf.org; Mon, 14 Nov 2005 13:01:04 -0500 Received: from malaysia.net (-1222254608 [-1215998360]) by m141.net85-168-126.noos.fr (Qmailv1) with ESMTP id 3C3F66BC95 for ; Mon, 14 Nov 2005 11:56:51 -0500 Date: Mon, 14 Nov 2005 11:56:51 -0500 From: Doctor X-Mailer: The Bat! (v2.00.9) Personal X-Priority: 3 Message-ID: <7869293115.20051114115651@malaysia.net> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------25DEEFE7FBFE006" X-Virus-Scanned: Norton X-Spam-Score: 2.6 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------25DEEFE7FBFE006 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlaigra $3.3 Levittra $3.3 Ciazlis $3.7 Imitcrex $16.4 Flomkax $2.2 Ultrkam $0.78 Viosxx $4.75 Ambfien $2.2 Valmium $0.97 Xanasx $1.09 Sorma $3 Merijdia $2.2 visit our website http://familinludi.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals fgfgkkflrpa RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------25DEEFE7FBFE006 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlagbra - $3.3
Leqvitra - $3.3
Cialios - $3.7
Imhitrex - $16.4
Flpomax - $2.2
Ulxtram - $0.78
Vikoxx - $4.75
Amxbien - $2.2
Vaelium - $0.97
Xalnax - $1.09
Sloma - $3
Mweridia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

fgfgkkflrpa RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------25DEEFE7FBFE006-- From w3c-dist-auth-request@frink.w3.org Mon Nov 14 16:30:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eblue-0005Tk-2v for webdav-archive@megatron.ietf.org; Mon, 14 Nov 2005 16:30:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02550 for ; Mon, 14 Nov 2005 16:30:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EblsY-0007WR-5m for w3c-dist-auth-dist@listhub.w3.org; Mon, 14 Nov 2005 21:28:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EblsT-0007Vc-Ao for w3c-dist-auth@listhub.w3.org; Mon, 14 Nov 2005 21:28:37 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EblsO-00083Z-RL for w3c-dist-auth@w3.org; Mon, 14 Nov 2005 21:28:36 +0000 Received: (qmail invoked by alias); 14 Nov 2005 21:28:31 -0000 Received: from p508FBD37.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.189.55] by mail.gmx.net (mp013) with SMTP; 14 Nov 2005 22:28:31 +0100 X-Authenticated: #1915285 Message-ID: <43790156.9090005@gmx.de> Date: Mon, 14 Nov 2005 22:27:50 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: multipart/mixed; boundary="------------060600080203070300070902" X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EblsO-00083Z-RL a976c2057e0eec6ece87503ada3c19aa X-Original-To: w3c-dist-auth@w3.org Subject: [Fwd: I-D ACTION:draft-reschke-webdav-url-constraints-00.txt] X-Archived-At: http://www.w3.org/mid/43790156.9090005@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10322 X-Loop: w3c-dist-auth@w3.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, 14 Nov 2005 21:28:42 +0000 This is a multi-part message in MIME format. --------------060600080203070300070902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, this is a first take of describing the issues around encoding non-ASCII characters in WebDAV URLs. As usual, recent versions and HTML at... . Feedback appreciated, Julian -------- Original Message -------- From: - Mon Nov 14 22:24:59 2005 X-Account-Key: account5 X-UIDL: 1e0ad7ceaf80b3480c48ea4538d88705 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 Return-Path: X-Flags: 0000 Delivered-To: GMX delivery to julian.reschke@gmx.de Received: (qmail invoked by alias); 14 Nov 2005 21:18:49 -0000 Received: from megatron.ietf.org (EHLO megatron.ietf.org) [132.151.6.71] by mx0.gmx.net (mx011) with SMTP; 14 Nov 2005 22:18:49 +0100 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblHU-0007G3-Uc; Mon, 14 Nov 2005 15:50:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblH9-00078w-0r for i-d-announce@megatron.ietf.org; Mon, 14 Nov 2005 15:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22471 for ; Mon, 14 Nov 2005 15:49:30 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EblYE-0003lg-Bp for i-d-announce@ietf.org; Mon, 14 Nov 2005 16:07:42 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EblH7-0005iN-Dc for i-d-announce@ietf.org; Mon, 14 Nov 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 14 Nov 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: I-D ACTION:draft-reschke-webdav-url-constraints-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) X-GMX-UID: bZoKY3wfeSEkefRadnQhaXN1IGRvb0Cj A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Web Distributed Authoring and Versioning (WebDAV) URL constraints Author(s) : J. Reschke Filename : draft-reschke-webdav-url-constraints-00.txt Pages : 10 Date : 2005-11-14 Both WebDAV servers and clients frequently map URI-escaped characters inside a path segment to non-ASCII characters. These mappings can only be interoperable if there is a consensus about the appropriate character encoding. This document specifies a default encoding that is compatible with both the recommendations for URIs in HTML content and the "Internationalized Resource Identifiers" (IRI) specification. Furthermore, servers that implement a mapping to locally constrained names frequently do not support specific names, or silently map "similar" names to the same resource (for instance when content is stored in a filesystem that is case-preserving, but not case- sensitive). For these cases, discovery and error signalling features are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reschke-webdav-url-constraints-00.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-reschke-webdav-url-constraints-00.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-reschke-webdav-url-constraints-00.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. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 --------------060600080203070300070902 Content-Type: Message/External-body; name="draft-reschke-webdav-url-constraints-00.txt" Content-Disposition: inline; filename="draft-reschke-webdav-url-constraints-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-11-14115845.I-D@ietf.org> --------------060600080203070300070902 Content-Type: text/plain; name="file:///C|/DOKUME%7E1/JR/LOKALE%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOKUME%7E1/JR/LOKALE%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------060600080203070300070902-- From w3c-dist-auth-request@frink.w3.org Mon Nov 14 20:13:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpOD-0001Le-6K for webdav-archive@megatron.ietf.org; Mon, 14 Nov 2005 20:13:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16135 for ; Mon, 14 Nov 2005 20:13:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EbpMu-00059I-Sd for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 01:12:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EbpMm-00056g-I9 for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 01:12:08 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EbpMj-0006SN-7A for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 01:12:08 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 11FC114228B; Mon, 14 Nov 2005 17:12:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25137-08; Mon, 14 Nov 2005 17:12:03 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 401CF142281; Mon, 14 Nov 2005 17:12:00 -0800 (PST) In-Reply-To: <436E61BA.4040808@gmx.de> References: <436A7A81.5050706@gmx.de> <80384a06c24ed28e1e638bc41e62b04e@osafoundation.org> <436E61BA.4040808@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <885204fb4832103eb89b400c575a5a5e@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav WG From: Lisa Dusseault Date: Fri, 11 Nov 2005 14:53:57 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EbpMj-0006SN-7A 16f85ebcda599ae135e5b4c3f413f007 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/885204fb4832103eb89b400c575a5a5e@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10323 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 01:12:16 +0000 Content-Transfer-Encoding: 7bit In WebDAV implementations today, the only InfoSet piece that we know isn't always preserved on properties is the namespace prefix (and thus the namespace declaration attributes might also be rewritten). I'd assume we want to encourage new implementations to have at least as much preservation/fidelity as existing implementations, and to make implementations tend to be consistent with each other. So why would we allow servers to strip out stuff like comments? If servers reliably preserve those today, I don't see why we'd explicitly allow those to stop being preserved. Is there some reason why we would choose to be lax on this in the specification? Lisa On Nov 6, 2005, at 12:04 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> ... >>> You're confusing the terminology (that we can re-use) with the >>> question what parts of the Infoset WebDAV wants to make >>> reound-trippable. Those do not need to be the same. The XML Infoset >>> spec just helps in talking about these things. >> Fair enough, I think the terminology does make things clear and we >> can define our own list about what's round-tripped. On those terms >> I'm perfectly in favour of using InfoSet terminology. So does this >> boil down to saying something like: >> "All Information Items as defined in XML InfoSet [ref] MUST be >> round-tripped as part of the property value, with the exception of >> the following >> - On an element information item: the prefix and namespace >> attributes >> - On an attribute information item: the prefix >> - On a namespace information item: the prefix > > Why would we need any Namespace Information Items anyway? I thought > namespace declarations weren't considered important, as long as > namespace names are preserved for each item? > >> Anything that is not part of the Information Set does not need to >> be preserved by the server." >> ... > > So are comments, processing instructions, unparsed entities and so on > in? Probably not. > > Looking at the large set of information items, it's probably simpler > if we just list the items we want to be round-tripped, such as: > > 1) On the property element itself: [namespace name], [local name], > [children] of type element or character, plus [attributes] named > "xml:lang" present on the element itself or it's closest ancestor > > 2) On all children of the property element: [namespace name], [local > name], [attributes] and [children] of type element or character. > > Regarding the issue that started the whole discussion: we IMHO should > encourage servers to preserve the [prefix} on all but the property > element itself, and warn clients about information loss for those > servers that don't. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Tue Nov 15 03:04:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbvnL-0002Lh-OZ for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 03:04:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07951 for ; Tue, 15 Nov 2005 03:03:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ebvm7-0001Zy-Mx for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 08:02:43 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ebvm3-0001ZD-RD for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 08:02:40 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Ebvlz-0007yy-U2 for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 08:02:38 +0000 Received: (qmail invoked by alias); 15 Nov 2005 08:02:33 -0000 Received: from p508F9BD7.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.155.215] by mail.gmx.net (mp030) with SMTP; 15 Nov 2005 09:02:33 +0100 X-Authenticated: #1915285 Message-ID: <437995F1.6060106@gmx.de> Date: Tue, 15 Nov 2005 09:01:53 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDav WG References: <436A7A81.5050706@gmx.de> <80384a06c24ed28e1e638bc41e62b04e@osafoundation.org> <436E61BA.4040808@gmx.de> <885204fb4832103eb89b400c575a5a5e@osafoundation.org> In-Reply-To: <885204fb4832103eb89b400c575a5a5e@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ebvlz-0007yy-U2 e00aec7c5bfafa25c886c8c07fcb186e X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437995F1.6060106@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10324 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 08:02:43 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > In WebDAV implementations today, the only InfoSet piece that we know > isn't always preserved on properties is the namespace prefix (and thus > the namespace declaration attributes might also be rewritten). I'd I'm not sure how you can say that. I just tried with comments and PIs in Apache/moddav, and they aren't preserved. Do you have any data supporting your claim? > assume we want to encourage new implementations to have at least as much > preservation/fidelity as existing implementations, and to make > implementations tend to be consistent with each other. So why would we > allow servers to strip out stuff like comments? If servers reliably Well, because commments are just that -- comments? > preserve those today, I don't see why we'd explicitly allow those to > stop being preserved. This I agree with, but it seems that we don't have the necessary supporting data. > Is there some reason why we would choose to be lax on this in the > specification? I don't want to be lax. We should either document what we have today (if we want to advance RFC2518), or document what we tjink would be good (staying at proposed). Throwing in things like PIs, but keeping out *essential* things like prefixes doesn't make any sense to me, though. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Nov 15 13:05:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5B8-0007IG-Q3 for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 13:05:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13749 for ; Tue, 15 Nov 2005 13:04:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ec599-0001h8-DS for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 18:03:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ec595-0001gI-7q for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 18:03:03 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ec58w-0000uT-Vd for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 18:03:02 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3D23A14228E; Tue, 15 Nov 2005 10:02:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08697-02; Tue, 15 Nov 2005 10:02:53 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5FE7B142279; Tue, 15 Nov 2005 10:02:49 -0800 (PST) In-Reply-To: <437995F1.6060106@gmx.de> References: <436A7A81.5050706@gmx.de> <80384a06c24ed28e1e638bc41e62b04e@osafoundation.org> <436E61BA.4040808@gmx.de> <885204fb4832103eb89b400c575a5a5e@osafoundation.org> <437995F1.6060106@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <08f24d13d07d293695cdd6f0e9d84a42@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav WG From: Lisa Dusseault Date: Tue, 15 Nov 2005 10:02:38 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ec58w-0000uT-Vd a8a2ae6fd51c6c680fd72c306535f4c3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/08f24d13d07d293695cdd6f0e9d84a42@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10325 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 18:03:07 +0000 Content-Transfer-Encoding: 7bit On Nov 15, 2005, at 12:01 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> In WebDAV implementations today, the only InfoSet piece that we know >> isn't always preserved on properties is the namespace prefix (and >> thus the namespace declaration attributes might also be rewritten). >> I'd > > I'm not sure how you can say that. I just tried with comments and PIs > in Apache/moddav, and they aren't preserved. Do you have any data > supporting your claim? No -- I only said we don't *know* of other InfoSet items being lost, and now you've provided fresh data for this list. If it's been said before, I'd either missed it or forgotten. > > I don't want to be lax. We should either document what we have today > (if we want to advance RFC2518), or document what we tjink would be > good (staying at proposed). Throwing in things like PIs, but keeping > out *essential* things like prefixes doesn't make any sense to me, > though. Great; so what's a principled basis on which to make this decision? I can see one extreme option, plus an "exclusionary" choice and an "inclusionary" choice based on what we know implementations do today. This isn't full text for each point but just illustrative: Extreme option: All InfoSet items MUST be preserved. [This clearly has the disadvantage of making existing implementations change their code to comply, but has the advantage of simplicity and enforcing the greatest consistency between servers.] Exclusionary option: All InfoSet items MUST be preserved, except for the ones we know aren't preserved in some server implementations (comments and prefixes... ) [This encourages nearly as great consistency as the extreme option.] Inclusionary option: Of the InfoSet items, only the ones we know client implementations really need (text, element, attribute name and value...) MUST be preserved. [The difference between this one and exclusionary option covers InfoSet items like Processing Instructions. ] Has anybody considered this issue besides myself and Julian? Does anybody with an implementation wish to speak up and argue why it might be important to preserve or useful to discard various pieces of the InfoSet in property values? Lisa From w3c-dist-auth-request@frink.w3.org Tue Nov 15 14:04:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec668-00062C-It for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 14:04:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18409 for ; Tue, 15 Nov 2005 14:03:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ec65N-0004RR-Vf for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 19:03:17 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ec65J-0004Qr-1U for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 19:03:13 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Ec65F-0004LA-M0 for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 19:03:12 +0000 Received: (qmail invoked by alias); 15 Nov 2005 19:03:05 -0000 Received: from p508F9BD7.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.155.215] by mail.gmx.net (mp013) with SMTP; 15 Nov 2005 20:03:05 +0100 X-Authenticated: #1915285 Message-ID: <437A30BD.9050709@gmx.de> Date: Tue, 15 Nov 2005 20:02:21 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDav WG References: <436A7A81.5050706@gmx.de> <80384a06c24ed28e1e638bc41e62b04e@osafoundation.org> <436E61BA.4040808@gmx.de> <885204fb4832103eb89b400c575a5a5e@osafoundation.org> <437995F1.6060106@gmx.de> <08f24d13d07d293695cdd6f0e9d84a42@osafoundation.org> In-Reply-To: <08f24d13d07d293695cdd6f0e9d84a42@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ec65F-0004LA-M0 dd08d5503701be3bf7a5d8fc35e3367f X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437A30BD.9050709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10326 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 19:03:17 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >> I don't want to be lax. We should either document what we have today >> (if we want to advance RFC2518), or document what we tjink would be >> good (staying at proposed). Throwing in things like PIs, but keeping >> out *essential* things like prefixes doesn't make any sense to me, >> though. > > Great; so what's a principled basis on which to make this decision? I > can see one extreme option, plus an "exclusionary" choice and an > "inclusionary" choice based on what we know implementations do today. > This isn't full text for each point but just illustrative: I'm tempted to say "common sense". That PIs and comments do not necessarily round-trip should be quite clear. > Extreme option: All InfoSet items MUST be preserved. [This clearly has > the disadvantage of making existing implementations change their code to > comply, but has the advantage of simplicity and enforcing the greatest > consistency between servers.] Looking at what exactly is in (see ), I find that completely unreasonable. > Exclusionary option: All InfoSet items MUST be preserved, except for the > ones we know aren't preserved in some server implementations (comments > and prefixes... ) [This encourages nearly as great consistency as the > extreme option.] > Inclusionary option: Of the InfoSet items, only the ones we know client > implementations really need (text, element, attribute name and value...) > MUST be preserved. [The difference between this one and exclusionary > option covers InfoSet items like Processing Instructions. ] I think the latter option has the advantage that it's shorter to write down, and easier to understand. > Has anybody considered this issue besides myself and Julian? Does > anybody with an implementation wish to speak up and argue why it might > be important to preserve or useful to discard various pieces of the > InfoSet in property values? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Nov 15 18:12:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec9yx-0001FA-63 for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:12:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04428 for ; Tue, 15 Nov 2005 18:12:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ec9xf-00036Z-LQ for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 23:11:35 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ec9xa-00035u-Qk for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 23:11:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ec9xV-0004wz-8I for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 23:11:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAFNBM0R013663; Tue, 15 Nov 2005 15:11:22 -0800 Date: Tue, 15 Nov 2005 15:11:22 -0800 Message-Id: <200511152311.jAFNBM0R013663@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ec9xV-0004wz-8I 89f1599806cdc895dd890f8fb6194cb9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/200511152311.jAFNBM0R013663@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10327 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 23:11:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Tue Nov 15 18:14:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcA0c-0001er-8w for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:14:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04529 for ; Tue, 15 Nov 2005 18:14:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcA01-0003NG-AQ for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 23:14:01 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcA00-0003Md-Ou for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 23:14:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ec9zj-0005CQ-18 for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 23:13:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAFNDgQV013679; Tue, 15 Nov 2005 15:13:42 -0800 Date: Tue, 15 Nov 2005 15:13:42 -0800 Message-Id: <200511152313.jAFNDgQV013679@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ec9zj-0005CQ-18 863e7a54c7d4e1a22a9afcb57d1c417f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511152313.jAFNDgQV013679@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10328 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 23:14:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-15 15:13 ------- Jim's suggested text will be in 08 as well. ------- 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@frink.w3.org Tue Nov 15 18:15:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcA1i-0001oL-S4 for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:15:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04592 for ; Tue, 15 Nov 2005 18:15:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcA1A-0003yq-IY for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 23:15:12 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcA16-0003xl-PK for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 23:15:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcA0y-0005N6-0x for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 23:15:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAFNExSY013695; Tue, 15 Nov 2005 15:14:59 -0800 Date: Tue, 15 Nov 2005 15:14:59 -0800 Message-Id: <200511152314.jAFNExSY013695@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcA0y-0005N6-0x 3ff2526a13608214e92799372b388b4e 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/200511152314.jAFNExSY013695@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10329 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 23:15:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 ------- Additional Comments From lisa@osafoundation.org 2005-11-15 15:14 ------- The new para. in -08 would be: Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or getlastmodified value) for a resource that has an unchanged body. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed. ------- 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@frink.w3.org Tue Nov 15 18:15:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcA1r-0001pV-Tb for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:15:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04600 for ; Tue, 15 Nov 2005 18:15:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcA1K-00043b-Dz for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 23:15:22 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcA18-0003yG-22 for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 23:15:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcA14-0005OX-3P for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 23:15:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAFNF5Nc013711; Tue, 15 Nov 2005 15:15:05 -0800 Date: Tue, 15 Nov 2005 15:15:05 -0800 Message-Id: <200511152315.jAFNF5Nc013711@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcA14-0005OX-3P 63c17534295fdd625ec4f620b3d0a31f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200511152315.jAFNF5Nc013711@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10330 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 23:15:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Tue Nov 15 18:17:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcA3G-00024H-K9 for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:17:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04698 for ; Tue, 15 Nov 2005 18:16:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcA2g-0005ZZ-Sp for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 23:16:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcA2g-0005Z1-Cv for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 23:16:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcA2d-0001KL-4D for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 23:16:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAFNGe11013730; Tue, 15 Nov 2005 15:16:40 -0800 Date: Tue, 15 Nov 2005 15:16:40 -0800 Message-Id: <200511152316.jAFNGe11013730@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EcA2d-0001KL-4D f2ac2a12d168f882061bf1b25df67774 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 20] lock token example X-Archived-At: http://www.w3.org/mid/200511152316.jAFNGe11013730@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10331 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 23:16:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Tue Nov 15 18:23:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcA8w-00044R-SE for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:23:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04936 for ; Tue, 15 Nov 2005 18:22:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcA8F-0006U1-Jf for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 23:22:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcA8F-0006TO-4V for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 23:22:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcA8C-00020M-G3 for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 23:22:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAFNMR5g013770; Tue, 15 Nov 2005 15:22:27 -0800 Date: Tue, 15 Nov 2005 15:22:27 -0800 Message-Id: <200511152322.jAFNMR5g013770@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EcA8C-00020M-G3 c37e074ef1f27b9e59733008cff52de0 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/200511152322.jAFNMR5g013770@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10332 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 23:22:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Tue Nov 15 18:35:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAKn-0000NY-Eu for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:35:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06592 for ; Tue, 15 Nov 2005 18:34:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcAK4-0000st-TN for w3c-dist-auth-dist@listhub.w3.org; Tue, 15 Nov 2005 23:34:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcAK1-0000sL-0z for w3c-dist-auth@listhub.w3.org; Tue, 15 Nov 2005 23:34:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcAJr-0003a9-N0 for w3c-dist-auth@w3.org; Tue, 15 Nov 2005 23:34:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAFNYUek013792; Tue, 15 Nov 2005 15:34:30 -0800 Date: Tue, 15 Nov 2005 15:34:30 -0800 Message-Id: <200511152334.jAFNYUek013792@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EcAJr-0003a9-N0 2f25a857162c33b365bc6f360d11c246 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 29] refreshing locks X-Archived-At: http://www.w3.org/mid/200511152334.jAFNYUek013792@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10333 X-Loop: w3c-dist-auth@w3.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, 15 Nov 2005 23:34:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=29 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-15 15:34 ------- Note that this isn't quite the same meaning -- it is explicit that a server doesn't have to accept the Timeout value in the lock refresh request. However since timeouts chosen by clients have always been advisory, I believe this is correct anyway. The proposed text will be in 08. ------- 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@frink.w3.org Tue Nov 15 20:09:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBnw-0005KR-6P for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 20:09:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16545 for ; Tue, 15 Nov 2005 20:09:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcBmb-00044R-A8 for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 01:08:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcBmX-00043h-Pa for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 01:08:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcBmN-0003ck-Ko for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 01:08:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAG182Vs013871; Tue, 15 Nov 2005 17:08:02 -0800 Date: Tue, 15 Nov 2005 17:08:02 -0800 Message-Id: <200511160108.jAG182Vs013871@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-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EcBmN-0003ck-Ko 9917e351ea18b435023c43d2a4f12732 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 30] incorrect XML in example X-Archived-At: http://www.w3.org/mid/200511160108.jAG182Vs013871@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10334 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 01:08:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=30 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-15 17:08 ------- I believe this and other offenders will be fixed in 08 and a double-check from some other eyes would be welcome. ------- 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@frink.w3.org Tue Nov 15 20:12:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBqN-0005rN-7p for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 20:12:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16663 for ; Tue, 15 Nov 2005 20:11:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcBpm-00051L-Qm for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 01:11:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcBpm-00050j-BX for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 01:11:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcBpj-0000AL-7z for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 01:11:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAG1BT4a013917; Tue, 15 Nov 2005 17:11:29 -0800 Date: Tue, 15 Nov 2005 17:11:29 -0800 Message-Id: <200511160111.jAG1BT4a013917@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EcBpj-0000AL-7z fff4a7e6ad9ac7662b4b90394f2aff35 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/200511160111.jAG1BT4a013917@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10337 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 01:11:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-15 17:11 ------- I believe we came to consensus in a phone call and thus I'm making changes in -08, marking this 'fixed', and the WG can confirm whether the resulting draft changes are acceptable. ------- 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@frink.w3.org Tue Nov 15 20:10:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBp7-0005Tj-1f for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 20:10:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16616 for ; Tue, 15 Nov 2005 20:10:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcBoY-0004hV-SG for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 01:10:18 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcBoY-0004gx-AD for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 01:10:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcBo8-0005zv-G5 for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 01:10:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAG19ptp013903; Tue, 15 Nov 2005 17:09:51 -0800 Date: Tue, 15 Nov 2005 17:09:51 -0800 Message-Id: <200511160109.jAG19ptp013903@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcBo8-0005zv-G5 516d265f76423b50203c800ddb2fb271 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 36] Appendix numbering X-Archived-At: http://www.w3.org/mid/200511160109.jAG19ptp013903@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10336 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 01:10:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=36 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-15 17:09 ------- This should be fixed in -08. ------- 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@frink.w3.org Tue Nov 15 20:10:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBom-0005RE-V4 for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 20:10:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16591 for ; Tue, 15 Nov 2005 20:10:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcBoE-0004F3-9O for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 01:09:58 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcBoD-0004EV-MF for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 01:09:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcBnI-0005qK-Lj for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 01:09:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAG18uRW013887; Tue, 15 Nov 2005 17:08:56 -0800 Date: Tue, 15 Nov 2005 17:08:56 -0800 Message-Id: <200511160108.jAG18uRW013887@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcBnI-0005qK-Lj e15c5f1a1feff1e4a2a55c32803fac0c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 34] property "URI" X-Archived-At: http://www.w3.org/mid/200511160108.jAG18uRW013887@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10335 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 01:09:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=34 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-15 17:08 ------- Changed to "property name" in -08. ------- 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@frink.w3.org Tue Nov 15 20:23:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcC1k-0001Aq-DC for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 20:23:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17051 for ; Tue, 15 Nov 2005 20:23:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcC10-0007yb-0C for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 01:23:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcC0z-0007xy-CR for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 01:23:09 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EcC0w-00020L-MN for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 01:23:08 +0000 Received: (qmail invoked by alias); 16 Nov 2005 01:23:05 -0000 Received: from p508F9BD7.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.155.215] by mail.gmx.net (mp020) with SMTP; 16 Nov 2005 02:23:05 +0100 X-Authenticated: #1915285 Message-ID: <437A89B5.3020906@gmx.de> Date: Wed, 16 Nov 2005 02:21:57 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200511160111.jAG1BT4a013917@ietf.cse.ucsc.edu> In-Reply-To: <200511160111.jAG1BT4a013917@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EcC0w-00020L-MN 10cefb71ac202b0d396f0072e95c50cd X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/437A89B5.3020906@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10338 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 01:23:10 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |FIXED > > > > ------- Additional Comments From lisa@osafoundation.org 2005-11-15 17:11 ------- > I believe we came to consensus in a phone call and thus I'm making changes in > -08, marking this 'fixed', and the WG can confirm whether the resulting draft > changes are acceptable. Lisa, this is hard to argue with unless you state what you think the consensus was. My recollection is that opaquelocktoken can not obsoleted, because a) it's in use in existing implementations and b) its semantics is a true superset of urn:uuid. Thus it should be kept, but it's definition can be stripped to a minimum, referring normatively to syntax and generation instructions in the URN:UUID RFC. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Nov 15 21:10:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcCl7-0001iV-CD for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 21:10:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21265 for ; Tue, 15 Nov 2005 21:10:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcCk0-0002E2-E2 for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 02:09:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcCjv-0002Cj-Ut for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 02:09:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcCjn-0000IN-B8 for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 02:09:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAG29PaI013981; Tue, 15 Nov 2005 18:09:25 -0800 Date: Tue, 15 Nov 2005 18:09:25 -0800 Message-Id: <200511160209.jAG29PaI013981@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EcCjn-0000IN-B8 9d68f4eb814a159d89e74a23050c58dd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 102] lock tokens in examples X-Archived-At: http://www.w3.org/mid/200511160209.jAG29PaI013981@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10339 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 02:09:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=102 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-15 18:09 ------- I believe I happened to fix these during work on -08. ------- 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@frink.w3.org Tue Nov 15 21:14:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcCop-0003Ad-29 for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 21:14:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21377 for ; Tue, 15 Nov 2005 21:14:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcCoD-00033K-3l for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 02:14:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcCoC-00032m-Fp for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 02:14:00 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcCo9-00010X-FD for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 02:14:00 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3DB5B142277; Tue, 15 Nov 2005 18:13:56 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01482-07; Tue, 15 Nov 2005 18:13:56 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C13A314226C; Tue, 15 Nov 2005 18:13:55 -0800 (PST) In-Reply-To: <436E6317.1000101@gmx.de> References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> <8eaf9241d62055518696cf3f434114e1@osafoundation.org> <43639C2E.3040109@gmx.de> <43639F63.4090000@gmx.de> <436E6317.1000101@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Tue, 15 Nov 2005 18:13:51 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EcCo9-00010X-FD 1d6598d22eadbd963b6f195ee4513c82 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/f88bccd3fe2f87ce99db3a9f8307a53d@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10340 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 02:14:01 +0000 Content-Transfer-Encoding: 7bit I'm still concerned about a possible inconsistency here. Sorry if I'm being dense, but I thought that we had a previous consensus (a long time ago) that servers SHOULD provide lock tokens for all locks so that if there were a client bug, a crash, a LOCK reply "lost in the mail", or a need for an owner or administrator to remove somebody else's stale lock. Some text currently in the draft to that extent: "Anyone can find out anyone else's lock token by performing lock discovery." So given that implies that lock discovery can find out all lock tokens (given permission), and that the lockdiscovery property is returned in the LOCK response body, doesn't that mean that the lock token is returned both in the LOCK response headers (Lock-Token) and body? Also, we had previously discussed at an interop which is the "right" place to put the lock token and concluded that servers ought to put the token in both places because we found during interoperability testing that we had clients that looked in one place, and other clients that looked in the other, so we might as well continue supporting both. Lisa On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > For the record, > > I don't think that the recent discussion has brought up any new points > that need to be said here, so I'd like to again recommend to close the > issue with the following change (as seen in > 0242.html>). > > Proposed resolution for > : [...] > > NEW: > A lock token is a type of state token, represented as a URI, which > identifies a particular lock. Each lock has exactly one unique lock > token, which is returned upon a successful LOCK creation operation > in > the "Lock-Token" response header defined in Section 9.6. > > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Tue Nov 15 21:29:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcD3f-0007kD-6O for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 21:29:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21921 for ; Tue, 15 Nov 2005 21:29:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcD2x-00070S-Hv for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 02:29:15 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcD2w-0006zt-Ow for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 02:29:15 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcD2s-0001zY-G1 for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 02:29:13 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1259142276; Tue, 15 Nov 2005 18:29:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13750-04; Tue, 15 Nov 2005 18:29:08 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 87135142274; Tue, 15 Nov 2005 18:29:08 -0800 (PST) In-Reply-To: <4366920A.40808@gmx.de> References: <43667F68.6070904@gmx.de> <1e1259203fa74a1fa86f011e540118e7@osafoundation.org> <4366920A.40808@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Jim Whitehead , WebDav , Cullen Jennings From: Lisa Dusseault Date: Tue, 15 Nov 2005 18:29:04 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcD2s-0001zY-G1 8863e78a7636fc13fda3e63b44a187ac X-Original-To: w3c-dist-auth@w3.org Subject: Re: This Document Defines Two Namespaces (was Re: Combined set of issues ...) X-Archived-At: http://www.w3.org/mid/ca3c5278b982619dcf96a0c884eb3cbf@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10341 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 02:29:15 +0000 Content-Transfer-Encoding: 7bit On Oct 31, 2005, at 1:52 PM, Julian Reschke wrote: > > XX. IANA Considerations > > XX.1. URI schemes > > This specification defines two URI schemes: > > 1) the "opaquelocktoken" URI scheme for the encoding of lock tokens, > defined in Appendix XYZ, and > > 2) the "DAV" URI scheme, which historically was used in RFC2518 to > disambiguate WebDAV property and XML element names and which continues > to be used for that purpose in this specification and others extending > WebDAV. Creation of identifiers in the "DAV:" namespace is controlled > by the IETF. > > To ensure correct interoperation based on this specification, IANA > must reserve the URI namespaces starting with "DAV:" and with > "opaquelocktoken:" for use by this specification, its revisions, and > related WebDAV specifications. > > XX.2. Other namespaces > > This document also defines multiple namespaces, including the > namespace of property names, the namespace of WebDAV-specific XML > elements used within property values and the namespace of > pre-/postcondition names. Namespaced XML element names (pairs of > "namespace name" and "local name" as per [XML-Infoset]) are used for > all of them, for several reasons. Due to the fact that XML namespace > names syntactically use URIs, assignment of names does not require a > request to a central naming authority, and hence allow identifiers to > be quickly defined by any WebDAV user or application. Therefore, no > actions on behalf of IANA are required to manage these namespaces. > I find this last paragraph pretty hard to read. Assuming that the point is to convey what IANA is not involved in and why, how about this alternate wording and you can tell me if I've overlooked some other point: "WebDAV uses namespaces to disambiguate property names and XML elements (used in property values and more generally in XML request and response bodies). Any WebDAV user or application can define a new namespace with which to declare custom properties or XML elements. IANA does not need to manage such namespaces, property names or element names." Or even simpler: "XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names or element names." Also I think it's readable enough to have this section whole without subsections as it's pretty small. The rest of the changes I am fine with and I've heard no other suggestions so I'll apply those changes. Lisa From w3c-dist-auth-request@frink.w3.org Tue Nov 15 21:48:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcDLs-00061h-TZ for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 21:48:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22794 for ; Tue, 15 Nov 2005 21:48:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcDL7-0002wI-3j for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 02:48:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcDL4-0002ve-W1 for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 02:47:59 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcDL1-0001de-RJ for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 02:47:58 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E760C142277; Tue, 15 Nov 2005 18:47:54 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12665-04; Tue, 15 Nov 2005 18:47:54 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2825414226E; Tue, 15 Nov 2005 18:47:54 -0800 (PST) In-Reply-To: <4355456A.6000307@gmx.de> References: <200510181823.j9IINZCw029195@ietf.cse.ucsc.edu> <4355456A.6000307@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Tue, 15 Nov 2005 18:47:47 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EcDL1-0001de-RJ f710374d0d881cdfdc12c1cb52612862 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/e11056fe4dc755909162c429f881ec1a@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10342 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 02:48:01 +0000 Content-Transfer-Encoding: quoted-printable I agree some of the text on PROPFIND can be moved to the section on =20 Multi-Status. I had been cleaning that up and clearly hadn't =20 finished. I'll take this opportunity to clean both sections up. I =20 think the section on general Multi-Status usage is now big enough to =20 warrant a few sub-sections which you'll see shortly. It's probably not =20= done yet, of course. One point of confusion, you lost me on the reference to section 13.15. =20= How does that discuss what's allowable in ? Lisa On Oct 18, 2005, at 11:56 AM, Julian Reschke wrote: > Proposed resolution for =20 > : > > As far as I can tell, the current draft of RFC2518bis changes the end =20= > of the description for PROPFIND from: > > "All servers MUST support returning a response of content type =20 > text/xml or application/xml that contains a multistatus XML element =20= > that describes the results of the attempts to retrieve the various =20 > properties. > > If there is an error retrieving a property then a proper error result =20= > MUST be included in the response. A request to retrieve the value of a = =20 > property which does not exist is an error and MUST be noted, if the =20= > response uses a multistatus XML element, with a response XML element =20= > which contains a 404 (Not Found) status value. > > Consequently, the multistatus XML element for a collection resource =20= > with member URIs MUST include a response XML element for each member =20= > URI of the collection, to whatever depth was requested. Each response =20= > XML element MUST contain an href XML element that gives the URI of the = =20 > resource on which the properties in the prop XML element are defined. =20= > Results for a PROPFIND on a collection resource with internal member =20= > URIs are returned as a flat list whose order of entries is not =20 > significant. > > In the case of allprop and propname, if a principal does not have the =20= > right to know whether a particular property exists then the property =20= > should be silently excluded from the response." =20 > () > > to > > "All servers MUST support returning a response of content type =20 > text/xml or application/xml that contains a multistatus XML element =20= > that describes the results of the attempts to retrieve the various =20 > properties. The multistatus contains one response element for each =20 > resource in the scope of the request (in no required order) or may be =20= > empty if no resources match the request. > > If there is an error retrieving a property then a proper error result =20= > MUST be included in the response. A request to retrieve the value of a = =20 > property which does not exist is an error and MUST be noted, if the =20= > response uses a multistatus XML element, with a response XML element =20= > which contains a 404 (Not Found) status value. > > Consequently, the multistatus XML element for a collection resource =20= > with member URLs MUST include a response XML element for each member =20= > URL of the collection, to whatever depth was requested. Each response =20= > XML element MUST contain an href XML element that gives the URL of the = =20 > resource on which the properties in the prop XML element are defined. =20= > URLs for collections appearing in the results MUST end in a slash =20 > character. Results for a PROPFIND on a collection resource with =20 > internal member URLs are returned as a flat list whose order of =20 > entries is not significant. > > A server enumerating the members of a collection using absolute URLs =20= > in a PROPFIND response MUST use a common prefix in those URLs, and =20 > that prefix MUST be the absolute URL used in the response to refer to =20= > the parent collection. > > Unless otherwise notified, clients may expect that the URL for the =20 > parent collection in the PROPFIND response will be the same URL that =20= > was used to refer to the parent collection in the PROPFIND request. =20= > Servers MAY use an alternate URL for the parent collection in a =20 > PROPFIND response, but in this case the server MUST include a =20 > Content-Location header whose value is the fully-qualified URL used by = =20 > the server to refer to the parent collection in this response. > > URLs in a PROPFIND response body MAY be represented as fully- =20 > qualified URLs, in which case they must all contain the full parent =20= > collection URL (scheme, host, port, and absolute path). Alternatively, = =20 > these URLs MAY be absolute paths (not containing scheme, host or =20 > port), but in this case they must all still contain the full parent =20= > collection path. > > If a server allows resource names to include characters that aren=EDt =20= > legal in HTTP URL paths, these characters must be URI-escaped on the =20= > wire. For example, it is illegal to use a space character or double- =20= > quote in a URI [5]. URIs appearing in PROPFIND or PROPPATCH XML bodies = =20 > (or other XML marshalling defined in this specification) are still =20 > subject to all URI rules, including forbidden characters. > > Properties may be subject to access control. In the case of allprop =20= > and propname, if a principal does not have the right to know whether a = =20 > particular property exists then the property MAY be silently excluded =20= > from the response." =20 > ( -07.html#rfc.section.8.2.p.7>) > > The problems that I see here are > > - it makes statements about the multistatus format, which applies to =20= > other methods than PROPFIND as well, > > - consequently, it repeats lots of things that appear in section 12 =20= > ("multistatus") in different words > > - it throws in discussion of escaping "native" resource names to URIs, = =20 > which is really a completely different topic (and again has nothing to = =20 > do with PROPFIND at all) > > - it makes a new MUST-level requirement about collection URLs ending =20= > in slashes that as far as I can tell has no WG consensus > > - it incorrectly claims that PROPFIND may result in an empty =20 > multistatus element > > My proposal would be to remove all of these changes, but to add a =20 > forward reference to section 12 instead. We then should concentrate on = =20 > getting section 12 right (which, funny enough, has it's own ticket =20 > ). > > So the proposed change would be: > > Section 8., para. 30: > OLD: > > All servers MUST support returning a response of content type text/ > xml or application/xml that contains a multistatus XML element that > describes the results of the attempts to retrieve the various > properties. The multistatus contains one response element for each > resource in the scope of the request (in no required order) or may =20= > be > empty if no resources match the request. > > NEW: > > All servers MUST support returning a response of content type text/ > xml or application/xml that contains a multistatus XML element that > describes the results of the attempts to retrieve the various > properties. > > > Section 8., para. 32: > OLD: > > Consequently, the multistatus XML element for a collection resource > with member URLs MUST include a response XML element for each = member > URL of the collection, to whatever depth was requested. Each > response XML element MUST contain an href XML element that gives = the > URL of the resource on which the properties in the prop XML element > are defined. URLs for collections appearing in the results MUST = end > in a slash character. Results for a PROPFIND on a collection > resource with internal member URLs are returned as a flat list = whose > order of entries is not significant. > > NEW: > > Consequently, the multistatus XML element for a collection resource > with member URLs MUST include a response XML element for each = member > URL of the collection, to whatever depth was requested. Each > response XML element MUST contain an href XML element that gives = the > URL of the resource on which the properties in the prop XML element > are defined (see Section 13.15 for a discussion of allowable values > inside the href elements). Results for a PROPFIND on a collection > resource with internal member URLs are returned as a flat list = whose > order of entries is not significant. > > > Section 8., para. 33: > OLD: > > A server enumerating the members of a collection using absolute = URLs > in a PROPFIND response MUST use a common prefix in those URLs, and > that prefix MUST be the absolute URL used in the response to refer =20= > to > the parent collection. > > Unless otherwise notified, clients may expect that the URL for the > parent collection in the PROPFIND response will be the same URL = that > was used to refer to the parent collection in the PROPFIND request. > Servers MAY use an alternate URL for the parent collection in a > PROPFIND response, but in this case the server MUST include a > Content-Location header whose value is the fully-qualified URL used > by the server to refer to the parent collection in this response. > > 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. > > If a server allows resource names to include characters that aren't > legal in HTTP URL paths, these characters must be URI-escaped on = the > wire. For example, it is illegal to use a space character or =20 > double- > quote in a URI [5]. URIs appearing in PROPFIND or PROPPATCH XML > bodies (or other XML marshalling defined in this specification) are > still subject to all URI rules, including forbidden characters. > > Properties may be subject to access control. In the case of = allprop > and propname, if a principal does not have the right to know = whether > a particular property exists then the property MAY be silently > excluded from the response. > > NEW: > > Properties may be subject to access control. In the case of = allprop > and propname, if a principal does not have the right to know = whether > a particular property exists then the property MAY be silently > excluded from the response. > > > Best regards, Julian > > > --- draft-ietf-webdav-rfc2518bis-latest.xml 2005-10-18 =20 > 19:36:56.000000000 +0100 > +++ draft-ietf-webdav-rfc2518bis-latest.26.xml 2005-10-18 =20 > 19:49:47.000000000 +0100 > @@ -1308,9 +1308,7 @@ > All servers MUST support returning a response of content type > text/xml or application/xml that contains a multistatus XML = element > that describes the results of the attempts to retrieve the various > - properties. 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. > + properties. > > > If there is an error retrieving a property then a proper error > @@ -1325,42 +1323,11 @@ > URL of the collection, to whatever depth was requested. Each > response XML element MUST contain an href XML element that gives =20= > the > URL of the resource on which the properties in the prop XML = element > - are defined. URLs for collections appearing in the results MUST =20= > end > - in a slash character. Results for a PROPFIND on a collection > + are defined (see > + for a discussion of allowable values inside the href elements). =20= > Results > + for a PROPFIND on a collection > resource with internal member URLs are returned as a flat list =20 > whose > - order of entries is not significant. > - > - > - A server enumerating the members of a collection using absolute =20= > URLs > - in a PROPFIND response MUST use a common prefix in those URLs, and > - that prefix MUST be the absolute URL used in the response to refer > - to the parent collection. > - > - > - Unless otherwise notified, clients may expect that the URL for the > - parent collection in the PROPFIND response will be the same URL =20= > that > - was used to refer to the parent collection in the PROPFIND = request. > - Servers MAY use an alternate URL for the parent collection in a > - PROPFIND response, but in this case the server MUST include a > - Content-Location header whose value is the fully-qualified URL = used > - by the server to refer to the parent collection in this response. > - > - > - > - 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. > - > - > - If a server allows resource names to include characters that = aren't > - legal in HTTP URL paths, these characters must be URI-escaped on =20= > the > - wire. For example, it is illegal to use a space character or =20 > double- > - quote in a URI. URIs appearing in = =20 > PROPFIND or PROPPATCH > - XML bodies (or other XML marshalling defined in this = specification) > - are still subject to all URI rules, including forbidden = characters. > + order of entries is not significant. > > > Properties may be subject to access control. In the case of = allprop > @@ -3923,7 +3890,7 @@ > > > > -
> +
> > multistatus > DAV: From w3c-dist-auth-request@frink.w3.org Tue Nov 15 22:16:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcDmX-0005pC-Kz for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 22:16:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24229 for ; Tue, 15 Nov 2005 22:15:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcDla-0000sJ-GA for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 03:15:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcDlX-0000oP-OE for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 03:15:19 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcDlV-0005lF-Q9 for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 03:15:19 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 016F914226E for ; Tue, 15 Nov 2005 19:15:17 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12801-08 for ; Tue, 15 Nov 2005 19:15:16 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7466A142260 for ; Tue, 15 Nov 2005 19:15:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <59908be6a9dd30691ec75846b0be7dfc@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDav WG From: Lisa Dusseault Date: Tue, 15 Nov 2005 19:15:11 -0800 X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EcDlV-0005lF-Q9 cb2e2a978ee395f23a438e2b900bb1ea X-Original-To: w3c-dist-auth@w3.org Subject: URI spec RFC2396 obsoleted by RFC3986 X-Archived-At: http://www.w3.org/mid/59908be6a9dd30691ec75846b0be7dfc@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10343 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 03:15:22 +0000 Content-Transfer-Encoding: 7bit RFC 3986 obsoletes RFC2396 (http://www.ietf.org/rfc/rfc3986.txt). If 2518bis refers to 3986, this will cause some changes. 1. WebDAV uses definitions of "absoluteURI" from the URI spec in the syntax of Destination and If headers: Destination = "Destination" ":" ( absoluteURI ) ... Coded-URL = "<" absoluteURI ">" RFC2396 defines absolute-URI: absolute-URI = scheme ":" hier-part [ "?" query ] RFC3986 instead defines absoluteURI: absoluteURI = scheme ":" ( hier_part | opaque_part ) 2. WebDAV uses the "path" definition from the URI spec in the definition of Opaquelocktoken OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] Extension = path Path has the same name in 3986 but its definition changed. 3. We have an example of what kind of illegal characters in URIs might need to be escaped: "For example, it is illegal to use a space character or double-quote in a URI" 4. "DAV:" is now legal! 5. IPv6 addresses are legal... 6. Some new reserved characters: "!", "*", "'", "(", ")" I believe the overall WebDAV spec is OK with the new RFC, but others should check too. Lisa From w3c-dist-auth-request@frink.w3.org Tue Nov 15 22:54:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcENk-0008D6-8N for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 22:54:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25948 for ; Tue, 15 Nov 2005 22:54:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcEMx-000882-1s for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 03:53:59 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcEMt-00087N-Fw for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 03:53:56 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcEMj-0006wn-4J for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 03:53:54 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAG3rfoj023167 for ; Tue, 15 Nov 2005 22:53:41 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAG3rfPd114036 for ; Tue, 15 Nov 2005 22:53:41 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAG3rfcS015297 for ; Tue, 15 Nov 2005 22:53:41 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAG3rfm7015293 for ; Tue, 15 Nov 2005 22:53:41 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 15 Nov 2005 22:53:39 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/15/2005 22:53:40, Serialize complete at 11/15/2005 22:53:40 Content-Type: multipart/alternative; boundary="=_alternative 001049E0852570BB_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcEMj-0006wn-4J dc5ae0a3601b5620093b19610d9e80a7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/OFA7E98C0D.DE4E0458-ON852570BB.000FB358-852570BB.00155DE6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10344 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 03:53:59 +0000 This is a multipart message in MIME format. --=_alternative 001049E0852570BB_= Content-Type: text/plain; charset="US-ASCII" I can only repeat what I posted a few weeks ago ... a client should never steal a lock taken out by an earlier client by re-using the lock token of that earlier client ... it should do so by UNLOCK'ing the resource and requesting its own lock. That way if the original lock owner is still alive or comes back to life, the earlier client's attempt to use the original lock token to update the resource will fail, thus preventing the changes made by the later client from being overwritten. So I object to the text in the current draft, because it encourages clients to do the wrong thing, and encourages servers to support clients doing the wrong thing. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM: > > I'm still concerned about a possible inconsistency here. Sorry if I'm > being dense, but I thought that we had a previous consensus (a long > time ago) that servers SHOULD provide lock tokens for all locks so that > if there were a client bug, a crash, a LOCK reply "lost in the mail", > or a need for an owner or administrator to remove somebody else's stale > lock. Some text currently in the draft to that extent: > > "Anyone can > find out anyone else's lock token by performing lock discovery." > > So given that implies that lock discovery can find out all lock tokens > (given permission), and that the lockdiscovery property is returned in > the LOCK response body, doesn't that mean that the lock token is > returned both in the LOCK response headers (Lock-Token) and body? > > Also, we had previously discussed at an interop which is the "right" > place to put the lock token and concluded that servers ought to put the > token in both places because we found during interoperability testing > that we had clients that looked in one place, and other clients that > looked in the other, so we might as well continue supporting both. > > Lisa > > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > > > > For the record, > > > > I don't think that the recent discussion has brought up any new points > > that need to be said here, so I'd like to again recommend to close the > > issue with the following change (as seen in > > > 0242.html>). > > > > Proposed resolution for > > : [...] > > > > NEW: > > A lock token is a type of state token, represented as a URI, which > > identifies a particular lock. Each lock has exactly one unique lock > > token, which is returned upon a successful LOCK creation operation > > in > > the "Lock-Token" response header defined in Section 9.6. > > > > > > Best regards, Julian > > > > --=_alternative 001049E0852570BB_= Content-Type: text/html; charset="US-ASCII"
I can only repeat what I posted a few weeks ago ... a client should
never steal a lock taken out by an earlier client by re-using the
lock token of that earlier client ... it should do so by UNLOCK'ing
the resource and requesting its own lock.  That way if the original
lock owner is still alive or comes back to life, the earlier client's
attempt to use the original lock token to update the resource will fail,
thus preventing the changes made by the later client from being overwritten.

So I object to the text in the current draft, because it encourages
clients to do the wrong thing, and encourages servers to support clients
doing the wrong thing.

Cheers,
Geoff


w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM:

>
> I'm still concerned about a possible inconsistency here.  Sorry if I'm  
> being dense, but I thought that we had a previous consensus (a long  
> time ago) that servers SHOULD provide lock tokens for all locks so that  
> if there were a client bug, a crash, a LOCK reply "lost in the mail",  
> or a need for an owner or administrator to remove somebody else's stale  
> lock.  Some text currently in the draft to that extent:
>
>    "Anyone can
>     find out anyone else's lock token by performing lock discovery."
>
> So given that implies that lock discovery can find out all lock tokens  
> (given permission), and that the lockdiscovery property is returned in  
> the LOCK response body, doesn't that mean that the lock token is  
> returned both in the LOCK response headers (Lock-Token) and body?
>
> Also, we had previously discussed at an interop which is the "right"  
> place to put the lock token and concluded that servers ought to put the  
> token in both places because we found during interoperability testing  
> that we had clients that looked in one place, and other clients that  
> looked in the other, so we might as well continue supporting both.
>
> Lisa
>
> On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote:
>
> >
> > For the record,
> >
> > I don't think that the recent discussion has brought up any new points  
> > that need to be said here, so I'd like to again recommend to close the  
> > issue with the following change (as seen in  
> > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/
> > 0242.html>).
> >
> > Proposed resolution for  
> > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>: [...]
> >
> > NEW:
> >    A lock token is a type of state token, represented as a URI, which
> >    identifies a particular lock.  Each lock has exactly one unique lock
> >    token, which is returned upon a successful LOCK creation operation  
> > in
> >    the "Lock-Token" response header defined in Section 9.6.
> >
> >
> > Best regards, Julian
> >
>
>
--=_alternative 001049E0852570BB_=-- From w3c-dist-auth-request@frink.w3.org Tue Nov 15 22:59:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcERo-00010D-5L for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 22:59:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26159 for ; Tue, 15 Nov 2005 22:58:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcERD-0000G0-KJ for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 03:58:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcERD-0000FS-6l for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 03:58:23 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcER9-0008Lp-Mt for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 03:58:22 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 35110142272 for ; Tue, 15 Nov 2005 19:58:18 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16347-09 for ; Tue, 15 Nov 2005 19:58:18 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 05EAD142270 for ; Tue, 15 Nov 2005 19:58:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDav WG From: Lisa Dusseault Date: Tue, 15 Nov 2005 19:58:13 -0800 X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EcER9-0008Lp-Mt 1c475eee4de3866fdb40aeb40e283a9c X-Original-To: w3c-dist-auth@w3.org Subject: Draft -08 RFC2518bis X-Archived-At: http://www.w3.org/mid/d252f229e3c019d94936dafb71af3e05@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10345 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 03:58:23 +0000 Content-Transfer-Encoding: 7bit Now that the IETF draft lock-out period is over -- and the busy IETF week -- and a very brief vacation (my niece is awful cute) -- I've uploaded a new draft, hopefully resolving a few bugzilla issues. The change list is of course in the draft which can be found here until the Internet-Drafts directory is updated. http://ietf.webdav.org/webdav/rfc2518bis/ Lisa From w3c-dist-auth-request@frink.w3.org Tue Nov 15 23:00:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcESv-0001Fm-LJ for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 23:00:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26284 for ; Tue, 15 Nov 2005 22:59:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcESJ-0000RF-2S for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 03:59:31 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcESI-0000Qh-29 for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 03:59:30 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcES5-0007pb-FB for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 03:59:29 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 08AA6142272; Tue, 15 Nov 2005 19:59:15 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18362-07; Tue, 15 Nov 2005 19:59:14 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 22C64142270; Tue, 15 Nov 2005 19:59:13 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-3--812471832 Message-Id: <3b311460bf8ce49719db7184f87ccb59@osafoundation.org> Cc: " webdav" From: Lisa Dusseault Date: Tue, 15 Nov 2005 19:59:10 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcES5-0007pb-FB 4a0fe145e089f7ba50a271d1983b9bf0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/3b311460bf8ce49719db7184f87ccb59@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10346 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 03:59:31 +0000 --Apple-Mail-3--812471832 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I agree with you, but isn't the client supposed to UNLOCK by using the=20= lock token? If so then how does it learn it... ? Lisa On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote: > > I can only repeat what I posted a few weeks ago ... a client should > never steal a lock taken out by an earlier client by re-using the > lock token of that earlier client ... it should do so by UNLOCK'ing > the resource and requesting its own lock. =A0That way if the original > lock owner is still alive or comes back to life, the earlier client's > attempt to use the original lock token to update the resource will=20 > fail, > thus preventing the changes made by the later client from being=20 > overwritten. > > So I object to the text in the current draft, because it encourages > clients to do the wrong thing, and encourages servers to support=20 > clients > doing the wrong thing. > > Cheers, > Geoff > > > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM: > > > > > I'm still concerned about a possible inconsistency here. =A0Sorry = if=20 > I'm =A0 > > being dense, but I thought that we had a previous consensus (a long=20= > =A0 > > time ago) that servers SHOULD provide lock tokens for all locks so=20= > that =A0 > > if there were a client bug, a crash, a LOCK reply "lost in the=20 > mail", =A0 > > or a need for an owner or administrator to remove somebody else's=20= > stale =A0 > > lock. =A0Some text currently in the draft to that extent: > > > > =A0 =A0"Anyone can > > =A0 =A0 find out anyone else's lock token by performing lock = discovery." > > > > So given that implies that lock discovery can find out all lock=20 > tokens =A0 > > (given permission), and that the lockdiscovery property is returned=20= > in =A0 > > the LOCK response body, doesn't that mean that the lock token is =A0 > > returned both in the LOCK response headers (Lock-Token) and body? > > > > Also, we had previously discussed at an interop which is the=20 > "right" =A0 > > place to put the lock token and concluded that servers ought to put=20= > the =A0 > > token in both places because we found during interoperability=20 > testing =A0 > > that we had clients that looked in one place, and other clients=20 > that =A0 > > looked in the other, so we might as well continue supporting both. > > > > Lisa > > > > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > > > > > > > For the record, > > > > > > I don't think that the recent discussion has brought up any new=20= > points =A0 > > > that need to be said here, so I'd like to again recommend to=20 > close the =A0 > > > issue with the following change (as seen in =A0 > > > > > 0242.html>). > > > > > > Proposed resolution for =A0 > > > : = [...] > > > > > > NEW: > > > =A0 =A0A lock token is a type of state token, represented as a = URI,=20 > which > > > =A0 =A0identifies a particular lock. =A0Each lock has exactly one=20= > unique lock > > > =A0 =A0token, which is returned upon a successful LOCK creation=20= > operation =A0 > > > in > > > =A0 =A0the "Lock-Token" response header defined in Section 9.6. > > > > > > > > > Best regards, Julian > > > > > > > --Apple-Mail-3--812471832 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with you, but isn't the client supposed to UNLOCK by using the lock token? If so then how does it learn it... ? Lisa On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote: I can only repeat what I posted a few weeks ago ... a client should=20 never steal a lock taken out by an earlier client by re-using the=20 lock token of that earlier client ... it should do so by UNLOCK'ing=20 the resource and requesting its own lock. =A0That way if the original=20 lock owner is still alive or comes back to life, the earlier client's=20 attempt to use the original lock token to update the resource will fail, thus preventing the changes made by the later client from being overwritten.=20 So I object to the text in the current draft, because it encourages=20 clients to do the wrong thing, and encourages servers to support clients=20 doing the wrong thing.=20 Cheers,=20 Geoff=20 w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM: > > I'm still concerned about a possible inconsistency here. =A0Sorry if I'm =A0 > being dense, but I thought that we had a previous consensus (a long =A0 > time ago) that servers SHOULD provide lock tokens for all locks so that =A0 > if there were a client bug, a crash, a LOCK reply "lost in the mail", =A0 > or a need for an owner or administrator to remove somebody else's stale =A0 > lock. =A0Some text currently in the draft to that extent: > > =A0 =A0"Anyone can > =A0 =A0 find out anyone else's lock token by performing lock discovery." > > So given that implies that lock discovery can find out all lock tokens =A0 > (given permission), and that the lockdiscovery property is returned in =A0 > the LOCK response body, doesn't that mean that the lock token is =A0 > returned both in the LOCK response headers (Lock-Token) and body? > > Also, we had previously discussed at an interop which is the "right" =A0 > place to put the lock token and concluded that servers ought to put the =A0 > token in both places because we found during interoperability testing =A0 > that we had clients that looked in one place, and other clients that =A0 > looked in the other, so we might as well continue supporting both. > > Lisa > > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > > > > For the record, > > > > I don't think that the recent discussion has brought up any new points =A0 > > that need to be said here, so I'd like to again recommend to close the =A0 > > issue with the following change (as seen in = =A0 > > = < > > 0242.html>). > > > > Proposed resolution for = =A0 > > <: = [...] > > > > NEW: > > =A0 =A0A lock token is a type of state token, represented as a URI, which > > =A0 =A0identifies a particular lock. =A0Each = lock has exactly one unique lock > > =A0 =A0token, which is returned upon a successful LOCK creation operation =A0 > > in > > =A0 =A0the "Lock-Token" response header = defined in Section 9.6. > > > > > > Best regards, Julian > > > > = --Apple-Mail-3--812471832-- From w3c-dist-auth-request@frink.w3.org Tue Nov 15 23:41:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcF7F-0004BY-Ib for webdav-archive@megatron.ietf.org; Tue, 15 Nov 2005 23:41:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28247 for ; Tue, 15 Nov 2005 23:41:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcF6C-000169-Bl for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 04:40:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcF69-00015Y-Jq for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 04:40:41 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcF64-0005m4-9R for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 04:40:41 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAG4eWMu021721 for ; Tue, 15 Nov 2005 23:40:32 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAG4eWPd106332 for ; Tue, 15 Nov 2005 23:40:32 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAG4eWrF012177 for ; Tue, 15 Nov 2005 23:40:32 -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 jAG4eWAP012171 for ; Tue, 15 Nov 2005 23:40:32 -0500 In-Reply-To: <3b311460bf8ce49719db7184f87ccb59@osafoundation.org> To: Lisa Dusseault Cc: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 15 Nov 2005 23:40:30 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/15/2005 23:40:31, Serialize complete at 11/15/2005 23:40:31 Content-Type: multipart/alternative; boundary="=_alternative 0019A792852570BB_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EcF64-0005m4-9R 9aff6dbe9b38e5d7ad672058bf0acce2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/OF5E599060.3012AAFF-ON852570BB.00172386-852570BB.0019A802@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10347 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 04:40:44 +0000 This is a multipart message in MIME format. --=_alternative 0019A792852570BB_= Content-Type: text/plain; charset="US-ASCII" Sorry, I misread your message. The text that I was objecting to was the clauses: > if there were a client bug, a crash, a LOCK reply "lost in the mail" in: > servers SHOULD provide lock tokens for all locks so > that if there were a client bug, a crash, a LOCK reply "lost in the > mail", or a need for an owner or administrator to remove somebody else's > stale lock. but the text you were proposing was just: > "Anyone can > find out anyone else's lock token by performing lock discovery." which is fine. I'd prefer making that explicit (e.g. "A lock token discovered by a client via lock discovery SHOULD NOT be used by that client for anything other than an UNLOCK request, even if the user is authenticated as owning that lock"), but I don't insist that this be added (as long as the converse is not added :-). Cheers, Geoff Lisa Dusseault wrote on 11/15/2005 10:59:10 PM: > I agree with you, but isn't the client supposed to UNLOCK by using the > lock token? If so then how does it learn it... ? > > Lisa > > On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote: > > > > > I can only repeat what I posted a few weeks ago ... a client should > > never steal a lock taken out by an earlier client by re-using the > > lock token of that earlier client ... it should do so by UNLOCK'ing > > the resource and requesting its own lock. That way if the original > > lock owner is still alive or comes back to life, the earlier client's > > attempt to use the original lock token to update the resource will > > fail, > > thus preventing the changes made by the later client from being > > overwritten. > > > > So I object to the text in the current draft, because it encourages > > clients to do the wrong thing, and encourages servers to support > > clients > > doing the wrong thing. > > > > Cheers, > > Geoff > > > > > > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM: > > > > > > > > I'm still concerned about a possible inconsistency here. Sorry if > > I'm > > > being dense, but I thought that we had a previous consensus (a long > > > > > time ago) that servers SHOULD provide lock tokens for all locks so > > that > > > if there were a client bug, a crash, a LOCK reply "lost in the > > mail", > > > or a need for an owner or administrator to remove somebody else's > > stale > > > lock. Some text currently in the draft to that extent: > > > > > > "Anyone can > > > find out anyone else's lock token by performing lock discovery." > > > > > > So given that implies that lock discovery can find out all lock > > tokens > > > (given permission), and that the lockdiscovery property is returned > > in > > > the LOCK response body, doesn't that mean that the lock token is > > > returned both in the LOCK response headers (Lock-Token) and body? > > > > > > Also, we had previously discussed at an interop which is the > > "right" > > > place to put the lock token and concluded that servers ought to put > > the > > > token in both places because we found during interoperability > > testing > > > that we had clients that looked in one place, and other clients > > that > > > looked in the other, so we might as well continue supporting both. > > > > > > Lisa > > > > > > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > > > > > > > > > > For the record, > > > > > > > > I don't think that the recent discussion has brought up any new > > points > > > > that need to be said here, so I'd like to again recommend to > > close the > > > > issue with the following change (as seen in > > > > > > > 0242.html>). > > > > > > > > Proposed resolution for > > > > : [...] > > > > > > > > NEW: > > > > A lock token is a type of state token, represented as a URI, > > which > > > > identifies a particular lock. Each lock has exactly one > > unique lock > > > > token, which is returned upon a successful LOCK creation > > operation > > > > in > > > > the "Lock-Token" response header defined in Section 9.6. > > > > > > > > > > > > Best regards, Julian > > > > > > > > > > --=_alternative 0019A792852570BB_= Content-Type: text/html; charset="US-ASCII"
Sorry, I misread your message.  The text that I was objecting to was
the clauses:

> if there were a client bug, a crash, a LOCK reply "lost in the mail"

in:

> servers SHOULD provide lock tokens for all locks so
> that if there were a client bug, a crash, a LOCK reply "lost in the
> mail", or a need for an owner or administrator to remove somebody else's
> stale lock.

but the text you were proposing was just:

>  "Anyone can
>   find out anyone else's lock token by performing lock discovery."

which is fine.  I'd prefer making that explicit (e.g. "A lock token
discovered by a client via lock discovery SHOULD NOT be used by that
client for anything other than an UNLOCK request, even if the user
is authenticated as owning that lock"), but I don't insist that this
be added (as long as the converse is not added :-).

Cheers,
Geoff

Lisa Dusseault <lisa@osafoundation.org> wrote on 11/15/2005 10:59:10 PM:

> I agree with you, but isn't the client supposed to UNLOCK by using the
> lock token?  If so then how does it learn it... ?
>
> Lisa
>
> On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote:
>
> >
> > I can only repeat what I posted a few weeks ago ... a client should
> > never steal a lock taken out by an earlier client by re-using the
> > lock token of that earlier client ... it should do so by UNLOCK'ing
> > the resource and requesting its own lock.  That way if the original
> > lock owner is still alive or comes back to life, the earlier client's
> > attempt to use the original lock token to update the resource will
> > fail,
> > thus preventing the changes made by the later client from being
> > overwritten.
> >
> > So I object to the text in the current draft, because it encourages
> > clients to do the wrong thing, and encourages servers to support
> > clients
> > doing the wrong thing.
> >
> > Cheers,
> > Geoff
> >
> >
> > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM:
> >
> >  >
> >  > I'm still concerned about a possible inconsistency here.  Sorry if
> > I'm  
> >  > being dense, but I thought that we had a previous consensus (a long
> >  
> >  > time ago) that servers SHOULD provide lock tokens for all locks so
> > that  
> >  > if there were a client bug, a crash, a LOCK reply "lost in the
> > mail",  
> >  > or a need for an owner or administrator to remove somebody else's
> > stale  
> >  > lock.  Some text currently in the draft to that extent:
> >  >
> >  >    "Anyone can
> >  >     find out anyone else's lock token by performing lock discovery."
> >  >
> >  > So given that implies that lock discovery can find out all lock
> > tokens  
> >  > (given permission), and that the lockdiscovery property is returned
> > in  
> >  > the LOCK response body, doesn't that mean that the lock token is  
> >  > returned both in the LOCK response headers (Lock-Token) and body?
> >  >
> >  > Also, we had previously discussed at an interop which is the
> > "right"  
> >  > place to put the lock token and concluded that servers ought to put
> > the  
> >  > token in both places because we found during interoperability
> > testing  
> >  > that we had clients that looked in one place, and other clients
> > that  
> >  > looked in the other, so we might as well continue supporting both.
> >  >
> >  > Lisa
> >  >
> >  > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote:
> >  >
> >  > >
> >  > > For the record,
> >  > >
> >  > > I don't think that the recent discussion has brought up any new
> > points  
> >  > > that need to be said here, so I'd like to again recommend to
> > close the  
> >  > > issue with the following change (as seen in  
> >  > > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/
> >  > > 0242.html>).
> >  > >
> >  > > Proposed resolution for  
> >  > > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>: [...]
> >  > >
> >  > > NEW:
> >  > >    A lock token is a type of state token, represented as a URI,
> > which
> >  > >    identifies a particular lock.  Each lock has exactly one
> > unique lock
> >  > >    token, which is returned upon a successful LOCK creation
> > operation  
> >  > > in
> >  > >    the "Lock-Token" response header defined in Section 9.6.
> >  > >
> >  > >
> >  > > Best regards, Julian
> >  > >
> >  >
> >  >
 --=_alternative 0019A792852570BB_=-- From w3c-dist-auth-request@frink.w3.org Wed Nov 16 03:31:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcIhF-0007Wg-9f for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 03:31:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08950 for ; Wed, 16 Nov 2005 03:30:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcIfE-0006f6-63 for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 08:29:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcIf9-0006eR-LZ for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 08:29:03 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EcIf4-0007Zz-St for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 08:29:03 +0000 Received: (qmail invoked by alias); 16 Nov 2005 08:28:55 -0000 Received: from p508FA3F5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.245] by mail.gmx.net (mp013) with SMTP; 16 Nov 2005 09:28:55 +0100 X-Authenticated: #1915285 Message-ID: <437AED9D.9070908@gmx.de> Date: Wed, 16 Nov 2005 09:28:13 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> <8eaf9241d62055518696cf3f434114e1@osafoundation.org> <43639C2E.3040109@gmx.de> <43639F63.4090000@gmx.de> <436E6317.1000101@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EcIf4-0007Zz-St 27c08fa270a66932092f587a99ea01c3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437AED9D.9070908@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10348 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 08:29:08 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > I'm still concerned about a possible inconsistency here. Sorry if I'm > being dense, but I thought that we had a previous consensus (a long time > ago) that servers SHOULD provide lock tokens for all locks so that if > there were a client bug, a crash, a LOCK reply "lost in the mail", or a > need for an owner or administrator to remove somebody else's stale > lock. Some text currently in the draft to that extent: > > "Anyone can > find out anyone else's lock token by performing lock discovery." > > So given that implies that lock discovery can find out all lock tokens > (given permission), and that the lockdiscovery property is returned in That's not guaranteed. Servers are currently not to required to reveal locks, and if they do, they aren't required to reveal the individual lock tokens. Note that is optional in (). > the LOCK response body, doesn't that mean that the lock token is > returned both in the LOCK response headers (Lock-Token) and body? It may, but clients can not rely on it. > Also, we had previously discussed at an interop which is the "right" > place to put the lock token and concluded that servers ought to put the > token in both places because we found during interoperability testing > that we had clients that looked in one place, and other clients that > looked in the other, so we might as well continue supporting both. Again: the only *reliable* way to obtain the new lock token is to parse the Lock-Token response header. Anything else may not work because (a) the server may not be including it in the and/or (b) because there may be multiple entries due to shared locks. Of course all of this *could* be explained, but I absolutely do not understand why we would want to spend a paragraph describing a work flow that is not guaranteed to work, when there's another one which is. Servers not returning the Lock-Token response header upon successful lock creation are buggy and need to be fixed. Is anybody ware of a server that currently shows this behaviour? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 03:33:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcIjK-00083p-GQ for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 03:33:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09051 for ; Wed, 16 Nov 2005 03:32:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcIil-0000YN-5o for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 08:32:47 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcIik-0000Xj-Ic for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 08:32:46 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EcIiZ-00070t-6x for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 08:32:45 +0000 Received: (qmail invoked by alias); 16 Nov 2005 08:32:29 -0000 Received: from p508FA3F5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.245] by mail.gmx.net (mp012) with SMTP; 16 Nov 2005 09:32:29 +0100 X-Authenticated: #1915285 Message-ID: <437AEE71.2090500@gmx.de> Date: Wed, 16 Nov 2005 09:31:45 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDav WG References: <59908be6a9dd30691ec75846b0be7dfc@osafoundation.org> In-Reply-To: <59908be6a9dd30691ec75846b0be7dfc@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcIiZ-00070t-6x c02724ac07a83eb036de25723a318eeb X-Original-To: w3c-dist-auth@w3.org Subject: Re: URI spec RFC2396 obsoleted by RFC3986 X-Archived-At: http://www.w3.org/mid/437AEE71.2090500@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10349 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 08:32:47 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > RFC 3986 obsoletes RFC2396 (http://www.ietf.org/rfc/rfc3986.txt). If > 2518bis refers to 3986, this will cause some changes. > > 1. WebDAV uses definitions of "absoluteURI" from the URI spec in the > syntax of Destination and If headers: > > Destination = "Destination" ":" ( absoluteURI ) > ... > Coded-URL = "<" absoluteURI ">" > > RFC2396 defines absolute-URI: > > absolute-URI = scheme ":" hier-part [ "?" query ] > > RFC3986 instead defines absoluteURI: > > absoluteURI = scheme ":" ( hier_part | opaque_part ) Yes. > 2. WebDAV uses the "path" definition from the URI spec in the > definition of Opaquelocktoken > > OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] > Extension = path > > Path has the same name in 3986 but its definition changed. What did actually change? > 3. We have an example of what kind of illegal characters in URIs might > need to be escaped: > > "For example, it is illegal to use a space character or double-quote > in a URI" That's not a problem. > 4. "DAV:" is now legal! > > 5. IPv6 addresses are legal... > > 6. Some new reserved characters: "!", "*", "'", "(", ")" > > I believe the overall WebDAV spec is OK with the new RFC, but others > should check too. Agreed. From w3c-dist-auth-request@frink.w3.org Wed Nov 16 03:44:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcIuG-0002TK-FD for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 03:44:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10080 for ; Wed, 16 Nov 2005 03:44:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcIta-0001q5-UB for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 08:43:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcItY-0001pX-Qi for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 08:43:56 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EcItU-0006AO-NI for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 08:43:55 +0000 Received: (qmail invoked by alias); 16 Nov 2005 08:43:52 -0000 Received: from p508FA3F5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.245] by mail.gmx.net (mp033) with SMTP; 16 Nov 2005 09:43:52 +0100 X-Authenticated: #1915285 Message-ID: <437AF090.3090802@gmx.de> Date: Wed, 16 Nov 2005 09:40:48 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <200510181823.j9IINZCw029195@ietf.cse.ucsc.edu> <4355456A.6000307@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EcItU-0006AO-NI f7375d43071815f1abb4a22b65d82602 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/437AF090.3090802@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10350 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 08:43:58 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > I agree some of the text on PROPFIND can be moved to the section on > Multi-Status. I had been cleaning that up and clearly hadn't > finished. I'll take this opportunity to clean both sections up. I > think the section on general Multi-Status usage is now big enough to > warrant a few sub-sections which you'll see shortly. It's probably not > done yet, of course. > > One point of confusion, you lost me on the reference to section 13.15. > How does that discuss what's allowable in ? That was a mistake, the forward reference probably should go either to section 12 (multistatus response body) or section 13.7 (href element). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 10:43:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPRO-0004TA-8h for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 10:43:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04379 for ; Wed, 16 Nov 2005 10:42:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcPPw-0000N8-SE for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 15:41:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcPPs-0000MU-Qg for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 15:41:44 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcPPj-0001ul-UO for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 15:41:44 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9BA75142275; Wed, 16 Nov 2005 07:41:34 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25443-01; Wed, 16 Nov 2005 07:41:34 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6FC4614225E; Wed, 16 Nov 2005 07:41:31 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-4--770336575 Message-Id: <9273f80ff101b5dd2d30a4582502e91b@osafoundation.org> Cc: " webdav" From: Lisa Dusseault Date: Wed, 16 Nov 2005 07:41:25 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EcPPj-0001ul-UO d95b380674767c54e8b6f7a68c2162b8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/9273f80ff101b5dd2d30a4582502e91b@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10351 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 15:41:48 +0000 --Apple-Mail-4--770336575 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable That's fine with me too. So does this mean that lockdiscovery property=20= (if readable) MUST contain all the locks and all their lock tokens? =20 Does that mean that in reply to a LOCK request which successfully=20 creates a new lock, the server MUST include the full lockdiscovery=20 property including not just the new lock but also other locks? Lisa On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote: > > Sorry, I misread your message. =A0The text that I was objecting to was > the clauses: > > > if there were a client bug, a crash, a LOCK reply "lost in the mail" > > in: > > > servers SHOULD provide lock tokens for all locks so > > that if there were a client bug, a crash, a LOCK reply "lost in the > > mail", or a need for an owner or administrator to remove somebody=20= > else's > > stale lock. > > but the text you were proposing was just: > > > =A0"Anyone can > > =A0 find out anyone else's lock token by performing lock = discovery." > > which is fine. =A0I'd prefer making that explicit (e.g. "A lock token > discovered by a client via lock discovery SHOULD NOT be used by that > client for anything other than an UNLOCK request, even if the user > is authenticated as owning that lock"), but I don't insist that this > be added (as long as the converse is not added :-). > > Cheers, > Geoff > > > Lisa Dusseault wrote on 11/15/2005 10:59:10=20= > PM: > > > I agree with you, but isn't the client supposed to UNLOCK by using=20= > the > > lock token? =A0If so then how does it learn it... ? > > > > Lisa > > > > On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote: > > > > > > > > I can only repeat what I posted a few weeks ago ... a client=20 > should > > > never steal a lock taken out by an earlier client by re-using the > > > lock token of that earlier client ... it should do so by=20 > UNLOCK'ing > > > the resource and requesting its own lock. =A0That way if the=20 > original > > > lock owner is still alive or comes back to life, the earlier=20 > client's > > > attempt to use the original lock token to update the resource = will > > > fail, > > > thus preventing the changes made by the later client from being > > > overwritten. > > > > > > So I object to the text in the current draft, because it=20 > encourages > > > clients to do the wrong thing, and encourages servers to support > > > clients > > > doing the wrong thing. > > > > > > Cheers, > > > Geoff > > > > > > > > > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM: > > > > > > =A0> > > > =A0> I'm still concerned about a possible inconsistency here.=20 > =A0Sorry if > > > I'm =A0 > > > =A0> being dense, but I thought that we had a previous consensus = (a=20 > long > > > =A0 > > > =A0> time ago) that servers SHOULD provide lock tokens for all=20 > locks so > > > that =A0 > > > =A0> if there were a client bug, a crash, a LOCK reply "lost in = the > > > mail", =A0 > > > =A0> or a need for an owner or administrator to remove somebody=20= > else's > > > stale =A0 > > > =A0> lock. =A0Some text currently in the draft to that extent: > > > =A0> > > > =A0> =A0 =A0"Anyone can > > > =A0> =A0 =A0 find out anyone else's lock token by performing lock=20= > discovery." > > > =A0> > > > =A0> So given that implies that lock discovery can find out all = lock > > > tokens =A0 > > > =A0> (given permission), and that the lockdiscovery property is=20= > returned > > > in =A0 > > > =A0> the LOCK response body, doesn't that mean that the lock = token=20 > is =A0 > > > =A0> returned both in the LOCK response headers (Lock-Token) and=20= > body? > > > =A0> > > > =A0> Also, we had previously discussed at an interop which is the > > > "right" =A0 > > > =A0> place to put the lock token and concluded that servers ought=20= > to put > > > the =A0 > > > =A0> token in both places because we found during = interoperability > > > testing =A0 > > > =A0> that we had clients that looked in one place, and other = clients > > > that =A0 > > > =A0> looked in the other, so we might as well continue supporting=20= > both. > > > =A0> > > > =A0> Lisa > > > =A0> > > > =A0> On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > > =A0> > > > =A0> > > > > =A0> > For the record, > > > =A0> > > > > =A0> > I don't think that the recent discussion has brought up = any=20 > new > > > points =A0 > > > =A0> > that need to be said here, so I'd like to again recommend = to > > > close the =A0 > > > =A0> > issue with the following change (as seen in =A0 > > > =A0> >=20 > > > =A0> > 0242.html>). > > > =A0> > > > > =A0> > Proposed resolution for =A0 > > > =A0> > = :=20 > [...] > > > =A0> > > > > =A0> > NEW: > > > =A0> > =A0 =A0A lock token is a type of state token, represented = as a=20 > URI, > > > which > > > =A0> > =A0 =A0identifies a particular lock. =A0Each lock has = exactly one > > > unique lock > > > =A0> > =A0 =A0token, which is returned upon a successful LOCK = creation > > > operation =A0 > > > =A0> > in > > > =A0> > =A0 =A0the "Lock-Token" response header defined in Section = 9.6. > > > =A0> > > > > =A0> > > > > =A0> > Best regards, Julian > > > =A0> > > > > =A0> > > > =A0> --Apple-Mail-4--770336575 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's fine with me too. So does this mean that lockdiscovery property (if readable) MUST contain all the locks and all their lock tokens? Does that mean that in reply to a LOCK request which successfully creates a new lock, the server MUST include the full lockdiscovery property including not just the new lock but also other locks? Lisa On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote: Sorry, I misread your message. =A0The text that I was objecting to was=20 the clauses:=20 > if there were a client bug, a crash, a LOCK reply "lost in the mail"=20 in:=20 > servers SHOULD provide lock tokens for all locks so > that if there were a client bug, a crash, a LOCK reply "lost in the > mail", or a need for an owner or administrator to remove somebody else's > stale lock. but the text you were proposing was just:=20 > =A0"Anyone can > =A0 find out anyone else's lock token by performing lock discovery."=20 which is fine. =A0I'd prefer making that explicit (e.g. "A lock token discovered by a client via lock discovery SHOULD NOT be used by that=20 client for anything other than an UNLOCK request, even if the user=20 is authenticated as owning that lock"), but I don't insist that this=20 be added (as long as the converse is not added :-).=20 Cheers,=20 Geoff Lisa Dusseault < wrote on 11/15/2005 10:59:10 PM: > I agree with you, but isn't the client supposed to UNLOCK by using the > lock token? =A0If so then how does it learn it... ? > > Lisa > > On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote: > > > > > I can only repeat what I posted a few weeks ago ... a client should > > never steal a lock taken out by an earlier client by re-using the > > lock token of that earlier client ... it should do so by UNLOCK'ing > > the resource and requesting its own lock. =A0That way if the original > > lock owner is still alive or comes back to life, the earlier client's > > attempt to use the original lock token to update the resource will > > fail, > > thus preventing the changes made by the later client from being > > overwritten. > > > > So I object to the text in the current draft, because it encourages > > clients to do the wrong thing, and encourages servers to support > > clients > > doing the wrong = thing. > > > > Cheers, > > Geoff > > > > > > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM: > > > > =A0> > > =A0> I'm still concerned about a possible inconsistency here. =A0Sorry if > > I'm =A0 > > =A0> being dense, but I thought that we had a previous consensus (a long > > =A0 > > =A0> time ago) that servers SHOULD provide lock tokens for all locks so > > that =A0 > > =A0> if there were a client bug, a crash, a LOCK reply "lost in the > > mail", =A0 > > =A0> or a need for an owner or administrator to remove somebody else's > > stale =A0 > > =A0> lock. =A0Some text currently in the = draft to that extent: > > =A0> > > =A0> =A0 =A0"Anyone = can > > =A0> =A0 =A0 find out anyone else's lock = token by performing lock discovery." > > =A0> > > =A0> So given that implies that lock discovery can find out all lock > > tokens =A0 > > =A0> (given permission), and that the lockdiscovery property is returned > > in =A0 > > =A0> the LOCK response body, doesn't that mean that the lock token is =A0 > > =A0> returned both in the LOCK response headers (Lock-Token) and body? > > =A0> > > =A0> Also, we had previously discussed at an interop which is the > > "right" =A0 > > =A0> place to put the lock token and concluded that servers ought to put > > the =A0 > > =A0> token in both places because we found during interoperability > > testing =A0 > > =A0> that we had clients that looked in one place, and other clients > > that =A0 > > =A0> looked in the other, so we might as well continue supporting both. > > =A0> > > =A0> Lisa > > =A0> > > =A0> On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > =A0> > > =A0> > > > =A0> > For the = record, > > =A0> > > > =A0> > I don't think that the recent discussion has brought up any new > > points =A0 > > =A0> > that need to be said here, so I'd like to again recommend to > > close the =A0 > > =A0> > issue with the following change (as seen in =A0 > > =A0> > = < > > =A0> > 0242.html>). > > =A0> > > > =A0> > Proposed resolution for = =A0 > > =A0> > <: = [...] > > =A0> > > > =A0> > NEW: > > =A0> > =A0 =A0A lock token is a type of state token, represented as a URI, > > which > > =A0> > =A0 =A0identifies a particular lock. = =A0Each lock has exactly one > > unique lock > > =A0> > =A0 =A0token, which is returned upon a successful LOCK creation > > operation =A0 > > =A0> > in > > =A0> > =A0 =A0the "Lock-Token" response = header defined in Section 9.6. > > =A0> > > > =A0> > > > =A0> > Best regards, = Julian > > =A0> > > > =A0> > > =A0> = --Apple-Mail-4--770336575-- From w3c-dist-auth-request@frink.w3.org Wed Nov 16 10:59:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPhP-0000tJ-M2 for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 10:59:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05876 for ; Wed, 16 Nov 2005 10:59:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcPgg-00065I-CC for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 15:59:06 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcPgU-00060Q-SU for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 15:58:55 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EcPgE-00040W-NC for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 15:58:53 +0000 Received: (qmail invoked by alias); 16 Nov 2005 15:58:33 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 16 Nov 2005 16:58:33 +0100 X-Authenticated: #1915285 Message-ID: <437B56E6.6080506@gmx.de> Date: Wed, 16 Nov 2005 16:57:26 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <9273f80ff101b5dd2d30a4582502e91b@osafoundation.org> In-Reply-To: <9273f80ff101b5dd2d30a4582502e91b@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcPgE-00040W-NC 8a88fc32ff34ade68aee11d276c73a30 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437B56E6.6080506@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10352 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 15:59:06 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > That's fine with me too. So does this mean that lockdiscovery property > (if readable) MUST contain all the locks and all their lock tokens? Does No: : "The server is free to withhold any or all of this information if the requesting principal does not have sufficient access rights to see the requested data." > that mean that in reply to a LOCK request which successfully creates a > new lock, the server MUST include the full lockdiscovery property > including not just the new lock but also other locks? I think RFC2518 is very clear about this. Why are we discussing this? Upon lock creation, you get the lock token in the "lock-token" response header. I do not understand why you're trying to describe an alternate method, which may or may not work depending on how the server treats lock token privacy and shared locks. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 11:11:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPt4-0006bD-Nm for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 11:11:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06744 for ; Wed, 16 Nov 2005 11:11:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcPsO-0002N0-Lp for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 16:11:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcPsK-0002Lo-CD for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 16:11:08 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcPsA-0001Jn-NR for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 16:11:06 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAGGAu8L017150 for ; Wed, 16 Nov 2005 11:10:56 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAGGAu9N086920 for ; Wed, 16 Nov 2005 11:10:56 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAGGAu81012301 for ; Wed, 16 Nov 2005 11:10:56 -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 jAGGAujM012293; Wed, 16 Nov 2005 11:10:56 -0500 In-Reply-To: <9273f80ff101b5dd2d30a4582502e91b@osafoundation.org> To: Lisa Dusseault Cc: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 16 Nov 2005 11:11:07 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/16/2005 11:10:55, Serialize complete at 11/16/2005 11:10:55 Content-Type: multipart/alternative; boundary="=_alternative 0058E20C852570BB_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EcPsA-0001Jn-NR 6b778d703feb5299cd703524ab898431 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/OF6F9075BF.109C3BFE-ON852570BB.00589A89-852570BB.0058E288@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10353 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 16:11:12 +0000 This is a multipart message in MIME format. --=_alternative 0058E20C852570BB_= Content-Type: text/plain; charset="US-ASCII" Some of the reasons why a server does not include the lock-token: - all locks time-out in a reasonable period of time, and so no explicit unlock is needed/supported - only the owner/admin is allowed to do the unlock, so the lock-token is only exposed to a client that is authenticated as being either the owner or the admin Cheers, Geoff Lisa Dusseault wrote on 11/16/2005 10:41:25 AM: > That's fine with me too. So does this mean that lockdiscovery property > (if readable) MUST contain all the locks and all their lock tokens? > Does that mean that in reply to a LOCK request which successfully > creates a new lock, the server MUST include the full lockdiscovery > property including not just the new lock but also other locks? > > Lisa > > On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote: > > > > > Sorry, I misread your message. The text that I was objecting to was > > the clauses: > > > > > if there were a client bug, a crash, a LOCK reply "lost in the mail" > > > > in: > > > > > servers SHOULD provide lock tokens for all locks so > > > that if there were a client bug, a crash, a LOCK reply "lost in the > > > mail", or a need for an owner or administrator to remove somebody > > else's > > > stale lock. > > > > but the text you were proposing was just: > > > > > "Anyone can > > > find out anyone else's lock token by performing lock discovery." > > > > which is fine. I'd prefer making that explicit (e.g. "A lock token > > discovered by a client via lock discovery SHOULD NOT be used by that > > client for anything other than an UNLOCK request, even if the user > > is authenticated as owning that lock"), but I don't insist that this > > be added (as long as the converse is not added :-). > > > > Cheers, > > Geoff > > > > > > Lisa Dusseault wrote on 11/15/2005 10:59:10 > > PM: > > > > > I agree with you, but isn't the client supposed to UNLOCK by using > > the > > > lock token? If so then how does it learn it... ? > > > > > > Lisa > > > > > > On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote: > > > > > > > > > > > I can only repeat what I posted a few weeks ago ... a client > > should > > > > never steal a lock taken out by an earlier client by re-using the > > > > lock token of that earlier client ... it should do so by > > UNLOCK'ing > > > > the resource and requesting its own lock. That way if the > > original > > > > lock owner is still alive or comes back to life, the earlier > > client's > > > > attempt to use the original lock token to update the resource will > > > > fail, > > > > thus preventing the changes made by the later client from being > > > > overwritten. > > > > > > > > So I object to the text in the current draft, because it > > encourages > > > > clients to do the wrong thing, and encourages servers to support > > > > clients > > > > doing the wrong thing. > > > > > > > > Cheers, > > > > Geoff > > > > > > > > > > > > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM: > > > > > > > > > > > > > > I'm still concerned about a possible inconsistency here. > > Sorry if > > > > I'm > > > > > being dense, but I thought that we had a previous consensus (a > > long > > > > > > > > > time ago) that servers SHOULD provide lock tokens for all > > locks so > > > > that > > > > > if there were a client bug, a crash, a LOCK reply "lost in the > > > > mail", > > > > > or a need for an owner or administrator to remove somebody > > else's > > > > stale > > > > > lock. Some text currently in the draft to that extent: > > > > > > > > > > "Anyone can > > > > > find out anyone else's lock token by performing lock > > discovery." > > > > > > > > > > So given that implies that lock discovery can find out all lock > > > > tokens > > > > > (given permission), and that the lockdiscovery property is > > returned > > > > in > > > > > the LOCK response body, doesn't that mean that the lock token > > is > > > > > returned both in the LOCK response headers (Lock-Token) and > > body? > > > > > > > > > > Also, we had previously discussed at an interop which is the > > > > "right" > > > > > place to put the lock token and concluded that servers ought > > to put > > > > the > > > > > token in both places because we found during interoperability > > > > testing > > > > > that we had clients that looked in one place, and other clients > > > > that > > > > > looked in the other, so we might as well continue supporting > > both. > > > > > > > > > > Lisa > > > > > > > > > > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > > > > > > > > > > > > > > > > For the record, > > > > > > > > > > > > I don't think that the recent discussion has brought up any > > new > > > > points > > > > > > that need to be said here, so I'd like to again recommend to > > > > close the > > > > > > issue with the following change (as seen in > > > > > > > > > > > > > 0242.html>). > > > > > > > > > > > > Proposed resolution for > > > > > > : > > [...] > > > > > > > > > > > > NEW: > > > > > > A lock token is a type of state token, represented as a > > URI, > > > > which > > > > > > identifies a particular lock. Each lock has exactly one > > > > unique lock > > > > > > token, which is returned upon a successful LOCK creation > > > > operation > > > > > > in > > > > > > the "Lock-Token" response header defined in Section 9.6. > > > > > > > > > > > > > > > > > > Best regards, Julian > > > > > > > > > > > > > > > > --=_alternative 0058E20C852570BB_= Content-Type: text/html; charset="US-ASCII"
Some of the reasons why a server does not include the lock-token:
- all locks time-out in a reasonable period of time, and so no explicit unlock is needed/supported
- only the owner/admin is allowed to do the unlock, so the lock-token is only exposed to a client that is authenticated as being either the owner or the admin

Cheers,
Geoff

Lisa Dusseault <lisa@osafoundation.org> wrote on 11/16/2005 10:41:25 AM:

> That's fine with me too.  So does this mean that lockdiscovery property
> (if readable) MUST contain all the locks and all their lock tokens?  
> Does that mean that in reply to a LOCK request which successfully
> creates a new lock, the server MUST include the full lockdiscovery
> property including not just the new lock but also other locks?
>
> Lisa
>
> On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote:
>
> >
> > Sorry, I misread your message.  The text that I was objecting to was
> > the clauses:
> >
> > > if there were a client bug, a crash, a LOCK reply "lost in the mail"
> >
> > in:
> >
> > > servers SHOULD provide lock tokens for all locks so
> >  > that if there were a client bug, a crash, a LOCK reply "lost in the
> >  > mail", or a need for an owner or administrator to remove somebody
> > else's
> >  > stale lock.
> >
> > but the text you were proposing was just:
> >
> > >  "Anyone can
> >  >   find out anyone else's lock token by performing lock discovery."
> >
> > which is fine.  I'd prefer making that explicit (e.g. "A lock token
> > discovered by a client via lock discovery SHOULD NOT be used by that
> > client for anything other than an UNLOCK request, even if the user
> > is authenticated as owning that lock"), but I don't insist that this
> > be added (as long as the converse is not added :-).
> >
> > Cheers,
> > Geoff
> >
> >
> > Lisa Dusseault <lisa@osafoundation.org> wrote on 11/15/2005 10:59:10
> > PM:
> >
> >  > I agree with you, but isn't the client supposed to UNLOCK by using
> > the
> >  > lock token?  If so then how does it learn it... ?
> >  >
> >  > Lisa
> >  >
> >  > On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote:
> >  >
> >  > >
> >  > > I can only repeat what I posted a few weeks ago ... a client
> > should
> >  > > never steal a lock taken out by an earlier client by re-using the
> >  > > lock token of that earlier client ... it should do so by
> > UNLOCK'ing
> >  > > the resource and requesting its own lock.  That way if the
> > original
> >  > > lock owner is still alive or comes back to life, the earlier
> > client's
> >  > > attempt to use the original lock token to update the resource will
> >  > > fail,
> >  > > thus preventing the changes made by the later client from being
> >  > > overwritten.
> >  > >
> >  > > So I object to the text in the current draft, because it
> > encourages
> >  > > clients to do the wrong thing, and encourages servers to support
> >  > > clients
> >  > > doing the wrong thing.
> >  > >
> >  > > Cheers,
> >  > > Geoff
> >  > >
> >  > >
> >  > > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM:
> >  > >
> >  > >  >
> >  > >  > I'm still concerned about a possible inconsistency here.
> >  Sorry if
> >  > > I'm  
> >  > >  > being dense, but I thought that we had a previous consensus (a
> > long
> >  > >  
> >  > >  > time ago) that servers SHOULD provide lock tokens for all
> > locks so
> >  > > that  
> >  > >  > if there were a client bug, a crash, a LOCK reply "lost in the
> >  > > mail",  
> >  > >  > or a need for an owner or administrator to remove somebody
> > else's
> >  > > stale  
> >  > >  > lock.  Some text currently in the draft to that extent:
> >  > >  >
> >  > >  >    "Anyone can
> >  > >  >     find out anyone else's lock token by performing lock
> > discovery."
> >  > >  >
> >  > >  > So given that implies that lock discovery can find out all lock
> >  > > tokens  
> >  > >  > (given permission), and that the lockdiscovery property is
> > returned
> >  > > in  
> >  > >  > the LOCK response body, doesn't that mean that the lock token
> > is  
> >  > >  > returned both in the LOCK response headers (Lock-Token) and
> > body?
> >  > >  >
> >  > >  > Also, we had previously discussed at an interop which is the
> >  > > "right"  
> >  > >  > place to put the lock token and concluded that servers ought
> > to put
> >  > > the  
> >  > >  > token in both places because we found during interoperability
> >  > > testing  
> >  > >  > that we had clients that looked in one place, and other clients
> >  > > that  
> >  > >  > looked in the other, so we might as well continue supporting
> > both.
> >  > >  >
> >  > >  > Lisa
> >  > >  >
> >  > >  > On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote:
> >  > >  >
> >  > >  > >
> >  > >  > > For the record,
> >  > >  > >
> >  > >  > > I don't think that the recent discussion has brought up any
> > new
> >  > > points  
> >  > >  > > that need to be said here, so I'd like to again recommend to
> >  > > close the  
> >  > >  > > issue with the following change (as seen in  
> >  > >  > >
> > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/
> >  > >  > > 0242.html>).
> >  > >  > >
> >  > >  > > Proposed resolution for  
> >  > >  > > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>:
> > [...]
> >  > >  > >
> >  > >  > > NEW:
> >  > >  > >    A lock token is a type of state token, represented as a
> > URI,
> >  > > which
> >  > >  > >    identifies a particular lock.  Each lock has exactly one
> >  > > unique lock
> >  > >  > >    token, which is returned upon a successful LOCK creation
> >  > > operation  
> >  > >  > > in
> >  > >  > >    the "Lock-Token" response header defined in Section 9.6.
> >  > >  > >
> >  > >  > >
> >  > >  > > Best regards, Julian
> >  > >  > >
> >  > >  >
> >  > >  >
 --=_alternative 0058E20C852570BB_=-- From w3c-dist-auth-request@frink.w3.org Wed Nov 16 12:12:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQpm-0006dm-MW for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 12:12:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10589 for ; Wed, 16 Nov 2005 12:12:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcQom-0002vH-OY for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 17:11:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcQoi-0002uT-T2 for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 17:11:28 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcQod-0002l6-EK for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 17:11:28 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CFE6C142275; Wed, 16 Nov 2005 09:11:22 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01237-03; Wed, 16 Nov 2005 09:11:22 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8DB8414226D; Wed, 16 Nov 2005 09:11:15 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-9--764951460 Message-Id: <26184f4d8cb12e826aa55c943ec9616d@osafoundation.org> Cc: " webdav" From: Lisa Dusseault Date: Wed, 16 Nov 2005 09:11:11 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EcQod-0002l6-EK 88cb89893fd7affecf15f9fe17da28e6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/26184f4d8cb12e826aa55c943ec9616d@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10354 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 17:11:32 +0000 --Apple-Mail-9--764951460 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I agree there's a fair argument for allowing servers not to put lock=20 tokens in lockdiscovery all the time. I can clarify the text there=20 because there certainly isn't a consensus to require servers to do=20 that. We could, however, treat the LOCK (create lock) response slightly=20 differently, and require that the body contains the lockdiscovery=20 property *including* the new lock token -- a special case to handle=20 those clients that had problems at Interop tests. Lisa On Nov 16, 2005, at 8:11 AM, Geoffrey M Clemm wrote: > > Some of the reasons why a server does not include the lock-token: > - all locks time-out in a reasonable period of time, and so no=20 > explicit unlock is needed/supported > - only the owner/admin is allowed to do the unlock, so the lock-token=20= > is only exposed to a client that is authenticated as being either the=20= > owner or the admin > > Cheers, > Geoff > > Lisa Dusseault wrote on 11/16/2005 10:41:25=20= > AM: > > > That's fine with me too. =A0So does this mean that lockdiscovery=20 > property > > (if readable) MUST contain all the locks and all their lock tokens?=20= > =A0 > > Does that mean that in reply to a LOCK request which successfully > > creates a new lock, the server MUST include the full lockdiscovery > > property including not just the new lock but also other locks? > > > > Lisa > > > > On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote: > > > > > > > > Sorry, I misread your message. =A0The text that I was objecting = to=20 > was > > > the clauses: > > > > > > > if there were a client bug, a crash, a LOCK reply "lost in the=20= > mail" > > > > > > in: > > > > > > > servers SHOULD provide lock tokens for all locks so > > > =A0> that if there were a client bug, a crash, a LOCK reply "lost=20= > in the > > > =A0> mail", or a need for an owner or administrator to remove=20 > somebody > > > else's > > > =A0> stale lock. > > > > > > but the text you were proposing was just: > > > > > > > =A0"Anyone can > > > =A0> =A0 find out anyone else's lock token by performing lock=20 > discovery." > > > > > > which is fine. =A0I'd prefer making that explicit (e.g. "A lock=20= > token > > > discovered by a client via lock discovery SHOULD NOT be used by=20= > that > > > client for anything other than an UNLOCK request, even if the = user > > > is authenticated as owning that lock"), but I don't insist that=20= > this > > > be added (as long as the converse is not added :-). > > > > > > Cheers, > > > Geoff > > > > > > > > > Lisa Dusseault wrote on 11/15/2005=20 > 10:59:10 > > > PM: > > > > > > =A0> I agree with you, but isn't the client supposed to UNLOCK by=20= > using > > > the > > > =A0> lock token? =A0If so then how does it learn it... ? > > > =A0> > > > =A0> Lisa > > > =A0> > > > =A0> On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote: > > > =A0> > > > =A0> > > > > =A0> > I can only repeat what I posted a few weeks ago ... a = client > > > should > > > =A0> > never steal a lock taken out by an earlier client by=20 > re-using the > > > =A0> > lock token of that earlier client ... it should do so by > > > UNLOCK'ing > > > =A0> > the resource and requesting its own lock. =A0That way if = the > > > original > > > =A0> > lock owner is still alive or comes back to life, the = earlier > > > client's > > > =A0> > attempt to use the original lock token to update the=20 > resource will > > > =A0> > fail, > > > =A0> > thus preventing the changes made by the later client from=20= > being > > > =A0> > overwritten. > > > =A0> > > > > =A0> > So I object to the text in the current draft, because it > > > encourages > > > =A0> > clients to do the wrong thing, and encourages servers to=20= > support > > > =A0> > clients > > > =A0> > doing the wrong thing. > > > =A0> > > > > =A0> > Cheers, > > > =A0> > Geoff > > > =A0> > > > > =A0> > > > > =A0> > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 = PM: > > > =A0> > > > > =A0> > =A0> > > > =A0> > =A0> I'm still concerned about a possible inconsistency = here. > > > =A0Sorry if > > > =A0> > I'm =A0 > > > =A0> > =A0> being dense, but I thought that we had a previous=20 > consensus (a > > > long > > > =A0> > =A0 > > > =A0> > =A0> time ago) that servers SHOULD provide lock tokens for = all > > > locks so > > > =A0> > that =A0 > > > =A0> > =A0> if there were a client bug, a crash, a LOCK reply = "lost=20 > in the > > > =A0> > mail", =A0 > > > =A0> > =A0> or a need for an owner or administrator to remove = somebody > > > else's > > > =A0> > stale =A0 > > > =A0> > =A0> lock. =A0Some text currently in the draft to that = extent: > > > =A0> > =A0> > > > =A0> > =A0> =A0 =A0"Anyone can > > > =A0> > =A0> =A0 =A0 find out anyone else's lock token by = performing lock > > > discovery." > > > =A0> > =A0> > > > =A0> > =A0> So given that implies that lock discovery can find = out=20 > all lock > > > =A0> > tokens =A0 > > > =A0> > =A0> (given permission), and that the lockdiscovery = property is > > > returned > > > =A0> > in =A0 > > > =A0> > =A0> the LOCK response body, doesn't that mean that the = lock=20 > token > > > is =A0 > > > =A0> > =A0> returned both in the LOCK response headers = (Lock-Token)=20 > and > > > body? > > > =A0> > =A0> > > > =A0> > =A0> Also, we had previously discussed at an interop which = is=20 > the > > > =A0> > "right" =A0 > > > =A0> > =A0> place to put the lock token and concluded that = servers=20 > ought > > > to put > > > =A0> > the =A0 > > > =A0> > =A0> token in both places because we found during=20 > interoperability > > > =A0> > testing =A0 > > > =A0> > =A0> that we had clients that looked in one place, and = other=20 > clients > > > =A0> > that =A0 > > > =A0> > =A0> looked in the other, so we might as well continue=20 > supporting > > > both. > > > =A0> > =A0> > > > =A0> > =A0> Lisa > > > =A0> > =A0> > > > =A0> > =A0> On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote: > > > =A0> > =A0> > > > =A0> > =A0> > > > > =A0> > =A0> > For the record, > > > =A0> > =A0> > > > > =A0> > =A0> > I don't think that the recent discussion has = brought up=20 > any > > > new > > > =A0> > points =A0 > > > =A0> > =A0> > that need to be said here, so I'd like to again=20 > recommend to > > > =A0> > close the =A0 > > > =A0> > =A0> > issue with the following change (as seen in =A0 > > > =A0> > =A0> > > > > > > =A0> > =A0> > 0242.html>). > > > =A0> > =A0> > > > > =A0> > =A0> > Proposed resolution for =A0 > > > =A0> > =A0> >=20 > : > > > [...] > > > =A0> > =A0> > > > > =A0> > =A0> > NEW: > > > =A0> > =A0> > =A0 =A0A lock token is a type of state token, = represented=20 > as a > > > URI, > > > =A0> > which > > > =A0> > =A0> > =A0 =A0identifies a particular lock. =A0Each lock = has exactly=20 > one > > > =A0> > unique lock > > > =A0> > =A0> > =A0 =A0token, which is returned upon a successful = LOCK=20 > creation > > > =A0> > operation =A0 > > > =A0> > =A0> > in > > > =A0> > =A0> > =A0 =A0the "Lock-Token" response header defined in = Section=20 > 9.6. > > > =A0> > =A0> > > > > =A0> > =A0> > > > > =A0> > =A0> > Best regards, Julian > > > =A0> > =A0> > > > > =A0> > =A0> > > > =A0> > =A0> --Apple-Mail-9--764951460 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree there's a fair argument for allowing servers not to put lock tokens in lockdiscovery all the time. I can clarify the text there because there certainly isn't a consensus to require servers to do that. We could, however, treat the LOCK (create lock) response slightly differently, and require that the body contains the lockdiscovery property *including* the new lock token -- a special case to handle those clients that had problems at Interop tests. Lisa On Nov 16, 2005, at 8:11 AM, Geoffrey M Clemm wrote: Some of the reasons why a server does not include the lock-token:=20 - all locks time-out in a reasonable period of time, and so no explicit unlock is needed/supported=20 - only the owner/admin is allowed to do the unlock, so the lock-token is only exposed to a client that is authenticated as being either the owner or the admin=20 Cheers,=20 Geoff=20 Lisa Dusseault < wrote on 11/16/2005 10:41:25 AM: > That's fine with me too. =A0So does this mean that lockdiscovery property > (if readable) MUST contain all the locks and all their lock tokens? =A0 > Does that mean that in reply to a LOCK request which successfully > creates a new lock, the server MUST include the full lockdiscovery > property including not just the new lock but also other locks? > > Lisa > > On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote: > > > > > Sorry, I misread your message. =A0The text that I was objecting to was > > the clauses: > > > > > if there were a client bug, a crash, a LOCK reply "lost in the mail" > > > > in: > > > > > servers SHOULD provide lock tokens for all locks so > > =A0> that if there were a client bug, a crash, a LOCK reply "lost in the > > =A0> mail", or a need for an owner or administrator to remove somebody > > else's > > =A0> stale lock. > > > > but the text you were proposing was = just: > > > > > =A0"Anyone can > > =A0> =A0 find out anyone else's lock token by performing lock discovery." > > > > which is fine. =A0I'd prefer making that explicit (e.g. "A lock token > > discovered by a client via lock discovery SHOULD NOT be used by that > > client for anything other than an UNLOCK request, even if the user > > is authenticated as owning that lock"), but I don't insist that this > > be added (as long as the converse is not added :-). > > > > Cheers, > > Geoff > > > > > > Lisa Dusseault < wrote on 11/15/2005 10:59:10 > > PM: > > > > =A0> I agree with you, but isn't the client supposed to UNLOCK by using > > the > > =A0> lock token? =A0If so then how does it learn it... ? > > =A0> > > =A0> Lisa > > =A0> > > =A0> On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm wrote: > > =A0> > > =A0> > > > =A0> > I can only repeat what I posted a few weeks ago ... a client > > should > > =A0> > never steal a lock taken out by an earlier client by re-using the > > =A0> > lock token of that earlier client ... it should do so by > > UNLOCK'ing > > =A0> > the resource and requesting its own lock. =A0That way if the > > original > > =A0> > lock owner is still alive or comes back to life, the earlier > > client's > > =A0> > attempt to use the original lock token to update the resource will > > =A0> > fail, > > =A0> > thus preventing the changes made by the later client from being > > =A0> > overwritten. > > =A0> > > > =A0> > So I object to the text in the current draft, because it > > encourages > > =A0> > clients to do the wrong thing, and encourages servers to support > > =A0> > clients > > =A0> > doing the wrong = thing. > > =A0> > > > =A0> > Cheers, > > =A0> > Geoff > > =A0> > > > =A0> > > > =A0> > w3c-dist-auth-request@w3.org wrote on 11/15/2005 09:13:51 PM: > > =A0> > > > =A0> > =A0> > > =A0> > =A0> I'm still concerned about a possible inconsistency here. > > =A0Sorry if > > =A0> > I'm =A0 > > =A0> > =A0> being dense, but I thought that = we had a previous consensus (a > > long > > =A0> > =A0 > > =A0> > =A0> time ago) that servers SHOULD provide lock tokens for all > > locks so > > =A0> > that =A0 > > =A0> > =A0> if there were a client bug, a crash, a LOCK reply "lost in the > > =A0> > mail", =A0 > > =A0> > =A0> or a need for an owner or administrator to remove somebody > > else's > > =A0> > stale =A0 > > =A0> > =A0> lock. =A0Some text currently in = the draft to that extent: > > =A0> > =A0> > > =A0> > =A0> =A0 =A0"Anyone = can > > =A0> > =A0> =A0 =A0 find out anyone else's = lock token by performing lock > > discovery." > > =A0> > =A0> > > =A0> > =A0> So given that implies that lock discovery can find out all lock > > =A0> > tokens =A0 > > =A0> > =A0> (given permission), and that the lockdiscovery property is > > returned > > =A0> > in =A0 > > =A0> > =A0> the LOCK response body, doesn't that mean that the lock token > > is =A0 > > =A0> > =A0> returned both in the LOCK = response headers (Lock-Token) and > > body? > > =A0> > =A0> > > =A0> > =A0> Also, we had previously discussed at an interop which is the > > =A0> > "right" =A0 > > =A0> > =A0> place to put the lock token and concluded that servers ought > > to put > > =A0> > the =A0 > > =A0> > =A0> token in both places because we found during interoperability > > =A0> > testing =A0 > > =A0> > =A0> that we had clients that looked = in one place, and other clients > > =A0> > that =A0 > > =A0> > =A0> looked in the other, so we might = as well continue supporting > > both. > > =A0> > =A0> > > =A0> > =A0> Lisa > > =A0> > =A0> > > =A0> > =A0> On Nov 6, 2005, at 12:09 PM, = Julian Reschke wrote: > > =A0> > =A0> > > =A0> > =A0> > > > =A0> > =A0> > For the = record, > > =A0> > =A0> > > > =A0> > =A0> > I don't think that the recent discussion has brought up any > > new > > =A0> > points =A0 > > =A0> > =A0> > that need to be said here, so = I'd like to again recommend to > > =A0> > close the =A0 > > =A0> > =A0> > issue with the following change (as seen in =A0 > > =A0> > =A0> > > > = < > > =A0> > =A0> > = 0242.html>). > > =A0> > =A0> > > > =A0> > =A0> > Proposed resolution for = =A0 > > =A0> > =A0> > <: = > > [...] > > =A0> > =A0> > > > =A0> > =A0> > NEW: > > =A0> > =A0> > =A0 =A0A lock token is a type = of state token, represented as a > > URI, > > =A0> > which > > =A0> > =A0> > =A0 =A0identifies a particular = lock. =A0Each lock has exactly one > > =A0> > unique lock > > =A0> > =A0> > =A0 =A0token, which is returned = upon a successful LOCK creation > > =A0> > operation =A0 > > =A0> > =A0> > in > > =A0> > =A0> > =A0 =A0the "Lock-Token" = response header defined in Section 9.6. > > =A0> > =A0> > > > =A0> > =A0> > > > =A0> > =A0> > Best regards, = Julian > > =A0> > =A0> > > > =A0> > =A0> > > =A0> > =A0> = --Apple-Mail-9--764951460-- From w3c-dist-auth-request@frink.w3.org Wed Nov 16 12:18:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQvL-000127-E0 for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 12:18:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11131 for ; Wed, 16 Nov 2005 12:17:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcQug-00063Y-U8 for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 17:17:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcQug-000630-2j for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 17:17:38 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EcQuX-0006Pa-9r for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 17:17:37 +0000 Received: (qmail invoked by alias); 16 Nov 2005 17:17:26 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp026) with SMTP; 16 Nov 2005 18:17:26 +0100 X-Authenticated: #1915285 Message-ID: <437B695F.5050404@gmx.de> Date: Wed, 16 Nov 2005 18:16:15 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <26184f4d8cb12e826aa55c943ec9616d@osafoundation.org> In-Reply-To: <26184f4d8cb12e826aa55c943ec9616d@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcQuX-0006Pa-9r 67d0c8fef86a3e956baa307f3f323524 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437B695F.5050404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10355 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 17:17:38 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I agree there's a fair argument for allowing servers not to put lock > tokens in lockdiscovery all the time. I can clarify the text there > because there certainly isn't a consensus to require servers to do that. > > We could, however, treat the LOCK (create lock) response slightly > differently, and require that the body contains the lockdiscovery > property *including* the new lock token -- a special case to handle > those clients that had problems at Interop tests. This does not make any sense. Sorry. It's the "Lock-Token" response header that *always* contains the result. Why do you insist on changing the spec so that there's a second mechanism? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 12:24:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcR1k-0004Ap-8T for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 12:24:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11504 for ; Wed, 16 Nov 2005 12:24:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcR10-00071A-M7 for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 17:24:10 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcR0z-00070X-MK for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 17:24:10 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcR0q-000875-IR for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 17:24:08 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1C6E8142275; Wed, 16 Nov 2005 09:23:58 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22542-06; Wed, 16 Nov 2005 09:23:57 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0002214226D; Wed, 16 Nov 2005 09:23:56 -0800 (PST) In-Reply-To: <437B695F.5050404@gmx.de> References: <26184f4d8cb12e826aa55c943ec9616d@osafoundation.org> <437B695F.5050404@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <86e9592f155eafa24db8a8931c19cad5@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , webdav From: Lisa Dusseault Date: Wed, 16 Nov 2005 09:23:50 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcR0q-000875-IR d2b81bb0bc5011ad8135838822648c97 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/86e9592f155eafa24db8a8931c19cad5@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10356 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 17:24:10 +0000 Content-Transfer-Encoding: 7bit On Nov 16, 2005, at 9:16 AM, Julian Reschke wrote: > > Lisa Dusseault wrote: >> I agree there's a fair argument for allowing servers not to put lock >> tokens in lockdiscovery all the time. I can clarify the text there >> because there certainly isn't a consensus to require servers to do >> that. >> We could, however, treat the LOCK (create lock) response slightly >> differently, and require that the body contains the lockdiscovery >> property *including* the new lock token -- a special case to handle >> those clients that had problems at Interop tests. > > This does not make any sense. Sorry. > > It's the "Lock-Token" response header that *always* contains the > result. Why do you insist on changing the spec so that there's a > second mechanism? > Because that was the rough consensus at the Interop that year, amongst the people there, and I don't want to overthrow that too lightly. As soon as Cullen declares that there's a consensus for a single mechanism, I'll edit the spec according to the consensus. Lisa From w3c-dist-auth-request@frink.w3.org Wed Nov 16 12:29:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcR5n-0006AJ-BD for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 12:29:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11714 for ; Wed, 16 Nov 2005 12:28:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcR5B-0007kT-Lw for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 17:28:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcR59-0007jt-G8 for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 17:28:27 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EcR57-0005zl-Ez for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 17:28:27 +0000 Received: (qmail invoked by alias); 16 Nov 2005 17:28:22 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 16 Nov 2005 18:28:22 +0100 X-Authenticated: #1915285 Message-ID: <437B6BED.4000602@gmx.de> Date: Wed, 16 Nov 2005 18:27:09 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <26184f4d8cb12e826aa55c943ec9616d@osafoundation.org> <437B695F.5050404@gmx.de> <86e9592f155eafa24db8a8931c19cad5@osafoundation.org> In-Reply-To: <86e9592f155eafa24db8a8931c19cad5@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EcR57-0005zl-Ez 6d7ea3dd8d025cc1d5bfb90f541820d1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437B6BED.4000602@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10357 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 17:28:29 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > On Nov 16, 2005, at 9:16 AM, Julian Reschke wrote: > >> >> Lisa Dusseault wrote: >>> I agree there's a fair argument for allowing servers not to put lock >>> tokens in lockdiscovery all the time. I can clarify the text there >>> because there certainly isn't a consensus to require servers to do that. >>> We could, however, treat the LOCK (create lock) response slightly >>> differently, and require that the body contains the lockdiscovery >>> property *including* the new lock token -- a special case to handle >>> those clients that had problems at Interop tests. >> >> This does not make any sense. Sorry. >> >> It's the "Lock-Token" response header that *always* contains the >> result. Why do you insist on changing the spec so that there's a >> second mechanism? >> > Because that was the rough consensus at the Interop that year, amongst > the people there, and I don't want to overthrow that too lightly. As > soon as Cullen declares that there's a consensus for a single mechanism, > I'll edit the spec according to the consensus. Ultimately, consensus needs to be found in the WG (== the mailing list), not at a meeting. I don't recall any discussion over here about requiring the response body. Did I miss something? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 12:34:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRBA-0007Zo-7R for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 12:34:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12020 for ; Wed, 16 Nov 2005 12:34:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcRAV-0001ZT-GD for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 17:33:59 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcRAU-0001Ym-MD for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 17:33:59 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcRAG-0001sv-SJ for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 17:33:57 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jAGHXgmr029490 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 16 Nov 2005 09:33:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) To: webdav WG Message-Id: <9BF05E70-E1D1-475B-AF28-015F319481C3@cs.ucsc.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-1--763602818 References: <60897A0F7690ED43A1E0995D0534F8FB03FE29@daddy.numcom.local> From: Jim Whitehead Date: Wed, 16 Nov 2005 09:33:39 -0800 X-Mailer: Apple Mail (2.746.2) Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcRAG-0001sv-SJ 1de36679d8b53ce9429cc563daa56d83 X-Original-To: w3c-dist-auth@w3.org Subject: Fwd: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/9BF05E70-E1D1-475B-AF28-015F319481C3@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10358 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 17:33:59 +0000 --Apple-Mail-1--763602818 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Begin forwarded message: > From: "Lukas Mathis" > Date: November 15, 2005 11:53:39 PM PST > To: > Subject: RE: XML InfoSet and property value preservation > >> Extreme option: All InfoSet items MUST be preserved. [This clearly >> has the disadvantage of making existing implementations change their >> code to comply, but has the advantage of simplicity and enforcing the >> greatest consistency between servers.] > > Maybe I'm missing something, so I hope somebody can explain this to > me: > Are you arguing about whether a server should preserve data which > has no > specific semantic meaning (comments) or which could be changed to a > semantic equivalent in XML (namespace prefixes)? > > Maybe I don't understand the issue well enough to comment on it, > but I'd > tend to go with the last option - only require servers to preserve > that > which is really needed by clients. > > Lukas > > --Apple-Mail-1--763602818 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = "Lukas Mathis" <lukas.mathis@numcom.com>
Date: November 15, 2005 11:53:39 PM = PST

Extreme = option:=A0 All InfoSet = items MUST be preserved.=A0 = [This clearly=A0
has the = disadvantage of making existing implementations change their=A0
code to = comply, but has the advantage of simplicity and enforcing the=A0
greatest = consistency between servers.] =A0

Maybe = I'm missing something, so I hope somebody can explain this to = me:
Are you arguing about whether a = server should preserve data which has no
specific = semantic meaning (comments) or which could be changed to a
semantic equivalent in XML (namespace = prefixes)?

Maybe I don't understand the issue well enough to = comment on it, but I'd
tend to go with the last = option - only require servers to preserve that
which is really needed by clients.



=

= --Apple-Mail-1--763602818-- From w3c-dist-auth-request@frink.w3.org Wed Nov 16 13:45:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSHY-0003Fy-Kf for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 13:45:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16598 for ; Wed, 16 Nov 2005 13:44:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcSGJ-0005I1-OV for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 18:44:03 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcSGF-0005HT-O3 for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 18:43:59 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EcSG1-0007sI-C5 for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 18:43:58 +0000 Received: (qmail invoked by alias); 16 Nov 2005 18:43:42 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp003) with SMTP; 16 Nov 2005 19:43:42 +0100 X-Authenticated: #1915285 Message-ID: <437B7D8F.1040709@gmx.de> Date: Wed, 16 Nov 2005 19:42:23 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: webdav WG References: <60897A0F7690ED43A1E0995D0534F8FB03FE29@daddy.numcom.local> <9BF05E70-E1D1-475B-AF28-015F319481C3@cs.ucsc.edu> In-Reply-To: <9BF05E70-E1D1-475B-AF28-015F319481C3@cs.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcSG1-0007sI-C5 51a2ac840f8be2c66649562d7a430bbd X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fwd: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437B7D8F.1040709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10359 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 18:44:03 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > > > Begin forwarded message: > >> *From: *"Lukas Mathis" > > >> *Date: *November 15, 2005 11:53:39 PM PST >> *To: *> >> *Subject: **RE: XML InfoSet and property value preservation* >> >>> Extreme option: All InfoSet items MUST be preserved. [This clearly >>> has the disadvantage of making existing implementations change their >>> code to comply, but has the advantage of simplicity and enforcing the >>> greatest consistency between servers.] >> >> Maybe I'm missing something, so I hope somebody can explain this to me: >> Are you arguing about whether a server should preserve data which has no >> specific semantic meaning (comments) or which could be changed to a >> semantic equivalent in XML (namespace prefixes)? >> >> Maybe I don't understand the issue well enough to comment on it, but I'd >> tend to go with the last option - only require servers to preserve that >> which is really needed by clients. Yes, sure. The trouble actually is to figure out what this is. For instance, I do agree with you that comments do not need to be preserved, but I don't agree that namespace prefixes are irrelevant. And of course there's the separate issue that we can't simply invent new requirements without also thinking about how to get servers to quickly support these.... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 14:59:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTRS-0007SK-Dl for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 14:59:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20479 for ; Wed, 16 Nov 2005 14:59:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcTQ8-0005t4-Vq for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 19:58:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcTQ4-0005sW-W2 for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 19:58:13 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcTQ0-0008OJ-LU for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 19:58:12 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F17BD142281; Wed, 16 Nov 2005 11:58:06 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10426-07; Wed, 16 Nov 2005 11:58:06 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 11BDB142279; Wed, 16 Nov 2005 11:58:06 -0800 (PST) In-Reply-To: <437B6BED.4000602@gmx.de> References: <26184f4d8cb12e826aa55c943ec9616d@osafoundation.org> <437B695F.5050404@gmx.de> <86e9592f155eafa24db8a8931c19cad5@osafoundation.org> <437B6BED.4000602@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0739300795ac5aaa1e7505bfec83d215@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , webdav From: Lisa Dusseault Date: Wed, 16 Nov 2005 11:58:01 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EcTQ0-0008OJ-LU f43d2d643d1db2590b6e6a314e6e4d5d X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/0739300795ac5aaa1e7505bfec83d215@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10360 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 19:58:16 +0000 Content-Transfer-Encoding: 7bit On Nov 16, 2005, at 9:27 AM, Julian Reschke wrote: > > Lisa Dusseault wrote: >> On Nov 16, 2005, at 9:16 AM, Julian Reschke wrote: >>> >>> Lisa Dusseault wrote: >>>> I agree there's a fair argument for allowing servers not to put >>>> lock tokens in lockdiscovery all the time. I can clarify the text >>>> there because there certainly isn't a consensus to require servers >>>> to do that. >>>> We could, however, treat the LOCK (create lock) response slightly >>>> differently, and require that the body contains the lockdiscovery >>>> property *including* the new lock token -- a special case to handle >>>> those clients that had problems at Interop tests. >>> >>> This does not make any sense. Sorry. >>> >>> It's the "Lock-Token" response header that *always* contains the >>> result. Why do you insist on changing the spec so that there's a >>> second mechanism? >>> >> Because that was the rough consensus at the Interop that year, >> amongst the people there, and I don't want to overthrow that too >> lightly. As soon as Cullen declares that there's a consensus for a >> single mechanism, I'll edit the spec according to the consensus. > > Ultimately, consensus needs to be found in the WG (== the mailing > list), not at a meeting. I don't recall any discussion over here about > requiring the response body. Did I miss something? > I checked back in the email archives, and it looks like there was a very closely related discussion which I thought covered it but it didn't get into this specific issue. Naturally consensus needs to be found in the WG and I'm sure we can accomplish this. So are there any other opinions on whether the server MUST return the lock token in the body as well as the header of a response when a new lock is created -- even though we all agree the server doesn't need to normally put that info in the lockdiscovery property? Lisa From w3c-dist-auth-request@frink.w3.org Wed Nov 16 15:00:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTRo-0007V9-5P for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 15:00:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20490 for ; Wed, 16 Nov 2005 14:59:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcTRF-00060K-3t for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 19:59:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcTRE-0005zl-Km for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 19:59:24 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcTR5-00006g-M1 for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 19:59:24 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CE05D142281; Wed, 16 Nov 2005 11:59:14 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23453-01; Wed, 16 Nov 2005 11:59:14 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 31C7B142279; Wed, 16 Nov 2005 11:59:14 -0800 (PST) In-Reply-To: <437AF090.3090802@gmx.de> References: <200510181823.j9IINZCw029195@ietf.cse.ucsc.edu> <4355456A.6000307@gmx.de> <437AF090.3090802@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74189e75b094a98b2ccb1bde8e203efa@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Wed, 16 Nov 2005 11:59:08 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EcTR5-00006g-M1 35090278575ba4ee19f4e81616e81c39 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/74189e75b094a98b2ccb1bde8e203efa@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10361 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 19:59:25 +0000 Content-Transfer-Encoding: 7bit Ok; since a lot of this text has now moved to section 12 anyway in draft -08, please let me know if you think there are good spots for additional references. Thanks, Lisa On Nov 16, 2005, at 12:40 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> I agree some of the text on PROPFIND can be moved to the section on >> Multi-Status. I had been cleaning that up and clearly hadn't >> finished. I'll take this opportunity to clean both sections up. I >> think the section on general Multi-Status usage is now big enough to >> warrant a few sub-sections which you'll see shortly. It's probably >> not done yet, of course. >> One point of confusion, you lost me on the reference to section >> 13.15. How does that discuss what's allowable in ? > > That was a mistake, the forward reference probably should go either to > section 12 (multistatus response body) or section 13.7 (href element). > > Best regards, Julian > > From w3c-dist-auth-request@frink.w3.org Wed Nov 16 15:24:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTpf-0005Hp-8V for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 15:24:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21839 for ; Wed, 16 Nov 2005 15:24:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcToy-0003SZ-8v for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 20:23:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcTov-0003Rw-VR for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 20:23:53 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EcTot-0001UY-TW for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 20:23:53 +0000 Received: (qmail invoked by alias); 16 Nov 2005 20:23:49 -0000 Received: from p508FA3F5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.245] by mail.gmx.net (mp002) with SMTP; 16 Nov 2005 21:23:49 +0100 X-Authenticated: #1915285 Message-ID: <437B952A.5010300@gmx.de> Date: Wed, 16 Nov 2005 21:23:06 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <26184f4d8cb12e826aa55c943ec9616d@osafoundation.org> <437B695F.5050404@gmx.de> <86e9592f155eafa24db8a8931c19cad5@osafoundation.org> <437B6BED.4000602@gmx.de> <0739300795ac5aaa1e7505bfec83d215@osafoundation.org> In-Reply-To: <0739300795ac5aaa1e7505bfec83d215@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EcTot-0001UY-TW 9eff30aa113e7ad58bf83b90cdba9c76 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437B952A.5010300@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10362 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 20:23:56 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I checked back in the email archives, and it looks like there was a very > closely related discussion which I thought covered it but it didn't get > into this specific issue. Naturally consensus needs to be found in the > WG and I'm sure we can accomplish this. So are there any other opinions (nod) > on whether the server MUST return the lock token in the body as well as > the header of a response when a new lock is created -- even though we > all agree the server doesn't need to normally put that info in the > lockdiscovery property? Making a normative change to the spec because of specific broken clients IMHO is as bad as the other way round. Just because we say so will not resolve the interop issue, if it still exists. Does anybody know whether this is still the case? To me, this seems to a a perfect example, for an interop guide, not a change to the spec. Such as: 1) What to do if the LOCK request suceeds, but no Lock-Token respnse header is there (answer: complain to the server vendor, and then in the worst case check the response body). 2) What to do if a PROPFIND response contains *multipple* properties? (answer: complain to the server vendor, and/or assume that this is this server's idea how to return info about shared locks). We've talked about a document like that several times. Should I start one? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 15:39:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcU3z-0000iE-Um for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 15:39:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22792 for ; Wed, 16 Nov 2005 15:38:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcU2L-0006UY-8s for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 20:37:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcU2K-0006Tz-Id for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 20:37:44 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcU2D-0003ln-Dd for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 20:37:44 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2005 12:37:34 -0800 X-IronPort-AV: i="3.97,338,1125903600"; d="scan'208"; a="231329946:sNHT1991598674" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAGKbW6a002385; Wed, 16 Nov 2005 12:37:32 -0800 (PST) Received: from 128.107.139.141 ([128.107.139.141]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2005 20:38:09 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 16 Nov 2005 12:37:34 -0800 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: Geoffrey M Clemm , WebDav Message-ID: Thread-Topic: [Bug 23] lock discovery vs shared locks Thread-Index: AcXq7ZK90ShPRlbgEdqOkQARJEEJ/A== In-Reply-To: <437B952A.5010300@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1EcU2D-0003ln-Dd ed07ecb57a8d0e57de8e30b32be88746 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/BFA0D88E.60CF0%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10363 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 20:37:45 +0000 Content-Transfer-Encoding: 7bit On the call this morning, I thought that Geoff outlined 3 proposals 1) change nothing (assuming says MUST put in header) 2) don't change how anything works today but add the clarifying statement that servers MAY NOT put it in a body 3) change to say that servers MUST put in both body and header Now I might have the descriptions of these three all wrong but I am pretty sure that I heard that 1 or 2 worked for someone and 2 or 3 worked for someone else and that 2 worked for everyone. I thought we decided to put 2 in the next rev of the *draft* and then ask the WG (folks on the list including people on this thread) had a problem with that draft. What part of this did I not get? What are we still discussing? On 11/16/05 12:23 PM, "Julian Reschke" wrote: > > Lisa Dusseault wrote: >> I checked back in the email archives, and it looks like there was a very >> closely related discussion which I thought covered it but it didn't get >> into this specific issue. Naturally consensus needs to be found in the >> WG and I'm sure we can accomplish this. So are there any other opinions > > (nod) > >> on whether the server MUST return the lock token in the body as well as >> the header of a response when a new lock is created -- even though we >> all agree the server doesn't need to normally put that info in the >> lockdiscovery property? > > Making a normative change to the spec because of specific broken clients > IMHO is as bad as the other way round. Just because we say so will not > resolve the interop issue, if it still exists. Does anybody know whether > this is still the case? > > To me, this seems to a a perfect example, for an interop guide, not a > change to the spec. > > Such as: > > 1) What to do if the LOCK request suceeds, but no Lock-Token respnse > header is there (answer: complain to the server vendor, and then in the > worst case check the response body). > > 2) What to do if a PROPFIND response contains *multipple* > properties? (answer: complain to the server vendor, > and/or assume that this is this server's idea how to return info about > shared locks). > > We've talked about a document like that several times. Should I start one? > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 15:40:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcU51-0001Iw-Mi for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 15:40:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22878 for ; Wed, 16 Nov 2005 15:39:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcU3y-0006lG-OH for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 20:39:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcU3y-0006kd-By for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 20:39:26 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcU3w-00048K-AG for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 20:39:26 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2005 12:39:23 -0800 X-IronPort-AV: i="3.97,338,1125903600"; d="scan'208"; a="231330375:sNHT25470000" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAGKdLOp007557; Wed, 16 Nov 2005 12:39:21 -0800 (PST) Received: from 128.107.139.141 ([128.107.139.141]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2005 20:39:59 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 16 Nov 2005 12:39:25 -0800 From: Cullen Jennings To: Julian Reschke CC: WebDav Message-ID: Thread-Topic: XML InfoSet and property value preservation Thread-Index: AcXq7dTnEzyqw1bhEdqOkQARJEEJ/A== In-Reply-To: <437B7D8F.1040709@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1EcU3w-00048K-AG ba7c2e0d32138a5bac26e429321aa9f2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/BFA0D8FD.60CF5%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10364 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 20:39:26 +0000 Content-Transfer-Encoding: 7bit Can you put out a proposal of which of the items you think clients should be able to depend on the clients preserving? On 11/16/05 10:42 AM, "Julian Reschke" wrote: > > Jim Whitehead wrote: >> >> >> Begin forwarded message: >> >>> *From: *"Lukas Mathis" >> > >>> *Date: *November 15, 2005 11:53:39 PM PST >>> *To: *> >>> *Subject: **RE: XML InfoSet and property value preservation* >>> >>>> Extreme option: All InfoSet items MUST be preserved. [This clearly >>>> has the disadvantage of making existing implementations change their >>>> code to comply, but has the advantage of simplicity and enforcing the >>>> greatest consistency between servers.] >>> >>> Maybe I'm missing something, so I hope somebody can explain this to me: >>> Are you arguing about whether a server should preserve data which has no >>> specific semantic meaning (comments) or which could be changed to a >>> semantic equivalent in XML (namespace prefixes)? >>> >>> Maybe I don't understand the issue well enough to comment on it, but I'd >>> tend to go with the last option - only require servers to preserve that >>> which is really needed by clients. > > Yes, sure. The trouble actually is to figure out what this is. > > For instance, I do agree with you that comments do not need to be > preserved, but I don't agree that namespace prefixes are irrelevant. > > And of course there's the separate issue that we can't simply invent new > requirements without also thinking about how to get servers to quickly > support these.... > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 15:51:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUFb-0004Q9-Bq for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 15:51:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23626 for ; Wed, 16 Nov 2005 15:50:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcUEO-0001pw-LB for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 20:50:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcUEM-0001pB-Dg for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 20:50:10 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by maggie.w3.org with esmtp (Exim 4.50) id 1EcUEE-0000rv-H5 for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 20:50:09 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EcUED-0008T0-BR; Wed, 16 Nov 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 Nov 2005 15:50:01 -0500 Received-SPF: none (maggie.w3.org: domain of mlee@newodin.ietf.org does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EcUEE-0000rv-H5 7e07665d33a7ec338f1f123c3ff0368b X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-08.txt X-Archived-At: http://www.w3.org/mid/E1EcUED-0008T0-BR@newodin.ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10365 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 20:50:12 +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 : HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis Author(s) : L. Dusseault Filename : draft-ietf-webdav-rfc2518bis-08.txt Pages : 123 Date : 2005-11-16 WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes minor revisions mostly due to interoperability experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-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-rfc2518bis-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-rfc2518bis-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: <2005-11-16145046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-rfc2518bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-16145046.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@frink.w3.org Wed Nov 16 17:00:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVKp-00089o-Lr for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 17:00:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02616 for ; Wed, 16 Nov 2005 17:00:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcVJc-0003Eo-CT for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 21:59:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcVFY-0002G2-Ih for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 21:55:28 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EcV2h-0006yA-Hq for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 21:42:13 +0000 Received: (qmail invoked by alias); 16 Nov 2005 21:42:10 -0000 Received: from p508FA3F5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.245] by mail.gmx.net (mp023) with SMTP; 16 Nov 2005 22:42:10 +0100 X-Authenticated: #1915285 Message-ID: <437BA781.2090009@gmx.de> Date: Wed, 16 Nov 2005 22:41:21 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , Geoffrey M Clemm , WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EcV2h-0006yA-Hq fe9f46732085c03a456238116b4b5de4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437BA781.2090009@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10366 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 21:59:40 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > On the call this morning, I thought that Geoff outlined 3 proposals > > 1) change nothing (assuming says MUST put in header) > 2) don't change how anything works today but add the clarifying statement > that servers MAY NOT put it in a body > 3) change to say that servers MUST put in both body and header Right. > Now I might have the descriptions of these three all wrong but I am pretty > sure that I heard that 1 or 2 worked for someone and 2 or 3 worked for > someone else and that 2 worked for everyone. I thought we decided to put 2 > in the next rev of the *draft* and then ask the WG (folks on the list > including people on this thread) had a problem with that draft. > > What part of this did I not get? What are we still discussing? No, you are right. These options were discussed, and 2) was something everybody seemed to be able to agree upon. Sorry if I added to the confusion. So I'll rephrase that: when in the future we come across things that could *also* go into an implementation guide instead of the spec, we may want to actually consider to start a document like that; and I'm volunteering to work on that. That would be separate from RFC2518bis, and potentially not even an IETF document (unless the WG would want it to be that way). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 17:06:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVQE-0000th-3U for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 17:06:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02889 for ; Wed, 16 Nov 2005 17:05:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcVPa-00076d-3J for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 22:05:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcVPV-00075t-00 for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 22:05:45 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcVPQ-0001x0-Hp for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 22:05:44 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAGM5dfH003042 for ; Wed, 16 Nov 2005 14:05:39 -0800 (PST) Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay5.apple.com (Apple SCV relay) with ESMTP id 5D04F324017 for ; Wed, 16 Nov 2005 14:05:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <437AED9D.9070908@gmx.de> References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> <8eaf9241d62055518696cf3f434114e1@osafoundation.org> <43639C2E.3040109@gmx.de> <43639F63.4090000@gmx.de> <436E6317.1000101@gmx.de> <437AED9D.9070908@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <361994E2-4C4B-494B-AC8E-225D81C29ABC@apple.com> Content-Transfer-Encoding: 7bit From: Jim Luther Date: Wed, 16 Nov 2005 14:05:42 -0800 To: webdav X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: pass (lisa.w3.org: domain of luther.j@apple.com designates 17.254.13.23 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EcVPQ-0001x0-Hp 10e13df1d3d6ac7ce27cdb1f11a56240 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/361994E2-4C4B-494B-AC8E-225D81C29ABC@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10367 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 22:05:50 +0000 Content-Transfer-Encoding: 7bit On Nov 16, 2005, at 12:28 AM, Julian Reschke wrote: >> the LOCK response body, doesn't that mean that the lock token is >> returned both in the LOCK response headers (Lock-Token) and body? > > It may, but clients can not rely on it. The Mac OS X WebDAV file system client gets the locktoken out of the response body when it creates a new lock. My guess (since this code was written before I started working on anything WebDAV related) is that it was done because: * rcf2518 section 8.10.1 says, "The response MUST contain the value of the lockdiscovery property in a prop XML element." * the example given in rcf2518 section 8.10.8 does not show a Lock- Token response header in the response. Of course, the Mac OS X WebDAV file system client can be changed in some future release to use the Lock-Token response header (and I just wrote up a bug report to make sure that happens). However, if a server wants to interoperate with existing versions of the Mac OS X WebDAV file system client, they'll need to return the the locktoken in the body. - Jim From w3c-dist-auth-request@frink.w3.org Wed Nov 16 17:57:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcWDB-0007KM-EK for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 17:57:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05512 for ; Wed, 16 Nov 2005 17:56:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcWCR-00036c-FT for w3c-dist-auth-dist@listhub.w3.org; Wed, 16 Nov 2005 22:56:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcWCN-00035L-5r for w3c-dist-auth@listhub.w3.org; Wed, 16 Nov 2005 22:56:15 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcWCK-00014E-TD for w3c-dist-auth@w3.org; Wed, 16 Nov 2005 22:56:14 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAGMtubD009779; Wed, 16 Nov 2005 14:55:56 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 98914324017; Wed, 16 Nov 2005 14:55:56 -0800 (PST) In-Reply-To: <437B7D8F.1040709@gmx.de> References: <60897A0F7690ED43A1E0995D0534F8FB03FE29@daddy.numcom.local> <9BF05E70-E1D1-475B-AF28-015F319481C3@cs.ucsc.edu> <437B7D8F.1040709@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: webdav WG Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Wed, 16 Nov 2005 14:55:54 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EcWCK-00014E-TD f63c212a03026a8578eb5114d78c2b57 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/EA8F11A3-7583-44B1-8DEC-6BEE90F56B7F@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10368 X-Loop: w3c-dist-auth@w3.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, 16 Nov 2005 22:56:19 +0000 Content-Transfer-Encoding: 7bit Hate to sound ignorant again, but, well I guess I don't hate it that much... Recognizing that we can't say that XML sub-elements aren't allowed in property elements because of history, the spec should encourage clients that want to know that their data will be preserved exactly as-is (comments and all) SHOULD encode their content, and perhaps the spec should recommend an encoding (eg. escaped XML/CDATA) for property contents. This has the advantage of working reliably on 100% of existing servers, regardless of how they expand namespaces, ignore comments (or not), use CDATA or escaped XML, etc. Clients putting sub-elements into properties should accept that the server will likely parse those elements, potentially storing that into some normative form, then re-render that into XML when asked for it later, and that semantically equivalent but byte-for-byte different data may come back. I think forcing a server author to care about preserving the original XML rendering at all is a bad idea. WebDAV is already pretty complicated. XML with namespaces is no small part of that complexity. Why make it harder when an easy solution is already available in current implementations? -wsv On Nov 16, 2005, at 10:42 AM, Julian Reschke wrote: > Yes, sure. The trouble actually is to figure out what this is. > > For instance, I do agree with you that comments do not need to be > preserved, but I don't agree that namespace prefixes are irrelevant. > > And of course there's the separate issue that we can't simply > invent new requirements without also thinking about how to get > servers to quickly support these.... > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 16 19:45:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcXtn-0005SN-Cf for webdav-archive@megatron.ietf.org; Wed, 16 Nov 2005 19:45:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11362 for ; Wed, 16 Nov 2005 19:44:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcXsc-0000WW-1d for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 00:43:58 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcXsF-0000VA-7H for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 00:43:35 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EcXs0-0001R6-Ca for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 00:43:26 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C89E8142289; Wed, 16 Nov 2005 16:43:16 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30581-03; Wed, 16 Nov 2005 16:43:16 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1C000142279; Wed, 16 Nov 2005 16:43:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <361994E2-4C4B-494B-AC8E-225D81C29ABC@apple.com> References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> <8eaf9241d62055518696cf3f434114e1@osafoundation.org> <43639C2E.3040109@gmx.de> <43639F63.4090000@gmx.de> <436E6317.1000101@gmx.de> <437AED9D.9070908@gmx.de> <361994E2-4C4B-494B-AC8E-225D81C29ABC@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9f42511bad90545e98a9d4963fb1a342@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Wed, 16 Nov 2005 16:43:12 -0800 To: Julian Reschke , webdav WG X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcXs0-0001R6-Ca 72b81187e72ddec30626fdb249baa3aa X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/9f42511bad90545e98a9d4963fb1a342@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10369 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 00:43:58 +0000 Content-Transfer-Encoding: 7bit Julian, do these data points affect your conclusion? thanks, Lisa On Nov 16, 2005, at 2:05 PM, Jim Luther wrote: > > On Nov 16, 2005, at 12:28 AM, Julian Reschke wrote: > >>> the LOCK response body, doesn't that mean that the lock token is >>> returned both in the LOCK response headers (Lock-Token) and body? >> >> It may, but clients can not rely on it. > > The Mac OS X WebDAV file system client gets the locktoken out of the > response body when it creates a new lock. My guess (since this code > was written before I started working on anything WebDAV related) is > that it was done because: > > * rcf2518 section 8.10.1 > > says, "The response MUST contain the value of the lockdiscovery > property in a prop XML element." > > * the example given in rcf2518 section 8.10.8 > > does not show a Lock-Token response header in the response. > > Of course, the Mac OS X WebDAV file system client can be changed in > some future release to use the Lock-Token response header (and I just > wrote up a bug report to make sure that happens). However, if a server > wants to interoperate with existing versions of the Mac OS X WebDAV > file system client, they'll need to return the the locktoken in the > body. > > - Jim > From w3c-dist-auth-request@frink.w3.org Thu Nov 17 02:49:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EceWq-000163-MJ for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 02:49:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05086 for ; Thu, 17 Nov 2005 02:49:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EceVS-0000er-NL for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 07:48:30 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EceVN-0000dJ-Sf for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 07:48:26 +0000 Received: from mx1.init7.net ([213.144.129.5] helo=taguan.init7.net) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EceVH-0003yE-Qw for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 07:48:24 +0000 Received: from daddy.numcom.local ([213.144.131.169]) by taguan.init7.net (8.13.4/8.13.4/Debian-3) with ESMTP id jAH7mBTJ029425 for ; Thu, 17 Nov 2005 08:48:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2005 08:48:04 +0100 Message-ID: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> Thread-Topic: XML InfoSet and property value preservation Thread-Index: AcXrARrk01lxrbo/SVSE0dH7QS9f2wASajhg From: "Lukas Mathis" To: "WebDav" Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of lukas.mathis@numcom.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EceVH-0003yE-Qw bdf66458b1ad3061791b5a56247c1979 X-Original-To: w3c-dist-auth@w3.org Subject: RE: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10370 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 07:48:30 +0000 Content-Transfer-Encoding: quoted-printable > Clients putting sub-elements into properties should=20 > accept that the server will likely parse those elements,=20 > potentially storing that into some normative form, then=20 > re-render that into XML when asked for it later, and that=20 > semantically equivalent but byte-for-byte different data may=20 > come back. I think forcing a server author to care about=20 > preserving the original XML rendering at all is a bad idea. I agree with that. It's XML, and it should be treated as such. If the = client wants it be treated as text, it must but it in a CDATA section. lucas --=20 Lukas Mathis, Numcom Software AG Hardturmstrasse 66, CH-8005 Z=FCrich Direct +41(0)43-204 06 08 mailto:lukas.mathis@numcom.com, http://www.numcom.com/ From w3c-dist-auth-request@frink.w3.org Thu Nov 17 05:13:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcglO-00005u-Mf for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 05:13:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11327 for ; Thu, 17 Nov 2005 05:12:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ecgjb-0005xp-M2 for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 10:11:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcgjX-0005x9-Ht for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 10:11:11 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EcgjT-0000Db-Un for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 10:11:11 +0000 Received: (qmail invoked by alias); 17 Nov 2005 10:11:06 -0000 Received: from p508FAF12.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.175.18] by mail.gmx.net (mp010) with SMTP; 17 Nov 2005 11:11:06 +0100 X-Authenticated: #1915285 Message-ID: <437C570B.6020806@gmx.de> Date: Thu, 17 Nov 2005 11:10:19 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lukas Mathis CC: WebDav References: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> In-Reply-To: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EcgjT-0000Db-Un baee126d3519f4fdd3d8988c9167e2e5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437C570B.6020806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10371 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 10:11:15 +0000 Content-Transfer-Encoding: 7bit Lukas Mathis wrote: >> Clients putting sub-elements into properties should >> accept that the server will likely parse those elements, >> potentially storing that into some normative form, then >> re-render that into XML when asked for it later, and that >> semantically equivalent but byte-for-byte different data may >> come back. I think forcing a server author to care about >> preserving the original XML rendering at all is a bad idea. > > I agree with that. It's XML, and it should be treated as such. If the client wants it be treated as text, it must but it in a CDATA section. I agree with that too. As a matter of fact, I don't think anybody disagrees here. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 17 05:24:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecgwa-0005hA-Hi for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 05:24:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11957 for ; Thu, 17 Nov 2005 05:24:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ecgvu-0000dE-6u for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 10:23:58 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ecgvt-0000cb-DI for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 10:23:57 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Ecgvk-0002K5-OM for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 10:23:56 +0000 Received: (qmail invoked by alias); 17 Nov 2005 10:23:44 -0000 Received: from p508FAF12.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.175.18] by mail.gmx.net (mp038) with SMTP; 17 Nov 2005 11:23:44 +0100 X-Authenticated: #1915285 Message-ID: <437C59FD.9000300@gmx.de> Date: Thu, 17 Nov 2005 11:22:53 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: webdav WG References: <60897A0F7690ED43A1E0995D0534F8FB03FE29@daddy.numcom.local> <9BF05E70-E1D1-475B-AF28-015F319481C3@cs.ucsc.edu> <437B7D8F.1040709@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ecgvk-0002K5-OM 66dcd63ff951009dd92acfc6ece8c2ef X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437C59FD.9000300@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10372 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 10:23:58 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA11957 Wilfredo S=E1nchez Vega wrote: >=20 > Hate to sound ignorant again, but, well I guess I don't hate it > that much... >=20 > Recognizing that we can't say that XML sub-elements aren't allowed > in property elements because of history, the spec should encourage XML sub-elements *are* allowed in property values. RFC2518 says this,=20 and many servers get this right. > clients that want to know that their data will be preserved exactly > as-is (comments and all) SHOULD encode their content, and perhaps the > spec should recommend an encoding (eg. escaped XML/CDATA) for > property contents. This has the advantage of working reliably on > 100% of existing servers, regardless of how they expand namespaces, > ignore comments (or not), use CDATA or escaped XML, etc. If a client really expects the property value to be treated as text,=20 yes, it should send it as text. The issue here that there are very good reasons to use XML, for=20 instance, when the format of the property is already defined as XML=20 (such as when tunneling DC metadata in WebDAV properties). > Clients putting sub-elements into properties should accept that > the server will likely parse those elements, potentially storing that > into some normative form, then re-render that into XML when asked for > it later, and that semantically equivalent but byte-for-byte > different data may come back. I think forcing a server author to > care about preserving the original XML rendering at all is a bad idea. As far as I can tell, nobody asked for that. > WebDAV is already pretty complicated. XML with namespaces is no > small part of that complexity. Why make it harder when an easy > solution is already available in current implementations? We don't want to make it harder. On the other hand, we also don't want=20 to remove something I feel is an important feature, just because some=20 servers do not get it right (usually, these are the same servers that=20 don't get other things right as well, so trying to please those usually=20 would mean taking out lots of other things). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 17 05:42:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchEF-0002sc-FL for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 05:42:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12975 for ; Thu, 17 Nov 2005 05:42:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EchDT-00059w-5A for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 10:42:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EchDQ-00059H-Up for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 10:42:05 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EchDI-0006FD-Km for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 10:42:03 +0000 Received: (qmail invoked by alias); 17 Nov 2005 10:41:54 -0000 Received: from p508FAF12.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.175.18] by mail.gmx.net (mp020) with SMTP; 17 Nov 2005 11:41:54 +0100 X-Authenticated: #1915285 Message-ID: <437C5E42.10903@gmx.de> Date: Thu, 17 Nov 2005 11:41:06 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EchDI-0006FD-Km fdb950ee04df825d6596d0f5c272fe8c X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437C5E42.10903@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10373 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 10:42:07 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Can you put out a proposal of which of the items you think clients should be > able to depend on the clients preserving? That's in . Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 17 15:18:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqDZ-0001sR-SZ for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 15:18:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17263 for ; Thu, 17 Nov 2005 15:18:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eco6C-0004g1-AT for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 18:03:04 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eco68-0004fA-5h for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 18:03:00 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eco65-0007vt-C5 for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 18:02:59 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAHI2MSN011830; Thu, 17 Nov 2005 10:02:22 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay8.apple.com (Apple SCV relay) with ESMTP id 251A3648; Thu, 17 Nov 2005 10:02:22 -0800 (PST) In-Reply-To: <437C59FD.9000300@gmx.de> References: <60897A0F7690ED43A1E0995D0534F8FB03FE29@daddy.numcom.local> <9BF05E70-E1D1-475B-AF28-015F319481C3@cs.ucsc.edu> <437B7D8F.1040709@gmx.de> <437C59FD.9000300@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: webdav WG Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 17 Nov 2005 10:02:19 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eco65-0007vt-C5 d2c17f732a90ffeda9225f120c39e5e1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/EA6D9427-EFA0-4416-A57C-99DDA1557EB9@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10374 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 18:03:04 +0000 Content-Transfer-Encoding: quoted-printable Typo; I meant are, not aren't. You're right, of course. -wsv On Nov 17, 2005, at 2:22 AM, Julian Reschke wrote: > Wilfredo S=E1nchez Vega wrote: >> Hate to sound ignorant again, but, well I guess I don't hate it >> that much... >> Recognizing that we can't say that XML sub-elements aren't allowed >> in property elements because of history, the spec should encourage > > XML sub-elements *are* allowed in property values. RFC2518 says =20 > this, and many servers get this right. From w3c-dist-auth-request@frink.w3.org Thu Nov 17 15:18:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqDa-0001se-9X for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 15:18:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17265 for ; Thu, 17 Nov 2005 15:18:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ecojd-000503-0a for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 18:43:49 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ecojc-0004zL-DF for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 18:43:48 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EcojY-0006r3-NV for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 18:43:47 +0000 Received: (qmail invoked by alias); 17 Nov 2005 18:43:39 -0000 Received: from p508F91B6.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.145.182] by mail.gmx.net (mp037) with SMTP; 17 Nov 2005 19:43:39 +0100 X-Authenticated: #1915285 Message-ID: <437CCF0E.5070203@gmx.de> Date: Thu, 17 Nov 2005 19:42:22 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Lukas Mathis , WebDav References: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> <437C570B.6020806@gmx.de> <5C532EDC-A9F9-4AEA-8B1E-FBEFD7259BE3@apple.com> In-Reply-To: <5C532EDC-A9F9-4AEA-8B1E-FBEFD7259BE3@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcojY-0006r3-NV 491422a7b02d49fac614d7a9df78ca14 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437CCF0E.5070203@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10376 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 18:43:49 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA17265 Wilfredo S=E1nchez Vega wrote: > Except that I think attempting to preserve namespace prefixes in=20 > property XML falls in that category. >=20 > Namespace prefixes aren't supposed to be semantically meaningful, and= =20 > changing them shouldn't have any more effect on the XML reader than=20 > changing a variable name in code should on a program. What matters is=20 > the data being referred to, not the name of the reference. Wilfredo, it would be helpful if you go through the mailing list archives and=20 re-read the thread. I absolutely do agree that namespace prefixes were not *meant* to be=20 significant, but now they are, because people (incl. the W3C) have=20 started putting them into attribute *values*, such as in XPath or XML=20 Schema. Was that a bad idea? Probably yes. Can we change that? No. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 17 15:18:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqDa-0001t8-Sm for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 15:18:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17270 for ; Thu, 17 Nov 2005 15:18:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ecohx-0004od-OJ for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 18:42:05 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ecoht-0004o3-Ax for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 18:42:01 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ecohq-00043d-0L for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 18:42:00 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jAHIfddk024592; Thu, 17 Nov 2005 10:41:39 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay8.apple.com (Apple SCV relay) with ESMTP id 6175965A; Thu, 17 Nov 2005 10:41:39 -0800 (PST) In-Reply-To: <437C570B.6020806@gmx.de> References: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> <437C570B.6020806@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <092D3AD3-4288-4043-A259-9B464A6DFD47@wsanchez.net> Cc: Lukas Mathis , WebDav Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 17 Nov 2005 10:41:38 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (maggie.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ecohq-00043d-0L b5f1212c825df962c219fc78945a5f03 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/092D3AD3-4288-4043-A259-9B464A6DFD47@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10375 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 18:42:05 +0000 Content-Transfer-Encoding: 7bit On Nov 17, 2005, at 2:10 AM, Julian Reschke wrote: > Lukas Mathis wrote: >>> Clients putting sub-elements into properties should accept >>> that the server will likely parse those elements, potentially >>> storing that into some normative form, then re-render that into >>> XML when asked for it later, and that semantically equivalent but >>> byte-for-byte different data may come back. I think forcing a >>> server author to care about preserving the original XML rendering >>> at all is a bad idea. >> I agree with that. It's XML, and it should be treated as such. If >> the client wants it be treated as text, it must but it in a CDATA >> section. > > I agree with that too. As a matter of fact, I don't think anybody > disagrees here. > > Best regards, Julian Except that I think attempting to preserve namespace prefixes in property XML falls in that category. Namespace prefixes aren't supposed to be semantically meaningful, and changing them shouldn't have any more effect on the XML reader than changing a variable name in code should on a program. What matters is the data being referred to, not the name of the reference. -wsv From w3c-dist-auth-request@frink.w3.org Thu Nov 17 15:51:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqjJ-0007Xu-IQ for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 15:51:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19915 for ; Thu, 17 Nov 2005 15:51:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcqCb-0004oq-Kp for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 20:17:49 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EcqCX-0004oH-0V for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 20:17:45 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EcqCR-0006s8-51 for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 20:17:43 +0000 Received: (qmail invoked by alias); 17 Nov 2005 20:17:34 -0000 Received: from p508F91B6.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.145.182] by mail.gmx.net (mp002) with SMTP; 17 Nov 2005 21:17:34 +0100 X-Authenticated: #1915285 Message-ID: <437CE50B.3090207@gmx.de> Date: Thu, 17 Nov 2005 21:16:11 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Lukas Mathis , WebDav References: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> <437C570B.6020806@gmx.de> <5C532EDC-A9F9-4AEA-8B1E-FBEFD7259BE3@apple.com> <437CCF0E.5070203@gmx.de> <6FAB68CB-62DC-437E-8D72-FF326DA99728@apple.com> In-Reply-To: <6FAB68CB-62DC-437E-8D72-FF326DA99728@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EcqCR-0006s8-51 939a9b354bb570769c96e4f49b2a2cac X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437CE50B.3090207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10377 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 20:17:49 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA19915 Wilfredo S=E1nchez Vega wrote: > Right, but the fact is that XML parsing libraries don't generally=20 > preserve prefix names. So I agree that those were bad ideas. What do you mean by generally? DOM - as far as I can tell the only XML=20 API with an W3C stamp on it - preserves them. So does SAX. In fact, building a compliant XSLT processor on top of an API does=20 require that. > So unless the XML spec is going to change to require parsers to=20 > preserve prefix and we can require XML parsers to comply with the=20 The XML spec requires that. > updated XML spec, I don't think it's reasonable to expect a server to=20 > preserve prefixes. Doing so requires the server author to use an XML=20 With all due respect, I think you need to check the facts. > library that does more than the XML spec requires, which may mean they=20 > have to write their own. If you can't use a standard XML library,=20 > you're obviating the main advantage of using XML at all. >=20 > If you need to preserve prefixes, regardless of what your reasons are= ,=20 > including your use of other (perhaps poorly thought out) W3C specs, you= =20 > are in effect expecting the server to treat your XML as text. If that'= s=20 > the case, then encode the property XML as text and be done with it. I=20 > don't really follow why this isn't considered a viable option here. Wilfredo, I think you're arguing based on a misunderstanding of XML. The XML spec=20 itself doesn't say anything about the prefix in a name being ignorable=20 (as a matter of fact, it doesn't speak of prefixes at all, because=20 that's in the Namespaces spec). Nor does the XML Namespaces spec itself.=20 Nor does DOM, XPath or XSLT. Or SAX (for an example of a non-W3C API). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 17 16:12:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecr3Z-0006yx-Ek for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 16:12:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24925 for ; Thu, 17 Nov 2005 16:11:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ecr2d-0001R1-Gf for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 21:11:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ecr2Z-0001PZ-5q for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 21:11:31 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ecr2U-0008Op-9g for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 21:11:30 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAHLArZc012657; Thu, 17 Nov 2005 13:10:53 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id E5636324002; Thu, 17 Nov 2005 13:10:52 -0800 (PST) In-Reply-To: <437CE50B.3090207@gmx.de> References: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> <437C570B.6020806@gmx.de> <5C532EDC-A9F9-4AEA-8B1E-FBEFD7259BE3@apple.com> <437CCF0E.5070203@gmx.de> <6FAB68CB-62DC-437E-8D72-FF326DA99728@apple.com> <437CE50B.3090207@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Lukas Mathis , WebDav Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 17 Nov 2005 13:10:51 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (maggie.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ecr2U-0008Op-9g b2dfdc5d86937a6d4866936c3524f47f X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/DC3E4AE2-CE51-478E-BF7C-7E6F95F3766C@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10378 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 21:11:35 +0000 Content-Transfer-Encoding: 7bit On Nov 17, 2005, at 12:16 PM, Julian Reschke wrote: > I think you're arguing based on a misunderstanding of XML. The XML > spec itself doesn't say anything about the prefix in a name being > ignorable (as a matter of fact, it doesn't speak of prefixes at > all, because that's in the Namespaces spec). Nor does the XML > Namespaces spec itself. Nor does DOM, XPath or XSLT. Or SAX (for an > example of a non-W3C API). Not saying anything isn't the same as requiring that they be preserved, but OK. I get my impression from the following. Here is some input XML: value0 value1 value2 value3 value4 value5 value6 value7 value8 value9 And here is a snippet in the Python interpreter that reads it and writes it back out: >>> doc = xml.dom.minidom.parseString(file("/Volumes/data/Users/ wsanchez/Developer/Python/Twisted/twisted/web2/dav/test/data/xml/ PROPPATCH_request.xml").read()) >>> xml.dom.ext.Print(doc) value0 value1 value2 value3 value4 value5 value6 value7 value8 value9 I've done nothing other than ask my library to read the file and then render it back out. Note that the "L" prefix was not merely modified, it was removed entirely. Clearly the XML library I'm using here thinks it's OK to rewrite the XML. Is this a bug? -wsv From w3c-dist-auth-request@frink.w3.org Thu Nov 17 16:56:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecrjz-0002aX-Hf for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 16:56:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28588 for ; Thu, 17 Nov 2005 16:55:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ecrii-0007bd-6y for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 21:55:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcrMT-0000Sc-0o for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 21:32:05 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1Ecr7m-0001F7-RT for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 21:16:55 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Ecr7I-0008Gw-DI for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 21:16:51 +0000 Received: (qmail invoked by alias); 17 Nov 2005 21:16:18 -0000 Received: from p508F91B6.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.145.182] by mail.gmx.net (mp032) with SMTP; 17 Nov 2005 22:16:18 +0100 X-Authenticated: #1915285 Message-ID: <437CF2C6.7020708@gmx.de> Date: Thu, 17 Nov 2005 22:14:46 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Lukas Mathis , WebDav References: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> <437C570B.6020806@gmx.de> <5C532EDC-A9F9-4AEA-8B1E-FBEFD7259BE3@apple.com> <437CCF0E.5070203@gmx.de> <6FAB68CB-62DC-437E-8D72-FF326DA99728@apple.com> <437CE50B.3090207@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ecr7I-0008Gw-DI 1fab9c4c8b1f70b9d0510ab4a7275147 Received-SPF: fail (maggie.w3.org: domain of julian.reschke@gmx.de does not designate 133.27.228.225 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437CF2C6.7020708@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10379 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 21:55:04 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA28588 Wilfredo S=E1nchez Vega wrote: > ... > I've done nothing other than ask my library to read the file and then= =20 > render it back out. Note that the "L" prefix was not merely modified,=20 > it was removed entirely. Clearly the XML library I'm using here thinks= =20 > it's OK to rewrite the XML. Is this a bug? No, it's not a bug. There is no standard whatsoever about what an XML=20 API needs to provide. I even wrote a similar one for Java myself. But that doesn't mean that "generally", APIs do not provide this kind of=20 information. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 17 18:17:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ect0r-0003To-10 for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 18:17:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03632 for ; Thu, 17 Nov 2005 18:17:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcszU-0002zG-Mc for w3c-dist-auth-dist@listhub.w3.org; Thu, 17 Nov 2005 23:16:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcszQ-0002yi-Cp for w3c-dist-auth@listhub.w3.org; Thu, 17 Nov 2005 23:16:24 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcszN-00010L-Dt for w3c-dist-auth@w3.org; Thu, 17 Nov 2005 23:16:23 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAHNGA5Z000632; Thu, 17 Nov 2005 15:16:10 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id DF15E375; Thu, 17 Nov 2005 15:16:09 -0800 (PST) In-Reply-To: <437CF2C6.7020708@gmx.de> References: <60897A0F7690ED43A1E0995D0534F8FB03FE4D@daddy.numcom.local> <437C570B.6020806@gmx.de> <5C532EDC-A9F9-4AEA-8B1E-FBEFD7259BE3@apple.com> <437CCF0E.5070203@gmx.de> <6FAB68CB-62DC-437E-8D72-FF326DA99728@apple.com> <437CE50B.3090207@gmx.de> <437CF2C6.7020708@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Lukas Mathis , WebDav Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 17 Nov 2005 15:16:09 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (maggie.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EcszN-00010L-Dt 2904f0df2c6ebc1a41eece83f55321d0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/F42A9895-BDC9-46EE-97E1-79D841C297DE@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10380 X-Loop: w3c-dist-auth@w3.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, 17 Nov 2005 23:16:28 +0000 Content-Transfer-Encoding: 7bit OK, my concern is that I'm going to want to use any compliant XML library to read and write my XML by asking my library to read the XML and then telling it to render the property elements back out. I'd really like to avoid having to know much more about XML than that, as you've noticed. ;-) If you want me to preserve the prefixes, I'm worried that I would then have to choose an XML library that's "WebDAV compliant" (XML plus X) rather than simply XML compliant, or write my own XML generator. (You're right that the prefixes are available at parse time in both SAX and DOM, so the issue in this case in the XML renderer.) That's a lot more work for the server author as compared to the client simply escaping the XML so as to guarantee that the server gives you back exactly what you gave it. What value is there in the server doing any parsing of dead properties in the first place? I still see no good reason to give the server XML (which it *has to* parse, because it's part of the containing request document) in a dead property. I realize that we allow it today, and can't take that away, but why go through hoops preserve XML data on the server when the client can very easily guarantee it by sending the XML as CDATA instead? -wsv On Nov 17, 2005, at 1:14 PM, Julian Reschke wrote: > No, it's not a bug. There is no standard whatsoever about what an > XML API needs to provide. I even wrote a similar one for Java myself. > > But that doesn't mean that "generally", APIs do not provide this > kind of information. From w3c-dist-auth-request@frink.w3.org Thu Nov 17 23:54:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcyGL-0000bx-6K for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 23:54:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20927 for ; Thu, 17 Nov 2005 23:53:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcyF5-00064i-IM for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 04:52:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EcyEx-00063l-6M for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 04:52:47 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EcyEk-0006jS-RE for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 04:52:47 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2005 20:52:33 -0800 X-IronPort-AV: i="3.97,345,1125903600"; d="scan'208"; a="231932929:sNHT26046056" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAI4qSOp015932; Thu, 17 Nov 2005 20:52:29 -0800 (PST) Received: from 10.21.89.49 ([10.21.89.49]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Nov 2005 04:53:10 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 17 Nov 2005 20:35:30 -0800 From: Cullen Jennings To: Julian Reschke CC: WebDav Message-ID: Thread-Topic: XML InfoSet and property value preservation Thread-Index: AcXr+YFiv/VhT1fsEdqE7AARJEEJ/A== In-Reply-To: <437C5E42.10903@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EcyEk-0006jS-RE dabfacf9e58d6d34417228c40bb1c08f X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/BFA29A12.611C4%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10382 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 04:52:55 +0000 Content-Transfer-Encoding: 7bit On 11/17/05 2:41 AM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> >> Can you put out a proposal of which of the items you think clients should be >> able to depend on the clients preserving? > > That's in > . > > Best regards, Julian Ok so to trying to make sure I understand your proposal ... On 11/6/05 12:04 PM, "Julian Reschke" wrote: > So are comments, processing instructions, unparsed entities and so on > in? Probably not. Assume you mean MUST NOT and is there any more to the "so on" > > Looking at the large set of information items, it's probably simpler if > we just list the items we want to be round-tripped, such as: So assuming you mean "server MUST preserver" > > 1) On the property element itself: [namespace name], [local name], > [children] of type element or character, plus [attributes] named > "xml:lang" present on the element itself or it's closest ancestor > > 2) On all children of the property element: [namespace name], [local > name], [attributes] and [children] of type element or character. > > Regarding the issue that started the whole discussion: we IMHO should > encourage servers to preserve the [prefix} on all but the property > element itself, and warn clients about information loss for those > servers that don't. I'm a bit lost on the point of encouraging them to preserver this. Do we plan to make a later version of the specification require this? If not, I'm not sure I see the point. (I do see the point of telling clients they can't count on it) > > Best regards, Julian If others understand this proposal, I've got not complaint with it and please ignore this email but when I read it I did not realize this was a specific proposal and saw it more as a general leaning towards what a proposal might look like. I was happy to see the outline post but it seemed like you had an excellent grasp on what the problem was here and might be able to provide some crisp description of the solution and a bit of explanation on why this was the right solution so that none of us were doomed to an endless recurring conversation. Seriously, you are in a great position to put the nail in the coffin on this one once and for all. Make it end. Cullen From w3c-dist-auth-request@frink.w3.org Thu Nov 17 23:54:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcyGL-0000bw-6M for webdav-archive@megatron.ietf.org; Thu, 17 Nov 2005 23:54:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20928 for ; Thu, 17 Nov 2005 23:53:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EcyEz-00064F-8m for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 04:52:49 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EcyEv-00063Q-6s for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 04:52:45 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EcyEs-00075Y-Hh for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 04:52:44 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2005 20:52:40 -0800 X-IronPort-AV: i="3.97,345,1125903600"; d="scan'208"; a="231932948:sNHT25878462" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAI4qZOp015968; Thu, 17 Nov 2005 20:52:35 -0800 (PST) Received: from 10.21.89.49 ([10.21.89.49]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Nov 2005 04:53:16 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 17 Nov 2005 20:52:41 -0800 From: Cullen Jennings To: Julian Reschke CC: Lisa Dusseault , Geoffrey M Clemm , WebDav Message-ID: Thread-Topic: [Bug 23] lock discovery vs shared locks Thread-Index: AcXr++foJot3uFfvEdqE7AARJEEJ/A== In-Reply-To: <437BA781.2090009@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1EcyEs-00075Y-Hh f9717c70d186392f49dd907fb86d4e3e X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/BFA29E19.611CC%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10381 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 04:52:49 +0000 Content-Transfer-Encoding: 7bit On 11/16/05 1:41 PM, "Julian Reschke" wrote: > an implementation > guide instead of the spec, we may want to actually consider to start a > document like that; and I'm volunteering to work on that. That would be > separate from RFC2518bis, and potentially not even an IETF document > (unless the WG would want it to be that way). My measure of a successful protocol is that people find it useful and that means it needs to get implemented. A "hints to implementers" document seems all good and could be IETF document or not - I don't care as long as it helped the adoption of the protocol by making it easier to implement. Example flow documents have helped other groups make it easier to get interoperable implementations. That said, a skilled programmer still needs to be able to correctly implement and understand the protocol by just reading the spec and things it normatively references. The spec should help make this easy not hard. And if there is something that in the specification that a significant percentage of competent implementers might get wrong on the wire, the specification was probably not clear enough. From w3c-dist-auth-request@frink.w3.org Fri Nov 18 01:01:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EczJe-0007VP-KU for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 01:01:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23856 for ; Fri, 18 Nov 2005 01:01:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EczIP-0006px-1Y for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 06:00:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EczIL-0006oG-1U for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 06:00:21 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EczID-0002Sq-0f for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 06:00:20 +0000 Received: (qmail invoked by alias); 18 Nov 2005 06:00:11 -0000 Received: from p508FB95C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.185.92] by mail.gmx.net (mp027) with SMTP; 18 Nov 2005 07:00:11 +0100 X-Authenticated: #1915285 Message-ID: <437D6DBE.7080101@gmx.de> Date: Fri, 18 Nov 2005 06:59:26 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , Geoffrey M Clemm , WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EczID-0002Sq-0f 491dddcba44c8fe88fd77a7a08e894bf X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437D6DBE.7080101@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10383 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 06:00:25 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > ... > That said, a skilled programmer still needs to be able to correctly > implement and understand the protocol by just reading the spec and things it > normatively references. The spec should help make this easy not hard. And if > there is something that in the specification that a significant percentage > of competent implementers might get wrong on the wire, the specification was > probably not clear enough. Yes, and this is certainly the case here. As far as I can tell, there are two major problems (and possibly one minor problem) with RFC2518, and these should be fixed no matter what. In particular: 1) Normative text and examples are inconsistent. As almost all readers look at examples first and only read the rest when things do *not* work, making sure that examples are correct is extremely important. 2) The specification introduces two different ways to do things, where one would have been absolutely sufficient. To make things worse, one of the two things is flawed (it doesn't always work, so clients should not rely on in in the first place). 3) The given example at a minimum should have illustrated the potential problems with the second approach (for instance, by showing the result for the case that a second shared lock was created). I wasn't part of the WG when this was written, but it certainly looks like the "Lock-Token" response header was introduced very late because somebody realized that the other approach simply doesn't work. Unfortunately, the spec wasn't checked properly for other changes to be made. How to proceed? a) Make the *fixes* to the spec we obviously need (fix the example to use the Lock-Token header and modify the response body so that it becomes clear why parsing it will be a bad idea) b) Collect information what implementations do today (JimL, thanks for the feedback in this and all the other cases!). c) Then decide about what else needs to be done. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Nov 18 02:51:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed11b-0005qV-Q5 for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 02:51:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28706 for ; Fri, 18 Nov 2005 02:50:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed10G-0008Fl-5J for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 07:49:48 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ed106-0008Dh-7L for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 07:49:38 +0000 Received: from mx1.init7.net ([213.144.129.5] helo=taguan.init7.net) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ed0zw-0007nz-AN for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 07:49:35 +0000 Received: from daddy.numcom.local ([213.144.131.169]) by taguan.init7.net (8.13.4/8.13.4/Debian-3) with ESMTP id jAI7nLoX013782 for ; Fri, 18 Nov 2005 08:49:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2005 08:49:13 +0100 Message-ID: <60897A0F7690ED43A1E0995D0534F8FB03FE74@daddy.numcom.local> Thread-Topic: XML InfoSet and property value preservation Thread-Index: AcXrtAThXQa3AwCsRjaaWkfiKw4KZQAXo+wg From: "Lukas Mathis" To: "WebDav" Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of lukas.mathis@numcom.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ed0zw-0007nz-AN 1f83faee3142c9d2c9229aa33f5857a7 X-Original-To: w3c-dist-auth@w3.org Subject: RE: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/60897A0F7690ED43A1E0995D0534F8FB03FE74@daddy.numcom.local Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10384 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 07:49:48 +0000 Content-Transfer-Encoding: quoted-printable > > So unless the XML spec is going to change to require parsers to=20 > > preserve prefix and we can require XML parsers to comply with the > The XML spec requires that. Are you sure? I didn't find any requirement like that. I thought prefix names weren't important per se, it's their declaration = that gives them meaning. You need to bind a prefix to a namespace name, = and the parser needs to look that up. The server should be free to = change the prefix as long as he keeps the binding consistent. What if the client uses a prefix which the server already wants to use = for another namespace? What if different clients change different = properties, but use the same namespace prefixes with different bindings? Now, if current clients expect the prefixes to be kept, servers should = try to do that, but I don't think the spec should require it. lucas --=20 Lukas Mathis, Numcom Software AG Hardturmstrasse 66, CH-8005 Z=FCrich Direct +41(0)43-204 06 08 mailto:lukas.mathis@numcom.com, http://www.numcom.com/ From w3c-dist-auth-request@frink.w3.org Fri Nov 18 04:01:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed27D-0007HC-Ry for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 04:01:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02356 for ; Fri, 18 Nov 2005 04:00:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed25t-0005VC-JO for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 08:59:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed25p-0005Ue-Vk for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 08:59:38 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Ed25m-0007jD-Q3 for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 08:59:37 +0000 Received: (qmail invoked by alias); 18 Nov 2005 08:59:32 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 18 Nov 2005 09:59:32 +0100 X-Authenticated: #1915285 Message-ID: <437D97C9.1020900@gmx.de> Date: Fri, 18 Nov 2005 09:58:49 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lukas Mathis CC: WebDav References: <60897A0F7690ED43A1E0995D0534F8FB03FE74@daddy.numcom.local> In-Reply-To: <60897A0F7690ED43A1E0995D0534F8FB03FE74@daddy.numcom.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ed25m-0007jD-Q3 c03bb016b7cd8633fc45d7753dbb06ea X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437D97C9.1020900@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10385 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 08:59:41 +0000 Content-Transfer-Encoding: 7bit Lukas Mathis wrote: >>> So unless the XML spec is going to change to require parsers to >>> preserve prefix and we can require XML parsers to comply with the >> The XML spec requires that. > > Are you sure? I didn't find any requirement like that. The XML spec doesn't say anything at all about prefixes. An attribute name with prefix + colon is just an ordinary attribute name from the XML spec's point of view. > I thought prefix names weren't important per se, it's their declaration that gives them meaning. You need to bind a prefix to a namespace name, and the parser needs to look that up. The server should be free to change the prefix as long as he keeps the binding consistent. That may have been the plan once, but when people started putting QNames (qualified names) into attribute values or text content, it wasn't true any longer. > What if the client uses a prefix which the server already wants to use for another namespace? What if different clients change different properties, but use the same namespace prefixes with different bindings? Nobody has asked for servers preserving prefixes on the WebDAV property elements itself. We're talking about child elements of properties. > Now, if current clients expect the prefixes to be kept, servers should try to do that, but I don't think the spec should require it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Nov 18 04:10:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2GC-0003HT-DU for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 04:10:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02891 for ; Fri, 18 Nov 2005 04:09:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed2FX-0000Pr-9M for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 09:09:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed2FW-0000PI-JB for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 09:09:38 +0000 Received: from mx1.init7.net ([213.144.129.5] helo=taguan.init7.net) by maggie.w3.org with esmtp (Exim 4.50) id 1Ed2FS-0001UV-FR for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 09:09:38 +0000 Received: from daddy.numcom.local ([213.144.131.169]) by taguan.init7.net (8.13.4/8.13.4/Debian-3) with ESMTP id jAI99W3i023980 for ; Fri, 18 Nov 2005 10:09:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2005 10:09:24 +0100 Message-ID: <60897A0F7690ED43A1E0995D0534F8FB03FE7D@daddy.numcom.local> Thread-Topic: XML InfoSet and property value preservation Thread-Index: AcXsHnQqcwOBukwRRPyWgLsa/7r2FAAADsUg From: "Lukas Mathis" To: "WebDav" Received-SPF: none (maggie.w3.org: domain of lukas.mathis@numcom.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ed2FS-0001UV-FR 9fa2b0580fb9e4849c7c2734884d76ed X-Original-To: w3c-dist-auth@w3.org Subject: RE: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/60897A0F7690ED43A1E0995D0534F8FB03FE7D@daddy.numcom.local Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10386 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 09:09:39 +0000 Content-Transfer-Encoding: quoted-printable >> wants to use for another namespace? What if different clients=20 >> change different properties, but use the same namespace=20 >> prefixes with different bindings? > Nobody has asked for servers preserving prefixes on the=20 > WebDAV property elements itself. We're talking about child=20 > elements of properties. I realize that. But if clients store child elements into properties, = different clients can potentially use the same namespace prefixes for = different namespaces while doing so. If those two clients both change = different properties, the server has to somehow work around that. When = returning several properties at once, the server needs to reconcile this = difference in order to create a coherent XML result. Likewise, clients can't expect the prefixes to always mean what they = meant when the clients stored the properties, because other clients = could potentially use the same prefixes for different namespaces. lukas --=20 Lukas Mathis, Numcom Software AG Hardturmstrasse 66, CH-8005 Z=FCrich Direct +41(0)43-204 06 08 mailto:lukas.mathis@numcom.com, http://www.numcom.com/ From w3c-dist-auth-request@frink.w3.org Fri Nov 18 04:43:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2mQ-0008Kw-0u for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 04:43:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04752 for ; Fri, 18 Nov 2005 04:43:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed2le-0008JT-8T for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 09:42:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed2la-0008Io-5a for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 09:42:46 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Ed2lX-00005j-AW for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 09:42:45 +0000 Received: (qmail invoked by alias); 18 Nov 2005 09:42:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 18 Nov 2005 10:42:41 +0100 X-Authenticated: #1915285 Message-ID: <437DA1E2.5090005@gmx.de> Date: Fri, 18 Nov 2005 10:41:54 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lukas Mathis CC: WebDav References: <60897A0F7690ED43A1E0995D0534F8FB03FE7D@daddy.numcom.local> In-Reply-To: <60897A0F7690ED43A1E0995D0534F8FB03FE7D@daddy.numcom.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ed2lX-00005j-AW 3caaeca979447dcbc347669b9d40446d X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437DA1E2.5090005@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10387 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 09:42:50 +0000 Content-Transfer-Encoding: 7bit Lukas Mathis wrote: >>> wants to use for another namespace? What if different clients >>> change different properties, but use the same namespace >>> prefixes with different bindings? >> Nobody has asked for servers preserving prefixes on the >> WebDAV property elements itself. We're talking about child >> elements of properties. > > I realize that. But if clients store child elements into properties, different clients can potentially use the same namespace prefixes for different namespaces while doing so. If those two clients both change different properties, the server has to somehow work around that. When returning several properties at once, the server needs to reconcile this difference in order to create a coherent XML result. I honestly understand your point (and I *have* written a server that preserves the prefixes). Maybe you could give a concrete example? > Likewise, clients can't expect the prefixes to always mean what they meant when the clients stored the properties, because other clients could potentially use the same prefixes for different namespaces. Again, I don't understand. When Client A stores a property X, and client B overwrites that property with something else, then Client A may be confused. But this has nothing to do with whether prefixes are preserved or not. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Nov 18 05:02:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed34r-0007tM-BM for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 05:02:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05673 for ; Fri, 18 Nov 2005 05:02:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed33v-0004tx-1c for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 10:01:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed33q-0004rF-67 for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 10:01:38 +0000 Received: from mx1.init7.net ([213.144.129.5] helo=taguan.init7.net) by maggie.w3.org with esmtp (Exim 4.50) id 1Ed33k-00041h-1U for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 10:01:37 +0000 Received: from daddy.numcom.local ([213.144.131.169]) by taguan.init7.net (8.13.4/8.13.4/Debian-3) with ESMTP id jAIA1TvH029421 for ; Fri, 18 Nov 2005 11:01:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2005 11:01:21 +0100 Message-ID: <60897A0F7690ED43A1E0995D0534F8FB03FE82@daddy.numcom.local> Thread-Topic: XML InfoSet and property value preservation Thread-Index: AcXsJIDtrZe8rv1zRmKa1pXNJcNqUQAADESw From: "Lukas Mathis" To: "WebDav" Received-SPF: none (maggie.w3.org: domain of lukas.mathis@numcom.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ed33k-00041h-1U d610ed01da1475b724a92c809aa38626 X-Original-To: w3c-dist-auth@w3.org Subject: RE: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/60897A0F7690ED43A1E0995D0534F8FB03FE82@daddy.numcom.local Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10388 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 10:01:43 +0000 Content-Transfer-Encoding: quoted-printable > Maybe you could give a concrete example? Client A stores XML code in property x: some data Client B stores XML code in property y: some other data Client A's namespace prefix p points to a different namespace than = client B's namespace prefix p. Now, client A gets all properties = (including x ans y) for this resource. The server needs to create on XML = file containing both properties, but it can't preserve both prefixes, = since they point to different namespaces. It's entirely possible that I simply don't understand the sitation, of = course. lukas --=20 Lukas Mathis, Numcom Software AG Hardturmstrasse 66, CH-8005 Z=FCrich Direct +41(0)43-204 06 08 mailto:lukas.mathis@numcom.com, http://www.numcom.com/ From w3c-dist-auth-request@frink.w3.org Fri Nov 18 05:21:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3NM-0007AF-Dc for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 05:21:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06893 for ; Fri, 18 Nov 2005 05:21:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed3MV-0001MQ-Ar for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 10:20:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed3MR-0001Ls-2v for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 10:20:51 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1Ed3MK-0000bm-EP for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 10:20:51 +0000 Received: (qmail invoked by alias); 18 Nov 2005 10:20:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp011) with SMTP; 18 Nov 2005 11:20:41 +0100 X-Authenticated: #1915285 Message-ID: <437DAAC9.6000800@gmx.de> Date: Fri, 18 Nov 2005 11:19:53 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lukas Mathis CC: WebDav References: <60897A0F7690ED43A1E0995D0534F8FB03FE82@daddy.numcom.local> In-Reply-To: <60897A0F7690ED43A1E0995D0534F8FB03FE82@daddy.numcom.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ed3MK-0000bm-EP cdd3eb157e293751a15c5225f362b72d X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437DAAC9.6000800@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10389 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 10:20:55 +0000 Content-Transfer-Encoding: 7bit Lukas Mathis wrote: >> Maybe you could give a concrete example? > > Client A stores XML code in property x: > some data > > Client B stores XML code in property y: > some other data > > Client A's namespace prefix p points to a different namespace than client B's namespace prefix p. Now, client A gets all properties (including x ans y) for this resource. The server needs to create on XML file containing both properties, but it can't preserve both prefixes, since they point to different namespaces. Sure it can. For instance. Let's assume "x" and "y" live in namespace "custom", and "p" has namespace "ns1" for x and "ns2" for y. The response could be: some data some other data > It's entirely possible that I simply don't understand the sitation, of course. > > lukas > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Nov 18 05:34:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3Zc-0003A4-9v for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 05:34:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07709 for ; Fri, 18 Nov 2005 05:33:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed3Yz-0003s9-N9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 10:33:49 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed3Yz-0003rP-8H for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 10:33:49 +0000 Received: from mx1.init7.net ([213.144.129.5] helo=taguan.init7.net) by maggie.w3.org with esmtp (Exim 4.50) id 1Ed3Yr-0002a0-Jq for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 10:33:48 +0000 Received: from daddy.numcom.local ([213.144.131.169]) by taguan.init7.net (8.13.4/8.13.4/Debian-3) with ESMTP id jAIAXdWk001325 for ; Fri, 18 Nov 2005 11:33:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2005 11:33:31 +0100 Message-ID: <60897A0F7690ED43A1E0995D0534F8FB03FE83@daddy.numcom.local> Thread-Topic: XML InfoSet and property value preservation Thread-Index: AcXsJIDtrZe8rv1zRmKa1pXNJcNqUQAADESwAAGru4A= From: "Lukas Mathis" To: "WebDav" Received-SPF: none (maggie.w3.org: domain of lukas.mathis@numcom.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ed3Yr-0002a0-Jq 691ce74437f22deaa41b35f392649cd4 X-Original-To: w3c-dist-auth@w3.org Subject: RE: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/60897A0F7690ED43A1E0995D0534F8FB03FE83@daddy.numcom.local Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10390 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 10:33:49 +0000 Content-Transfer-Encoding: quoted-printable Ah! Gah. I just realized that you could obviously define namespaces on = the element level. So I think there's no problem after all :-) lukas --=20 Lukas Mathis, Numcom Software AG Hardturmstrasse 66, CH-8005 Z=FCrich Direct +41(0)43-204 06 08 mailto:lukas.mathis@numcom.com, http://www.numcom.com/ From w3c-dist-auth-request@frink.w3.org Fri Nov 18 06:05:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed43c-0000Ic-Rv for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 06:05:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09685 for ; Fri, 18 Nov 2005 06:04:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed42i-0002KV-0W for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 11:04:32 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ed42e-0002Js-GQ for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 11:04:28 +0000 Received: from mx1.init7.net ([213.144.129.5] helo=taguan.init7.net) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ed42V-0004fi-Kk for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 11:04:27 +0000 Received: from daddy.numcom.local ([213.144.131.169]) by taguan.init7.net (8.13.4/8.13.4/Debian-3) with ESMTP id jAIB4EuG005787 for ; Fri, 18 Nov 2005 12:04:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2005 12:04:06 +0100 Message-ID: <60897A0F7690ED43A1E0995D0534F8FB03FE84@daddy.numcom.local> Thread-Topic: XML InfoSet and property value preservation Thread-Index: AcXsKcq+mLhuL9h5Q0SyVfnSws9rIAABb4/g From: "Lukas Mathis" To: "WebDav" Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of lukas.mathis@numcom.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ed42V-0004fi-Kk 7772dd1450921719913a5888f87f9a38 X-Original-To: w3c-dist-auth@w3.org Subject: RE: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/60897A0F7690ED43A1E0995D0534F8FB03FE84@daddy.numcom.local Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10391 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 11:04:32 +0000 Content-Transfer-Encoding: quoted-printable > Sure it can. For instance. Let's assume "x" and "y" live in=20 > namespace "custom", and "p" has namespace "ns1" for x and "ns2" for y. >=20 > The response could be: >=20 > > some data > some other=20 > data Yes, you're right, of course. Sorry for the confusion :-) So the only issue that remains is that not all parsers can be used if = the prefix names are to be kept. lukas --=20 Lukas Mathis, Numcom Software AG Hardturmstrasse 66, CH-8005 Z=FCrich Direct +41(0)43-204 06 08 mailto:lukas.mathis@numcom.com, http://www.numcom.com/ From w3c-dist-auth-request@frink.w3.org Fri Nov 18 10:26:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed882-0000CP-7q for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 10:26:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23353 for ; Fri, 18 Nov 2005 10:25:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed84T-0001FM-Ge for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 15:22:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed84P-0001Eg-4A for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 15:22:33 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Ed84N-0002Ye-3k for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 15:22:32 +0000 Received: (qmail invoked by alias); 18 Nov 2005 15:22:28 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 18 Nov 2005 16:22:28 +0100 X-Authenticated: #1915285 Message-ID: <437DF16E.3090807@gmx.de> Date: Fri, 18 Nov 2005 16:21:18 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ed84N-0002Ye-3k eecc64b906aa691301ba74d146da568c X-Original-To: w3c-dist-auth@w3.org Subject: Re: XML InfoSet and property value preservation X-Archived-At: http://www.w3.org/mid/437DF16E.3090807@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10392 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 15:22:37 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 11/6/05 12:04 PM, "Julian Reschke" wrote: > >> So are comments, processing instructions, unparsed entities and so on >> in? Probably not. > Assume you mean MUST NOT and is there any more to the "so on" No. MUST NOT would mean that servers aren't allowed to persist these. A server should be free to persist more than then required set of items, though. >> Looking at the large set of information items, it's probably simpler if >> we just list the items we want to be round-tripped, such as: > So assuming you mean "server MUST preserver" >> 1) On the property element itself: [namespace name], [local name], >> [children] of type element or character, plus [attributes] named >> "xml:lang" present on the element itself or it's closest ancestor >> >> 2) On all children of the property element: [namespace name], [local >> name], [attributes] and [children] of type element or character. >> >> Regarding the issue that started the whole discussion: we IMHO should >> encourage servers to preserve the [prefix} on all but the property >> element itself, and warn clients about information loss for those >> servers that don't. > I'm a bit lost on the point of encouraging them to preserver this. Do we > plan to make a later version of the specification require this? If not, I'm > not sure I see the point. (I do see the point of telling clients they can't > count on it) I would hope that recommending it would encourage server implementors to implement it, so it could be made a required feature later. > If others understand this proposal, I've got not complaint with it and > please ignore this email but when I read it I did not realize this was a > specific proposal and saw it more as a general leaning towards what a > proposal might look like. I was happy to see the outline post but it seemed > like you had an excellent grasp on what the problem was here and might be > able to provide some crisp description of the solution and a bit of > explanation on why this was the right solution so that none of us were > doomed to an endless recurring conversation. Seriously, you are in a great > position to put the nail in the coffin on this one once and for all. Make it > end. I agree this is not "camera-ready" spec text. If we agree on the high-level approach, I can try to write it down in a manner that works in the spec. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Nov 18 11:55:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9W2-000241-0f for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 11:55:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28455 for ; Fri, 18 Nov 2005 11:54:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed9Ul-00039n-QX for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 16:53:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed9Uh-00038S-DR for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 16:53:47 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1Ed9Ua-0003Gl-Cu for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 16:53:47 +0000 Received: (qmail invoked by alias); 18 Nov 2005 16:53:37 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 18 Nov 2005 17:53:37 +0100 X-Authenticated: #1915285 Message-ID: <437E06C3.509@gmx.de> Date: Fri, 18 Nov 2005 17:52:19 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: webdav WG References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> <8eaf9241d62055518696cf3f434114e1@osafoundation.org> <43639C2E.3040109@gmx.de> <43639F63.4090000@gmx.de> <436E6317.1000101@gmx.de> <437AED9D.9070908@gmx.de> <361994E2-4C4B-494B-AC8E-225D81C29ABC@apple.com> <9f42511bad90545e98a9d4963fb1a342@osafoundation.org> In-Reply-To: <9f42511bad90545e98a9d4963fb1a342@osafoundation.org> Content-Type: multipart/mixed; boundary="------------050704030607040003080603" X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ed9Ua-0003Gl-Cu 4c2cfc7aa80ae6f4974b451a60abd23a X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437E06C3.509@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10393 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 16:53:51 +0000 This is a multi-part message in MIME format. --------------050704030607040003080603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Julian, do these data points affect your conclusion? This kind of proves how important it is to first clearly understand the problem, and to document it, and only then to think about spec changes. So I've gone back to the good old approach to actually run tests on existing servers (test script attached) and clients. Things I've been looking for: 1) Is the Lock-Token header returned upon LOCK? 2) Is the lockdiscovery property returned? 3) If the lockdiscovery property is returned, does it only contain the new lock token, or also other tokens (of shared locks)? And, while testing, I came across some more issues: 4) Are lock tokens correct? 5) Does PROPFIND/lockdiscovery work as expected on resources with multiple shared locks? Results: SAP Netweaver KM: 1) yes, 2) yes, 3) contains all, 4) yes, 5) yes Apache/moddav: 1) yes, 2) yes, 3) only the newly created, 4) yes, 5) yes IIS6: 1) yes, 2) yes, 3) only the newly created, 4) yes, 5) no (returns multiple property instances) Xythos: 1) yes, 2) yes, 3) contains all, 4) no (uses opaquelocktoken, but not the correct syntax), 5) yes Summary: S1) all servers tested return the Lock-Token header S2) all return the property, but with differences when there were multiple locks (naturally I claim that "contains all" is the right answer) S3) one server still does not get lock tokens right S4) one server doesn't get lock discovery in presence of multiple locks right Next steps: re S2) decide what's right; noting that it really doesn't matter if we tell clients just to use the Lock-Token response header; so why not remove the stuff about response bodies? re S3) I hope the developers are reading this :-) re S4) I'll open a bug report. On the client side I only tested what happens if Microsoft Office tries a lock, but doesn't get the response body. This led to Office thinking the lock did not succeed, opening the document read-only. I'll open a bug report for that one as well. Proposal: 1) Describe lock token discovery after successful LOCK in exactly one place in the spec, and make sure examples are correct 2) Remove the requirement to return the , and mention that change in the "changes" section, including rational and suggest servers continue to return it when backward-compatibility with older clients is an issue. Best regards, Julian --------------050704030607040003080603 Content-Type: application/x-javascript; name="lock_response.js" Content-Disposition: inline; filename="lock_response.js" Content-Transfer-Encoding: 7bit var req = new ActiveXObject ("MSXML2.ServerXMLHTTP"); if (WScript.Arguments.length == 0) { WScript.Echo("Test case property roundtrip"); WScript.Echo("Usage: cscript lock_response.js URI {username} {password}"); WScript.Quit(2); } var uri = WScript.Arguments(0); var user = null; var pwd = null; function dumpResponse(r) { WScript.Echo(r.status); WScript.Echo(r.getAllResponseHeaders()); WScript.Echo(r.responseText); } function getLockToken(r) { var locktoken = null; try { locktoken = req.getResponseHeader("lock-token"); } catch (x) {} if (locktoken == null || locktoken == "") { WScript.Echo("ERROR: server did not return lock token, trying response body"); WScript.Echo(req.responseText); req.responseXML.setProperty("SelectionLanguage", "XPath"); locktoken = req.responseXML.selectSingleNode("//*[local-name()='href']").text; } else { locktoken = locktoken.substring(1, locktoken.length - 1); } return locktoken; } if (WScript.Arguments.length > 1) { user = WScript.Arguments(1); } if (WScript.Arguments.length > 2) { pwd = WScript.Arguments(2); } // delete content WScript.Echo("DELETE " + uri); req.open("DELETE", uri, false, user, pwd); req.send("foobar"); dumpResponse(req); // put content WScript.Echo("PUT " + uri); req.open("PUT", uri, false, user, pwd); req.send("foobar"); dumpResponse(req); if (req.status < 200 || req.status >= 300) { WScript.Echo("unexpected status upon PUT"); WScript.Quit(2); } // lock WScript.Echo("LOCK " + uri); req.open("LOCK", uri, false, user, pwd); req.setRequestHeader("Depth", "0"); req.setRequestHeader("Timeout", "Second-60"); req.send(""); dumpResponse(req); if (req.status != 200) { WScript.Echo("unexpected status upon LOCK"); WScript.Quit(2); } var locktoken = getLockToken(req); // propfind WScript.Echo("PROPFIND " + uri); req.open("PROPFIND", uri, false, user, pwd); req.setRequestHeader("Depth", "0"); req.send(""); dumpResponse(req); // unlock WScript.Echo("UNLOCK " + uri); req.open("UNLOCK", uri, false, user, pwd); req.setRequestHeader("Lock-Token", "<" + locktoken +">"); req.send(""); dumpResponse(req); if (req.status!= 204) { WScript.Echo("unexpected status upon UNLOCK"); WScript.Quit(2); } // same thing with shared locks // lock WScript.Echo("LOCK (shared 1) " + uri); req.open("LOCK", uri, false, user, pwd); req.setRequestHeader("Depth", "0"); req.setRequestHeader("Timeout", "Second-60"); req.send(""); dumpResponse(req); if (req.status != 200) { WScript.Echo("unexpected status upon LOCK"); WScript.Quit(2); } var locktoken1 = getLockToken(req); // same thing with shared locks // lock WScript.Echo("LOCK (shared 2) " + uri); req.open("LOCK", uri, false, user, pwd); req.setRequestHeader("Depth", "0"); req.setRequestHeader("Timeout", "Second-60"); req.send(""); dumpResponse(req); if (req.status != 200) { WScript.Echo("unexpected status upon LOCK"); WScript.Quit(2); } var locktoken2 = getLockToken(req); // propfind WScript.Echo("PROPFIND " + uri); req.open("PROPFIND", uri, false, user, pwd); req.setRequestHeader("Depth", "0"); req.send(""); dumpResponse(req); // unlock WScript.Echo("UNLOCK (1)" + uri); req.open("UNLOCK", uri, false, user, pwd); req.setRequestHeader("Lock-Token", "<" + locktoken1 +">"); req.send(""); dumpResponse(req); if (req.status!= 204) { WScript.Echo("unexpected status upon UNLOCK"); WScript.Quit(2); } // unlock WScript.Echo("UNLOCK (2)" + uri); req.open("UNLOCK", uri, false, user, pwd); req.setRequestHeader("Lock-Token", "<" + locktoken2 +">"); req.send(""); dumpResponse(req); if (req.status!= 204) { WScript.Echo("unexpected status upon UNLOCK"); WScript.Quit(2); } --------------050704030607040003080603-- From w3c-dist-auth-request@frink.w3.org Fri Nov 18 12:00:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9bP-00081Y-JK for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 12:00:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28790 for ; Fri, 18 Nov 2005 12:00:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed9aj-00042E-5V for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 17:00:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed9ai-00041b-MJ for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 17:00:00 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ed9ab-0004Rv-VC for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 17:00:00 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 92309142298; Fri, 18 Nov 2005 08:59:52 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29236-06; Fri, 18 Nov 2005 08:59:52 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CEEC3142296; Fri, 18 Nov 2005 08:59:51 -0800 (PST) In-Reply-To: <437E06C3.509@gmx.de> References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> <8eaf9241d62055518696cf3f434114e1@osafoundation.org> <43639C2E.3040109@gmx.de> <43639F63.4090000@gmx.de> <436E6317.1000101@gmx.de> <437AED9D.9070908@gmx.de> <361994E2-4C4B-494B-AC8E-225D81C29ABC@apple.com> <9f42511bad90545e98a9d4963fb1a342@osafoundation.org> <437E06C3.509@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: webdav WG From: Lisa Dusseault Date: Fri, 18 Nov 2005 08:59:44 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Ed9ab-0004Rv-VC fb830021715603076b9349edda0c73ac X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/e534eff36188a15f898293ccb91de7ad@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10394 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 17:00:01 +0000 Content-Transfer-Encoding: 7bit This is great data Julian, very useful. On Nov 18, 2005, at 8:52 AM, Julian Reschke wrote: > > Proposal: > > 1) Describe lock token discovery after successful LOCK in exactly one > place in the spec, and make sure examples are correct > > 2) Remove the requirement to return the , and mention > that change in the "changes" section, including rational and suggest > servers continue to return it when backward-compatibility with older > clients is an issue. > What about clients learning the lock timeout? I know some clients use the in the response body to learn what timeout the server chose, and use that to know when to refresh the lock. Lisa From w3c-dist-auth-request@frink.w3.org Fri Nov 18 12:08:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9j1-0004fL-3b for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 12:08:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29426 for ; Fri, 18 Nov 2005 12:08:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ed9iH-00075Y-EP for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 17:07:49 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ed9iC-00074y-Rq for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 17:07:44 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1Ed9iA-0002aR-0i for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 17:07:44 +0000 Received: (qmail invoked by alias); 18 Nov 2005 17:07:40 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 18 Nov 2005 18:07:40 +0100 X-Authenticated: #1915285 Message-ID: <437E0A0D.6070209@gmx.de> Date: Fri, 18 Nov 2005 18:06:21 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: webdav WG References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> <8eaf9241d62055518696cf3f434114e1@osafoundation.org> <43639C2E.3040109@gmx.de> <43639F63.4090000@gmx.de> <436E6317.1000101@gmx.de> <437AED9D.9070908@gmx.de> <361994E2-4C4B-494B-AC8E-225D81C29ABC@apple.com> <9f42511bad90545e98a9d4963fb1a342@osafoundation.org> <437E06C3.509@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ed9iA-0002aR-0i 868f7494b5099b5d6b5c3408ee0749e5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437E0A0D.6070209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10395 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 17:07:49 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > This is great data Julian, very useful. > > On Nov 18, 2005, at 8:52 AM, Julian Reschke wrote: > >> >> Proposal: >> >> 1) Describe lock token discovery after successful LOCK in exactly one >> place in the spec, and make sure examples are correct >> >> 2) Remove the requirement to return the , and mention >> that change in the "changes" section, including rational and suggest >> servers continue to return it when backward-compatibility with older >> clients is an issue. >> > What about clients learning the lock timeout? I know some clients use > the in the response body to learn what timeout the > server chose, and use that to know when to refresh the lock. Good question, for which I don't have an answer. We *could* state that the response indeed is *not* the same as a property, and require servers to return complete information just for the newly created lock. That would require a change in the shared lock support in SAP KM and in Xythos, but I guess both parties could live with that. Geoff, any input about how a server concerned with the privacy of lock information would return the actual timeout value (as compared to the one sent by the client)? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Nov 18 12:32:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdA5d-0000ZJ-LU for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 12:32:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00728 for ; Fri, 18 Nov 2005 12:31:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdA4m-0004Ob-OB for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 17:31:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdA4i-0004Nj-RL; Fri, 18 Nov 2005 17:31:00 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdA4g-0001hI-PJ; Fri, 18 Nov 2005 17:31:00 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAIHUvHO009080; Fri, 18 Nov 2005 12:30: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/VERS6.8) with ESMTP id jAIHUvma082320; Fri, 18 Nov 2005 12:30:57 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAIHUvaa014813; Fri, 18 Nov 2005 12:30: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 jAIHUvj5014810; Fri, 18 Nov 2005 12:30:57 -0500 In-Reply-To: <437E0A0D.6070209@gmx.de> To: Julian Reschke Cc: Lisa Dusseault , webdav WG , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Fri, 18 Nov 2005 12:31:02 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/18/2005 12:30:56, Serialize complete at 11/18/2005 12:30:56 Content-Type: multipart/alternative; boundary="=_alternative 00603800852570BD_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EdA4g-0001hI-PJ 7bb6ddb323d5d5c774e795d407a70572 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/OFEDFAE74C.5426901F-ON852570BD.005FDB94-852570BD.0060386D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10396 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 17:31:04 +0000 This is a multipart message in MIME format. --=_alternative 00603800852570BD_= Content-Type: text/plain; charset="US-ASCII" >From a lock privacy perspective, putting all information about the newly created lock in the lockdiscovery response to a LOCK request is (of course) no problem, so requiring that is fine with me. Perhaps the new text could require that full information about a LOCK be returned in the lockdiscovery response to a LOCK, while information about other locks is optional in the lockdiscovery response to a LOCK. Cheers, Geoff Julian wrote on 11/18/2005 12:06:21 PM: > > Geoff, any input about how a server concerned with the privacy of lock > information would return the actual timeout value (as compared to the > one sent by the client)? --=_alternative 00603800852570BD_= Content-Type: text/html; charset="US-ASCII"
From a lock privacy perspective, putting all information about the
newly created lock in the lockdiscovery response to a LOCK
request is (of course) no problem, so requiring that is fine with me.

Perhaps the new text could require that full information about a LOCK
be returned in the lockdiscovery response to a LOCK, while information
about other locks is optional in the lockdiscovery response to a LOCK.

Cheers,
Geoff

Julian wrote on 11/18/2005 12:06:21 PM:
>
> Geoff, any input about how a server concerned with the privacy of lock
> information would return the actual timeout value (as compared to the
> one sent by the client)?
 --=_alternative 00603800852570BD_=-- From w3c-dist-auth-request@frink.w3.org Fri Nov 18 12:38:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdABs-0004yy-P1 for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 12:38:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01051 for ; Fri, 18 Nov 2005 12:37:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdABD-00068C-QI for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 17:37:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdABD-00067e-6o; Fri, 18 Nov 2005 17:37:43 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdAB5-0007ts-2d; Fri, 18 Nov 2005 17:37:42 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 57F8D14226C; Fri, 18 Nov 2005 09:37:32 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15746-07; Fri, 18 Nov 2005 09:37:32 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 689AF142260; Fri, 18 Nov 2005 09:37:31 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-31--590576695 Message-Id: <936d754fe084c6542e6ccabfcf928533@osafoundation.org> Cc: Julian Reschke , webdav WG , w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Fri, 18 Nov 2005 09:37:25 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EdAB5-0007ts-2d 4eaa37c1ba3e8e2c6ef3f02c2d8fce2b X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/936d754fe084c6542e6ccabfcf928533@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10397 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 17:37:43 +0000 --Apple-Mail-31--590576695 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit That works for me. If others agree I can try to write up text. Lisa On Nov 18, 2005, at 9:31 AM, Geoffrey M Clemm wrote: > > From a lock privacy perspective, putting all information about the > newly created lock in the lockdiscovery response to a LOCK > request is (of course) no problem, so requiring that is fine with me. > > Perhaps the new text could require that full information about a LOCK > be returned in the lockdiscovery response to a LOCK, while information > about other locks is optional in the lockdiscovery response to a LOCK. > > Cheers, > Geoff > > Julian wrote on 11/18/2005 12:06:21 PM: > > > > Geoff, any input about how a server concerned with the privacy of > lock > > information would return the actual timeout value (as compared to > the > > one sent by the client)? --Apple-Mail-31--590576695 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit That works for me. If others agree I can try to write up text. Lisa On Nov 18, 2005, at 9:31 AM, Geoffrey M Clemm wrote: From a lock privacy perspective, putting all information about the newly created lock in the lockdiscovery response to a LOCK request is (of course) no problem, so requiring that is fine with me. Perhaps the new text could require that full information about a LOCK be returned in the lockdiscovery response to a LOCK, while information about other locks is optional in the lockdiscovery response to a LOCK. Cheers, Geoff Julian wrote on 11/18/2005 12:06:21 PM: > > Geoff, any input about how a server concerned with the privacy of lock > information would return the actual timeout value (as compared to the > one sent by the client)? --Apple-Mail-31--590576695-- From w3c-dist-auth-request@frink.w3.org Fri Nov 18 13:25:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAvf-0003t3-OK for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 13:25:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03103 for ; Fri, 18 Nov 2005 13:25:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdAub-0004VF-Cy for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 18:24:37 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdAuX-0004Uc-1H for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 18:24:33 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdAuQ-0004Y6-I4 for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 18:24:32 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jAIIOJC6000927; Fri, 18 Nov 2005 10:24:19 -0800 (PST) Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay5.apple.com (Apple SCV relay) with ESMTP id 6415C324014; Fri, 18 Nov 2005 10:24:19 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Geoffrey M Clemm , Julian Reschke Content-Transfer-Encoding: 7bit From: Jim Luther Date: Fri, 18 Nov 2005 10:24:16 -0800 To: webdav X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of luther.j@apple.com designates 17.254.13.22 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdAuQ-0004Y6-I4 8a7f9853e4bd1aedd571e53f101773a0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/A41993B7-C55C-4F7C-893B-295BEAF65BB6@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10398 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 18:24:37 +0000 Content-Transfer-Encoding: 7bit Our existing code only uses LOCK to (1) get a new exclusive lock and (2) to refresh the exclusive locks we own. We parse the lockdiscovery response for a lock-token in both cases. I looked through the various versions of our code and I *think* that it wouldn't matter if the lockdiscovery response were not returned in the LOCK refresh response, but without a server to test against, I cannot be sure. So I agree with Geoff, but would add the requirement of returning the lockdiscovery response for a LOCK refresh because it would be useful for the same reasons you'd want the lockdiscovery response when a lock is created (to get the locktoken, timeout value, etc). This should not be a lock privacy problem because the client has proved it knows about the lock via the If header in the request. - Jim On Nov 18, 2005, at 9:31 AM, Geoffrey M Clemm wrote: > > From a lock privacy perspective, putting all information about the > newly created lock in the lockdiscovery response to a LOCK > request is (of course) no problem, so requiring that is fine with me. > > Perhaps the new text could require that full information about a LOCK > be returned in the lockdiscovery response to a LOCK, while information > about other locks is optional in the lockdiscovery response to a LOCK. > > Cheers, > Geoff > > Julian wrote on 11/18/2005 12:06:21 PM: > > > > Geoff, any input about how a server concerned with the privacy of > lock > > information would return the actual timeout value (as compared to > the > > one sent by the client)? From w3c-dist-auth-request@frink.w3.org Fri Nov 18 14:32:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdByF-0002dY-Qy for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 14:32:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06042 for ; Fri, 18 Nov 2005 14:31:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdBx7-0006M4-P2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 19:31:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdBx3-0006LW-7W for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 19:31:13 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdBx0-0002Ge-08 for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 19:31:12 +0000 Received: from [192.168.2.104] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jAIJV5dE018284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Nov 2005 11:31:05 -0800 (PST) Message-ID: <437E2BF9.40609@cse.ucsc.edu> Date: Fri, 18 Nov 2005 11:31:05 -0800 From: Elias Sinderson Reply-To: webdav WG User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG References: <936d754fe084c6542e6ccabfcf928533@osafoundation.org> In-Reply-To: <936d754fe084c6542e6ccabfcf928533@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (maggie.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EdBx0-0002Ge-08 a4ad924d65425e0f3abaa52d34f5d6a7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437E2BF9.40609@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10399 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 19:31:17 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > That works for me. If others agree I can try to write up text. +1, this looks like a very workable solution. Best, Elias From w3c-dist-auth-request@frink.w3.org Fri Nov 18 17:05:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEMn-0007Oq-ER for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 17:05:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13492 for ; Fri, 18 Nov 2005 17:05:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdEL9-0006LK-4I for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 22:04:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdEL4-0006KL-I7 for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 22:04:10 +0000 Received: from ithilien.qualcomm.com ([129.46.51.59]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdEL1-0000Jv-5P for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 22:04:10 +0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAIM42Nq015461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 Nov 2005 14:04:02 -0800 Received: from [24.23.128.66] (vpn-10-50-16-95.qualcomm.com [10.50.16.95]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAIM40JE010296 for ; Fri, 18 Nov 2005 14:04:01 -0800 (PST) Mime-Version: 1.0 Message-Id: Date: Fri, 18 Nov 2005 14:03:59 -0800 To: w3c-dist-auth@w3.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Received-SPF: none (maggie.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EdEL1-0000Jv-5P 959b7627e9c8973c5412e6fc5be3c781 X-Original-To: w3c-dist-auth@w3.org Subject: Timeline for completion X-Archived-At: http://www.w3.org/mid/p0623090cbfa3ffd5b231@%5B24.23.128.66%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10400 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 22:04:15 +0000 Howdy, Back in June, I asked Cullen to come in as Chair of WebDav and set out what I saw as the game plan for getting the WG to closure. As a reminder, here's one of the critical bits of that message: >The aim is to have the WG enter FIN_WAIT by January of 2006 by having all of its >documents at or through IETF Last Call prior to that point. We're getting very close to that time, and I want to reiterate that I see it as pretty close to a hard stop. I believe the working group should send 2518bis and any other documents it believes are done for IETF Last Call by Jan 1, 2006. If there are small pieces of wordsmithing still to be done, Cullen can extend that for a short period, but I believe that period will have to be very short and very focused. Stretching things past the end of January would require some serious convincing. In other words, this working group will close in six weeks, and we'll have to make the most of it. During the next six weeks, that means folks are going to have to be focused on getting the remaining issues resolved and the document complete. It also means folks will have to be willing to accept that some wording issues or personal preferences may have to be sacrificed to get the job done. The document as it stands improves on 2518 in some critical ways, and if the working group cannot complete it, that will leave the engineering community which needs the spec considerably worse off. The IESG will not consider an individual submission on this if the working group has just failed to come to consensus, and I hope everyone understands that. This is the opportunity to replace 2518 with something better, and we need to take advantage of it. regards, Ted Hardie From w3c-dist-auth-request@frink.w3.org Fri Nov 18 18:58:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdG7t-0007ra-86 for webdav-archive@megatron.ietf.org; Fri, 18 Nov 2005 18:58:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22955 for ; Fri, 18 Nov 2005 18:58:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdG6a-0002iP-8B for w3c-dist-auth-dist@listhub.w3.org; Fri, 18 Nov 2005 23:57:20 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdG6V-0002hp-PK for w3c-dist-auth@listhub.w3.org; Fri, 18 Nov 2005 23:57:15 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdG6R-0004t7-NV for w3c-dist-auth@w3.org; Fri, 18 Nov 2005 23:57:15 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jAINv9aQ016419 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 18 Nov 2005 15:57:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: webdav WG From: Jim Whitehead Date: Fri, 18 Nov 2005 15:57:27 -0800 X-Mailer: Apple Mail (2.746.2) Received-SPF: none (maggie.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: maggie.w3.org 1EdG6R-0004t7-NV a55988e413a8b6b928c254d99e6d1fc0 X-Original-To: w3c-dist-auth@w3.org Subject: Issues to address this coming week X-Archived-At: http://www.w3.org/mid/ED026702-664B-48E2-992C-53AC36254612@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10401 X-Loop: w3c-dist-auth@w3.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, 18 Nov 2005 23:57:20 +0000 Content-Transfer-Encoding: 7bit During the teleconference this past week, Elias and I volunteered to produce a list of issues that we should consider over the coming week, and resolve during next week's 3 hour teleconference. The intent is for the working group to discuss these issues on the mailing list as best we can until Wednesday, and then resolve remaining issues on the phone. Here is our proposed list of issues: trivial 8 - Section 9.1: extend production 39 - Syntax of property names in text content minor 11 - Protection against XML DOS attacks 15 - DAV:error description inconsistent with RFC3253 26 - URL syntax in PROPFIND 37 - Sentence lost in introduction 43 - "ill-formed" XML normal 10 - Round-tripping namespace decls in properties 45 - DAV request header 46 - URLs in multistatus 47 - 3xx in multistarus major 13 - new ETag requirements 16 - Trailing slash required in collection names? critical 27 - COPY vs live poperties 40 - Definition of "null resource" gone These issues were culled from the list of issues maintained in Bugzilla, at: http://ietf.cse.ucsc.edu:8080/bugzilla/query.cgi You can find individual issues by using the following URLs: http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=@@@put issue number here@@@ For example, the URL for issue 8 is: http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 - Jim From w3c-dist-auth-request@frink.w3.org Sat Nov 19 04:14:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdOnI-0007Za-CX for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:14:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16263 for ; Sat, 19 Nov 2005 04:13:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdOmj-0006Vk-Nr for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:13:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdOmj-0006VC-6X for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:13:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdOmX-0002ev-LW for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:13:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9DBta020260; Sat, 19 Nov 2005 01:13:11 -0800 Date: Sat, 19 Nov 2005 01:13:11 -0800 Message-Id: <200511190913.jAJ9DBta020260@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdOmX-0002ev-LW 9f1bffca1773b3a68c4330ce1027d708 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 7] Example for PROPFIND/allprop missing X-Archived-At: http://www.w3.org/mid/200511190913.jAJ9DBta020260@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10403 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:13:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=7 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 04:13:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdOmy-0007Tr-4w for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:13:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16250 for ; Sat, 19 Nov 2005 04:13:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdOl9-0006Hh-0d for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:11:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdOl4-0006H4-H3 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:11:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdOl2-0006ZY-Fe for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:11:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9BcU4020239; Sat, 19 Nov 2005 01:11:38 -0800 Date: Sat, 19 Nov 2005 01:11:38 -0800 Message-Id: <200511190911.jAJ9BcU4020239@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-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EdOl2-0006ZY-Fe f54498b642aebea945a2be6b80fbbfe9 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/200511190911.jAJ9BcU4020239@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10402 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:11:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=6 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:11 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 04:15:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdOoG-000851-Ov for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:15:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16308 for ; Sat, 19 Nov 2005 04:14:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdOnh-0006hn-T1 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:14:25 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdOnh-0006h9-Ad for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:14:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdOnX-0006s2-Hx for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:14:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9ECTK020272; Sat, 19 Nov 2005 01:14:12 -0800 Date: Sat, 19 Nov 2005 01:14:12 -0800 Message-Id: <200511190914.jAJ9ECTK020272@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdOnX-0006s2-Hx dbda50a24073e297e53b16125d588e78 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200511190914.jAJ9ECTK020272@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10404 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:14:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:14 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 04:20:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdOtu-0000yX-MY for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:20:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16562 for ; Sat, 19 Nov 2005 04:20:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdOtE-0001V1-H4 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:20:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdOtE-0001UR-0y for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:20:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdOtB-0003ty-5w for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:20:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9K467020286; Sat, 19 Nov 2005 01:20:04 -0800 Date: Sat, 19 Nov 2005 01:20:04 -0800 Message-Id: <200511190920.jAJ9K467020286@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdOtB-0003ty-5w c63e872fcee87a7580c6a3ac466590a4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/200511190920.jAJ9K467020286@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10405 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:20:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:20 ------- Draft 08 URL: Next text: -- Note that "DAV:" uses a scheme name defined solely for the purpose of creating this namespace. Defining new schemes for namespaces is discouraged. "DAV:" was defined before standard best practices emerged, and this namespace is still used only because of significant existing deployments. -- That's fine, although I think terminology can be used more precisely, such as: -- Note that "DAV:" uses an URI scheme defined solely for the purpose of creating this XML namespace. Defining new URI schemes for namespaces is discouraged. "DAV:" was defined before standard best practices emerged, and this XML namespace is still used only because of significant existing deployments. -- ------- 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@frink.w3.org Sat Nov 19 04:21:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdOuz-0001At-U2 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:21:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16645 for ; Sat, 19 Nov 2005 04:21:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdOuR-0001f0-4H for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:21:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdOuQ-0001eS-L9 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:21:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdOuO-00045b-0F for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:21:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9LJmR020298; Sat, 19 Nov 2005 01:21:19 -0800 Date: Sat, 19 Nov 2005 01:21:19 -0800 Message-Id: <200511190921.jAJ9LJmR020298@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdOuO-00045b-0F 698497aa97e4e5c91f4dc665ebea2f04 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/200511190921.jAJ9LJmR020298@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10406 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:21:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:21 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 04:22:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdOvR-0001JV-Nm for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:22:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16692 for ; Sat, 19 Nov 2005 04:21:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdOut-0001k9-9L for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:21:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdOus-0001jb-Ny for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:21:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdOur-0008Gi-8U for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:21:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9LmAb020306; Sat, 19 Nov 2005 01:21:48 -0800 Date: Sat, 19 Nov 2005 01:21:48 -0800 Message-Id: <200511190921.jAJ9LmAb020306@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-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EdOur-0008Gi-8U b222e3118b7e8f31a290d2b6fe830903 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/200511190921.jAJ9LmAb020306@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10407 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:21:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 04:33:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdP6G-0003jZ-6l for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:33:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17178 for ; Sat, 19 Nov 2005 04:32:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdP5a-0004V4-Ua for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:32:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdP5Y-0004UR-Le for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:32:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdP5V-0001b5-LK for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:32:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9Wn7G020322; Sat, 19 Nov 2005 01:32:49 -0800 Date: Sat, 19 Nov 2005 01:32:49 -0800 Message-Id: <200511190932.jAJ9Wn7G020322@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-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EdP5V-0001b5-LK c7d08f919358632083d6cbb9312698a0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511190932.jAJ9Wn7G020322@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10408 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:32:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:32 ------- The original section about the "Location" header was removed, which is good. It didn't make any sense. There's a new section that was silently added (): -- Use of the Location header with the Multi-Status response is intentionally undefined. -- Although this is technically, I'd prefer it not to be in. There are many things in RFC2616 for which the spec doesn't define anything particular, and this is not because the WG didn't want to, but because, in general, the definition in RFC2616 should be enough. I don't recall anybody *ever* asking for this; the recent discussion on the mailing list showed that the original trigger was an interop meeting where there was a discussion about the "Content-Location" header, which is a completely different thing. The next text goes on saying: -- Note that this specification does not define a way to redirect requests for individual resources within the scope of a Multi-Status response. The server MAY always redirect the entire request by responding with a 300 level status response instead of a Multi-Status response. -- Which means that the resolution for bug "MULTISTATUS_FOR_NON_DEPTH" from (marked "inbis" over there) has been removed, to which I object (I will open a new issue for this). ------- 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@frink.w3.org Sat Nov 19 04:42:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPEo-0005Tf-1u for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:42:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17393 for ; Sat, 19 Nov 2005 04:41:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPEA-0007YY-Qr for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:41:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPEA-0007Xz-EK for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:41:46 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1EdPEA-0003XX-4k for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:41:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdPE6-0003Tx-9k for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:41:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9fguW020363; Sat, 19 Nov 2005 01:41:42 -0800 Date: Sat, 19 Nov 2005 01:41:42 -0800 Message-Id: <200511190941.jAJ9fguW020363@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdPE6-0003Tx-9k e341a5321a13d52b4e4ca6b27be6f94a 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/200511190941.jAJ9fguW020363@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10409 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:41:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:41 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 04:47:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPKB-0006SH-5i for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:47:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17531 for ; Sat, 19 Nov 2005 04:47:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPJV-0000rv-Hr for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:47:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPJV-0000rM-5l for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:47:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdPJT-0004ZK-6l for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:47:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9lEvN020377; Sat, 19 Nov 2005 01:47:14 -0800 Date: Sat, 19 Nov 2005 01:47:14 -0800 Message-Id: <200511190947.jAJ9lEvN020377@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-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EdPJT-0004ZK-6l 5fb28376c8d4d165e0be9ab61ff1ead6 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/200511190947.jAJ9lEvN020377@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10410 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:47:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:47 ------- Draft 08 URL: summarizes the WG's opinion as of 2005-10-31: "* Create a new appendix in 2518bis * In this appendix, document the problem * Describe the known approaches for addressing the problem (If approach, 100-continue approach) and their issues * Create a separate draft focusing just on the Force-Authenticate approach, and discuss on HTTP-WG list." ------- 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@frink.w3.org Sat Nov 19 04:51:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPNF-0007Oe-SL for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:51:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17688 for ; Sat, 19 Nov 2005 04:50:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPMg-0001VW-OF for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:50:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPLj-0000y0-RG for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:49:35 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1EdPCh-0007YC-JP for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:40:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdPCd-0003Ep-Up for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:40:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9eB4S020351; Sat, 19 Nov 2005 01:40:11 -0800 Date: Sat, 19 Nov 2005 01:40:11 -0800 Message-Id: <200511190940.jAJ9eB4S020351@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdPCd-0003Ep-Up 37a473427215b04e7880c5630d966f12 Received-SPF: none (maggie.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/200511190940.jAJ9eB4S020351@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10411 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:50:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:40 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 04:51:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPNc-0007Qx-La for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:51:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17706 for ; Sat, 19 Nov 2005 04:50:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPN4-0001cH-JK for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:50:58 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdPN3-0001bb-R5 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:50:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdPMr-00058Z-US for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:50:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9ojnr020406; Sat, 19 Nov 2005 01:50:45 -0800 Date: Sat, 19 Nov 2005 01:50:45 -0800 Message-Id: <200511190950.jAJ9ojnr020406@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdPMr-00058Z-US afc52cb415e126b184e35cfd7a91637f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 22] attributes on properties X-Archived-At: http://www.w3.org/mid/200511190950.jAJ9ojnr020406@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10412 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:50:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=22 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:50 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 04:57:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPSu-00005A-6Z for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 04:57:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17902 for ; Sat, 19 Nov 2005 04:56:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPSH-0002Mq-Pq for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 09:56:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPSF-0002Lw-Oz for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:56:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdPSD-00067Z-Tk for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:56:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9uHAH020415; Sat, 19 Nov 2005 01:56:17 -0800 Date: Sat, 19 Nov 2005 01:56:17 -0800 Message-Id: <200511190956.jAJ9uHAH020415@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdPSD-00067Z-Tk 8c0743ea58ae7f7bed4ea944d5cdce65 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200511190956.jAJ9uHAH020415@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10413 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 09:56:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:56 ------- Draft 08 URL: Trying to summarize WG opinion (see thread ending in ): - define response marshalling for LOCK in exactly one place - in lock introduction, just refer to that place and do not make any additional statements - Servers MUST return Lock-Token response headers - Servers MUST return response, and that response MUST contain all information about the newly created lock (and MAY also contain information about other (shared) locks, so clients must use the lock token from the response header as pointer into the response) - Make sure all examples match ------- 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@frink.w3.org Sat Nov 19 05:02:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPXp-000128-VA for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:02:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18106 for ; Sat, 19 Nov 2005 05:01:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPXC-0004QL-3v for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:01:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPXA-0004Pg-21 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:01:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdPX6-0002q0-FN for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:01:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJA1J4u020438; Sat, 19 Nov 2005 02:01:19 -0800 Date: Sat, 19 Nov 2005 02:01:19 -0800 Message-Id: <200511191001.jAJA1J4u020438@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdPX6-0002q0-FN 8cc01938d8bcb10c2865e40e0ec8ec3e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/200511191001.jAJA1J4u020438@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10414 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:01:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=24 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:01 ------- Draft 08 URL: Now says: "When trying to lock a collection upon creation, clients may attempt to increase the likelihood of this by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation there's no guarantee this will work)." It's not clear to me what likelihood is going to be increased here :-) How about: "...the likelihood of race conditions by pipelining..." ------- 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@frink.w3.org Sat Nov 19 05:03:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPZX-0001LE-U6 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:03:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18235 for ; Sat, 19 Nov 2005 05:03:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPYz-0004Wr-Ra for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:03:17 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdPYz-0004WJ-21 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:03:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdPYX-0007KQ-Ld for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:03:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJA2nxC020451; Sat, 19 Nov 2005 02:02:49 -0800 Date: Sat, 19 Nov 2005 02:02:49 -0800 Message-Id: <200511191002.jAJA2nxC020451@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdPYX-0007KQ-Ld 283d197ee1d12b6d71567d89f348a9e7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200511191002.jAJA2nxC020451@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10415 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:03:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:02 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 05:05:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPbG-0001hX-Ii for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:05:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18332 for ; Sat, 19 Nov 2005 05:05:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPaX-0004is-SO for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:04:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPaX-0004iK-AF for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:04:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdPaU-0007XH-KF for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:04:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJA4nPX020462; Sat, 19 Nov 2005 02:04:49 -0800 Date: Sat, 19 Nov 2005 02:04:49 -0800 Message-Id: <200511191004.jAJA4nPX020462@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdPaU-0007XH-KF cc8e19da4adcbe0d8d58b4fca249647c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/200511191004.jAJA4nPX020462@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10416 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:04:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:04 ------- This text has gone in draft 08, will review new sections separately and raise issues when needed. ------- 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@frink.w3.org Sat Nov 19 05:06:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPbw-0001or-Rq for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:06:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18373 for ; Sat, 19 Nov 2005 05:05:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPbM-0005F4-NH for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:05:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPbM-0005EW-7p for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:05:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdPbJ-0003U3-HG for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:05:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJA5eV5020474; Sat, 19 Nov 2005 02:05:40 -0800 Date: Sat, 19 Nov 2005 02:05:40 -0800 Message-Id: <200511191005.jAJA5eV5020474@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdPbJ-0003U3-HG cd451c586b592a57587a676ab7546b82 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 27] COPY vs live properties X-Archived-At: http://www.w3.org/mid/200511191005.jAJA5eV5020474@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10417 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:05:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=27 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:05 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 05:10:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPfs-0002iz-W1 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:10:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18498 for ; Sat, 19 Nov 2005 05:09:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPfD-0005Tr-6l for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:09:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPfB-0005TE-C1 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:09:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdPf7-00046z-FA for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:09:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJA9aF1020487; Sat, 19 Nov 2005 02:09:36 -0800 Date: Sat, 19 Nov 2005 02:09:36 -0800 Message-Id: <200511191009.jAJA9aF1020487@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdPf7-00046z-FA 846dcf552922e3ab0e3da504ff0812cb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200511191009.jAJA9aF1020487@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10418 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:09:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:09 ------- Draft 08 URL: I'd also like to point out that putting in requiremens for getlastmodified upon MOVE is inherently incompatible with RFC2616 (because lastmodified may be used for caching, thus for a given URL it may never go back in time). ------- 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@frink.w3.org Sat Nov 19 05:12:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPhY-0002qB-MZ for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:12:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18542 for ; Sat, 19 Nov 2005 05:11:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPgy-00066P-J7 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:11:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdPLl-0000y0-Ud for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:49:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1EdP9k-00070r-Mc for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 09:37:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdP9f-0002hF-W4 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 09:37:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJ9b7ol020335; Sat, 19 Nov 2005 01:37:07 -0800 Date: Sat, 19 Nov 2005 01:37:07 -0800 Message-Id: <200511190937.jAJ9b7ol020335@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdP9f-0002hF-W4 e9f0b53e4cd0bbfe31d783d7142ce3bd Received-SPF: none (maggie.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/200511190937.jAJ9b7ol020335@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10419 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:11:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 01:37 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 05:12:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdPht-0002so-DL for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:12:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18571 for ; Sat, 19 Nov 2005 05:11:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdPhH-0006Cj-RH for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:11:51 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdPhH-0006C8-6p for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:11:51 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EdPhE-0000Qb-4q for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:11:50 +0000 Received: (qmail invoked by alias); 19 Nov 2005 10:11:44 -0000 Received: from p508FA2E5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.162.229] by mail.gmx.net (mp016) with SMTP; 19 Nov 2005 11:11:44 +0100 X-Authenticated: #1915285 Message-ID: <437EFA2F.6060506@gmx.de> Date: Sat, 19 Nov 2005 11:10:55 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jim Luther CC: webdav , Geoffrey M Clemm References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdPhE-0000Qb-4q 6798d1b96d4a0011cc4a6d874a41bee0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/437EFA2F.6060506@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10420 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:11:51 +0000 Content-Transfer-Encoding: 7bit Jim Luther wrote: > > Our existing code only uses LOCK to (1) get a new exclusive lock and (2) > to refresh the exclusive locks we own. We parse the lockdiscovery > response for a lock-token in both cases. I looked through the various > versions of our code and I *think* that it wouldn't matter if the > lockdiscovery response were not returned in the LOCK refresh response, > but without a server to test against, I cannot be sure. > > So I agree with Geoff, but would add the requirement of returning the > lockdiscovery response for a LOCK refresh because it would be useful for > the same reasons you'd want the lockdiscovery response when a lock is > created (to get the locktoken, timeout value, etc). This should not be a > lock privacy problem because the client has proved it knows about the > lock via the If header in the request. ...via the "Lock-Token" header in the request... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Nov 19 05:39:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQ82-0000cR-V9 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:39:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19967 for ; Sat, 19 Nov 2005 05:38:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQ6B-0003Ib-3A for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:37:35 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQ68-0003I3-S2 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:37:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQ64-00058h-JS for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:37:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAbR9F020524; Sat, 19 Nov 2005 02:37:27 -0800 Date: Sat, 19 Nov 2005 02:37:27 -0800 Message-Id: <200511191037.jAJAbR9F020524@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQ64-00058h-JS 60b1d71796113b37c1c0b9f13ade32dd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 30] incorrect XML in example X-Archived-At: http://www.w3.org/mid/200511191037.jAJAbR9F020524@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10421 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:37:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=30 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:37 ------- Draft 08 URL: Now uses urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4< /D:href> which doesn't parse. I recommend running all XML in the spec through a parser (rfc2629.xslt has support for that when running with MSXML). ------- 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@frink.w3.org Sat Nov 19 05:40:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQ90-0000rD-Eo for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:40:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20036 for ; Sat, 19 Nov 2005 05:39:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQ7W-0003OQ-Nr for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:38:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQ7V-0003Nl-NS for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:38:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQ7R-0001jJ-UL for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:38:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAcn1o020540; Sat, 19 Nov 2005 02:38:49 -0800 Date: Sat, 19 Nov 2005 02:38:49 -0800 Message-Id: <200511191038.jAJAcn1o020540@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQ7R-0001jJ-UL d993e01cd5a2ebdd6072b4257c5d8bcd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 32] DAV:displayname handling X-Archived-At: http://www.w3.org/mid/200511191038.jAJAcn1o020540@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10422 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:38:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=32 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:41:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQAO-0001I5-Vl for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:41:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20189 for ; Sat, 19 Nov 2005 05:41:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQ8w-0003z0-JL for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:40:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQ8w-0003yC-6r for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:40:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQ8k-0005KY-SP for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:40:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAeCHa020560; Sat, 19 Nov 2005 02:40:12 -0800 Date: Sat, 19 Nov 2005 02:40:12 -0800 Message-Id: <200511191040.jAJAeCHa020560@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQ8k-0005KY-SP 040bccc9df6286448212c71b136ef522 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 35] RFC2606 compliance X-Archived-At: http://www.w3.org/mid/200511191040.jAJAeCHa020560@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10423 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:40:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=35 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:43:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQBg-0001aa-VK for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:43:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20250 for ; Sat, 19 Nov 2005 05:42:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQAj-00048C-84 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:42:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQAi-00047Z-SD for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:42:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQAX-0005dv-BA for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:42:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAg58J020572; Sat, 19 Nov 2005 02:42:05 -0800 Date: Sat, 19 Nov 2005 02:42:05 -0800 Message-Id: <200511191042.jAJAg58J020572@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQAX-0005dv-BA 636ae4f7201c48613ee903b256076af9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200511191042.jAJAg58J020572@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10424 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:42:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:42 ------- Proposed resolution (see ): Section 1., para. 11: OLD: Finishing off the specification are sections on what it means for a resource to be compliant with this specification (Section 17), on internationalization support (Section 18), and on security (Section 19). NEW: 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 14 defines the properties used within the WebDAV specification. Finishing off the specification are sections on what it means for a resource to be compliant with this specification (Section 17), on internationalization support (Section 18), and on security (Section 19). ------- 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@frink.w3.org Sat Nov 19 05:44:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQCu-0001lU-JD for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:44:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20298 for ; Sat, 19 Nov 2005 05:43:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQCJ-0004GZ-IA for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:43:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQCJ-0004G0-6Z for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:43:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQCG-0005xW-S8 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:43:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAhqON020591; Sat, 19 Nov 2005 02:43:52 -0800 Date: Sat, 19 Nov 2005 02:43:52 -0800 Message-Id: <200511191043.jAJAhqON020591@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQCG-0005xW-S8 1c4efa53c896fddc08465a4df728f4e7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 38] RFC2396bis update X-Archived-At: http://www.w3.org/mid/200511191043.jAJAhqON020591@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10425 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:43:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=38 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:43 ------- I believe this can be closed with draft 08. Should there be problems because of the change, we should open new issues. ------- 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@frink.w3.org Sat Nov 19 05:46:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQES-000212-SY for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:46:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20357 for ; Sat, 19 Nov 2005 05:45:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQDr-0005nD-Il for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:45:31 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQDr-0005mc-09 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:45:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQDm-0006i1-JE for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:45:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAjQ33020607; Sat, 19 Nov 2005 02:45:26 -0800 Date: Sat, 19 Nov 2005 02:45:26 -0800 Message-Id: <200511191045.jAJAjQ33020607@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQDm-0006i1-JE 40468f24f015b99f45b7361224b711cf X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 40] Definition of "null resource" gone X-Archived-At: http://www.w3.org/mid/200511191045.jAJAjQ33020607@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10426 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:45:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=40 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:46:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQEp-000288-CC for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:46:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20378 for ; Sat, 19 Nov 2005 05:45:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQEG-0005sB-41 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:45:56 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQEF-0005rd-Eu for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:45:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQEB-0003D7-GF for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:45:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAjo1M020621; Sat, 19 Nov 2005 02:45:50 -0800 Date: Sat, 19 Nov 2005 02:45:50 -0800 Message-Id: <200511191045.jAJAjo1M020621@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQEB-0003D7-GF bd1574a465af3739e63d2c581f65699b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 41] Paragraph numbering/nesting broken in Section 13 X-Archived-At: http://www.w3.org/mid/200511191045.jAJAjo1M020621@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10427 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:45:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:47:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQFj-0002KU-Bg for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:47:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20414 for ; Sat, 19 Nov 2005 05:46:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQFB-0005zp-EU for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:46:53 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQFA-0005zC-SK for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:46:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQF7-00072X-Tc for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:46:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAknQ1020633; Sat, 19 Nov 2005 02:46:49 -0800 Date: Sat, 19 Nov 2005 02:46:49 -0800 Message-Id: <200511191046.jAJAknQ1020633@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQF7-00072X-Tc 6220f11f3aec0fdd24a0ff279dd5b4c4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 42] Consider deprecating text/xml for XML request/response bodies X-Archived-At: http://www.w3.org/mid/200511191046.jAJAknQ1020633@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10428 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:46:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=42 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:47:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQG9-0002Rb-Oc for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:47:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20445 for ; Sat, 19 Nov 2005 05:47:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQFb-00065R-Ql for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:47:19 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQFb-00064t-8d for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:47:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQFY-00078S-0H for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:47:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAlFOi020646; Sat, 19 Nov 2005 02:47:15 -0800 Date: Sat, 19 Nov 2005 02:47:15 -0800 Message-Id: <200511191047.jAJAlFOi020646@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQFY-00078S-0H b479d9295fce812c1abbe6b3191b9c42 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 43] "ill-formed" XML X-Archived-At: http://www.w3.org/mid/200511191047.jAJAlFOi020646@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10429 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:47:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=43 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:49:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQHH-0002bC-5R for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:49:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20507 for ; Sat, 19 Nov 2005 05:48:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQGf-0006F8-AS for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:48:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQGe-0006Ea-RN for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:48:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQGZ-0003lG-23 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:48:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAmIEP020659; Sat, 19 Nov 2005 02:48:18 -0800 Date: Sat, 19 Nov 2005 02:48:18 -0800 Message-Id: <200511191048.jAJAmIEP020659@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQGZ-0003lG-23 2a0406f478a05a436f568395c99be014 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] OPTIONS * X-Archived-At: http://www.w3.org/mid/200511191048.jAJAmIEP020659@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10430 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:48:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:48 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 05:50:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQIL-000306-0p for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:50:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20587 for ; Sat, 19 Nov 2005 05:49:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQHh-0006NO-EN for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:49:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQHg-0006Mg-SF for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:49:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQHe-0007js-4V for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:49:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAnPG5020671; Sat, 19 Nov 2005 02:49:25 -0800 Date: Sat, 19 Nov 2005 02:49:25 -0800 Message-Id: <200511191049.jAJAnPG5020671@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQHe-0007js-4V 43a8c6292fd9dad92e83be4699b7ab4b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 45] DAV request header X-Archived-At: http://www.w3.org/mid/200511191049.jAJAnPG5020671@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10431 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:49:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=45 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:51:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQJo-0003FR-7V for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:51:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20677 for ; Sat, 19 Nov 2005 05:51:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQJF-0006s7-Rj for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:51:05 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQJF-0006rU-0e for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:51:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQJC-000883-4X for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:51:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAp1lY020685; Sat, 19 Nov 2005 02:51:01 -0800 Date: Sat, 19 Nov 2005 02:51:01 -0800 Message-Id: <200511191051.jAJAp1lY020685@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQJC-000883-4X 656c34871c0cb1018f9d6ea0826e834c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200511191051.jAJAp1lY020685@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10432 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:51:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:51 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 05:53:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQLV-0003pJ-P4 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:53:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20763 for ; Sat, 19 Nov 2005 05:52:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQKx-0006yy-18 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:52:51 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQKw-0006yO-Ey for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:52:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQKq-0008Tn-IA for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:52:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAqiqn020700; Sat, 19 Nov 2005 02:52:44 -0800 Date: Sat, 19 Nov 2005 02:52:44 -0800 Message-Id: <200511191052.jAJAqiqn020700@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQKq-0008Tn-IA 647b369b0bc1b45840fff2fdbc06ef39 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200511191052.jAJAqiqn020700@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10433 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:52:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:52 ------- This section was removed in draft 08, undoing a prior issue resolution. It needs to be re-added, and the original issue with the text that was in draft 07 still needs to be resolved. ------- 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@frink.w3.org Sat Nov 19 05:54:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQM4-0003uZ-DE for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:54:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20788 for ; Sat, 19 Nov 2005 05:53:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQLT-00076T-I9 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:53:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQLT-00075q-3N for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:53:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQLQ-0004ws-CU for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:53:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJArGxx020714; Sat, 19 Nov 2005 02:53:16 -0800 Date: Sat, 19 Nov 2005 02:53:16 -0800 Message-Id: <200511191053.jAJArGxx020714@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQLQ-0004ws-CU 038f474955ebb04bc3d19bfe96b60d6b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200511191053.jAJArGxx020714@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10434 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:53:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:55:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQNh-00046b-BJ for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:55:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20867 for ; Sat, 19 Nov 2005 05:55:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQN6-0007hS-Cs for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:55:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQN6-0007gW-0E for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:55:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQN3-00084Y-Bl for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:55:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAt1vS020726; Sat, 19 Nov 2005 02:55:01 -0800 Date: Sat, 19 Nov 2005 02:55:01 -0800 Message-Id: <200511191055.jAJAt1vS020726@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQN3-00084Y-Bl d51296715f1195af00c4b9eb081a110e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 49] propfind XML description incorrect X-Archived-At: http://www.w3.org/mid/200511191055.jAJAt1vS020726@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10435 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:55:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=49 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:55 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 05:57:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQPS-0004hs-Lq for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:57:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20960 for ; Sat, 19 Nov 2005 05:56:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQOs-0007ry-3W for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:56:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQOr-0007rK-HP for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:56:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQOn-0001Di-Jd for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:56:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAunnI020740; Sat, 19 Nov 2005 02:56:49 -0800 Date: Sat, 19 Nov 2005 02:56:49 -0800 Message-Id: <200511191056.jAJAunnI020740@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQOn-0001Di-Jd 432989b7e14b8146197500fd23f3d48d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200511191056.jAJAunnI020740@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10436 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:56:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:56 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 05:57:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQPr-0004jN-Vi for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:57:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20973 for ; Sat, 19 Nov 2005 05:57:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQPK-0007xo-A1 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:57:22 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQPJ-0007wz-R0 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:57:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQPF-0005uC-EE for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:57:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAvDbv020755; Sat, 19 Nov 2005 02:57:13 -0800 Date: Sat, 19 Nov 2005 02:57:13 -0800 Message-Id: <200511191057.jAJAvDbv020755@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQPF-0005uC-EE fb568370e467589f651a2f2da4917750 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 51] Property behaviour upon COPY vs "remote COPY" X-Archived-At: http://www.w3.org/mid/200511191057.jAJAvDbv020755@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10437 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:57:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=51 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:58:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQQQ-0004pE-Is for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:58:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21007 for ; Sat, 19 Nov 2005 05:57:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQPs-000866-GU for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:57:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQPr-00085S-U1 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:57:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQPq-00008r-CD for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:57:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAvsoJ020769; Sat, 19 Nov 2005 02:57:54 -0800 Date: Sat, 19 Nov 2005 02:57:54 -0800 Message-Id: <200511191057.jAJAvsoJ020769@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQPq-00008r-CD 4ddd51cf84a95b39a0676d1526ec07e8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 52] "mandatory" properties X-Archived-At: http://www.w3.org/mid/200511191057.jAJAvsoJ020769@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10438 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:57:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=52 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 05:59:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQRO-00050r-4c for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 05:59:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21046 for ; Sat, 19 Nov 2005 05:58:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQQp-0008G8-1z for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:58:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQQo-0008Fa-GE for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:58:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQQm-0000K4-OJ for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:58:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAwqML020783; Sat, 19 Nov 2005 02:58:52 -0800 Date: Sat, 19 Nov 2005 02:58:52 -0800 Message-Id: <200511191058.jAJAwqML020783@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQQm-0000K4-OJ 9f01cf45c6d05ef6525b0c21780760a0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200511191058.jAJAwqML020783@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10439 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:58:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:00:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQSK-0005A4-8m for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:00:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21101 for ; Sat, 19 Nov 2005 05:59:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQRl-0008Mt-FC for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 10:59:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQRk-0008ML-TB for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 10:59:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQRi-0000UG-W8 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 10:59:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJAxo4p020797; Sat, 19 Nov 2005 02:59:50 -0800 Date: Sat, 19 Nov 2005 02:59:50 -0800 Message-Id: <200511191059.jAJAxo4p020797@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQRi-0000UG-W8 0fce4f337344cc066dafa9445310784b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200511191059.jAJAxo4p020797@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10440 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 10:59:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 02:59 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:02:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQUC-0005ca-Jq for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:02:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21210 for ; Sat, 19 Nov 2005 06:01:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQTY-0001Vs-QZ for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:01:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQTY-0001VJ-Ac for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:01:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQTV-00070V-0m for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:01:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJB1X6S020821; Sat, 19 Nov 2005 03:01:33 -0800 Date: Sat, 19 Nov 2005 03:01:33 -0800 Message-Id: <200511191101.jAJB1X6S020821@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQTV-00070V-0m 75e3ec92aa491e1bdc31f9ec4a1aa2cf X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 55] Multistatus format (empty) X-Archived-At: http://www.w3.org/mid/200511191101.jAJB1X6S020821@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10441 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:01:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=55 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:01 ------- (spec has been rewritten here; issue can be closed) ------- 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@frink.w3.org Sat Nov 19 06:02:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQUk-0005gT-HG for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:02:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21225 for ; Sat, 19 Nov 2005 06:02:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQUC-0001cV-PW for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:02:24 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQUC-0001bs-6j for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:02:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQU9-0002lO-DC for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:02:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJB2LK2020836; Sat, 19 Nov 2005 03:02:21 -0800 Date: Sat, 19 Nov 2005 03:02:21 -0800 Message-Id: <200511191102.jAJB2LK2020836@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQU9-0002lO-DC d5df90b7b0b752fb274c15be4d26e814 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 56] 423 Locked in Multistatus for PROPPATCH? X-Archived-At: http://www.w3.org/mid/200511191102.jAJB2LK2020836@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10442 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:02:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=56 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:02 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:05:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQWz-0006Ft-PV for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:05:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21368 for ; Sat, 19 Nov 2005 06:04:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQWR-0001mQ-SJ for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:04:43 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQWR-0001ls-3Y for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:04:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQWN-0003FF-QP for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:04:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJB4dDl020850; Sat, 19 Nov 2005 03:04:39 -0800 Date: Sat, 19 Nov 2005 03:04:39 -0800 Message-Id: <200511191104.jAJB4dDl020850@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQWN-0003FF-QP 6e25bfdd1a51878d04bceab5efe59d1a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 57] incorrect section reference X-Archived-At: http://www.w3.org/mid/200511191104.jAJB4dDl020850@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10443 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:04:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=57 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:04 ------- Draft 08 URL: (also note there's missing whitespace after 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@frink.w3.org Sat Nov 19 06:05:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQXY-0006PQ-ID for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:05:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21395 for ; Sat, 19 Nov 2005 06:05:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQX0-0002Ex-Ll for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:05:18 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQWz-0002E4-Sk for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:05:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQWw-0003Lt-So for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:05:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJB5Eso020864; Sat, 19 Nov 2005 03:05:14 -0800 Date: Sat, 19 Nov 2005 03:05:14 -0800 Message-Id: <200511191105.jAJB5Eso020864@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQWw-0003Lt-So ce306046cd6a7b616abf772d2473b560 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 58] MOVE status 403 description X-Archived-At: http://www.w3.org/mid/200511191105.jAJB5Eso020864@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10444 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:05:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=58 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:05 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:07:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQYj-0006kI-I7 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:07:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21478 for ; Sat, 19 Nov 2005 06:06:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQYB-0002NF-DC for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:06:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQY7-0002MT-My for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:06:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQY4-0001r3-H0 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:06:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJB6N7E020880; Sat, 19 Nov 2005 03:06:23 -0800 Date: Sat, 19 Nov 2005 03:06:23 -0800 Message-Id: <200511191106.jAJB6N7E020880@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQY4-0001r3-H0 efff369cfb6aff8d7a60206c48ce8a19 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 59] failed LOCK response body X-Archived-At: http://www.w3.org/mid/200511191106.jAJB6N7E020880@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10445 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:06:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=59 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:06 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:07:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQZY-0006yg-11 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:07:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21499 for ; Sat, 19 Nov 2005 06:07:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQYw-0002Ts-9N for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:07:18 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQYv-0002TI-NA for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:07:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQYs-0003hZ-Ty for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:07:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJB7E9m020895; Sat, 19 Nov 2005 03:07:14 -0800 Date: Sat, 19 Nov 2005 03:07:14 -0800 Message-Id: <200511191107.jAJB7E9m020895@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQYs-0003hZ-Ty 7a691b8e24b7680fe3148cdff88410c6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 60] If header evaluation when? X-Archived-At: http://www.w3.org/mid/200511191107.jAJB7E9m020895@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10446 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:07:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=60 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:07 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:11:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQdD-0007cj-Ht for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:11:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21718 for ; Sat, 19 Nov 2005 06:11:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQcV-0003Hw-Ry for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:10:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQcU-0003HO-3S for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:10:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQcQ-00008P-1d for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:10:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBAqNl020911; Sat, 19 Nov 2005 03:10:52 -0800 Date: Sat, 19 Nov 2005 03:10:52 -0800 Message-Id: <200511191110.jAJBAqNl020911@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQcQ-00008P-1d 702a23917f5298758bed173786225431 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] href format X-Archived-At: http://www.w3.org/mid/200511191110.jAJBAqNl020911@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10447 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:10:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:10 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:12:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQdd-0007rI-Fh for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:12:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21735 for ; Sat, 19 Nov 2005 06:11:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQd3-0003Ov-O8 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:11:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQd3-0003OI-8V for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:11:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQd0-0000FQ-34 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:11:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBBRbC020925; Sat, 19 Nov 2005 03:11:27 -0800 Date: Sat, 19 Nov 2005 03:11:27 -0800 Message-Id: <200511191111.jAJBBRbC020925@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQd0-0000FQ-34 e13b20420959615ed44cacfc03c63a8f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 63] typo in 13.16 "name" line X-Archived-At: http://www.w3.org/mid/200511191111.jAJBBRbC020925@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10448 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:11:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=63 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:11 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:12:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQeH-0007xe-7K for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:12:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21753 for ; Sat, 19 Nov 2005 06:12:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQde-0003VE-Ds for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:12:10 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQdd-0003Ug-Jw for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:12:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQdY-0004ZA-Sh for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:12:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBC4Ve020943; Sat, 19 Nov 2005 03:12:04 -0800 Date: Sat, 19 Nov 2005 03:12:04 -0800 Message-Id: <200511191112.jAJBC4Ve020943@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQdY-0004ZA-Sh 93fea91f11a79c6ac43eb7f53841c1a3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 66] references style X-Archived-At: http://www.w3.org/mid/200511191112.jAJBC4Ve020943@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10449 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:12:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=66 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:14:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQfp-0008Kv-PV for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:14:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21818 for ; Sat, 19 Nov 2005 06:13:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQfB-0003eB-2b for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:13:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQfA-0003dc-Iq for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:13:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQf4-0000e6-LB for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:13:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBDbCD020958; Sat, 19 Nov 2005 03:13:37 -0800 Date: Sat, 19 Nov 2005 03:13:37 -0800 Message-Id: <200511191113.jAJBDbCD020958@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQf4-0000e6-LB d37522497732e55adcb98f432e9692dd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 67] non-ASCII characters X-Archived-At: http://www.w3.org/mid/200511191113.jAJBDbCD020958@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10450 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:13:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=67 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:13 ------- Seems to be fixed (see ) ------- 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@frink.w3.org Sat Nov 19 06:15:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQh7-0000AX-Vo for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:15:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21961 for ; Sat, 19 Nov 2005 06:15:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQgU-0004du-2P for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:15:06 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQgT-0004VX-4M for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:15:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQgN-00051n-7n for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:15:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBEwGp020972; Sat, 19 Nov 2005 03:14:58 -0800 Date: Sat, 19 Nov 2005 03:14:58 -0800 Message-Id: <200511191114.jAJBEwGp020972@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQgN-00051n-7n 33793b9ad84f578e903f8e4a3ec393b4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 68] Reference to XML spec X-Archived-At: http://www.w3.org/mid/200511191114.jAJBEwGp020972@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10451 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:15:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=68 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:14 ------- Proposed fix: Use: Extensible Markup Language (XML) 1.0 (Third Edition) Textuality and Netscape
tbray@textuality.com
Microsoft
jeanpa@microsoft.com
University of Illinois at Chicago and Text Encoding Initiative
cmsmcq@uic.edu
Sun Microsystems
eve.maler@east.sun.com
francois@yergeau.com
------- 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@frink.w3.org Sat Nov 19 06:16:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQi3-0000K1-Ir for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:16:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22021 for ; Sat, 19 Nov 2005 06:16:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQhU-0005jJ-Jv for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:16:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQhT-0005if-QM for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:16:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQhQ-000138-Jq for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:16:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBG3KM020992; Sat, 19 Nov 2005 03:16:03 -0800 Date: Sat, 19 Nov 2005 03:16:03 -0800 Message-Id: <200511191116.jAJBG3KM020992@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQhQ-000138-Jq bedb5e7d3ebc5b36e05b2091e4bf0fee X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 72] Review references section X-Archived-At: http://www.w3.org/mid/200511191116.jAJBG3KM020992@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10452 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:16:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=72 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:18:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQjq-0000XY-JY for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:18:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22072 for ; Sat, 19 Nov 2005 06:17:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQjH-0005s4-7A for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:17:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQjG-0005rW-Ny for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:17:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQjE-0001Mj-45 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:17:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBHtBJ021009; Sat, 19 Nov 2005 03:17:55 -0800 Date: Sat, 19 Nov 2005 03:17:55 -0800 Message-Id: <200511191117.jAJBHtBJ021009@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQjE-0001Mj-45 7ebfd190f5be4b1f6f1125b090a68574 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200511191117.jAJBHtBJ021009@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10453 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:17:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:17 ------- A Changes section was added, which is good. 1) I don't think it is complete, this issue should be used to collect missing entries; 2) I think it's a bad idea to combine "what has changed since RFC2518" (which is an essential part of the new spec) and "what changed between different revisions" (which should be removed before publication) in the same section. ------- 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@frink.w3.org Sat Nov 19 06:19:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQkZ-0000fG-7W for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:19:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22111 for ; Sat, 19 Nov 2005 06:18:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQk0-0005z3-Kd for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:18:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQk0-0005yQ-1K for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:18:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQjy-0004Qg-EZ for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:18:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBIfjp021025; Sat, 19 Nov 2005 03:18:41 -0800 Date: Sat, 19 Nov 2005 03:18:41 -0800 Message-Id: <200511191118.jAJBIfjp021025@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQjy-0004Qg-EZ c018803d2fe2b753e0861669d46c9dc7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 79] PUT for collections rationale X-Archived-At: http://www.w3.org/mid/200511191118.jAJBIfjp021025@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10454 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:18:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=79 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:18 ------- Dtaft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:19:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQkm-0000hA-2Q for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:19:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22128 for ; Sat, 19 Nov 2005 06:18:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQkC-00063z-4R for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:18:56 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQkB-00063R-HX for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:18:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQk8-0005ih-PM for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:18:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBIqel021039; Sat, 19 Nov 2005 03:18:52 -0800 Date: Sat, 19 Nov 2005 03:18:52 -0800 Message-Id: <200511191118.jAJBIqel021039@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQk8-0005ih-PM 1ceb5b8ceee1635e16f22fcf865b061f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 80] Specify idempotence and safeness for all new methods X-Archived-At: http://www.w3.org/mid/200511191118.jAJBIqel021039@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10455 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:18:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:19:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQl4-0000wY-5p for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:19:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22147 for ; Sat, 19 Nov 2005 06:19:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQkV-0006AF-JC for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:19:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQkV-00069C-40 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:19:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQkS-0001Z6-48 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:19:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBJBjl021053; Sat, 19 Nov 2005 03:19:11 -0800 Date: Sat, 19 Nov 2005 03:19:11 -0800 Message-Id: <200511191119.jAJBJBjl021053@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQkS-0001Z6-48 65cd75a81ff48529153942c1b0c95d32 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200511191119.jAJBJBjl021053@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10456 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:19:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:19:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQlC-00011M-6S for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:19:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22149 for ; Sat, 19 Nov 2005 06:19:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQke-0006FU-QZ for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:19:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQke-0006Ev-Dz for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:19:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQkc-0004YC-Rv for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:19:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBJMrw021067; Sat, 19 Nov 2005 03:19:22 -0800 Date: Sat, 19 Nov 2005 03:19:22 -0800 Message-Id: <200511191119.jAJBJMrw021067@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQkc-0004YC-Rv 25d31fac9cce359d2989b2f6834f8623 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 86] DAV header definitions should use RFC3864 templates X-Archived-At: http://www.w3.org/mid/200511191119.jAJBJMrw021067@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10457 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:19:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=86 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:20:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQlT-00018g-Q6 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:20:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22158 for ; Sat, 19 Nov 2005 06:19:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQkv-0006LA-MH for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:19:41 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQku-0006KR-Ta for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:19:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQks-0005r8-2E for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:19:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBJbrt021081; Sat, 19 Nov 2005 03:19:37 -0800 Date: Sat, 19 Nov 2005 03:19:37 -0800 Message-Id: <200511191119.jAJBJbrt021081@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQks-0005r8-2E 7b34c06422584c6797a5975c4f8b28e1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 87] broken XML source of spec X-Archived-At: http://www.w3.org/mid/200511191119.jAJBJbrt021081@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10458 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:19:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=87 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:20:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQm5-0001CA-F1 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:20:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22173 for ; Sat, 19 Nov 2005 06:20:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQlV-0006ta-Nf for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:20:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQlV-0006sy-80 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:20:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdQlQ-0001m3-G8 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:20:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBKBH3021093; Sat, 19 Nov 2005 03:20:11 -0800 Date: Sat, 19 Nov 2005 03:20:11 -0800 Message-Id: <200511191120.jAJBKBH3021093@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdQlQ-0001m3-G8 017c7ebac035001d26e24774fcbf4a36 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 88] typo in list X-Archived-At: http://www.w3.org/mid/200511191120.jAJBKBH3021093@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10459 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:20:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=88 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:20 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:22:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQnL-0001MS-CA for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:22:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22244 for ; Sat, 19 Nov 2005 06:21:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQml-00072v-5L for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:21:35 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQmk-00072N-J8 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:21:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQmb-0006BK-Ft for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:21:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBLOki021107; Sat, 19 Nov 2005 03:21:24 -0800 Date: Sat, 19 Nov 2005 03:21:24 -0800 Message-Id: <200511191121.jAJBLOki021107@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQmb-0006BK-Ft be2b3fc0bfb5d5969d15642d8a0e5ac5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 89] whitespace introduced into hyphenated words X-Archived-At: http://www.w3.org/mid/200511191121.jAJBLOki021107@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10460 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:21:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=89 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:21 ------- For instance in , but potentially in other places as well. ------- 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@frink.w3.org Sat Nov 19 06:22:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQnp-0001Xt-SS for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:22:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22306 for ; Sat, 19 Nov 2005 06:22:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQnH-00079j-GE for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:22:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQnH-000794-3b for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:22:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQnA-00050N-Kd for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:22:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBM0OG021121; Sat, 19 Nov 2005 03:22:00 -0800 Date: Sat, 19 Nov 2005 03:22:00 -0800 Message-Id: <200511191122.jAJBM0OG021121@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQnA-00050N-Kd 0badf42d64b18358f4e92b91c100e33d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 90] broken RFC2277 reference X-Archived-At: http://www.w3.org/mid/200511191122.jAJBM0OG021121@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10461 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:22:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=90 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:25:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQqB-000254-ED for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:25:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22386 for ; Sat, 19 Nov 2005 06:24:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQpZ-0007QG-51 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:24:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQpX-0007PY-Ll for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:24:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQpW-0005QN-4G for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:24:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBOPe1021137; Sat, 19 Nov 2005 03:24:25 -0800 Date: Sat, 19 Nov 2005 03:24:25 -0800 Message-Id: <200511191124.jAJBOPe1021137@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQpW-0005QN-4G 3f6e052297b080f472d0cfaa14b8bd6e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 91] chapter name for lock token uri schemes X-Archived-At: http://www.w3.org/mid/200511191124.jAJBOPe1021137@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10462 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:24:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=91 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:24 ------- Section rewritten in 08, issue can be closed. ------- 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@frink.w3.org Sat Nov 19 06:26:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQrK-00029d-Tw for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:26:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22411 for ; Sat, 19 Nov 2005 06:25:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQqm-0007yE-CQ for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:25:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQql-0007xg-Mk for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:25:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQqk-0005d4-3u for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:25:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBPfw0021151; Sat, 19 Nov 2005 03:25:41 -0800 Date: Sat, 19 Nov 2005 03:25:41 -0800 Message-Id: <200511191125.jAJBPfw0021151@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQqk-0005d4-3u 0ebfd3de8502dffa47a76c66e96337ff X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 92] lock owner description X-Archived-At: http://www.w3.org/mid/200511191125.jAJBPfw0021151@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10463 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:25:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=92 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:25 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:27:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQsn-0002ea-0E for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:27:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22447 for ; Sat, 19 Nov 2005 06:27:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQsD-000873-Lv for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:27:13 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQsC-00086O-DZ for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:27:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQs7-0007AB-CS for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:27:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBR6pB021165; Sat, 19 Nov 2005 03:27:06 -0800 Date: Sat, 19 Nov 2005 03:27:06 -0800 Message-Id: <200511191127.jAJBR6pB021165@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQs7-0007AB-CS 82e3fd9e64e719c7f45dde07beea0678 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 93] Write Locks and Collections vs MOVE X-Archived-At: http://www.w3.org/mid/200511191127.jAJBR6pB021165@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10464 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:27:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=93 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:27 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:28:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQtd-0002sz-BB for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:28:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22481 for ; Sat, 19 Nov 2005 06:28:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQt5-0008IM-GZ for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:28:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQt4-0008Ho-UQ for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:28:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQt1-0007KE-Fs for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:28:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBS3bu021180; Sat, 19 Nov 2005 03:28:03 -0800 Date: Sat, 19 Nov 2005 03:28:03 -0800 Message-Id: <200511191128.jAJBS3bu021180@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQt1-0007KE-Fs 2003dd13fcefc38b7ea945d72956265f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 94] COPY and the Overwrite Header vs X-Archived-At: http://www.w3.org/mid/200511191128.jAJBS3bu021180@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10465 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:28:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=94 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|COPY and the Overwrite |COPY and the Overwrite |Header vs |Header vs Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:28 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:29:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQuT-00034G-7D for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:29:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22510 for ; Sat, 19 Nov 2005 06:28:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQtu-0008Pu-Ho for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:28:58 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQtt-0008PM-VN for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:28:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQtn-0007SN-PM for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:28:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBSo3s021194; Sat, 19 Nov 2005 03:28:50 -0800 Date: Sat, 19 Nov 2005 03:28:50 -0800 Message-Id: <200511191128.jAJBSo3s021194@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQtn-0007SN-PM 5103ac55c770605bcbb71aefcacc0759 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 95] possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200511191128.jAJBSo3s021194@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10466 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:28:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:28 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:30:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQvO-0003Nn-BV for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:30:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22557 for ; Sat, 19 Nov 2005 06:29:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQun-0000GG-7x for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:29:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQum-0000Fi-Rk for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:29:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQul-0006Mr-C3 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:29:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBToBm021208; Sat, 19 Nov 2005 03:29:50 -0800 Date: Sat, 19 Nov 2005 03:29:50 -0800 Message-Id: <200511191129.jAJBToBm021208@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQul-0006Mr-C3 0a9866a187f6e7cbeec853d9df3fbec2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200511191129.jAJBToBm021208@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10467 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:29:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:29 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:34:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdQzX-00047a-VL for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:34:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22718 for ; Sat, 19 Nov 2005 06:34:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQyx-00028L-BK for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:34:11 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdQyw-00027h-Mf for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:34:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdQyt-0008O3-CJ for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:34:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBY7co021223; Sat, 19 Nov 2005 03:34:07 -0800 Date: Sat, 19 Nov 2005 03:34:07 -0800 Message-Id: <200511191134.jAJBY7co021223@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdQyt-0008O3-CJ 3c1606f31abbc12258a20c48899e75df X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 97] new error code descriptions X-Archived-At: http://www.w3.org/mid/200511191134.jAJBY7co021223@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10468 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:34:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=97 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:34 ------- Draft 08 URL: Additional remark, now says in : "...If the request contains a conditional header, and if that condition fails to hold, then this error code MUST be returned unless some other error is returned..." OK, so if conditions fail, the server MUST return this status, unless it returns a different status???? That's a very long way to say nothing at all. ------- 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@frink.w3.org Sat Nov 19 06:35:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR0E-0004Iy-4R for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:35:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22788 for ; Sat, 19 Nov 2005 06:34:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdQzd-0002F6-JV for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:34:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdQzd-0002E3-7D for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:34:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdQzR-0007At-Sf for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:34:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBYfVQ021237; Sat, 19 Nov 2005 03:34:41 -0800 Date: Sat, 19 Nov 2005 03:34:41 -0800 Message-Id: <200511191134.jAJBYfVQ021237@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdQzR-0007At-Sf ff4c9f9aad75f64a3af51a61444219d6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 98] new error code descriptions, continued X-Archived-At: http://www.w3.org/mid/200511191134.jAJBYfVQ021237@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10469 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:34:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=98 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:34 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:36:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR16-0004hH-P3 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:36:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22863 for ; Sat, 19 Nov 2005 06:35:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR0W-0002iG-2D for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:35:48 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdR0V-0002hi-Fb for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:35:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdR0R-0000Fw-0R for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:35:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBZgrD021251; Sat, 19 Nov 2005 03:35:42 -0800 Date: Sat, 19 Nov 2005 03:35:42 -0800 Message-Id: <200511191135.jAJBZgrD021251@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdR0R-0000Fw-0R 5a6be3ba86cf3afad18730cf46a4fa60 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 99] Risks Connected with Lock Tokens X-Archived-At: http://www.w3.org/mid/200511191135.jAJBZgrD021251@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10470 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:35:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=99 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:37:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR1u-0004nN-IW for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:37:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22894 for ; Sat, 19 Nov 2005 06:36:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR1M-0002tj-4U for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:36:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdR1L-0002tA-IE for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:36:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdR1G-0000Qx-VC for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:36:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBaYR7021265; Sat, 19 Nov 2005 03:36:34 -0800 Date: Sat, 19 Nov 2005 03:36:34 -0800 Message-Id: <200511191136.jAJBaYR7021265@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdR1G-0000Qx-VC 94fe03fe993c9c99fb352f56bc6bfb6d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 100] "Notes on HTTP Client Compatibility" useful? X-Archived-At: http://www.w3.org/mid/200511191136.jAJBaYR7021265@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10471 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:36:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=100 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:38:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR2r-00057W-R1 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:38:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22934 for ; Sat, 19 Nov 2005 06:37:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR2H-00032i-9m for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:37:37 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdR2G-000325-K8 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:37:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdR2C-0000bs-8g for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:37:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBbWFt021280; Sat, 19 Nov 2005 03:37:32 -0800 Date: Sat, 19 Nov 2005 03:37:32 -0800 Message-Id: <200511191137.jAJBbWFt021280@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdR2C-0000bs-8g b023ae73f24d01f15b1b92e57409bcb1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 101] Extensibility for dav:owner X-Archived-At: http://www.w3.org/mid/200511191137.jAJBbWFt021280@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10472 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:37:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=101 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:37 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:39:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR4H-0005FU-EB for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:39:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22986 for ; Sat, 19 Nov 2005 06:39:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR3W-0003F6-Oa for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:38:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdR3W-0003EY-5X for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:38:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdR3S-0000pd-U5 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:38:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBcoY7021294; Sat, 19 Nov 2005 03:38:50 -0800 Date: Sat, 19 Nov 2005 03:38:50 -0800 Message-Id: <200511191138.jAJBcoY7021294@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdR3S-0000pd-U5 e64f1e68a483aa2cca8305e6e282730a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 102] lock tokens in examples X-Archived-At: http://www.w3.org/mid/200511191138.jAJBcoY7021294@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10473 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:38:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=102 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:38 ------- Still occurs in ------- 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@frink.w3.org Sat Nov 19 06:40:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR4g-0005Jf-3d for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:40:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23004 for ; Sat, 19 Nov 2005 06:39:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR48-0003LI-51 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:39:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdR47-0003Kf-LV for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:39:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdR44-0004wr-T1 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:39:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBdSWO021308; Sat, 19 Nov 2005 03:39:28 -0800 Date: Sat, 19 Nov 2005 03:39:28 -0800 Message-Id: <200511191139.jAJBdSWO021308@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdR44-0004wr-T1 c8df18aa496cb2e5d8f42e7eb5f3571a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 103] Start of introduction for DELETE confusing X-Archived-At: http://www.w3.org/mid/200511191139.jAJBdSWO021308@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10474 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:39:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=103 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:39 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:40:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR5W-0005TB-5Y for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:40:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23019 for ; Sat, 19 Nov 2005 06:40:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR4u-0003oh-CC for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:40:20 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdR4t-0003o9-JC for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:40:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdR4p-00016w-Eg for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:40:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBeF6o021322; Sat, 19 Nov 2005 03:40:15 -0800 Date: Sat, 19 Nov 2005 03:40:15 -0800 Message-Id: <200511191140.jAJBeF6o021322@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdR4p-00016w-Eg 599eb391f9c3434a0dbef7b4a84b1e65 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 104] Confusing new sentence in intro of COPY X-Archived-At: http://www.w3.org/mid/200511191140.jAJBeF6o021322@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10475 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:40:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=104 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:40 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:42:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR6u-0005xa-Rf for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:42:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23053 for ; Sat, 19 Nov 2005 06:41:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR6K-0004T3-32 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:41:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdR6J-0004SV-Mw for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:41:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdR6I-00009q-2M for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:41:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBfjW0021336; Sat, 19 Nov 2005 03:41:45 -0800 Date: Sat, 19 Nov 2005 03:41:45 -0800 Message-Id: <200511191141.jAJBfjW0021336@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdR6I-00009q-2M a90edbdf8d7438a5197625add66ec4bb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 105] COPY for Collection Resources vs infinite loops X-Archived-At: http://www.w3.org/mid/200511191141.jAJBfjW0021336@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10476 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:41:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=105 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:41 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:43:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR7w-00063J-Vs for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:43:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23081 for ; Sat, 19 Nov 2005 06:42:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR7N-0004cN-3s for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:42:53 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdR7M-0004bN-Gh for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:42:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdR7B-0001fe-Bh for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:42:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBgfsB021351; Sat, 19 Nov 2005 03:42:41 -0800 Date: Sat, 19 Nov 2005 03:42:41 -0800 Message-Id: <200511191142.jAJBgfsB021351@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdR7B-0001fe-Bh 99c3e1483abac5e179707b1a5ba36fd2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200511191142.jAJBgfsB021351@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10477 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:42:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:42 ------- Draft 08 URL: ------- 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@frink.w3.org Sat Nov 19 06:43:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdR8N-00068I-I0 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:43:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23109 for ; Sat, 19 Nov 2005 06:43:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR7p-0004jL-9r for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:43:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdR7o-0004iT-Q3 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:43:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdR7m-0000QP-CW for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:43:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBhILd021365; Sat, 19 Nov 2005 03:43:18 -0800 Date: Sat, 19 Nov 2005 03:43:18 -0800 Message-Id: <200511191143.jAJBhILd021365@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdR7m-0000QP-CW c85e1eed5cd88c25e8365f71a2eafcde X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 107] Status 102 present; but status-uri response header removed X-Archived-At: http://www.w3.org/mid/200511191143.jAJBhILd021365@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10478 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:43:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=107 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 06:45:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRAD-0006Wd-Sd for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:45:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23183 for ; Sat, 19 Nov 2005 06:45:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdR9a-0006BR-TT for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:45:10 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdR9Z-0005zE-3Y for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:45:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdR9W-000264-2T for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:45:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBj5ix021389; Sat, 19 Nov 2005 03:45:05 -0800 Date: Sat, 19 Nov 2005 03:45:05 -0800 Message-Id: <200511191145.jAJBj5ix021389@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdR9W-000264-2T bfdabd96c742a13fb64852e19b454d4e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 111] DEFINE_PRINCIPAL X-Archived-At: http://www.w3.org/mid/200511191145.jAJBj5ix021389@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10479 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:45:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=111 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:45 ------- Defined in . I think the issue can be closed. ------- 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@frink.w3.org Sat Nov 19 06:48:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRCq-0007B7-Lm for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:48:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23370 for ; Sat, 19 Nov 2005 06:47:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRCE-0006fx-Lu for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:47:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRCE-0006fO-3I for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:47:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRCB-0002YX-8t for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:47:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBlo8W021410; Sat, 19 Nov 2005 03:47:50 -0800 Date: Sat, 19 Nov 2005 03:47:50 -0800 Message-Id: <200511191147.jAJBlo8W021410@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRCB-0002YX-8t 411a172d4a2a40137b8c6238be38267e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 113] IMPLIED_LWS X-Archived-At: http://www.w3.org/mid/200511191147.jAJBlo8W021410@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10480 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:47:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=113 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:47 ------- Seems to be done (). ------- 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@frink.w3.org Sat Nov 19 06:50:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdREN-0007Yn-HF for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:50:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23470 for ; Sat, 19 Nov 2005 06:49:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRDo-0006pi-LF for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:49:32 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRDn-0006pA-Pr for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:49:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRDk-0002qT-PH for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:49:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBnSFD021433; Sat, 19 Nov 2005 03:49:28 -0800 Date: Sat, 19 Nov 2005 03:49:28 -0800 Message-Id: <200511191149.jAJBnSFD021433@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRDk-0002qT-PH 37cb6b2eb944f804b169ed9e5c8cd04d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 116] OVERWRITE_DELETE_ALL_TOO_STRONG X-Archived-At: http://www.w3.org/mid/200511191149.jAJBnSFD021433@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10481 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:49:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=116 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:49 ------- I believe the consensus is that RFC2518 says what it's meant to say, and a note was added to . AFAIK, the issue can be closed (as rejected). ------- 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@frink.w3.org Sat Nov 19 06:51:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRG8-0007vf-QH for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:51:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23576 for ; Sat, 19 Nov 2005 06:51:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRFZ-0007KB-Vx for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:51:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRFZ-0007JY-Fy for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:51:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRFW-000742-MW for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:51:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBpHHc021455; Sat, 19 Nov 2005 03:51:17 -0800 Date: Sat, 19 Nov 2005 03:51:17 -0800 Message-Id: <200511191151.jAJBpHHc021455@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRFW-000742-MW 9a45e58922ad2d185505f40a78b87ad7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 119] DATE_FORMAT_GETLASTMODIFIED X-Archived-At: http://www.w3.org/mid/200511191151.jAJBpHHc021455@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10482 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:51:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=119 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:51 ------- Seems to be done in , but I'd like to note that this change isn't mentioned in the Changes section. ------- 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@frink.w3.org Sat Nov 19 06:54:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRIu-00007i-2H for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:54:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23681 for ; Sat, 19 Nov 2005 06:54:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRIG-0007VH-Hj for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:54:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRIF-0007Uj-SW for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:54:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRHF-0001zy-O6 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:54:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBr52u021474; Sat, 19 Nov 2005 03:53:05 -0800 Date: Sat, 19 Nov 2005 03:53:05 -0800 Message-Id: <200511191153.jAJBr52u021474@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRHF-0001zy-O6 745bf18baa5a1b76554ab58ad8aa2fd2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 120] DEEP_LOCK_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200511191153.jAJBr52u021474@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10483 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:54:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:53 ------- Example was right, normative text was wrong. See . This change should be mentioned in the Changes section, though. ------- 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@frink.w3.org Sat Nov 19 06:56:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRKH-0000DC-Co for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:56:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23754 for ; Sat, 19 Nov 2005 06:55:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRJh-0007zK-2T for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:55:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRJg-0007yd-Lq for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:55:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRJd-0002P3-Oz for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:55:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBtX8r021508; Sat, 19 Nov 2005 03:55:33 -0800 Date: Sat, 19 Nov 2005 03:55:33 -0800 Message-Id: <200511191155.jAJBtX8r021508@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRJd-0002P3-Oz 69a77a9e214cdf5041f660ef5369b18f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 129] LOCK_BODY_SHOULD_BE_MUST X-Archived-At: http://www.w3.org/mid/200511191155.jAJBtX8r021508@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10484 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:55:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=129 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 03:55 ------- LOCK requests with body are for lock creation, without body for lock refresh. I think this is in -08, thus the bug can be closed. ------- 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@frink.w3.org Sat Nov 19 06:58:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRMH-0000hl-6h for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 06:58:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23922 for ; Sat, 19 Nov 2005 06:57:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRLe-0008DL-9h for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 11:57:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRLd-0008Cn-H7 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 11:57:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRLZ-00086K-W0 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 11:57:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJBvXF9021527; Sat, 19 Nov 2005 03:57:33 -0800 Date: Sat, 19 Nov 2005 03:57:33 -0800 Message-Id: <200511191157.jAJBvXF9021527@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRLZ-00086K-W0 dd5fc233694d497fc7d4a79eea15f1b3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 130] IF_AND_AUTH X-Archived-At: http://www.w3.org/mid/200511191157.jAJBvXF9021527@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10485 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 11:57:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=130 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- 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@frink.w3.org Sat Nov 19 07:01:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdROu-0001Ra-Ta for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:01:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24180 for ; Sat, 19 Nov 2005 07:00:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdROI-0001Nj-MW for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:00:22 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdROI-0001NB-3j for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:00:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdROE-0004fO-9D for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:00:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJC0IiW021547; Sat, 19 Nov 2005 04:00:18 -0800 Date: Sat, 19 Nov 2005 04:00:18 -0800 Message-Id: <200511191200.jAJC0IiW021547@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdROE-0004fO-9D 0066599a969a48f8b2a418c2cff8cdd5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 131] DISPLAYNAME X-Archived-At: http://www.w3.org/mid/200511191200.jAJC0IiW021547@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10486 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:00:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:00 ------- I think the WG consensus is that DAV:displayname optimally should work as a dead property, thus not being present when not explicitly set, and having the same value independently of Request-URI. Some servers implement displayname as live property that always reflects the URL-unescaped last path segment. This IMHO should be deprecated, because it seems to be completely useless. ------- 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@frink.w3.org Sat Nov 19 07:03:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRR1-0001tE-UL for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:03:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24268 for ; Sat, 19 Nov 2005 07:02:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRQS-0001e3-T4 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:02:36 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRQR-0001dV-Ks for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:02:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRQN-000581-Nz for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:02:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJC2Vva021774; Sat, 19 Nov 2005 04:02:31 -0800 Date: Sat, 19 Nov 2005 04:02:31 -0800 Message-Id: <200511191202.jAJC2Vva021774@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRQN-000581-Nz 6985e597aedab43d088e9f9c22e02ac0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 134] PROPFIND_INFINITY X-Archived-At: http://www.w3.org/mid/200511191202.jAJC2Vva021774@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10487 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:02:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=134 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:02 ------- "infinity" was made optional (see ). Note this change isn't mentioned in the Changes section. ------- 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@frink.w3.org Sat Nov 19 07:04:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRSR-0002I4-DY for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:04:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24307 for ; Sat, 19 Nov 2005 07:04:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRRr-0001mq-9L for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:04:03 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRRq-0001m8-K8 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:04:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRRn-0005MR-N8 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:04:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJC3xSc021792; Sat, 19 Nov 2005 04:03:59 -0800 Date: Sat, 19 Nov 2005 04:03:59 -0800 Message-Id: <200511191203.jAJC3xSc021792@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRRn-0005MR-N8 826bcefd56a2ccb4885bf16e7b0862e7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 135] RESOURCETYPE_EXTENSION X-Archived-At: http://www.w3.org/mid/200511191203.jAJC3xSc021792@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10488 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:04:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=135 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:03 ------- Present in . Issue can be closed. ------- 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@frink.w3.org Sat Nov 19 07:05:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRTL-0002XU-My for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:05:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24349 for ; Sat, 19 Nov 2005 07:05:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRSn-0001tN-Jt for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:05:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRSn-0001sp-7T for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:05:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRSl-00040d-Fp for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:05:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJC4xdS021812; Sat, 19 Nov 2005 04:04:59 -0800 Date: Sat, 19 Nov 2005 04:04:59 -0800 Message-Id: <200511191204.jAJC4xdS021812@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRSl-00040d-Fp 6167a60a63c1a7146805f8b1c975e1a0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 137] OPTIONS_RESPONSE_VARIES_FOR_RESOURCES X-Archived-At: http://www.w3.org/mid/200511191204.jAJC4xdS021812@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10489 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:05:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=137 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:04 ------- I think there is WG consensus that yes, OPTIONS responses vary by resource (by the way, that's an RFC2616 issue). ------- 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@frink.w3.org Sat Nov 19 07:08:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRWH-0003Dq-6s for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:08:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24458 for ; Sat, 19 Nov 2005 07:08:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRVd-0002Pe-N9 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:07:57 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRVc-0002P6-SV for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:07:56 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRVU-0001EZ-Gr for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:07:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJC7lfF021837; Sat, 19 Nov 2005 04:07:47 -0800 Date: Sat, 19 Nov 2005 04:07:47 -0800 Message-Id: <200511191207.jAJC7lfF021837@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRVU-0001EZ-Gr 8eae3fbdc47a48b966da85c4b9c9dd1d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 140] UNLOCK_NEEDS_IF_HEADER X-Archived-At: http://www.w3.org/mid/200511191207.jAJC7lfF021837@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10490 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:07:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=140 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:07 ------- AFAIK, consensus is that UNLOCK uses the "Lock-Token" request header. One could read the spec () as in this case, both headers are needed (because conditions may be checked first). I don't think that servers are implemented that way. This needs to be tested. ------- 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@frink.w3.org Sat Nov 19 07:09:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRXL-0003WA-Ev for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:09:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24519 for ; Sat, 19 Nov 2005 07:09:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRWn-0002W4-2M for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:09:09 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRWm-0002VW-Fa for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:09:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRWi-0006Vv-2c for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:09:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJC92t9021857; Sat, 19 Nov 2005 04:09:02 -0800 Date: Sat, 19 Nov 2005 04:09:02 -0800 Message-Id: <200511191209.jAJC92t9021857@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRWi-0006Vv-2c 8afd2715f9ed425182d2afc4d6a4fae8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 142] URL_ENCODING_ISSUES X-Archived-At: http://www.w3.org/mid/200511191209.jAJC92t9021857@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10491 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:09:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=142 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:09 ------- See . ------- 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@frink.w3.org Sat Nov 19 07:11:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRZC-0003oT-Jm for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:11:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24581 for ; Sat, 19 Nov 2005 07:11:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRYa-00031w-Fg for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:11:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRYa-00031J-0C for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:11:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRYX-0001j4-Ew for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:10:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCAu3R021879; Sat, 19 Nov 2005 04:10:56 -0800 Date: Sat, 19 Nov 2005 04:10:56 -0800 Message-Id: <200511191210.jAJCAu3R021879@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRYX-0001j4-Ew 95ce77a5b34f5901ae636f230adf60fa X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 145] LOCKDISCOVERY_ON_UNLOCKED_RESOURCE X-Archived-At: http://www.w3.org/mid/200511191210.jAJCAu3R021879@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10492 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:11:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=145 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:10 ------- For resources that support locking, an empty property should be returned. For resources that do no, the property should be reported as "404 Not Found". ------- 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@frink.w3.org Sat Nov 19 07:12:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRaL-0003wh-1D for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:12:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24633 for ; Sat, 19 Nov 2005 07:12:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRZg-0003AH-JD for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:12:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRZg-00039j-3N for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:12:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRZd-0001u5-88 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:12:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCC4ZS021901; Sat, 19 Nov 2005 04:12:04 -0800 Date: Sat, 19 Nov 2005 04:12:04 -0800 Message-Id: <200511191212.jAJCC4ZS021901@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRZd-0001u5-88 90f1ee0e54407eb487a8f3ddebe2e2b5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 148] SECTION_12_4_MENTIONS_HREF_ELEMENT X-Archived-At: http://www.w3.org/mid/200511191212.jAJCC4ZS021901@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10493 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:12:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=148 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:12 ------- DAV:source property was removed from -bis. Issue can be closed. ------- 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@frink.w3.org Sat Nov 19 07:13:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRaq-0004CF-U3 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:13:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24683 for ; Sat, 19 Nov 2005 07:12:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRaG-0003I4-MZ for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:12:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRaG-0003Gu-79 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:12:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRaE-0005Fs-ET for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:12:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCCfkQ021920; Sat, 19 Nov 2005 04:12:41 -0800 Date: Sat, 19 Nov 2005 04:12:41 -0800 Message-Id: <200511191212.jAJCCfkQ021920@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRaE-0005Fs-ET ece68e1d978d74a3682dc160e871858a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 149] NEW_MULTIPUT_METHOD X-Archived-At: http://www.w3.org/mid/200511191212.jAJCCfkQ021920@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10494 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:12:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=149 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:12 ------- I think there is WG consensus that this does not belong into RFC2518bis. Recommend to close it. ------- 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@frink.w3.org Sat Nov 19 07:14:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRbk-0004dV-Qu for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:14:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24765 for ; Sat, 19 Nov 2005 07:13:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRb6-0003Oj-SV for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:13:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRb6-0003OB-CH for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:13:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRaZ-0005Js-9C for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:13:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCD2pj021938; Sat, 19 Nov 2005 04:13:02 -0800 Date: Sat, 19 Nov 2005 04:13:02 -0800 Message-Id: <200511191213.jAJCD2pj021938@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRaZ-0005Js-9C 04925db9f6d71fd0b4557afedc0355d6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 150] SOURCE_PROPERTY_UNDERSPECIFIED X-Archived-At: http://www.w3.org/mid/200511191213.jAJCD2pj021938@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10495 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:13:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=150 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:13 ------- DAV:source was removed from -bis, thus the issue can be closed. ------- 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@frink.w3.org Sat Nov 19 07:14:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRc8-0004eT-LL for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:14:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24774 for ; Sat, 19 Nov 2005 07:14:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRba-0003Vw-1k for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:14:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRbZ-0003V7-I5 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:14:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRbV-0002CN-TC for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:14:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCDxOJ021976; Sat, 19 Nov 2005 04:13:59 -0800 Date: Sat, 19 Nov 2005 04:13:59 -0800 Message-Id: <200511191213.jAJCDxOJ021976@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRbV-0002CN-TC 32a2d8e9cf49ff820ca5439d1d0fa1ba X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 142] URL_ENCODING_ISSUES X-Archived-At: http://www.w3.org/mid/200511191213.jAJCDxOJ021976@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10496 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:14:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=142 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:13 ------- *** Bug 151 has been marked as a duplicate of this bug. *** ------- 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@frink.w3.org Sat Nov 19 07:14:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRcG-0004el-8y for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:14:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24776 for ; Sat, 19 Nov 2005 07:14:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRbi-0003ce-4F for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:14:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRbZ-0003V8-KF for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:14:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRbU-0002C1-8C for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:14:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCDwpQ021962; Sat, 19 Nov 2005 04:13:58 -0800 Date: Sat, 19 Nov 2005 04:13:58 -0800 Message-Id: <200511191213.jAJCDwpQ021962@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRbU-0002C1-8C ed734c01729072a49133fdf3a325f879 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 151] HOW_DO_WE_ENCODE_FILENAMES_AS_URLS X-Archived-At: http://www.w3.org/mid/200511191213.jAJCDwpQ021962@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10497 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:14:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=151 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:13 ------- *** This bug has been marked as a duplicate of 142 *** ------- 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@frink.w3.org Sat Nov 19 07:16:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRdb-00055D-I0 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:16:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24835 for ; Sat, 19 Nov 2005 07:15:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRd0-0005P8-If for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:15:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRd0-0005OO-29 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:15:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRce-0005iI-Dd for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:15:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCFBko022000; Sat, 19 Nov 2005 04:15:11 -0800 Date: Sat, 19 Nov 2005 04:15:11 -0800 Message-Id: <200511191215.jAJCFBko022000@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRce-0005iI-Dd 30bcced6533cc801fc095a2c95ae4f9e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 153] CAN_HREF_BE_RELATIVE X-Archived-At: http://www.w3.org/mid/200511191215.jAJCFBko022000@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10498 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:15:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=153 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:15 ------- Yes, it can be relative. We may have to make sure that it's always clear what the base URI is. ------- 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@frink.w3.org Sat Nov 19 07:16:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRe3-00056B-3Y for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:16:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24860 for ; Sat, 19 Nov 2005 07:16:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRdU-0005X7-5P for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:16:04 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRdT-0005WY-Ca for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:16:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRdM-000898-3l for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:16:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCFttS022049; Sat, 19 Nov 2005 04:15:55 -0800 Date: Sat, 19 Nov 2005 04:15:55 -0800 Message-Id: <200511191215.jAJCFttS022049@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRdM-000898-3l a081f26a8bc5a3355bf6ca50d11c2452 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 154] ADD_DEPTH_ZERO_DELETE X-Archived-At: http://www.w3.org/mid/200511191215.jAJCFttS022049@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10499 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:16:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=154 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:15 ------- Although I would find that functionality useful, I don't think there's consensus for adding this to the spec. ------- 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@frink.w3.org Sat Nov 19 07:17:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdReu-0005Ia-ES for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:17:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24876 for ; Sat, 19 Nov 2005 07:16:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdReL-0005f9-5M for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:16:57 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdReK-0005eb-JS for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:16:56 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdReA-0002lW-44 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:16:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCGirk022085; Sat, 19 Nov 2005 04:16:44 -0800 Date: Sat, 19 Nov 2005 04:16:44 -0800 Message-Id: <200511191216.jAJCGirk022085@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdReA-0002lW-44 ae67396366aec495362fdda2af9519fa X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 107] Status 102 present; but status-uri response header removed X-Archived-At: http://www.w3.org/mid/200511191216.jAJCGirk022085@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10500 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:16:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=107 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elias@cse.ucsc.edu ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:16 ------- *** Bug 155 has been marked as a duplicate of this bug. *** ------- 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@frink.w3.org Sat Nov 19 07:17:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRf0-0005Iv-Ma for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:17:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24878 for ; Sat, 19 Nov 2005 07:17:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdReS-0005km-KO for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:17:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdReS-0005kA-44 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:17:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRe9-0002lS-8B for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:17:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCGiDQ022075; Sat, 19 Nov 2005 04:16:44 -0800 Date: Sat, 19 Nov 2005 04:16:44 -0800 Message-Id: <200511191216.jAJCGiDQ022075@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRe9-0002lS-8B 6d574bce48d7e3eb3c5a558cf227c534 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 155] INTEROPERABILITY_OF_102PROCESSING_STATUS_DEMONSTRATED X-Archived-At: http://www.w3.org/mid/200511191216.jAJCGiDQ022075@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10501 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:17:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=155 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:16 ------- *** This bug has been marked as a duplicate of 107 *** ------- 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@frink.w3.org Sat Nov 19 07:18:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRfa-0005V3-1H for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:18:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24902 for ; Sat, 19 Nov 2005 07:17:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRf1-0005u3-F9 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:17:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRf1-0005tP-2h for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:17:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRey-0006Dv-VZ for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:17:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCHaus022110; Sat, 19 Nov 2005 04:17:36 -0800 Date: Sat, 19 Nov 2005 04:17:36 -0800 Message-Id: <200511191217.jAJCHaus022110@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRey-0006Dv-VZ 8c80dfec58cfd258e7bd5f5b764b8769 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 157] REMOVE_ETAG_SUPPORT_FOR_IF_HEADER X-Archived-At: http://www.w3.org/mid/200511191217.jAJCHaus022110@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10502 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:17:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=157 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:17 ------- As far as I can tell, there's no consensus to remove that support. ------- 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@frink.w3.org Sat Nov 19 07:19:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRh1-0005iy-Fg for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:19:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24969 for ; Sat, 19 Nov 2005 07:19:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRgN-00062V-ON for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:19:03 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRgM-00061x-SY for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:19:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRgF-0000EO-Vb for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:19:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCIs7K022131; Sat, 19 Nov 2005 04:18:54 -0800 Date: Sat, 19 Nov 2005 04:18:54 -0800 Message-Id: <200511191218.jAJCIs7K022131@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRgF-0000EO-Vb d5c4a838abb2cb6a02f1cae0d749caa5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 158] SHOULD_WE_SUPPORT_IRIS_AND_CHARMOD X-Archived-At: http://www.w3.org/mid/200511191218.jAJCIs7K022131@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10503 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:19:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=158 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:18 ------- This is similar, but not exactly the same thing as issue #151. ------- 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@frink.w3.org Sat Nov 19 07:21:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRis-00063e-5E for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:21:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25008 for ; Sat, 19 Nov 2005 07:21:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRiI-0006eW-RA for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:21:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRiI-0006dt-Bt for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:21:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdRi9-0003U0-I7 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:21:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCKqRD022153; Sat, 19 Nov 2005 04:20:52 -0800 Date: Sat, 19 Nov 2005 04:20:52 -0800 Message-Id: <200511191220.jAJCKqRD022153@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdRi9-0003U0-I7 dd6afd1424e766445adf5f2343b1a2ff X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/200511191220.jAJCKqRD022153@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10504 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:21:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=160 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:20 ------- bis changes the grammar with the intent to allow multi-line If headers, but I think it fails to do that properly. See also bug 171 () ------- 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@frink.w3.org Sat Nov 19 07:22:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRjG-00069O-Kc for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:22:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25017 for ; Sat, 19 Nov 2005 07:21:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRih-0006jn-Vs for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:21:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRih-0006jF-JV for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:21:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRif-0006sh-P7 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:21:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCLPTa022173; Sat, 19 Nov 2005 04:21:25 -0800 Date: Sat, 19 Nov 2005 04:21:25 -0800 Message-Id: <200511191221.jAJCLPTa022173@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRif-0006sh-P7 e336605386e87ec3540716a4e15b5774 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 162] REMOVE_UNTAGGED_IF_HEADER X-Archived-At: http://www.w3.org/mid/200511191221.jAJCLPTa022173@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10505 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:21:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=162 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:21 ------- As far as I can tell, there was no consensus for this change. ------- 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@frink.w3.org Sat Nov 19 07:22:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRja-0006E3-Tj for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:22:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25032 for ; Sat, 19 Nov 2005 07:21:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRj2-0006pb-Sy for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:21:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRj2-0006p3-GP for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:21:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRj0-0006vs-F9 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:21:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCLjqJ022191; Sat, 19 Nov 2005 04:21:45 -0800 Date: Sat, 19 Nov 2005 04:21:45 -0800 Message-Id: <200511191221.jAJCLjqJ022191@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRj0-0006vs-F9 ae1d58064bc8f9ab123e8dae4a1077d7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 163] REMOVE_NOT_SUPPORT_FROM_IF_HEADERS X-Archived-At: http://www.w3.org/mid/200511191221.jAJCLjqJ022191@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10506 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:21:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=163 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:21 ------- As far as I can tell, there was no consensus for this change. ------- 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@frink.w3.org Sat Nov 19 07:24:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRlR-0006TD-Op for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:24:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25099 for ; Sat, 19 Nov 2005 07:23:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRkr-00079D-2i for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:23:41 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRkq-00078e-EY for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:23:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRka-00016n-70 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:23:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCNNEG022212; Sat, 19 Nov 2005 04:23:23 -0800 Date: Sat, 19 Nov 2005 04:23:23 -0800 Message-Id: <200511191223.jAJCNNEG022212@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRka-00016n-70 96efe95a81c28446ff4e60bff4251a4b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 165] DAV_ERROR_SUPPORT X-Archived-At: http://www.w3.org/mid/200511191223.jAJCNNEG022212@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10507 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:23:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=165 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:23 ------- This was added in . However, there are some editorial issues, see bug 15 () ------- 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@frink.w3.org Sat Nov 19 07:24:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRli-0006gu-7O for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:24:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25107 for ; Sat, 19 Nov 2005 07:23:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRl9-0007En-Rd for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:23:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRl9-0007EA-Ei for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:23:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRl2-0007KG-OD for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:23:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCNq3r022234; Sat, 19 Nov 2005 04:23:52 -0800 Date: Sat, 19 Nov 2005 04:23:52 -0800 Message-Id: <200511191223.jAJCNq3r022234@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRl2-0007KG-OD f46c2dcf6a1a1e6409e93a303d0710a7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 167] XML_ENTITY_DOS X-Archived-At: http://www.w3.org/mid/200511191223.jAJCNq3r022234@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10508 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:23:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=167 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:23 ------- *** This bug has been marked as a duplicate of 11 *** ------- 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@frink.w3.org Sat Nov 19 07:24:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRli-0006gv-9S for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:24:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25108 for ; Sat, 19 Nov 2005 07:23:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRlA-0007FP-93 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:24:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRl9-0007Ep-SO for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:23:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRl3-0007KO-7m for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:23:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCNqiO022240; Sat, 19 Nov 2005 04:23:52 -0800 Date: Sat, 19 Nov 2005 04:23:52 -0800 Message-Id: <200511191223.jAJCNqiO022240@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRl3-0007KO-7m 578bda719f1332359ff62114039b455e 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/200511191223.jAJCNqiO022240@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10509 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:24:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elias@cse.ucsc.edu ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:23 ------- *** Bug 167 has been marked as a duplicate of this bug. *** ------- 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@frink.w3.org Sat Nov 19 07:25:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRn5-00074I-G6 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:25:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25151 for ; Sat, 19 Nov 2005 07:25:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRmT-0007xg-Pi for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:25:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRmT-0007x7-DW for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:25:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdRmR-0007ZG-Ek for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:25:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCPJE4022261; Sat, 19 Nov 2005 04:25:19 -0800 Date: Sat, 19 Nov 2005 04:25:19 -0800 Message-Id: <200511191225.jAJCPJE4022261@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EdRmR-0007ZG-Ek 7c9bd1c8d5175d1a25d881c8b4b4a400 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 169] Date header required? X-Archived-At: http://www.w3.org/mid/200511191225.jAJCPJE4022261@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10510 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:25:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=169 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:25 ------- This was removed (thanks), but the Changes section still mentions it. ------- 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@frink.w3.org Sat Nov 19 07:27:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRoH-0007AH-Nl for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:27:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25218 for ; Sat, 19 Nov 2005 07:26:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRni-00084g-B3 for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:26:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRnh-000848-IF for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:26:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRnV-0001ab-5x for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:26:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCQOYm022279; Sat, 19 Nov 2005 04:26:24 -0800 Date: Sat, 19 Nov 2005 04:26:24 -0800 Message-Id: <200511191226.jAJCQOYm022279@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRnV-0001ab-5x 6af179996936f353e8e1b61aef8eb0fd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 170] no mention of 424 in section 8.3.2 X-Archived-At: http://www.w3.org/mid/200511191226.jAJCQOYm022279@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10511 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:26:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=170 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:26 ------- Done in . I think this bug can be closed. ------- 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@frink.w3.org Sat Nov 19 07:29:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRqM-0007m2-Gq for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:29:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25321 for ; Sat, 19 Nov 2005 07:28:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRpn-0008Ch-LF for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:28:47 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdRpn-0008C4-2V for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:28:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdRpg-0001wH-Jr for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:28:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAJCSe5L022294; Sat, 19 Nov 2005 04:28:40 -0800 Date: Sat, 19 Nov 2005 04:28:40 -0800 Message-Id: <200511191228.jAJCSe5L022294@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdRpg-0001wH-Jr e303f86edd1f552f9cfad509501f9d68 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/200511191228.jAJCSe5L022294@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10512 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:28:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|-07 |-08 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 04:28 ------- states that "opaquelocktoken" was obsoleted. As far as I recall, there was no consensus for that statement (it begs the question: by what?). ------- 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@frink.w3.org Sat Nov 19 07:33:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdRu2-00005u-8H for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:33:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25536 for ; Sat, 19 Nov 2005 07:32:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdRtP-0001jY-0a for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 12:32:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdRtO-0001iz-Iy for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 12:32:30 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EdRtM-0000Jo-8F for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 12:32:30 +0000 Received: (qmail invoked by alias); 19 Nov 2005 12:32:26 -0000 Received: from p508FA2E5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.162.229] by mail.gmx.net (mp011) with SMTP; 19 Nov 2005 13:32:26 +0100 X-Authenticated: #1915285 Message-ID: <437F1B20.9090303@gmx.de> Date: Sat, 19 Nov 2005 13:31:28 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: webdav WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EdRtM-0000Jo-8F acd8e509da68dc1b68493abf687cb41f X-Original-To: w3c-dist-auth@w3.org Subject: BugZilla mail flood X-Archived-At: http://www.w3.org/mid/437F1B20.9090303@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10513 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 12:32:31 +0000 Content-Transfer-Encoding: 7bit Hi, I apologize for the mail flood. What I did was: - checked all bugs raised by me and updated them (moving them to -08 where required) - reopened bugs that I think should not have been closed - marked some of the bugs as duplicates of others - added a remark about what I think the last WG consensus was for some of the issues, or pointed to changes in bis that may affect the status of the bug What I have *not* done yet is to review draft -08 for other potential problems, not directly connected to issues in the tracker. I'll try to get that done tomorrow. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Nov 19 11:34:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdVfB-000752-1n for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 11:34:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06069 for ; Sat, 19 Nov 2005 11:33:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdVe5-0003Lj-MS for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 16:32:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdVe1-0003Kt-C3 for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 16:32:53 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdVdw-0005BC-He for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 16:32:53 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2C0B314227B; Sat, 19 Nov 2005 08:32:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22060-07; Sat, 19 Nov 2005 08:32:47 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B52D114226C; Sat, 19 Nov 2005 08:32:42 -0800 (PST) In-Reply-To: <437F1B20.9090303@gmx.de> References: <437F1B20.9090303@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: webdav WG From: Lisa Dusseault Date: Sat, 19 Nov 2005 08:32:16 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EdVdw-0005BC-He bbd0f4c384cf45e1663724c25d99e5e3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BugZilla mail flood X-Archived-At: http://www.w3.org/mid/b67f5ee120af4768898f7a929fa1f33a@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10514 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 16:32:57 +0000 Content-Transfer-Encoding: 7bit Thanks for doing this, Julian. It would be somewhat less of a mail flood if we didn't change the "version" value of each bug when there's a new draft out. We can consider that the version that the bug was found in, and the bug is not fixed until it's fixed-- thus an issue found in version 07 might be fixed in draft 09 and we still don't have to change the field. Lisa On Nov 19, 2005, at 4:31 AM, Julian Reschke wrote: > > Hi, > > I apologize for the mail flood. What I did was: > > - checked all bugs raised by me and updated them (moving them to -08 > where required) > > - reopened bugs that I think should not have been closed > > - marked some of the bugs as duplicates of others > > - added a remark about what I think the last WG consensus was for some > of the issues, or pointed to changes in bis that may affect the status > of the bug > > What I have *not* done yet is to review draft -08 for other potential > problems, not directly connected to issues in the tracker. I'll try to > get that done tomorrow. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Sat Nov 19 12:01:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdW5T-0004Uv-E4 for webdav-archive@megatron.ietf.org; Sat, 19 Nov 2005 12:01:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07017 for ; Sat, 19 Nov 2005 12:00:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdW4h-0000WH-5M for w3c-dist-auth-dist@listhub.w3.org; Sat, 19 Nov 2005 17:00:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EdW4g-0000VW-Mx for w3c-dist-auth@listhub.w3.org; Sat, 19 Nov 2005 17:00:26 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EdW4e-00016Q-O1 for w3c-dist-auth@w3.org; Sat, 19 Nov 2005 17:00:26 +0000 Received: from [192.168.2.104] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jAJH0Mp2001526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 19 Nov 2005 09:00:23 -0800 (PST) Message-ID: <437F5A26.9080506@cse.ucsc.edu> Date: Sat, 19 Nov 2005 09:00:22 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG CC: webdav WG References: <437F1B20.9090303@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (lisa.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EdW4e-00016Q-O1 a1a52b0096bd6eaa492e90b682e818e6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BugZilla mail flood X-Archived-At: http://www.w3.org/mid/437F5A26.9080506@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10515 X-Loop: w3c-dist-auth@w3.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, 19 Nov 2005 17:00:27 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Thanks for doing this, Julian. Indeed, thank you. > It would be somewhat less of a mail flood if we didn't change the > "version" value of each bug when there's a new draft out. We can > consider that the version that the bug was found in [...] +1, I'd like to follow this suggestion. FYI, I've started to go through the most recent draft to verify that 'concensus text' is there... Cheers, Elias From w3c-dist-auth-request@frink.w3.org Sun Nov 20 14:33:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EduwT-0002pa-2O for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 14:33:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08801 for ; Sun, 20 Nov 2005 14:33:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eduu6-0006hK-VD for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 19:31:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eduu2-0006gk-E0 for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 19:31:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Edutx-0001t6-Nr for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 19:31:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKJUxZk003115; Sun, 20 Nov 2005 11:30:59 -0800 Date: Sun, 20 Nov 2005 11:30:59 -0800 Message-Id: <200511201930.jAKJUxZk003115@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Edutx-0001t6-Nr b367057bb48f86490acfee2b503809bb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511201930.jAKJUxZk003115@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10516 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 19:31:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-20 11:30 ------- Correction: the lost change was for "302_AND_MULTISTATUS". ------- 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@frink.w3.org Sun Nov 20 14:39:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edv2X-0003jV-BD for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 14:39:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09082 for ; Sun, 20 Nov 2005 14:39:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edv1p-0007R4-18 for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 19:39:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Edv1o-0007QW-H8 for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 19:39:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Edv1i-0003AS-JV for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 19:39:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKJd0YU003136; Sun, 20 Nov 2005 11:39:00 -0800 Date: Sun, 20 Nov 2005 11:39:00 -0800 Message-Id: <200511201939.jAKJd0YU003136@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Edv1i-0003AS-JV 5f6739ea8fdd7d596a531cc1332bd24a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 173] New: Info about inside multistatus lost X-Archived-At: http://www.w3.org/mid/200511201939.jAKJd0YU003136@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10517 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 19:39:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=173 Summary: Info about inside multistatus lost Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://http://greenbytes.de/tech/webdav/draft-ietf- webdav-rfc2518bis-07.html#rfc.section.12.1 OS/Version: other Status: NEW Severity: critical Priority: P2 Component: 12. Multi-Status Response AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org The recent edits on section have removed the next section 12.1, which was added to resolve issue 302_AND_MULTISTATUS from the original issues list (). The XML element description for also needs to be readded. ------- 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@frink.w3.org Sun Nov 20 14:50:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvCW-000543-Lu for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 14:50:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09616 for ; Sun, 20 Nov 2005 14:49:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdvBo-0001Qw-Hz for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 19:49:28 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdvBn-0001QJ-Ut for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 19:49:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdvBJ-0007ed-5O for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 19:49:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKJmsAx003156; Sun, 20 Nov 2005 11:48:54 -0800 Date: Sun, 20 Nov 2005 11:48:54 -0800 Message-Id: <200511201948.jAKJmsAx003156@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdvBJ-0007ed-5O 89dd9b428f3b867cfc7db015adf9dc1b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 174] New: Terminology in 4.4: "namespace name in scope" X-Archived-At: http://www.w3.org/mid/200511201948.jAKJmsAx003156@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10518 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 19:49:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=174 Summary: Terminology in 4.4: "namespace name in scope" Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://http://greenbytes.de/tech/webdav/draft-ietf- webdav-rfc2518bis-08.html#rfc.section.4.4.p.5 OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 04. Data Model for Resource Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org In draft 08 (), the text was changed to say "...namespace names that are in scope..." (from "...namespaces that are in scope..."). I think the best terminology here would be "...namespace declarations that are in scope...". ------- 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@frink.w3.org Sun Nov 20 14:58:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvKN-0005wZ-Iu for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 14:58:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09950 for ; Sun, 20 Nov 2005 14:57:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdvJh-0002TO-Om for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 19:57:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdvJh-0002Sn-1k for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 19:57:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdvJa-0005xL-DO for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 19:57:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKJvTrg003169; Sun, 20 Nov 2005 11:57:29 -0800 Date: Sun, 20 Nov 2005 11:57:29 -0800 Message-Id: <200511201957.jAKJvTrg003169@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdvJa-0005xL-DO 34c37009213ddd13685c5e4fe3e03deb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200511201957.jAKJvTrg003169@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10519 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 19:57:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-20 11:57 ------- Furthermore: "When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in Section 9.6, and also in the body of the response." I don't think we need that sentence here at all. It's just an introduction to locks, and naturally people looking for details should read the definition of the LOCK method. That being said; *if* we want to keep the forward reference here, please simplify not to repeat text from somewhere else (that's generally a good way to create inconsistent specs), and just say something like "When a LOCK operation creates a new lock, information about the newly created lock is returned in the HTTP response (see Section x.y)" (where x.y is the subsection number for the section where LOCK creation is defined). Then...: "This specification encourages servers to create UUIDs for lock tokens, and to use the URI form defined by A Universally Unique Identifier (UUID) URN Namespace [9]. However servers are free to use another valid URI so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in an appendix of this document." 1) s/to use another valid URI/to use any other valid URI scheme/ 2) s/defined in an appendix/defined in Appendix xyx/ ------- 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@frink.w3.org Sun Nov 20 15:01:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvNG-0006LS-1C for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:01:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10104 for ; Sun, 20 Nov 2005 15:00:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdvMc-00044V-BF for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:00:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdvMb-00043v-Oe for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:00:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdvMY-0001OP-Qr for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:00:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKK0YRl003186; Sun, 20 Nov 2005 12:00:34 -0800 Date: Sun, 20 Nov 2005 12:00:34 -0800 Message-Id: <200511202000.jAKK0YRl003186@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdvMY-0001OP-Qr d9ac7d1b003c57a8f37af363aa22d3bb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 175] New: Sectiion 8.1.3 unneeded X-Archived-At: http://www.w3.org/mid/200511202000.jAKK0YRl003186@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10520 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:00:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=175 Summary: Sectiion 8.1.3 unneeded Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.8.1.3 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 QAContact: w3c-dist-auth@w3.org : "HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible." Adding this section doesn't seem to be an improvement over RFC2518. It doesn't say any interesting except that a WebDAV server is an HTTP server as well by definition, thus RFC2616 applies. ------- 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@frink.w3.org Sun Nov 20 15:05:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvRV-0007Jb-7j for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:05:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10460 for ; Sun, 20 Nov 2005 15:05:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdvQo-0004NY-F1 for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:04:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdvQn-0004N0-VD for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:04:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdvQk-00074d-3i for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:04:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKK4qpJ003217; Sun, 20 Nov 2005 12:04:52 -0800 Date: Sun, 20 Nov 2005 12:04:52 -0800 Message-Id: <200511202004.jAKK4qpJ003217@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdvQk-00074d-3i ce349679a2eacdb9ca27602436633943 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 176] New: Etag requirements (unchanged body for resource) X-Archived-At: http://www.w3.org/mid/200511202004.jAKK4qpJ003217@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10521 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:04:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=176 Summary: Etag requirements (unchanged body for resource) Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.8.1.4.p.3 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 QAContact: w3c-dist-auth@w3.org : "Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or getlastmodified value) for a resource that has an unchanged body. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed." That may trick people into thinking that they should keep ETag and Last-Modified when a resource is moved (because the body didn't change, after all...), which would be a big mistake. Furthermore the text should use consistent terminlogy, that is either HTTP header names or WebDAV property names. ------- 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@frink.w3.org Sun Nov 20 15:13:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvZV-0008QI-7y for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:13:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10783 for ; Sun, 20 Nov 2005 15:13:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdvYp-0005Qf-TB for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:13:15 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EdvYn-0005Q1-Ke for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:13:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdvYi-0003cA-Og for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:13:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKD8Y6003234; Sun, 20 Nov 2005 12:13:08 -0800 Date: Sun, 20 Nov 2005 12:13:08 -0800 Message-Id: <200511202013.jAKKD8Y6003234@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdvYi-0003cA-Og 9985d9e2d8d94c45586fc486b6722c62 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 177] New: "PROPFIND status codes" section X-Archived-At: http://www.w3.org/mid/200511202013.jAKKD8Y6003234@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10522 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:13:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=177 Summary: "PROPFIND status codes" section Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://http://greenbytes.de/tech/webdav/draft-ietf- webdav-rfc2518bis-08.html#rfc.section.8.2.1 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 QAContact: w3c-dist-auth@w3.org "A server MAY fail an entire PROPFIND request with an appropriate status code and MAY redirect the entire request." This is true for any HTTP request. Saying it here explicitly may cause people to wonder whether this is true for other methods defined here... "In addition, the following error codes are specifically defined for PROPFIND requests: 403 Forbidden - A server MAY reject all PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the element 'propfind-infinite-depth-forbidden' inside the error body." 1) No, 403 is not defined specifically for PROPFIND. 2) A server MAY reject them also if the resource is not a collection (why check first???) 3) I think the part about the response body is only understandable to people who already knew that. Let's have one piece in the earlier sections that defines the error response body in a consistent way with RFC3253, then just define a precondition name here. The text goes on listing 4 specific status codes to which I object: 1) As far as I can tell, nobody asked for that restriction, and worse: 2) There's an IESG-accepted spec that already shows another status code that can be used here (), which IMHO is a real-world proof that this subsection is not only unnecessary, but also harmful. ------- 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@frink.w3.org Sun Nov 20 15:17:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvdP-0000LW-Jn for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:17:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10907 for ; Sun, 20 Nov 2005 15:17:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edvcp-00078s-E3 for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:17:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Edvco-00078K-U2 for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:17:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Edvcm-0000T7-3a for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:17:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKHJeg003254; Sun, 20 Nov 2005 12:17:19 -0800 Date: Sun, 20 Nov 2005 12:17:19 -0800 Message-Id: <200511202017.jAKKHJeg003254@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Edvcm-0000T7-3a 13bba4730323d5567de7db314ad21d7b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 178] New: Multistatus for DELETE X-Archived-At: http://www.w3.org/mid/200511202017.jAKKHJeg003254@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10523 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:17:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=178 Summary: Multistatus for DELETE Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.8.7.2.p.8 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 QAContact: w3c-dist-auth@w3.org : "424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi- Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi- Status). The reason for this prohibition is that 204 (No Content) is the default success code." 1) s/errors/status codes/ 2) Fix whitespace after "Multi-" ------- 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@frink.w3.org Sun Nov 20 15:23:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdviI-00016u-AD for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:23:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11188 for ; Sun, 20 Nov 2005 15:22:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edvhd-0007i8-Oi for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:22:21 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Edvhc-0007hV-Cl for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:22:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EdvhZ-00055A-DU for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:22:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKMG0v003271; Sun, 20 Nov 2005 12:22:16 -0800 Date: Sun, 20 Nov 2005 12:22:16 -0800 Message-Id: <200511202022.jAKKMG0v003271@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EdvhZ-00055A-DU 5f7d53ac1850a7469a2f7787df09c0fb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 179] New: DAV:no-lock X-Archived-At: http://www.w3.org/mid/200511202022.jAKKMG0v003271@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10524 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:22:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=179 Summary: DAV:no-lock Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.9.5.3.p.4 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 QAContact: w3c-dist-auth@w3.org : "The Not production is particularly useful with the "" state token. The clause "Not " MUST evaluate to true. Thus, any "OR" statement containing the clause "Not " MUST also evaluate to true." Again, Dav:no-lock is not anything special. It's an *example* for a URI that by definition never identifies a lock (like "DAV:lock", for instance). So a normative MUST is incorrect here. Just say "The Not production is particularly useful with a state token known not to ever identify a lock, such as "DAV:no-lock". The clause "Not " will evaluate to true. Thus, any "OR" statement containing the clause "Not " will also evaluate to true." ------- 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@frink.w3.org Sun Nov 20 15:27:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvmM-0001pP-Oy for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:27:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11505 for ; Sun, 20 Nov 2005 15:26:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edvll-0008Dg-5J for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:26:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Edvlk-0008D7-Ek for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:26:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Edvlh-0001i1-MU for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:26:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKQW3H003292; Sun, 20 Nov 2005 12:26:32 -0800 Date: Sun, 20 Nov 2005 12:26:32 -0800 Message-Id: <200511202026.jAKKQW3H003292@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Edvlh-0001i1-MU 7147ade55a177ebf11127bb06e631785 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 177] "PROPFIND status codes" section X-Archived-At: http://www.w3.org/mid/200511202026.jAKKQW3H003292@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10525 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:26:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=177 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-20 12:26 ------- Note this is referenced by 12.3 (), so that subsection needs to be fixed as well. ------- 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@frink.w3.org Sun Nov 20 15:29:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edvol-00023p-R9 for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:29:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11554 for ; Sun, 20 Nov 2005 15:29:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edvo9-0008Pv-8C for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:29:05 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Edvo8-0008PN-LB for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:29:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Edvo4-00061L-OB for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:29:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKT0YT003305; Sun, 20 Nov 2005 12:29:00 -0800 Date: Sun, 20 Nov 2005 12:29:00 -0800 Message-Id: <200511202029.jAKKT0YT003305@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Edvo4-00061L-OB 3ebc71e01e919bf1e06061a60b09f193 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 180] New: Typo in 13.18, enhance reference X-Archived-At: http://www.w3.org/mid/200511202029.jAKKT0YT003305@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10526 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:29:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=180 Summary: Typo in 13.18, enhance reference Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.13.18 OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 13. XML Element Definitions AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org : "status-line (status-line defined in RFC2616 [6]" replace by "status-line (status-line defined in Section 6.1 of RFC2616 [6])" ------- 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@frink.w3.org Sun Nov 20 15:33:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvsX-0002cZ-5D for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:33:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11755 for ; Sun, 20 Nov 2005 15:33:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdvrZ-0001gT-72 for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:32:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdvrY-0001fv-NA for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:32:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdvrV-0002eW-SO for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:32:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKWXXR003321; Sun, 20 Nov 2005 12:32:33 -0800 Date: Sun, 20 Nov 2005 12:32:33 -0800 Message-Id: <200511202032.jAKKWXXR003321@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdvrV-0002eW-SO 1559b8b0caef2c0265fa3431a647b74d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] New: error element X-Archived-At: http://www.w3.org/mid/200511202032.jAKKWXXR003321@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10527 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:32:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 Summary: error element Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.13.29 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 13. XML Element Definitions AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org : "Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. When an error response contains a body in WebDAV, the body is in XML with the root element 'error'. The 'error' tag SHOULD include a standard error tag defined in this specification or another specification. The 'error' tag MAY include custom error tags (in custom namespaces) which a client can safely ignore." Clients MAY ignore everything here. And that doesn't depend on where the condition code is defined. Of course the better resolution is just to copy the text from RFC3253, and to use it's terminology to be consistent with RFC3253, RFC3648 and RFC3744. ------- 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@frink.w3.org Sun Nov 20 15:35:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvuZ-0002um-60 for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:35:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11821 for ; Sun, 20 Nov 2005 15:35:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edvtq-0001ya-GB for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:34:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Edvtp-0001xv-Vv for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:34:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Edvtm-000340-He for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:34:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKYr1u003338; Sun, 20 Nov 2005 12:34:53 -0800 Date: Sun, 20 Nov 2005 12:34:53 -0800 Message-Id: <200511202034.jAKKYr1u003338@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Edvtm-000340-He 4e084b188a3012737745bbd3caa02504 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 182] New: whitespace in lock token in example X-Archived-At: http://www.w3.org/mid/200511202034.jAKKYr1u003338@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10528 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:34:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=182 Summary: whitespace in lock token in example Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.14.8.1 OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org : urn:uuid:f81de2ad-7f3d-a1b2-4f3c -00a0c91a9d76 ------- 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@frink.w3.org Sun Nov 20 15:40:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edvym-0003SK-H9 for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:40:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11992 for ; Sun, 20 Nov 2005 15:39:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdvyA-0002dd-DF for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:39:26 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Edvy9-0002d1-Jg for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:39:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Edvy6-0007iv-Kh for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:39:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKdMhE003356; Sun, 20 Nov 2005 12:39:22 -0800 Date: Sun, 20 Nov 2005 12:39:22 -0800 Message-Id: <200511202039.jAKKdMhE003356@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Edvy6-0007iv-Kh 4d87322b9515c1fd39b03a5c4d4a6bd0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 183] New: Outdated references X-Archived-At: http://www.w3.org/mid/200511202039.jAKKdMhE003356@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10529 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:39:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=183 Summary: Outdated references Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.22 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 22. References AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Output from check-ietf-references.xslt: Normative References: RFC2069: [PROPOSED STANDARD] obsoleted by RFC2617 RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok RFC2277: [BEST CURRENT PRACTICE] (-> BCP0018) ok RFC2279: [DRAFT STANDARD] obsoleted by RFC3629 RFC2518: [PROPOSED STANDARD] ok RFC2616: [DRAFT STANDARD] ok RFC3339: [PROPOSED STANDARD] ok RFC3986: [STANDARD] (-> STD0066) ok RFC4122: [PROPOSED STANDARD] ok Informational References: RFC2291: [INFORMATIONAL] ok RFC2376: [INFORMATIONAL] obsoleted by RFC3023 RFC3253: [PROPOSED STANDARD] ok RFC3744: [PROPOSED STANDARD] ok ------- 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@frink.w3.org Sun Nov 20 15:41:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edw0Z-0003i4-25 for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:41:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12073 for ; Sun, 20 Nov 2005 15:41:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edvzx-00039N-11 for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:41:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Edvzw-00038o-HE for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:41:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Edvzr-0003ww-TN for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:41:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKfADM003372; Sun, 20 Nov 2005 12:41:10 -0800 Date: Sun, 20 Nov 2005 12:41:10 -0800 Message-Id: <200511202041.jAKKfADM003372@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Edvzr-0003ww-TN 8e27e0f01de15246190f163cb8dab343 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 184] New: Section 19.8 added with no open issue nor WG consensus X-Archived-At: http://www.w3.org/mid/200511202041.jAKKfADM003372@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10530 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:41:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=184 Summary: Section 19.8 added with no open issue nor WG consensus Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.19.8 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 19. Security Considerations AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org I don't recall any WG consensus for adding the stuff in . ------- 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@frink.w3.org Sun Nov 20 15:43:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edw1l-0003yz-L6 for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:43:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12120 for ; Sun, 20 Nov 2005 15:42:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edw1C-0003GU-8D for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:42:34 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Edw1B-0003Fs-H0 for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:42:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Edw18-0008EB-IU for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:42:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKgTmF003388; Sun, 20 Nov 2005 12:42:29 -0800 Date: Sun, 20 Nov 2005 12:42:29 -0800 Message-Id: <200511202042.jAKKgTmF003388@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Edw18-0008EB-IU 52e3f52f5965694d96222137faa2b712 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 185] New: Missing interpunction in "previous authors" subsection X-Archived-At: http://www.w3.org/mid/200511202042.jAKKgTmF003388@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10531 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:42:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=185 Summary: Missing interpunction in "previous authors" subsection Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.21.1 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 21. Acknowledgements AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de 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@frink.w3.org Sun Nov 20 15:51:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edw9d-000504-75 for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:51:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12503 for ; Sun, 20 Nov 2005 15:50:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Edw8w-0005fD-EL for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:50:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Edw8u-0005ea-Ke for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:50:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Edw8s-0007wb-Mm for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:50:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKoT4C003459; Sun, 20 Nov 2005 12:50:29 -0800 Date: Sun, 20 Nov 2005 12:50:29 -0800 Message-Id: <200511202050.jAKKoT4C003459@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Edw8s-0007wb-Mm ce56aa5f8ac571181cd56f6d9b3716db X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 186] New: opaquelocktoken appendix X-Archived-At: http://www.w3.org/mid/200511202050.jAKKoT4C003459@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10532 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:50:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=186 Summary: opaquelocktoken appendix Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://http://greenbytes.de/tech/webdav/draft-ietf- webdav-rfc2518bis-08.html#rfc.section.C OS/Version: other Status: NEW Severity: minor Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org "The 'opaquelocktoken' URI scheme was defined in RFC2518 (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time. This scheme has been obsoleted by [9], but is re-defined here for clarity." No, it has not been obsoleted. "A server MAY generate one ore more UUIDs to use with the 'opaquelocktoken' scheme as lock tokens. A server MAY reuse a UUID with extension characters added. If the server does this then the algorithm generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID." Correct, but the first sentence doesn't say anything meaninful. "OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID. Note that white space (LWS) is not allowed between elements of this production." Please make this a figure, and make sure that ABNF comments are properly formatted. ------- 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@frink.w3.org Sun Nov 20 15:53:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdwBt-0005LI-3m for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 15:53:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12624 for ; Sun, 20 Nov 2005 15:53:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdwBI-0005oE-UA for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 20:53:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdwBI-0005na-98 for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 20:53:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdwBD-0005iK-Bx for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 20:52:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKKqrns003475; Sun, 20 Nov 2005 12:52:53 -0800 Date: Sun, 20 Nov 2005 12:52:53 -0800 Message-Id: <200511202052.jAKKqrns003475@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdwBD-0005iK-Bx 7d812ee423ad66a1a00b247f8eda9be3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 187] New: Changes section organization X-Archived-At: http://www.w3.org/mid/200511202052.jAKKqrns003475@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10533 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 20:53:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=187 Summary: Changes section organization Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.D OS/Version: other Status: NEW Severity: minor Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org "Summary of changes from RFC2518" is something that will be published in the RFC, but the subsequent subsections won't. Thus: - make "Summary of changes from RFC2518" an appendix of it's own - put the rest into a new appendix with the note "To be removed by the RFC Editor before publication". ------- 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@frink.w3.org Sun Nov 20 16:05:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdwNM-00077i-02 for webdav-archive@megatron.ietf.org; Sun, 20 Nov 2005 16:05:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13244 for ; Sun, 20 Nov 2005 16:04:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EdwMg-0008Bu-8v for w3c-dist-auth-dist@listhub.w3.org; Sun, 20 Nov 2005 21:04:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EdwMe-0008BF-RW for w3c-dist-auth@listhub.w3.org; Sun, 20 Nov 2005 21:04:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EdwMa-0007KY-V1 for w3c-dist-auth@w3.org; Sun, 20 Nov 2005 21:04:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAKL4dwb003514; Sun, 20 Nov 2005 13:04:39 -0800 Date: Sun, 20 Nov 2005 13:04:39 -0800 Message-Id: <200511202104.jAKL4dwb003514@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EdwMa-0007KY-V1 29b42115e034c128e867db06b3d33404 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 188] New: PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/200511202104.jAKL4dwb003514@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10534 X-Loop: w3c-dist-auth@w3.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: Sun, 20 Nov 2005 21:04:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188 Summary: PROPFIND include-dead-props Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.8.2.4 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 QAContact: w3c-dist-auth@w3.org We talked about this during the interim meeting in January 2003, discussing the proposal in . Back then, we reached consensus, but recent tests show that what we agreed upon back then doesn't have all the semantics needed. What we initially proposed was to extend PROPFIND/allprop by specifiying additional live properties. What we ended with was an extension to PROPFIND/prop, including dead properties. The difference here is that with the originally proposed extension, the client can tell whether the server evaluated the extension, while with the definition in RCF2518bis, it can't (it has no way knowing whether the server just ignored the extension, or happens to have no dead properties). We therefore would like the spec to add an extension based on what we proposed in , that is extending DAV:allprop with an "include" element. ------- 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@frink.w3.org Mon Nov 21 07:35:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeAsv-0001PF-Q8 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 07:35:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25670 for ; Mon, 21 Nov 2005 07:34:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeArG-0007A1-CJ for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 12:33:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeArB-000794-M3 for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 12:33:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeAr8-0000Hn-Lj for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 12:33:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALCX9i8004281; Mon, 21 Nov 2005 04:33:09 -0800 Date: Mon, 21 Nov 2005 04:33:09 -0800 Message-Id: <200511211233.jALCX9i8004281@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EeAr8-0000Hn-Lj 3c0e39491dde8653d21f02962ce2d90c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 168] Revert to original reference style X-Archived-At: http://www.w3.org/mid/200511211233.jALCX9i8004281@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10535 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 12:33:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=168 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-21 04:33 ------- *** Bug 66 has been marked as a duplicate of this bug. *** ------- 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@frink.w3.org Mon Nov 21 07:35:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeAsv-0001PJ-R5 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 07:35:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25671 for ; Mon, 21 Nov 2005 07:34:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeArM-0007Az-T4 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 12:33:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeArE-00079P-C7 for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 12:33:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeAr9-0006Wa-0T for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 12:33:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALCX9Vs004271; Mon, 21 Nov 2005 04:33:09 -0800 Date: Mon, 21 Nov 2005 04:33:09 -0800 Message-Id: <200511211233.jALCX9Vs004271@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeAr9-0006Wa-0T 89a757e878721bbdf31a38dcac749de3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 66] references style X-Archived-At: http://www.w3.org/mid/200511211233.jALCX9Vs004271@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10536 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 12:33:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=66 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-21 04:33 ------- *** This bug has been marked as a duplicate of 168 *** ------- 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@frink.w3.org Mon Nov 21 08:38:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBsi-0003eO-7N for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 08:38:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00619 for ; Mon, 21 Nov 2005 08:38:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeBrO-0007uE-MF for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 13:37:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeBrI-0007tg-PK for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 13:37:25 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EeBqX-0003Um-AB for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 13:37:24 +0000 Received: (qmail invoked by alias); 21 Nov 2005 13:36:14 -0000 Received: from p508FBBEC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.187.236] by mail.gmx.net (mp007) with SMTP; 21 Nov 2005 14:36:14 +0100 X-Authenticated: #1915285 Message-ID: <4381CCFD.8040706@gmx.de> Date: Mon, 21 Nov 2005 14:34:53 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: webdav WG , Lisa Dusseault Content-Type: multipart/mixed; boundary="------------020801060708040008040807" X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EeBqX-0003Um-AB 8592da2e9e775d37fbea4689032e6e48 X-Original-To: w3c-dist-auth@w3.org Subject: Fixes for editorial issues X-Archived-At: http://www.w3.org/mid/4381CCFD.8040706@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10537 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 13:37:30 +0000 This is a multi-part message in MIME format. --------------020801060708040008040807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, the attachment fixes many editorial issues: 30, 41, 57, 63, 68, 88, 89, 168, 174, 180, 182, 185, 187. Hopefully this is useful in reducing the number of open issues, and concentrating on non-editorial ones. Best regards, Julian --------------020801060708040008040807 Content-Type: text/plain; name="diffs" Content-Disposition: inline; filename="diffs" Content-Transfer-Encoding: 7bit Index: draft-ietf-webdav-rfc2518bis-latest.xml =================================================================== RCS file: /var/cvsroot/xml2rfc/draft-ietf-webdav-rfc2518bis-latest.xml,v retrieving revision 1.8 diff -r1.8 draft-ietf-webdav-rfc2518bis-latest.xml 21a22,24 > > > 23c26,28 < --- > > > 99,100c104,105 < companion document, "Requirements for a Distributed Authoring and < Versioning Protocol for the World Wide Web" (RFC2291). --- > companion document, "Requirements for a Distributed Authoring and > Versioning Protocol for the World Wide Web" . 104,105c109,110 < by RFC2291. That work was done in a separate document, < "Versioning Extensions to WebDAV" (RFC3253). --- > by . That work was done in a separate document, > "Versioning Extensions to WebDAV" . 128c133 < WebDAV uses XML to marshal complicated --- > WebDAV uses to marshal complicated 149c154 < RFC2616, including the rules about --- > , including the rules about 152c157 < section 2.2 of RFC2616, these rules apply to this document as --- > section 2.2 of , these rules apply to this document as 158c163 < this document are to be interpreted as described in RFC2119. --- > this document are to be interpreted as described in . 173c178 < them) are defined in RFC3986. --- > them) are defined in . 236,237c241,242 < properties include cases where a) the value of a property is read- < only, maintained by the server, and b) the value of the property is --- > properties include cases where a) the value of a property is read-only, > maintained by the server, and b) the value of the property is 263c268 < information either in an XML --- > information either in an 303,304c308,309 < because of its support for multiple character sets. XML's self- < describing nature allows any property's value to be extended by --- > because of its support for multiple character sets. XML's self-describing > nature allows any property's value to be extended by 324a330 > 329c335 < further XML elements, namespace names that are in scope for that part of --- > further XML elements, namespace declarations that are in scope for that part of 364c370 < The XML namespace mechanism, which is based on URIs, is --- > The XML namespace mechanism, which is based on URIs (), is 413c419 <
--- >
436,437c442,443 < Although implicit in RFC2616 and < RFC3986, any resource, --- > Although implicit in and > , any resource, 451,452c457,458 < containing collection's URL plus an additional segment for non- < collection resources, or additional segment plus trailing slash "/" --- > containing collection's URL plus an additional segment for non-collection > resources, or additional segment plus trailing slash "/" 454c460 < RFC3986. --- > . 569,570c575,576 < band communication channel to coordinate their work (e.g., face-to- < face interaction, written notes, post-it notes on the screen, --- > band communication channel to coordinate their work (e.g., face-to-face > interaction, written notes, post-it notes on the screen, 643,644c649,650 < and to use the URI form defined by A Universally Unique < Identifier (UUID) URN Namespace. However --- > and to use the URI form defined by "A Universally Unique > Identifier (UUID) URN Namespace" (). However 906,907c912,913 < a Content-Type if any is known. If the client supplies a Content- < Type value the server MUST set that value (this requirement actually --- > a Content-Type if any is known. If the client supplies a Content-Type > value the server MUST set that value (this requirement actually 943,944c949,950 < MOVE a member into the collection, unless it overwrites a pre- < existing member --- > MOVE a member into the collection, unless it overwrites a pre-existing > member 946,947c952,953 < COPY a member into a collection, unless it overwrites a pre- < existing member --- > COPY a member into a collection, unless it overwrites a pre-existing > member 1111c1117 < XML parsers that are compliant with XML --- > XML parsers that are compliant with 1114,1115c1120,1121 < formed and use namespaces correctly. If a server receives non- < wellformed XML in a request it MUST reject the entire request with a --- > formed and use namespaces correctly. If a server receives non-wellformed > XML in a request it MUST reject the entire request with a 1185c1191 < (section 1.6 of RFC3253). The mechanism is appropriate to use with --- > (section 1.6 of ). The mechanism is appropriate to use with 1277,1278c1283,1284 < properties (see RFC3253 and < RFC3744) --- > properties (see and > ) 1582,1583c1588,1589 < 403 (Forbidden): The client has attempted to set a read- < only property, such as getetag. If returning this error, the server --- > 403 (Forbidden): The client has attempted to set a read-only > property, such as getetag. If returning this error, the server 1707,1708c1713,1714 < Responses from a MKCOL request MUST NOT be cached as MKCOL has non- < idempotent semantics. --- > Responses from a MKCOL request MUST NOT be cached as MKCOL has non-idempotent > semantics. 1840,1841c1846,1847 < The server MAY return a 4xx status response, rather than a Multi- < Status, if the request failed. --- > The server MAY return a 4xx status response, rather than a Multi-Status, > if the request failed. 1844,1845c1850,1851 < 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi- < Status) response for DELETE. They can be safely left out because the client will know --- > 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status) > response for DELETE. They can be safely left out because the client will know 1848,1849c1854,1855 < 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi- < Status). The reason for this prohibition is that 204 (No Content) --- > 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The > reason for this prohibition is that 204 (No Content) 1914c1920 < As defined in RFC2616, the "PUT method requests that the enclosed --- > As defined in , the "PUT method requests that the enclosed 2015a2022 > 2018c2025 < consistent namespace at the destination (see for the --- > consistent namespace at the destination (see for the 2032,2033c2039,2040 < /a/c/. Similarly, after encountering an error copying a non- < collection resource as part of an infinite depth copy, the server --- > /a/c/. Similarly, after encountering an error copying a non-collection > resource as part of an infinite depth copy, the server 2087,2088c2094,2095 < of the source and destination URLs, appear in the body of the multi- < status response. E.g. if a destination resource was locked and could --- > of the source and destination URLs, appear in the body of the multi-status > response. E.g. if a destination resource was locked and could 2298,2299c2305,2306 < moving /a/c/. Similarly, after encountering an error moving a non- < collection resource as part of an infinite depth move, the server --- > moving /a/c/. Similarly, after encountering an error moving a non-collection > resource as part of an infinite depth move, the server 2344,2345c2351,2352 < of the source and destination URLs, appear in the body of the multi- < status response. E.g. if a source resource was locked and could not --- > of the source and destination URLs, appear in the body of the multi-status > response. E.g. if a source resource was locked and could not 2483c2490 < --- > 2613c2620,2621 < h --- > > 2630a2639 > 2674,2675c2683,2684 < urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4< < /D:href> --- > >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 2948,2949c2957,2958 < IETF RFC process are tokens, but other identifiers SHOULD be Coded- < URLs to encourage uniqueness. --- > IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs > to encourage uniqueness. 3059c3068 < defined in RFC3986. --- > defined in . 3102c3111 < header defined in section 14.24 of RFC2616. However the If --- > header defined in section 14.24 of . However the If 3125,3126c3134 < Note that the absolute-URI production is defined in < RFC3986. --- > Note that the absolute-URI production is defined in . 3294,3295c3302,3303 < its cache. When dealing with HTTP/1.0 proxies the "Pragma: no- < cache" request header MUST be used for the same reason. --- > its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" > request header MUST be used for the same reason. 3406c3414 < RFC2616. --- > . 3640,3641c3648,3649 < wire. For example, it is illegal to use a space character or double- < quote in a URI. URIs appearing in PROPFIND or PROPPATCH --- > wire. For example, it is illegal to use a space character or double-quote > in a URI. URIs appearing in PROPFIND or PROPPATCH 3664c3672 < XML. The --- > . The 3675c3683,3684 < --- > > 3688d3696 <
3735a3744 >
3776c3785 < URI (See section 3.2.1 of RFC2616) --- > URI (See section 3.2.1 of ) 3811a3821 > 3826d3835 <
3859a3869 >
3860a3871 > 3875d3885 < 3891a3902 > 3892a3904 > 3911d3922 < 3915c3926,3927 < locktype --- > > response 3936,3937d3947 < < 3961c3971,3972 < status-line (status-line defined in RFC2616 --- > > status-line (status-line defined in Section 6.1 of ) 3970a3982,3983 > > 3985a3999 > 4032a4047 > 4047d4061 < 4089a4104 > 4090a4106 > 4107d4122 < 4153a4169 > 4179c4195 < declaration using the format defined in XML. --- > declaration using the format defined in . 4205c4221 < date-time (defined in RFC3339, see the ABNF in section --- > date-time (defined in , see the ABNF in section 4263c4279 < RFC2616) --- > ) 4287c4303 < content-length (see section 14.14 of RFC2616) --- > content-length (see section 14.14 of ) 4312c4328 < media-type (defined in section 3.7 of RFC2616) --- > media-type (defined in section 3.7 of ) 4336c4352 < entity-tag (defined in section 3.11 of RFC2616) --- > entity-tag (defined in section 3.11 of ) 4362c4378 < rfc1123-date (defined in section 3.3.1 of RFC2616) --- > rfc1123-date (defined in section 3.3.1 of ) 4380,4381c4396,4397 < on any DAV compliant resource that returns the Last- < Modified header in response to a GET. --- > on any DAV compliant resource that returns the Last-Modified > header in response to a GET. 4419a4436 > 4454,4455c4471,4472 < urn:uuid:f81de2ad-7f3d-a1b2-4f3c < -00a0c91a9d76 --- > >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 4496,4497c4513,4514 < recognized child elements it should be treated as a non- < collection WebDAV-compliant resource. --- > recognized child elements it should be treated as a non-collection > WebDAV-compliant resource. 4778c4795 < compliant with RFC2616. --- > compliant with . 4801,4802c4818,4819 < lockdiscovery property, the Time-Out response header and the Lock- < Token request header. A class "2" compliant resource SHOULD also --- > lockdiscovery property, the Time-Out response header and the Lock-Token > request header. A class "2" compliant resource SHOULD also 4843c4860 < with the IETF Character Set Policy RFC2277. In this specification, --- > with the IETF Character Set Policy . In this specification, 4849c4866 < encoded, at minimum, using the UTF-8 RFC2279 and UTF-16 encodings of --- > encoded, at minimum, using the UTF-8 and UTF-16 encodings of 4852c4869 < Content-Type header, as defined in RFC2376, as well as the XML --- > Content-Type header, as defined in , as well as the XML 4860c4877 < language of its content and attributes. See XML for --- > language of its content and attributes. See for 4867c4884 < strongly encouraged to read "XML Media Types" RFC2376 for --- > strongly encouraged to read "XML Media Types" for 4919,4920c4936,4937 < RFC2616) and XML (discussed in < RFC2376) also apply to WebDAV. In --- > ) and XML (discussed in > ) also apply to WebDAV. In 4953c4970 < RFC2069. Since Digest authentication verifies that both parties to --- > . Since Digest authentication verifies that both parties to 5037c5054 < section 4.2.2 of XML, which instruct an XML processor to --- > section 4.2.2 of , which instruct an XML processor to 5041,5045c5058,5061 < used to include XML within the content of an XML document. For non- < validating XML, such as the XML used in this specification, < including an external XML entity is not required by < XML. However, < XML does state that an XML processor may, at its --- > used to include XML within the content of an XML document. For non-validating > XML, such as the XML used in this specification, > including an external XML entity is not required by XML. However, > XML does state that an XML processor may, at its 5054c5070 < XML processor to the security risks discussed in RFC2376. --- > XML processor to the security risks discussed in . 5074,5075c5090,5091 < This specification requires the use of A Universally < Unique Identifier (UUID) URN Namespace for lock tokens, in order to guarantee --- > This specification requires the use of "A Universally > Unique Identifier (UUID) URN Namespace" () for lock tokens, in order to guarantee 5129c5145 < --- > 5159,5160c5175,5176 < Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners- < Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith --- > Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, > Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith 5204a5221 > 5206,5223d5222 < < Editors of RFC2518 < < < < Y. Y. Goland < Microsoft Corporation < One Microsoft Way < Redmond, WA 98052-6399 < Email: yarong@microsoft.com < < < E. J. Whitehead, Jr. < Dept. Of Information and Computer Science < University of California, Irvine < Irvine, CA 92697-3425 < Email: ejw@ics.uci.edu < 5225,5245c5224,5258 < A. Faizi < Netscape < 685 East Middlefield Road < Mountain View, CA 94043 < Email: asad@netscape.com < < < S. R. Carter < Novell < 1555 N. Technology Way < M/S ORM F111 < Orem, UT 84097-2399 < Email: srcarter@novell.com < < < D. Jensen < Novell < 1555 N. Technology Way < M/S ORM F111 < Orem, UT 84097-2399 < Email: dcjensen@novell.com --- > Y. Y. Goland, > Microsoft Corporation, > One Microsoft Way, > Redmond, WA 98052-6399. > Email: yarong@microsoft.com. > > > E. J. Whitehead, Jr., > Dept. Of Information and Computer Science, > University of California, Irvine, > Irvine, CA 92697-3425. > Email: ejw@ics.uci.edu. > > > A. Faizi, > Netscape, > 685 East Middlefield Road, > Mountain View, CA 94043. > Email: asad@netscape.com. > > > S. R. Carter, > Novell, > 1555 N. Technology Way, > M/S ORM F111, > Orem, UT 84097-2399. > Email: srcarter@novell.com. > > > D. Jensen, > Novell, > 1555 N. Technology Way, > M/S ORM F111, > Orem, UT 84097-2399. > Email: dcjensen@novell.com. 5267d5279 < &w3cXML; 5268a5281,5319 > > > > Extensible Markup Language (XML) 1.0 (Third Edition) > > Textuality and Netscape >
> tbray@textuality.com >
> > > Microsoft >
> jeanpa@microsoft.com >
> > > University of Illinois at Chicago and Text Encoding Initiative >
> cmsmcq@uic.edu >
> > > Sun Microsystems >
> eve.maler@east.sun.com >
> > > >
> francois@yergeau.com >
> > > > > > 5470c5521 < Extension = path ; path is defined in section 3.3 of RFC3986 --- > Extension = path ; path is defined in section 3.3 of 5476,5477c5527,5528 <
<
--- > >
5527c5578 < --- > 5546,5547c5597,5599 < < --- > > >
--------------020801060708040008040807 Content-Type: text/xml; name="draft-ietf-webdav-rfc2518bis-latest.xml.jr" Content-Disposition: inline; filename="draft-ietf-webdav-rfc2518bis-latest.xml.jr" Content-Transfer-Encoding: 7bit ]> HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis Open Source Application Foundation
2064 Edgewood Dr. Palo Alto CA 94303 US lisa@osafoundation.org
Applications WebDAV webdav http authoring web WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes minor revisions mostly due to interoperability experience.
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for: Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Also, the ability to link pages of any media type to related pages. Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system). Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem", in which modifications are lost as first one author then another writes changes without merging the other author's changes. Namespace Operations: The ability to instruct the server to copy and move Web resources. Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" . This standard does not specify the versioning operations suggested by . That work was done in a separate document, "Versioning Extensions to WebDAV" . The sections below provide a detailed introduction to resource properties, collections of resources, and locking operations. These sections introduce the abstractions manipulated by the WebDAV-specific HTTP methods and the new HTTP headers used with WebDAV methods. While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines new status codes developed for WebDAV methods and describes existing HTTP status codes as used in WebDAV. Since some WebDAV methods may operate over many resources, the Multi-Status response has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces XML elements in error response bodies in . WebDAV uses to marshal complicated request and response information, as well as to express metadata, so this specification contains definitions of all XML elements used. WebDAV includes a few special rules on how to process XML appearing in WebDAV so that it truly is extensible. Finishing off the specification are sections on what it means for a resource to be compliant with this specification, on internationalization support, and on security.
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in section 2.1 of , including the rules about implied linear white-space. Since this augmented BNF uses the basic production rules provided in section 2.2 of , these rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Note that in natural language, a property like the "creationdate" property in the "DAV:" namespace is sometimes referred to as "DAV:creationdate" for brevity.
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in . Collection - A resource that contains a set of URLs, which identify and locate member resources and which meet the collections requirements. Member URL - A URL which is a member of the set of URLs contained by a collection. Internal Member URL - A Member URL that is immediately relative to the URL of the collection (the definition of immediately relative is given later). Property - A name/value pair that contains descriptive information about a resource. Live Property - A property whose semantics and syntax are enforced by the server. For example, the live "getcontentlength" property has its value, the length of the entity returned by a GET request, automatically calculated by the server. Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property. Principal - A "principal" is a distinct human or computational actor that initiates access to network resources.
Properties are pieces of data that describe the state of a resource. Properties are data about data. Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents. The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics. There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is read-only, maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus a mechanism is needed which allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support. In addition to encoding method parameters, XML is used in WebDAV to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input. The XML namespace extension is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group. Note that "DAV:" uses a scheme name defined solely for the purpose of creating this namespace. Defining new schemes for namespaces is discouraged. "DAV:" was defined before standard best practices emerged, and this namespace is still used only because of significant existing deployments.
The value of a property is always a (well-formed) XML fragment. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. A property is always represented in XML with an XML element consisting of the property name. The simplest example is an empty property, which is different from a property that does not exist. <R:title xmlns:R="http://www.example.com/ns/"></R:title> The value of a property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. When the property value contains further XML elements, namespace declarations that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. Namespace prefixes need not be preserved due to the rules of prefix declaration in XML. Attributes on the property name element may convey information about the property, but are not considered part of the value. However, when language information appears in the 'xml:lang' attribute on the property name element, the language information MUST be preserved in server storage for retransmission later. Note that a property only has one value, in one language (or language MAY be left undefined), not multiple values in different languages or a single value in multiple languages. The XML attribute xml:space MUST NOT be used to change white space handling. White space in property values is significant.
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property. Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition. The XML namespace mechanism, which is based on URIs (), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control. The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced which will address issues relating to hierarchical properties. Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
This section provides a description of a new type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace. All DAV compliant resources MUST support the HTTP URL namespace model specified herein.
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character. An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. The root, or top-level collection of the namespace under consideration is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/', it may be identified by one or more path segments (e.g. /servlets/webdav/...) Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies. Although implicit in and , any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
A collection is a resource whose state consists of at least a list of internal member URLs and a set of properties, but which may have additional state such as entity bodies returned by GET. An internal member URL MUST be immediately relative to a base URL of the collection. That is, the internal member URL is equal to a containing collection's URL plus an additional segment for non-collection resources, or additional segment plus trailing slash "/" for collection resources, where segment is defined in section 3.3 of . Any given internal member URL MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URL in a collection. Properties defined on collections behave exactly as do properties on non-collection resources. For all WebDAV compliant resources A and B, identified by URLs U and V, for which U is immediately relative to V, B MUST be a collection that has U as an internal member URL. So, if the resource with URL http://example.com/bar/blah is WebDAV compliant and if the resource with URL http://example.com/bar/ is WebDAV compliant then the resource with URL http://example.com/bar/ must be a collection and must contain URL http://example.com/bar/blah as an internal member. Collection resources MAY list the URLs of non-WebDAV compliant children in the HTTP URL namespace hierarchy as internal members but are not required to do so. For example, if the resource with URL http://example.com/bar/blah is not WebDAV compliant and the URL http://example.com/bar/ identifies a collection then URL http://example.com/bar/blah may or may not be an internal member of the collection with URL http://example.com/bar/. If a WebDAV compliant resource has no WebDAV compliant children in the HTTP URL namespace hierarchy then the WebDAV compliant resource is not required to be a collection. There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. In this case it SHOULD return a Content-Location header in the response, pointing to the URL ending with the "/". For example, if a client invokes a method on http://example.com/blah (no trailing slash), the server may respond as if the operation were invoked on http://example.com/blah/ (trailing slash), and should return a Content-Location header with the value http://example.com/blah/. Wherever a server produces a URL referring to a collection, the server MUST include the trailing slash. In general clients SHOULD use the "/" form of collection names. Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if a OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections.
The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem. This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.
The most basic form of lock is an exclusive lock. Only one exclusive lock may exist on any resource, whether it is directly or indirectly locked. Exclusive locks avoid having to merge results, without requiring any coordination other than the methods described in this specification. However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal with appropriate access can use the lock. With shared locks there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set. Starting with every possible principal on the Internet, in most situations the vast majority of these principals will not have write access to a given resource. Of the small number who do have write access, some principals may decide to guarantee their edits are free from overwrite conflicts by using exclusive write locks. Others may decide they trust their collaborators will not overwrite their work (the potential set of collaborators being the set of principals who have write permission) and use a shared lock, which informs their collaborators that a principal may be working on the resource. The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out of band communication channel to coordinate their work (e.g., face-to-face interaction, written notes, post-it notes on the screen, telephone conversation, Email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource. Shared locks are included because experience from web distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example when a program crashes, or when a lock owner leaves without unlocking a resource. While both timeouts and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
A WebDAV compliant resource is not required to support locking in any form. If the resource does support locking it may choose to support any combination of exclusive and shared locks for any access types. The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks while others only provide support for exclusive write locks while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
A lock token is a type of state token, represented as a URI, which identifies a particular lock. Each lock has exactly one unique lock token generated by the server. Clients MUST NOT attempt to interpret lock tokens in any way. Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in , and also in the body of the response. Submitting a lock token does not confer full privilege to use the lock token or modify the locked resource. Anyone can find out anyone else's lock token by performing lock discovery. Write access and other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the slight obscurity of lock token values. Since lock tokens are unique, a client MAY submit a lock token in an If header on a resource other than the one that returned it. This specification encourages servers to create UUIDs for lock tokens, and to use the URI form defined by "A Universally Unique Identifier (UUID) URN Namespace" (). However servers are free to use another valid URI so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in an appendix of this document. Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. A client can determine what lock types the server supports by retrieving the supportedlock property. Any DAV compliant resource that supports the LOCK method MUST support the supportedlock property.
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and where available, provides their lock token. Any DAV compliant resource that supports the LOCK method MUST support the lockdiscovery property.
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 section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification. An exclusive write lock will prevent parallel changes to a resource by any principal other than the write lock holder. In general terms, changes affected by write locks include changes to: the content of the resource any dead property of the resource any live property defined to be lockable (all properties defined in this specification are lockable) the direct membership of the resource, if it is a collection the URL/location of a resource The next few sections describe in more specific terms how write locks interact with various operations.
The creator of the lock is the lock owner. The server MUST restrict the usage of the lock token to the lock owner (both for shared and exclusive locks -- for multi-user shared lock cases, each authenticated principal MUST obtain its own shared lock). The server MAY allow privileged users other than the lock owner to destroy a lock (for example, the resource owner or an administrator) as a special case of lock usage. If an anonymous user requests a lock, the server MAY refuse the request.
A server MUST reject any write request that alters a write-locked resource unless a valid lock token is provided. The write operations defined in HTTP and WebDAV are PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL. All other HTTP/WebDAV methods, GET in particular, function independently of the lock. A shared write lock prevents the same operations, however it also allows access by any principal that has a shared write lock on the same resource. Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.
A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal.
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked.
Although the write locks provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario: Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking. Client A doesn't lock the document, but does a GET and begins editing. Client B does LOCK, performs a GET and begins editing. Client B finishes editing, performs a PUT, then an UNLOCK. Client A performs a PUT, overwriting and losing all of B's changes. There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK. WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources. WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking. HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources. Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.
It is possible to lock an unmapped URL in order to lock the name for use. This is a simple way to avoid the lost-update problem on the creation of a new resource (another way is to use If-None-Match header specified in HTTP 1.1). It has the side benefit of locking the new resource immediately for use of the creator. 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. When trying to lock a collection upon creation, clients may attempt to increase the likelihood of this by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation there's no guarantee this will work). A lock request to an unmapped URL SHOULD result in the creation of an locked resource with empty content. A subsequent PUT request with the correct lock token SHOULD normally succeed, and this new request provides the content, content-type, content-language and other information as appropriate. In this situation, a WebDAV server that was implemented from RFC2518 MAY create "lock-null" resources which are special and unusual resources. Historically, a lock-null resource: Responds with a 404 or 405 to any DAV method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. Appears as a member of its parent collection. Disappears (URI becomes unmapped) if its lock goes away before it is converted to a regular resource. (This must also happen if it is renamed or moved, or if any parent collection is renamed or moved, because locks are tied to URLs). May be turned into a regular resource when a PUT request to the URL is successful. Ceases to be a lock-null resource. May be turned into a collection when a MKCOL request to the URL is successful. Ceases to be a lock-null resource. Has defined values for lockdiscovery and supportedlock properties. However, interoperability and compliance problems have been found with lock-null resources. Therefore, they are deprecated. WebDAV servers SHOULD create regular locked empty resources, which are and behave in every way as normal resources. A locked empty resource: Can be read, deleted, moved, copied, and in all ways behave as a regular resource, not a lock-null resource. Appears as a member of its parent collection. SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation) SHOULD default to having no content type. MAY NOT have values for properties like getcontentlanguage which haven't been specified yet by the client. May have content added with a PUT request. MUST be able to change content type. MUST NOT be turned into a collection. A MKCOL request must fail as it would to any existing resource. MUST have defined values for lockdiscovery and supportedlock properties. The response MUST indicate that a resource was created, by use of the "201 Created" response code (a LOCK request to an existing resource instead will result in 200 OK). The body must still include the lockdiscovery property, as with a LOCK request to an existing resource. The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH. When the client uses PUT to overwrite a locked empty resource the client MUST supply a Content-Type if any is known. If the client supplies a Content-Type value the server MUST set that value (this requirement actually applies to any resource that is overwritten but is particularly necessary for locked empty resources which are initially created with no Content-Type. Clients can easily interoperate both with servers that support the deprecated lock-null resources and servers that support simpler locked empty resources by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET.
A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URLs of the collection by non-lock owners. A zero-depth lock on a collection affects changes to the direct membership of that collection. When a principal issues a write request to create a new resource in a write locked collection, or isses a DELETE, MOVE or other request that would remove an existing internal member URL of a write locked collection or change the binding name, this request MUST fail if the principal does not provide the correct lock token for the locked collection. This means that if a collection is locked (depth 0 or infinity), its lock-token is required in all these cases: DELETE a collection's direct internal member MOVE a member out of the collection MOVE a member into the collection, unless it overwrites a pre-existing member MOVE to rename it within a collection, COPY a member into a collection, unless it overwrites a pre-existing member PUT or MKCOL request which would create a new member. The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately. In addition, a depth-infinity lock affects all write operations to all descendents of the locked collection. With a depth-infinity lock, the root of the lock is directly locked, and all its descendants are indirectly locked. Any new resource added as a descendent of a depth-infinity locked collection becomes indirectly locked. Any indirectly locked resource moved out of the locked collection into an unlocked collection is thereafter unlocked. Any indirectly locked resource moved out of a locked source collection into a depth-infinity locked target collection remains indirectly locked but is now within the scope of the lock on the target collection (the target collection's lock token will thereafter be required to make further changes). If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'missing-lock-token' precondition. If a lock owner causes the URL of a resource to be added as an internal member URL of a depth-infinity locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock.
If a user agent is not required to have knowledge about a lock when requesting an operation on a locked resource, the following scenario might occur. Program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by Program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization. In order to prevent these collisions a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted in the if header, one for the source and the other for the destination.
Example - Write Lock >Request COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html If: () >>Response HTTP/1.1 204 No Content ]]>
In this example, even though both the source and destination are locked, only one lock token must be submitted, for the lock on the destination. This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with "Depth: infinity", then the resource will be added to the lock. A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, the resource is subject to being added to an existing lock at the destination (see ). For example, if the MOVE makes the resource a child of a collection that is locked with "Depth: infinity", then the resource will be added to that collection's lock. Additionally, if a resource locked with "Depth: infinity" is moved to a destination that is within the scope of the same lock (e.g., within the namespace tree covered by the lock), the moved resource will again be a added to the lock. In both these examples, as specified in , an If header must be submitted containing a lock token for both the source and destination.
A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked. However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set. A server may return a Timeout header with a lock refresh that is different than the Timeout header returned when the lock was originally requested. Additionally clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client. Note that timeout is measured in seconds remaining until expiration. If an error is received in response to a refresh LOCK request the client MUST NOT assume that the lock was refreshed.
Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with and XML Namespaces. All XML used in either requests or responses MUST be, at minimum, well formed and use namespaces correctly. If a server receives non-wellformed XML in a request it MUST reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response then it MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as they intended.
HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible.
HTTP 1.1 recommends the use of the ETag header in responses to GET and PUT requests. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem. A client might fail to renew a lock, for example when the lock times out and the client is accidentally offline or in the middle of a long upload. When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user whether it has changed. Timestamps do not solve this problem nearly as well as ETags. WebDAV servers SHOULD support strong ETags for all resources that may be PUT. If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the 'getetag' property. Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or getlastmodified value) for a resource that has an unchanged body. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed.
HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of ). The mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This mechanism does not take the place of using a correct numeric error code as defined here or in HTTP, because the client MUST always be able to take a reasonable course of action based only on the numeric error. However, it does remove the need to define new numeric error codes, avoiding the confusion of who is allowed to define such new codes. The codes used in this mechanism are XML elements in a namespace, so naturally any group defining a new error code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups. A server supporting "bis" SHOULD include a specific XML error code in a "DAV:error" response body element, when a specific XML error code is defined in this document. The DAV:error element may contain multiple elements describing specific errors. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank.
]]>
In this specification, both the numeric and the XML error code are defined for some failure situations, in which case the XML error code must have the "DAV:" namespace, appear in the "error" root element, and be returned in a body with the numeric error code specified.
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs. All DAV compliant resources MUST support the PROPFIND method and the propfind XML element () along with all XML elements defined for use with that element. A client may submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND on a collection resource. Servers MUST support the "0", "1" and "infinity" behaviors on WebDAV-compliant resources. By default, the PROPFIND method without a Depth header MUST act as if a "Depth: infinity" header was included. A client may submit a propfind XML element in the body of the request method describing what information is being requested. It is possible to: Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by server) Request all dead property values, by using 'dead-props' element. This can be combined with retrieving specific live properties named as above. Servers advertising support for RFC2518bis MUST support this feature. Request property values for those properties defined in this specification plus dead properties, by using 'allprop' element Request a list of names of all the properties defined on the resource, by using the 'propname' element. A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request. Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see and ) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. A WebDAV server MAY omit certain live properties from other specifications when responding to an allprop request from an older client, and MAY return only custom (dead) properties and those defined in this specification. All servers MUST support returning a response of content type text/xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties. If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element which contains a 404 (Not Found) status value. Consequently, the multistatus XML element for a collection resource with member URLs MUST include a response XML element for each member URL of the collection, to whatever depth was requested. Each response XML element MUST contain an href XML element that gives the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URLs are returned as a flat list whose order of entries is not significant. Properties may be subject to access control. In the case of allprop and propname, if a principal does not have the right to know whether a particular property exists then the property MAY be silently excluded from the response. The results of this method SHOULD NOT be cached.
A server MAY fail an entire PROPFIND request with an appropriate status code and MAY redirect the entire request. In addition, the following error codes are specifically defined for PROPFIND requests: 403 Forbidden - A server MAY reject all PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the element 'propfind-infinite-depth-forbidden' inside the error body.
The following status codes are defined for use within the PROPFIND Multi-Status response: 200 OK - A property exists and/or its value is successfully returned. 401 Unauthorized - The property cannot be viewed without appropriate authorization. 403 Forbidden - The property cannot be viewed regardless of authentication. 404 Not Found - The property does not exist.
>Request PROPFIND /file HTTP/1.1 Host: www.example.com Content-type: text/xml; charset="utf-8" Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/file Box type A J.J. Johnson HTTP/1.1 200 OK HTTP/1.1 403 Forbidden The user does not have access to the DingALing property. There has been an access violation error. ]]>
In this example, PROPFIND is executed on a non-collection resource http://www.example.com/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
>Request PROPFIND /mycol/ HTTP/1.1 Host: www.example.com Depth: 1 Content-type: text/xml; charset="utf-8" Content-Length: xxxx ]]>
In this example, PROPFIND is executed on a collection resource http://www.example.com/mycol/. The client requests the values of two specific live properties plus all dead properties (names and values). The response is not shown.
>Request PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/container/ HTTP/1.1 200 OK http://www.example.com/container/front.html HTTP/1.1 200 OK ]]>
In this example, PROPFIND is invoked on the collection resource http://www.example.com/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its descendents should be returned. Consistent with the previous example, resource http://www.example.com/container/ has six properties defined on it: bigbox and author in the "http://www.example.com/boxschema/" namespace, and creationdate, displayname, resourcetype, and supportedlock in the "DAV:" namespace. The resource http://www.example.com/container/index.html, a member of the "container" collection, has nine properties defined on it, bigbox in the "http://www.example.com/boxschema/" namespace and, creationdate, displayname, getcontentlength, getcontenttype, getetag, getlastmodified, resourcetype, and supportedlock in the "DAV:" namespace. This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI. All DAV compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV compliant resources SHOULD support the setting of arbitrary dead properties. The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Instruction processing MUST occur in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus if any error occurs during processing all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in sections 13.23 and section 13.24.
The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. 200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate. 403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties. 403 (Forbidden): The client has attempted to set a read-only property, such as getetag. If returning this error, the server SHOULD use 'read-only-property' inside the response body. 409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. 423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it. This response SHOULD contain the 'missing-lock-token' precondition element. 424 (Failed Dependency) - The property change could not be made because of another property change that failed. 507 (Insufficient Storage) - The server did not have sufficient space to record the property.
>Request PROPPATCH /bar.html HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Jim Whitehead Roy Fielding >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/bar.html HTTP/1.1 424 Failed Dependency HTTP/1.1 409 Conflict Copyright Owner can not be deleted or altered. ]]>
In this example, the client requests the server to set the value of the "Authors" property in the "http://www.w3.com/standards/z39.50/" namespace, and to remove the property "Copyright-Owner" in the "http://www.w3.com/standards/z39.50/" namespace. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
The MKCOL method is used to create a new collection. All WebDAV compliant resources MUST support the MKCOL method. MKCOL creates a new collection resource at the location specified by the Request-URI. If the resource identified by the Request-URI is non-null then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI a member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the request must fail. When MKCOL is invoked without a request body, the newly created collection SHOULD have no members. A MKCOL request message may contain a message body. The precise behavior of a MKCOL request when the body is present is undefined, but limited to creating collections, members of a collection, bodies of members and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand it MUST respond with a 415 (Unsupported Media Type) status code. If the server decides to reject the request based on the presence of an entity or the type of an entity, it should use the 415 (Unsupported Media Type) status code.
Responses from a MKCOL request MUST NOT be cached as MKCOL has non-idempotent semantics. 201 (Created) - The collection was created. 403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its namespace, or 2) the parent collection of the Request-URI exists but cannot accept members. 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL. 409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 415 (Unsupported Media Type) - The server does not support the request type of the body. 507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
This example creates a collection called /webdisc/xfiles/ on the server www.example.com.
>Request MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.example.com >>Response HTTP/1.1 201 Created ]]>
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET when applied to a collection may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection. Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection.
Locks rooted on a resource MUST be destroyed in a successful DELETE of that resource.
When a client issues a DELETE request to a Request-URI mapping to a non-collection resource, if the operation is successful the server MUST remove that mapping. Thus, after a successful DELETE operation (and in the absence of other actions) a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found).
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity. DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted. If any resource identified by a member URL cannot be deleted then all of the member's ancestors MUST NOT be deleted, so as to maintain namespace consistency. Any headers included with DELETE MUST be applied in processing every resource to be deleted. When the DELETE method has completed processing it MUST result in a consistent namespace. If an error occurs deleting an internal resource (a resource other than the resource identified in the Request-URI) then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked. The server MAY return a 4xx status response, rather than a Multi-Status, if the request failed. 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
>Request DELETE /container/ HTTP/1.1 Host: www.example.com >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/container/resource3 HTTP/1.1 423 Locked ]]>
In this example the attempt to delete http://www.example.com/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.example.com/container/ also failed. Thus the client knows that the attempt to delete http://www.example.com/container/ must have also failed since the parent can not be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties. A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
As defined in , the "PUT method requests that the enclosed entity be stored under the supplied Request-URI." Since submission of an entity representing a collection would implicitly encode creation and deletion of resources, this specification intentionally does not define a transmission format for creating a collection using PUT. Instead, the MKCOL method is defined to create collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed).
The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource. The state of the resource to be copied is fixed at the point the server begins processing the COPY request. All WebDAV compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
When the source resource is not a collection the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
After a successful COPY invocation, all dead properties on the source resource MUST be duplicated on the destination resource, along with all properties as appropriate. Live properties described in this document SHOULD be duplicated as identically behaving live properties at the destination resource, but not necessarily with the same values. 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. A COPY operation creates a new resource, much like a PUT operation does. Live properties which are related to resource creation (such as creationdate) should have their values set accordingly.
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". Servers MUST support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources. A COPY of depth infinity instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy. Servers should of course avoid infinite recursion, and can do so by copying the source resource as it existed at the point where processing started. A COPY of "Depth: 0" only instructs that the collection and its properties but not resources identified by its internal member URLs, are to be copied. Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header. The Destination header only specifies the destination URI for the Request-URI. When applied to members of the collection identified by the Request-URI the value of Destination is to be modified to reflect the current location in the hierarchy. So, if the Request-URI is /a/ with Host header value http://example.com/ and the Destination is http://example.com/b/ then when http://example.com/a/c/d is processed it must use a Destination of http://example.com/b/c/d. When the COPY method has completed processing it MUST have created a consistent namespace at the destination (see for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite depth copy, the server SHOULD try to finish as much of the original copy operation as possible. If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status), and the URL of the resource causing the failure MUST appear with the specific error. The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail. (Extensions to WebDAV might not follow this rule to the letter but must consider backwards compatibility with clients that expect COPY to work this way.) Interoperability testing has shown that some clients expect a collection COPY to actually do a merge if a destination collection exists. That behavior is appropriate for file system folders but not necessarily for other data objects modelled as collections. Thus, implementors are urged to comply with the standard language above, and leave clients to perform a manual merge if that's the expected behavior when copying a collection over another collection.
201 (Created) - The source resource was successfully copied. The copy operation resulted in the creation of a new resource. 204 (No Content) - The source resource was successfully copied to a pre-existing destination resource. 207 (Multi-Status) - Multiple resources were to be affected by the COPY, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. E.g. if a destination resource was locked and could not be overwritten, then the destination resource URL appears with the 423 (Locked) status. 403 (Forbidden) - The operation is forbidden. Possibly this is because the source and destination resources are the same resource. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 412 (Precondition Failed) - A precondition failed, e.g. the Overwrite header is "F" and the state of the destination resource is non-null. 423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response SHOULD contain the 'missing-lock-token' precondition element. 502 (Bad Gateway) - This may occur when the destination is on another server, repository or namespace. Either the source namespace does not support copying to the destination namespace, or the destination namespace refuses to accept the resource. The client may wish to try GET/PUT and PROPFIND/PROPPATCH instead. 507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
This example shows resource http://www.ics.uci.edu/~fielding/index.html being copied to the location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No Content) status code indicates the existing resource at the destination was overwritten.
COPY with Overwrite >Request COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html >>Response HTTP/1.1 204 No Content ]]>
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination resource has a non-null state.
COPY with No Overwrite >Request COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html Overwrite: F >>Response HTTP/1.1 412 Precondition Failed ]]>
Example - COPY of a Collection >Request COPY /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Depth: infinity >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/othercontainer/R2/ HTTP/1.1 423 Locked ]]>
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example most of the resources, along with the collection, were copied successfully. However the collection R2 failed because the destination R2 is locked. Because there was an error copying R2, none of R2's members were copied. However no errors were listed for those members due to the error minimization rules.
The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs other than the Request-URI which identify the source resource, to point to the new destination resource. Consequently, the Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV compliant resources MUST support the MOVE method. However, support for the MOVE method does not guarantee the ability to move a resource to a particular destination. For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server. If a resource exists at the destination, the destination resource will be deleted as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
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 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. MOVE is frequently used by clients to rename a file without changing its parent collection, 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 after a MOVE. Dead properties must be moved along with the resource.
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the address specified in the Destination header, and all resources identified by its internal member URLs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy. The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity". Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header. The behavior of the Destination header is the same as given for COPY on collections. When the MOVE method has completed processing it MUST have created a consistent namespace at both the source and destination (see section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible. If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status), and the errored resource's URL MUST appear with the specific error. The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the move the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail.
201 (Created) - The source resource was successfully moved, and a new resource was created at the destination. 204 (No Content) - The source resource was successfully moved to a pre-existing destination resource. 207 (Multi-Status) - Multiple resources were to be affected by the MOVE, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. E.g. if a source resource was locked and could not be moved, then the source resource URL appears with the 423 (Locked) status. 403 (Forbidden) - The source and destination resources are the same. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. Or, the server was unable to preserve the behavior of the live properties and still move the resource to the destination (see 'live-properties-not-preserved' postcondition). 412 (Precondition Failed) - A condition failed, e.g. the Overwrite header is "F" and the state of the destination resource is non-null. 423 (Locked) - The source or the destination resource, or some resource within the source or destination collection, was locked. This response SHOULD contain the 'missing-lock-token' precondition element. 502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource. This could also occur when the destination is on another sub-section of the same server namespace.
This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the location http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination resource had been non-null. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
MOVE of a Non-Collection >Request MOVE /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html >>Response HTTP/1.1 201 Created Location: http://www.ics.uci.edu/users/f/fielding/index.html ]]>
MOVE of a Collection >Request MOVE /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Overwrite: F If: () () >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/othercontainer/C2/ HTTP/1.1 423 Locked ]]> In this example the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case the proper lock token was not submitted for the destination http://www.example.com/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error moving /container/C2/, none of /container/C2's members were moved. However no errors were listed for those members due to the error minimization rules. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested. Any resource which supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein. A LOCK method invocation to an unlocked resource creates a lock on the resource identified by the Request-URI, which becomes the root of the lock. Lock method requests to create a new lock MUST have a XML request body which contains an owner XML element and other information for this lock request. The server MUST preserve the information provided by the client in the owner field when the lock information is requested. The LOCK request MAY have a Timeout header. Clients MUST assume that locks may arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if extraordinary circumstances do not occur. For example, a sufficiently privileged user may remove a lock at any time or the system may crash in such a way that it loses the record of the lock's existence. When a new lock is created, the LOCK response: MUST contain a body with the value of the lockdiscovery property in a prop XML element. MUST include the Lock-Token response header with the token associated with the new lock.
A lock is refreshed by sending a LOCK request without a request body to the URL of a resource within the scope 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). It MAY contain a Timeout header, which a server MAY accept to change the duration remaining on the lock to the new value. A server MUST ignore the Depth header on a LOCK refresh. If the resource has other (shared) locks, those locks are unaffected by a lock refresh. Additionally, those locks do not prevent the named lock from being refreshed. Note that in RFC2518, clients were indicated through the example in the text to use the If header to specify what lock to refresh (rather than the Lock-Token header). Servers are encouraged to continue to support this as well as the Lock-Token header. Note that the Lock-Token header is not be returned in the response for a successful refresh LOCK request, but the LOCK response body MUST contain the new value for the lockdiscovery body.
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK method. All resources that support the LOCK method MUST support the Depth header. A Depth header of value 0 means to just lock the resource specified by the Request-URI. If the Depth header is set to infinity then the resource specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token which represents all the resources that have been locked. If an UNLOCK is successfully executed on this token, all associated resources are unlocked. If the lock cannot be granted to all resources, a 207 (Multi-Status) status code MUST be returned with a response entity body containing a multistatus XML element describing which resource(s) prevented the lock from being granted. Hence, partial success is not an option. Either the entire hierarchy is locked or no resources are locked. If no Depth header is submitted on a LOCK request then the request MUST act as if a "Depth:infinity" had been submitted.
A successful LOCK method MUST result in the creation of an empty resource which is locked (and which is not a collection), when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length and no Content-Type.
The table below describes the behavior that occurs when a lock request is made on a resource. Current State Shared Lock Request Exclusive Lock Request ---------------------------------------------------------------- None True True Shared Lock True False Exclusive Lock False False* Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice.
The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating the lock must not be granted.
200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 423 (Locked) - The resource is locked already. For consistency's sake, this response SHOULD contain the 'missing-lock-token' precondition element. 400 (Bad Request), with 'request-uri-must-match-lock-token' precondition - The LOCK request was made with a Lock-Token header, indicating that the client wishes to refresh the given lock. However, the Request-URI did not fall within the scope of the lock identified by the token. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid. 424 (Failed Dependency) - This may appear inside a 207 response to a LOCK request, to indicate that a resource could not be locked because of a failure on another resource.
>Request LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." http://www.ics.uci.edu/~ejw/contact.html >>Response HTTP/1.1 200 OK Lock-Token: Content-Type: text/xml; charset="utf-8" Content-Length: xxxx infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 http://example.com/workspace/webdav/proposal.doc< /D:href> ]]>
This example shows the successful creation of an exclusive write lock on resource http://example.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header. Note that the locktoken and lockroot href elements would not contain any whitespace. The line return appearing in this document is only for formatting.
>Request LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 Lock-Token: Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." >>Response HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4< /D:href> http://example.com/workspace/webdav/proposal.doc< /D:href> ]]> This request would refresh the lock, attempting to reset the timeout to the new value specified in the timeout header. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
>Request LOCK /webdav/ HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 Depth: infinity Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." http://www.ics.uci.edu/~ejw/contact.html >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://example.com/webdav/secret HTTP/1.1 403 Forbidden http://example.com/webdav/ HTTP/1.1 424 Failed Dependency ]]>
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock, in this case a web page URL. The error is a 403 (Forbidden) response on the resource http://example.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the lockdiscovery property for the Request-URI has been included as required. In this example the lockdiscovery property is empty which means that there are no outstanding locks on the resource. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock. 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. For a successful response to this method, the server MUST remove the lock from the resource identified by the Request-URI and from all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. A successful response to an UNLOCK method does not mean that the resource is necessarily unlocked. It means that the specific lock corresponding to the specified token no longer exists. Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method.
204 (No Content) - Normal success response (rather than 200 OK, since 200 OK would imply a response body, and an UNLOCK success response does not normally contain a body) 400 (Bad Request) - No lock token was provided (see 'missing-lock-token' precondition), or request was made to a Request-URI that was not within the scope of the lock (see 'requesturi-must-match-lock-token' precondition). 403 (Forbidden) - The currently authenticated principal does not have permission to remove the lock (the server SHOULD use the 'need-privileges' precondition element). 412 (Precondition Failed) - The resource was not locked.
>Request UNLOCK /workspace/webdav/info.doc HTTP/1.1 Host: example.com Lock-Token: Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." >>Response HTTP/1.1 204 No Content ]]>
In this example, the lock identified by the lock token "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas.
DAV = "DAV" ":" #( compliance-code ) compliance-code = ( "1" | "2" | "bis" | extend ) extend = Coded-URL | token
This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources MUST return the DAV header on all OPTIONS responses. The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs to encourage uniqueness. A resource must show class 1 compliance if it shows class 2 or "bis" compliance. In general, support for one compliance class does not entail support for any other. Please refer to section 16 for more details on compliance classes defined in this specification. 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. 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.
Depth = "Depth" ":" ("0" | "1" | "infinity")
The Depth request header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity"). The Depth header is only supported if a method's definition explicitly provides for such support. The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition. Methods which support the Depth header may choose not to support all of the header's values and may define, on a case by case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity" and if a Depth header is not present will act as if a "Depth: infinity" header had been applied. Clients MUST NOT rely upon methods executing on members of their hierarchies in any particular order or on the execution being atomic unless the particular method explicitly provides such guarantees. Upon execution, a method with a Depth header will perform as much of its assigned task as possible and then return a response specifying what it was able to accomplish and what it failed to do. So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not. Any headers on a method that has a defined interaction with the Depth header MUST be applied to all resources in the scope of the method except where alternative behavior is explicitly defined. For example, an If-Match header will have its value applied against every resource in the method's scope and will cause the method to fail if the header fails to match. If a resource, source or destination, within the scope of the method with a Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header. The Depth header only specifies the behavior of the method with regards to internal children. If a resource does not have internal children then the Depth header MUST be ignored. Please note, however, that it is always an error to submit a value for the Depth header that is not allowed by the method's definition. Thus submitting a "Depth: 1" on a COPY, even if the resource does not have internal members, will result in a 400 (Bad Request). The method should fail not because the resource doesn't have internal members, but because of the illegal value in the header.
Destination = "Destination" ":" ( absolute-URI ) The Destination request header specifies the URI which identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters. Note that the absolute-URI production is defined in . If the Destination value is an absolute URI, it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request with a 502 (Bad Gateway) response. Servers MAY attempt to copy the resource to the remote server using PUT/PROPPATCH or another mechanism.
Force-Authentication = "Force-Authentication" ":" Method The Force-Authentication request header is used with the OPTIONS method to specify that the client wants to be challenged for authentication credentials to the resource identified by the Request-URI. If present on a request to a WebDAV-compliant resource, the server MUST respond with either 401 (Unauthorized) or 501 (Not Implemented) status code. The Method value is used for the client to indicate what method it intends to use first on the resource identified in the Request-URI.
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) No-tag-list = List Tagged-list = Resource 1*List Resource = Coded-URL List = #( "(" List | Clause ")" ) Clause = ["Not"] State-token | State-token State-token = Coded-URL | "[" entity-tag "]" Coded-URL = "<" absolute-URI ">"
The If request header is intended to have similar functionality to the If-Match header defined in section 14.24 of . However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. The <DAV:no-lock> state token is an example of a state token that will never match an actual valid lock token. The purpose of this is described in . The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). If one of the described state lists matches the state of the resource then the request may succeed. The server must parse the If header when it appears on any request, evaluate all the clauses, and if the conditional evaluates to false, fail the request. Note that the absolute-URI production is defined in . RFC2518 originally defined the If header without comma separators. This oversight meant that the If header couldn't be divided up among multiple lines according to the HTTP header manipulation rules. Servers supporting "bis" MUST be able to accept commas in If header values. If the header has commas between tokens or clauses, the header can be evaluated simply by removing the commas and proceeding with the evaluation rules.
The No-tag-list production describes a series of state tokens and ETags. If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue. All untagged tokens apply to the resource identified in the Request-URI.
Example - no-tag-list production ["I am an ETag"]), (["I am another ETag"]) ]]>
The previous header would require that the resource identified in the Request-URI be locked with the specified lock token and in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag". To put the matter more plainly one can think of the previous If header as being in the form (or (and <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> ["I am an ETag"]) (and ["I am another ETag"])).
The tagged-list production may be used instead of the no-tag-list production, in order to scope each token to a specific resource. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any. All clauses must be evaluated. If the state of the resource named in the tag does not match any of the associated state lists then the request MUST fail with a 412 (Precondition Failed). The tagged-list production MUST NOT be used together with the no-tag-list production, either in the same If header or in a continuation. The same URI MUST NOT appear more than once in a resource production in an If header.
Example - Tagged List If header ( [W/"A weak ETag"]), (["strong ETag"]), (["another strong ETag"]) ]]>
In this example http://www.example.com/resource1 is being copied to http://www.example.com/resource2. When the method is first applied to http://www.example.com/resource1, resource1 must be in the state specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag". That is the only success condition since the resource http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.example.com/resource2 is not listed in the If header.
Every state token or ETag is either current, and hence describes the state of a resource, or is not current, and does not describe the state of a resource. The boolean operation of matching a state token or ETag to the current state of a resource thus resolves to a true or false value. The "Not" production is used to reverse that value. The scope of the not production is the state-token or entity-tag immediately following it.
) ]]>
When submitted with a request, this If header requires that all operand resources must not be locked with urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked with urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092. The Not production is particularly useful with the "<DAV:no-lock>" state token. The clause "Not <DAV:no-lock>" MUST evaluate to true. Thus, any "OR" statement containing the clause "Not <DAV:no-lock>" MUST also evaluate to true.
When performing If header processing, the definition of a matching state token or entity tag is as follows. Identifying a resource: The resource is identified by the URI along with the token, in tagged list production, or by the Request-URI in untagged list production. Matching entity tag: Where the entity tag matches an entity tag associated with the identified resource. Matching state token: Where there is an exact match between the state token in the If header and any state token on the identified resource. A lock state token is considered to match if the resource is anywhere in the scope of the lock.
Example - Matching lock tokens with collection locks () ]]> For this example, the lock token must be compared to the identified resource, which is the 'specs' collection identified by the URL in the tagged list production. If the 'specs' collection is not locked or has a lock with a different token, the request MUST fail. If the 'specs' collection is locked (depth infinity) with that lock token, then this request could succeed, both because the If header evaluates to true, and because the lock token for the lock affecting the affected resource has been provided. Alternatively, a request where the 'rfc2518.txt' URL is associated with the lock token in the If header could also succeed.
Non-DAV aware proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: no-cache" request header MUST be used so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" request header MUST be used for the same reason.
Lock-Token = "Lock-Token" ":" Coded-URL The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member. The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
Overwrite = "Overwrite" ":" ("T" | "F") The Overwrite request header specifies whether the server should overwrite the state of a non-null destination resource during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the state of the destination resource is non-null. If the overwrite header is not included in a COPY or MOVE request then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of the If-Match: * header of HTTP/1.1, If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE. If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. All DAV compliant resources MUST support the Overwrite header.
TimeOut = "Timeout" ":" 1#TimeType TimeType = ("Second-" DAVTimeOutVal | "Infinite") DAVTimeOutVal = 1*digit
Clients may include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method. Timeout response values MUST use a Second value or Infinite. The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1. The timeout counter MUST be restarted if a refresh LOCK request is successful. The timeout counter SHOULD NOT be restarted at any other time. If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request. Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going off-line. A client MUST NOT assume that just because the time-out has expired the lock has been lost. Likewise, a client MUST NOT assume that just because the time-out has not expired, the lock still exists (and for this reason, clients are strongly advised to use ETags as well).
The following status codes are added to those defined in HTTP/1.1 .
The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed. Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.
The 207 (Multi-Status) status code provides status for multiple independent operations (see for more information).
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain the 'missing-lock-token' element and corresponding href in the error body.
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request which received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
These HTTP codes are not redefined, but this section serves as a reminder that these HTTP codes may be used in responses to WebDAV methods and clients must be appropriately prepared to handle them.
A server MAY use this status code in response to any request.
A server MAY use this status code in response to any request.
A server MAY use this status code in response to any request. Some possible reasons: the Host header is missing in any request The protocol version is HTTP/1.0 Any header is improperly formatted The request method line is improperly formatted
A server MAY use this status code in response to any request. An appropriate use example would be in response to a PUT request to a collection, if the server does not ever allow PUT to a collection.
A server MAY use this status code in response to any request. In base WebDAV, the 409 Conflict is most typically returned when a method that attempts to create a new resource must fail, because one of the collections that resource depends on does not exist. However, other types of conflicts are defined in specifications extending RFC2518.
Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or the "If" conditional header defined in this specification. If the request contains a conditional header, and if that condition fails to hold, then this error code MUST be returned unless some other error is returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this error.
This status code is used in HTTP 1.1 only for Request-URIs, because full URIs aren't used in other headers. WebDAV specifies full URLs in other headers, therefore this error may be used if the URI is too long in other locations as well. A server MAY use this status code in response to any request.
This status code is particularly useful to respond to requests that the server considers a denial-of-service attack, such as excessively large PROPFIND depth infinity requests or requests in quick succession. A server MAY use this status code in response to any request, provided that the request did not partially or completely succeed.
A Multi-Status response 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. The default 207 (Multi-Status) response body is a text/xml or application/xml HTTP entity that contains a single XML element called multistatus, which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a response XML element. The 207 status code itself MUST NOT be considered a success response, it is only completely successful if all response elements inside contain success status codes. The body of a 207 Multi-Status response MUST contain a URL associated with each specific status code, so that the client can tell whether the error occurred with the source resource, destination resource or some other resource in the scope of the request.
Use of the Location header with the Multi-Status response is intentionally undefined. Note that this specification does not define a way to redirect requests for individual resources within the scope of a Multi-Status response. The server MAY always redirect the entire request by responding with a 300 level status response instead of a Multi-Status response.
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. If the URLs are absolute, then the server MUST ensure that the URLs have the same prefix (scheme, host, port, and path) as the URL of the requested resource. If the URLs are relative, they MUST be resolved against the Request-URI. When a Multi-Status body is returned in response to MOVE or COPY, relative URI 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. Servers MUST NOT return "." or ".." within an absolute or relative URI returned within a Multi-Status response. URLs for collections appearing in the results SHOULD end in a '/' character. If a server allows resource names to include characters that aren't legal in HTTP URL paths, these characters must be URI-escaped on the wire. For example, it is illegal to use a space character or double-quote in a URI. URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in this specification) are still subject to all URI rules, including forbidden characters.
, , , and define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses.
In this section, the final line of each section gives the element type declaration using the format defined in . The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). The "Extensibility" field discusses how the element may be extended in the future (or in existing extensions to WebDAV. All of the elements defined here may be extended by the addition of attributes and child elements not defined in this specification.
activelock DAV: Describes a lock on a resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
depth DAV: The value of the Depth header. "0" | "1" | "infinity" MAY be extended with attributes which SHOULD be ignored.
]]>
locktoken DAV: The lock token associated with a lock. The href contains a single lock token URI which refers to the lock. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockroot DAV: Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request. The href contains a URL with the address of the root of the lock. The server SHOULD include this in all lockdiscovery property values and the response to LOCK requests. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
timeout DAV: The number of seconds remaining before a lock expires. TimeType (defined in ). MAY be extended with attributes which SHOULD be ignored.
]]>
collection DAV: Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST contain this element. It is normally empty but extensions may add sub-elements. MAY be extended with child elements or attributes which SHOULD be ignored if not recognized.
]]>
href DAV: 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. URI (See section 3.2.1 of ) MAY be extended with attributes which SHOULD be ignored.
<!ELEMENT href (#PCDATA)>
lockentry DAV: Defines the types of locks that can be used with the resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockinfo DAV: The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockscope DAV: Specifies whether a lock is an exclusive lock, or a shared lock. SHOULD NOT be extended with child elements. MAY be extended with attributes which SHOULD be ignored.
]]>
exclusive DAV: Specifies an exclusive lock Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
shared DAV: Specifies a shared lock Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
locktype DAV: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
write DAV: Specifies a write lock. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
multistatus DAV: Contains multiple response messages. The responsedescription at the top level is used to provide a general message describing the overarching nature of the response. If this value is available an application may use it instead of presenting the individual response descriptions contained within the responses. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
response DAV: Holds a single response describing the effect of a method on resource and/or its properties. A particular href MUST NOT appear more than once as the child of a response XML element under a multistatus XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by href. There are, however, no requirements regarding ordering based on href values. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
propstat DAV: Groups together a prop and status element that is associated with a particular href element. The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
status DAV: Holds a single HTTP status-line status-line (status-line defined in Section 6.1 of ) MAY be extended with attributes which SHOULD be ignored.
]]>
responsedescription DAV: Contains a message that can be displayed to the user explaining the nature of the response. This XML element provides information suitable to be presented to a user. MAY be extended with attributes which SHOULD be ignored.
]]>
owner DAV: Provides information about the principal taking out a lock. The owner XML element provides information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who owns a lock. This information is provided by the client, and may only be altered by the server if the owner value provided by the client is empty. MAY be extended with child elements, mixed content, text content or attributes. Structured content, for example one or more <href> child elements containing URLs, is RECOMMENDED.
]]>
prop DAV: Contains properties related to a resource. The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element MUST define properties related to the resource. No other elements may be used inside of a prop element. MAY be extended with attributes which SHOULD be ignored if not recognized. Any child element of this element must be considered to be a property name, however these are not restricted to the property names defined in this document or other standards.
]]>
propertyupdate DAV: Contains a request to alter the properties on a resource. This XML element is a container for the information required to modify the properties on the resource. This XML element is multi-valued. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
remove DAV: Lists the DAV properties to be removed from a resource. Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a prop XML element inside of a remove XML element MUST be empty, as only the names of properties to be removed are required. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
set DAV: Lists the DAV property values to be set for a resource. The set XML element MUST contain only a prop XML element. The elements contained by the prop XML element inside the set XML element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists then its value is replaced. Language tagging information appearing in the scope of the prop element (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
<!ELEMENT set (prop) >
propfind DAV: Specifies the properties to be returned from a PROPFIND method. Four special elements are specified for use with propfind: prop, dead-props, allprop and propname. If prop is used inside propfind it MUST NOT contain property values. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized, as long as it still contains one of the required elements.
]]>
allprop DAV: The allprop XML element specifies that all names and values of dead properties and the live properties defined by this document existing on the resource are to be returned. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
propname DAV: The propname XML element specifies that only a list of property names on the resource is to be returned. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
dead-props DAV: The dead-props XML element specifies that all dead properties, names and values, should be returned in the response. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
error DAV: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. When an error response contains a body in WebDAV, the body is in XML with the root element 'error'. The 'error' tag SHOULD include a standard error tag defined in this specification or another specification. The 'error' tag MAY include custom error tags (in custom namespaces) which a client can safely ignore. Contains any XML element Fully extensible with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
For DAV properties, the name of the property is also the same as the name of the XML element that contains its value. In the section below, the final line of each section gives the element type declaration using the format defined in . The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses or PROPPATCH requests. 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.
creationdate DAV: Records the time and date the resource was created. date-time (defined in , see the ABNF in section 5.6.) MAY be protected. Some servers allow creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use getetag instead). This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY. 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). MAY contain attributes which SHOULD be ignored if not recognized.
]]>
displayname DAV: Provides a name for the resource that is suitable for presentation to a user. Any text Possibly This property value SHOULD be preserved in local COPY and MOVE operations. It MAY be attempted to be set in a COPY operation to a remote server. The displayname property should be defined on all DAV compliant resources. If present, the property contains a description of the resource that is suitable for presentation to a user. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontentlanguage DAV: Contains the Content-Language header returned by a GET without accept headers language-tag (language-tag is defined in section 14.13 of ) SHOULD NOT be protected, so that clients can reset the language. This property value SHOULD be preserved in local COPY and MOVE operations. It SHOULD be attempted to be set in a COPY operation to a remote server. The getcontentlanguage property MUST be defined on any DAV compliant resource that returns the Content-Language header on a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontentlength DAV: Contains the Content-Length header returned by a GET without accept headers. content-length (see section 14.14 of ) SHOULD be protected so clients cannot set to misleading values The getcontentlength property MUST be defined on any DAV compliant resource that returns the Content-Length header in response to a GET. This property value is dependent on the size of the destination resource, not the value of the property on the source resource. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontenttype DAV: Contains the Content-Type header returned by a GET without accept headers. media-type (defined in section 3.7 of ) SHOULD NOT be protected, so clients may fix this value This property value SHOULD be preserved in local COPY and MOVE operations. In a remote COPY operation that is implemented through a PUT request, the PUT request must have the appropriate Content-Type header. This getcontenttype property MUST be defined on any DAV compliant resource that returns the Content-Type header in response to a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getetag DAV: Contains the ETag header returned by a GET without accept headers. entity-tag (defined in section 3.11 of ) MUST be protected because this value is created and controlled by the server. This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Refer to RFC2616 for a complete definition of the semantics of an ETag. Note that changes in properties or lock state MUST not cause a resource's ETag to change. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getlastmodified DAV: Contains the Last-Modified header returned by a GET method without accept headers. rfc1123-date (defined in section 3.3.1 of ) SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked. This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the 'getlastmodified' value, and this is preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Thus, clients cannot rely on this value for caching and SHOULD use ETags. Note that the last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body. The getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
lockdiscovery DAV: Describes the active locks on a resource MUST be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH. The value of this property depends on the lock state of the destination, not on the locks of the source resource. Recall that locks are not moved in a MOVE operation. The lockdiscovery property returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there is one or more lock, an 'activelock' element appears for each lock on the resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
>Request PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Length: xxxx Content-Type: text/xml; charset="utf-8" >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/container/ 0 Jane Smith Infinite urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 http://www.example.com/container/ HTTP/1.1 200 OK ]]> This resource has a single exclusive write lock on it, with an infinite timeout.
resourcetype DAV: Specifies the nature of the resource. SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH. Generally a COPY/MOVE of a resource results in the same type of resource at the destination. In a remote COPY, the source server SHOULD NOT attempt to set this property. The resourcetype property MUST be defined on all DAV compliant resources. The default value is empty. MAY be extended with any child elements or attributes which SHOULD be ignored if not recognized. If the element contains the 'collection' child element plus additional unrecognized elements/attributes, it should generally be treated as a collection. If the element contains no recognized child elements it should be treated as a non-collection WebDAV-compliant resource.
Example: (fictional example to show extensibility) ]]>
supportedlock DAV: To provide a listing of the lock capabilities supported by the resource. MUST be protected. Servers determine what lock mechanisms are supported, not clients. This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination. The supportedlock property of a resource returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to see. MAY be extended with any child elements or attributes which SHOULD be ignored if not recognized.
]]>
>Request PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Length: xxxx Content-Type: text/xml; charset="utf-8" >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/container/ HTTP/1.1 200 OK ]]>
The numerical status codes used in HTTP responses are not sufficiently granular or informative for all purposes. Some extensions to HTTP have used the error response body along with some status codes in order to provide additiona machine-readable response detail. The machine-readable codes are XML elements classified as preconditions (generally client error or failure to meet the conditions in order for the request to be considered) and postconditions (generally server error or failure to respond successfully to an otherwise valid request). The precondition or postcondition XML element appears inside an 'error' element which is the root of the XML body of the response. The 'error' root element or the precondition or postcondition elements MAY contain additional XML elements or attributes not defined in this specification. XML elements in error response bodies were not used in RFC2518, but were introduced in RFC2518bis. Thus, use of these informative elements is RECOMMENDED. Even if clients do not automatically recognize the error bodies they can be quite useful in interoperability testing and debugging. external-entities-forbidden DAV: 403 Forbidden (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.
]]>
requesturi-must-match-lock-token DAV: 400 Bad Request (precondition) -- A request may include a Lock-Token header to identify a lock for the purposes of an operation such as refresh LOCK or UNLOCK. However, if the Request-URI doe not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
]]>
missing-lock-token DAV: 400 Bad Request (precondition) -- If the server rejects a request because the request MUST have a lock token and is missing the lock token header or header value (e.g. on an UNLOCK request), the server SHOULD use this error. The 'missing-lock-token' element MUST contain at least one URL of a locked resource for which a lock token was expected.
]]>
live-properties-not-preserved DAV: 409 Conflict (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server only supports some live properties in some parts of the repository, or simply has an internal error.
]]>
read-only-property DAV: 403 Forbidden (precondition) -- The client attempted to set a read-only property in a PROPPATCH (such as 'getetag').
]]>
propfind-infinite-depth-forbidden DAV: 403 Forbidden (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.
]]>
need-privileges DAV: 403 Forbidden (precondition) -- The currently authenticated user simply does not have the privileges required to do the requested operation (e.g. UNLOCK a lock created by someone else).
]]>
missing-lock-token DAV: 423 Locked (precondition) -- The request could not succeed because a lock token should have been provided. This element, if present, MUST contain the URL of a locked resource that prevented the request. In cases of MOVE, COPY and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only resonsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all.
]]>
All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language. This restriction also applies to the processing, by clients, of DAV property values where unknown XML elements SHOULD be ignored unless the property's schema declares otherwise. This restriction does not apply to setting dead DAV properties on the server where the server MUST record unknown XML elements. Additionally, this restriction does not apply to the use of XML where XML happens to be the content type of the entity body, for example, when used as the body of a PUT. Since XML can be transported as text/xml or application/xml, a DAV server MUST accept DAV method requests with XML parameters transported as either text/xml or application/xml, and a DAV client MUST accept XML responses using either text/xml or application/xml. XML DTD fragments are included for all the XML elements defined in this specification. However, legal XML may not be valid according to any DTD due to namespace usage and extension rules, so the DTD is only informational. A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.
A DAV compliant resource can advertise several classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource, and examining the "DAV" header which is returned. Note particularly that resources are spoken of as being compliant, rather than servers. That is because theoretically some resources on a server could support different feature sets. E.g. a server could have a sub-repository where an advanced feature like server was supported, even if that feature was not supported on all servers. Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies MUST be compliant with . A resource that is class 2 compliant must also be class 1 compliant, and a resource that is compliant with "bis" must also be class 1 compliant.
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document. Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the supportedlock property, the lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element. Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
A resource can explicitly advertise its support for the revisions to RFC2518 made in this document. In particular, this allows clients to use the Force-Authentication header on requests. Class 1 must be supported as well. Class 2 MAY be supported. A resource that supports bis MUST support: the Force-Authentication header. Any behavior that it supports, in the manner specified in this document, rather than in the manner specified in RFC2518, for all client requests. A server MAY use an older behavior for specific clients that are discovered to have interoperability problems with the requirements of this specification, but MUST NOT use an older behavior indiscriminately.
Example: DAV: 1, bis
In the realm of internationalization, this specification complies with the IETF Character Set Policy . In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 and UTF-16 encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in , as well as the XML declarations which provide charset identification information for MIME and XML processors. XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See for definitions of values and scoping. WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header. Names used within this specification fall into four categories: names of protocol elements such as methods and headers, names of XML elements, names of properties, and names of conditions. Naming of protocol elements follows the precedent of HTTP, using English names encoded in USASCII for methods and headers. Since these protocol elements are not visible to users, and are simply long token identifiers, they do not need to support multiple languages. Similarly, the names of XML elements used in this specification are not visible to the user and hence do not need to support multiple languages. WebDAV property names are qualified XML names (pairs of XML namespace name and local name). Although some applications (e.g., a generic property viewer) will display property names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name and namespace to a human-readable field when displaying the property name to a user. 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 to a user. We recommend that applications provide human-readable property names wherever feasible. For error reporting, we follow the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 (Locked)). While the possibility exists that a poorly crafted user agent would display this message to a user, internationalized applications will ignore this message, and display an appropriate message in the user's language and character set. Since interoperation of clients and servers does not require locale information, this specification does not specify any mechanism for transmission of this information.
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware. All of the security considerations of HTTP/1.1 (discussed in ) and XML (discussed in ) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication. A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send Basic authentication credentials in a WWW-Authenticate header unless the connection is secure. Examples of secure connections include a Transport Layer Security (TLS) connection employing a strong cipher suite with mutual authentication of client and server, or a connection over a network which is physically secure, for example, an isolated network in a building with restricted access. WebDAV applications MUST support the Digest authentication scheme . Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication which is useful in a wide range of scenarios.
Denial of service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial of service attacks on every part of a system's resources. The underlying storage can be attacked by PUTting extremely large files. Asking for recursive operations on large collections can attack processing time. Making multiple pipelined requests on multiple connections can attack network connections. WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.
WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.
When submitting a lock request a user agent may also submit an owner XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.
XML supports a facility known as "external entities", defined in section 4.2.2 of , which instruct an XML processor to retrieve and include additional XML. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non-validating XML, such as the XML used in this specification, including an external XML entity is not required by XML. However, XML does state that an XML processor may, at its discretion, include the external XML entity. External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case significantly modifying its semantics, or exposing the XML processor to the security risks discussed in . Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server implementor chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the precondition defined above (external-entities-forbidden). There is also the scalability risk that would accompany a widely deployed application which made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any server which fields requests for the resource containing the external XML entity.
This specification requires the use of "A Universally Unique Identifier (UUID) URN Namespace" () for lock tokens, in order to guarantee their uniqueness across space and time. The security considerations for UUIDs do not apply because WebDAV does not assume that lock tokens are supposed to be hard to guess or require integrity. In addition, UUIDs MAY contain a IEEE 802 node ID, usually the host address. Since a WebDAV server will issue many locks over its lifetime, the use of node IDs might cause the WebDAV server to reveal its IEEE 802 address. Several risks are related to this: It is possible to track the movement of hardware from subnet to subnet. It may be possible to identify the manufacturer of the hardware running a WebDAV server. It may be possible to determine the number of each type of computer running WebDAV.
HTTP has the ability to host scripts which are executed on client machines. These scripts can be used to read another user's cookies and therefore may provide an attacker the ability to use another user's session, assume their identity temporarily and gain access to their resources. Other attacks are also possible with client-executed scripts. WebDAV may worsen this situation only by making it easier for a Web server to host content provided by many different authors (making it harder to trust the content providers) and to host content with restricted access alongside public pages (see particularly RFC3744). HTTP servers may mitigate some of these threats by filtering content in areas where many authors contribute pages -- the server could, for example, remove script from HTML pages. This vulnerability should provide yet another reason for server implementors and administrators not to replace authentication mechanisms with cookie-based session tokens if there's any sensitive information relying on the authenticated identity. HTTP and WebDAV client implementors might consider locking down the use of scripts and cookies based on these considerations.
This specification defines two URI schemes: the "opaquelocktoken" scheme defined in , and the "DAV" URI scheme, which historically was used in RFC2518 to disambiguate WebDAV property and XML element names and which continues to be used for that purpose in this specification and others extending WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by the IETF. XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names or element names.
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work. Contributors to RFC2518 Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable, both in helping the formation of the working group and in patiently coaching the authors along the way. In so many ways he has set high standards we have toiled to meet. The contributions of Judith Slein in clarifying the requirements, and in patiently reviewing draft after draft, both improved this specification and expanded our minds on document management. We would also like to thank John Turner for developing the XML DTD. The authors of RFC2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter and D. Jensen. Although their names had to be removed due to IETF author count restrictions they can take credit for the majority of the design of WebDAV. Additional Contributors to This Specification Valuable contributions to RFC2518 bis came from some already named. New contributors must also be gratefully acknowledged. Julian Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out specific text on the list or in meetings. Ilya Kirnos supplied text for Force-Authentication header. Joe Hildebrand contributed as co-chair. Barry Lind described an additional security consideration. Jason Crawford tracked issue status for this document for a period of years, followed by Elias Sinderson.
Y. Y. Goland, Microsoft Corporation, One Microsoft Way, Redmond, WA 98052-6399. Email: yarong@microsoft.com. E. J. Whitehead, Jr., Dept. Of Information and Computer Science, University of California, Irvine, Irvine, CA 92697-3425. Email: ejw@ics.uci.edu. A. Faizi, Netscape, 685 East Middlefield Road, Mountain View, CA 94043. Email: asad@netscape.com. S. R. Carter, Novell, 1555 N. Technology Way, M/S ORM F111, Orem, UT 84097-2399. Email: srcarter@novell.com. D. Jensen, Novell, 1555 N. Technology Way, M/S ORM F111, Orem, UT 84097-2399. Email: dcjensen@novell.com.
&rfc2069; &rfc2119; &rfc2277; &rfc2279; &rfc2518; &rfc2616; &rfc3339; &rfc3986; &rfc4122; &w3cXMLNS; Extensible Markup Language (XML) 1.0 (Third Edition) Textuality and Netscape
tbray@textuality.com
Microsoft
jeanpa@microsoft.com
University of Illinois at Chicago and Text Encoding Initiative
cmsmcq@uic.edu
Sun Microsystems
eve.maler@east.sun.com
francois@yergeau.com
&rfc2291; &rfc2376; &rfc3253; &rfc3744;
XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.
XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of white space, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements. There is no kindness in accepting illegal combinations of XML elements. At best it will cause an unwanted result and at worst it can cause real damage.
The following request body for a PROPFIND method is illegal.
]]>
The definition of the propfind element only allows for the allprop or the propname element, not both. Thus the above is an error and must be responded to with a 400 (Bad Request). Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop. Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
]]>
To understand why a 400 (Bad Request) is returned let us look at the request body as the server unfamiliar with expired-props sees it.
]]>
As the server does not understand the expired-props element, according to the WebDAV-specific XML processing rules specified in , it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal. Please note that had the extension been additive it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
*boss* ]]>
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with leave-out, the only result would be that the leave-out element would be ignored and a propname would be executed.
The PUT and DELETE methods are defined in HTTP and thus may be used by HTTP clients, but the responses to PUT and DELETE have been extended in this specification, so some special consideration on backward compatibility is worthwhile. First, if a PUT or DELETE request includes a header defined in this specification (Depth or If), the server can assume the request comes from a WebDAV-compatible client. The server may even be able to track a number of requests across a session and know that a client is a WebDAV client. However, this kind of detection may not be necessary. Since any HTTP client ought to handle unrecognized 400-level and 500-level status codes as errors, the following new status codes should not present any issues: 422, 423 and 507. 424 is also a new status code but it appears only in the body of a Multistatus response. So, for example, if a HTTP client attempted to PUT or DELETE a locked resource, the 423 Locked response ought to result in a generic error presented to the user. The 102 Processing response code is new, and indicates that the client may wish to extend its normal timeout period. However, the choice to extend the timeout period is entirely optional, and thus a HTTP client receiving a 102 Processing status response may time out anyway, with no avoidable adverse effects. The 207 Multistatus response is interesting because a HTTP client issuing a DELETE request to a collection might interpret a 207 response as a success, even though it does not realize the resource is a collection and cannot understand that the DELETE operation might have been a complete or partial failure. Thus, a server MAY choose to treat a DELETE of a collection as an atomic operation, and use either 204 No Content in case of success, or some appropriate error response (400 or 500 level) depending on what the error was. This approach would maximize backward compatibility. However, since interoperability tests and working group discussions have not turned up any instances of HTTP clients issuing a DELETE request against a WebDAV collection, this concern may be more theoretical than practical. Thus, servers MAY instead choose to treat any such DELETE request as a WebDAV request, and send a 207 Multistatus containing more detail about what resources could not be deleted.
The 'opaquelocktoken' URI scheme was defined in RFC2518 (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time. This scheme has been obsoleted by , but is re-defined here for clarity. A server MAY generate one ore more UUIDs to use with the 'opaquelocktoken' scheme as lock tokens. A server MAY reuse a UUID with extension characters added. If the server does this then the algorithm generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID. OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID. Note that white space (LWS) is not allowed between elements of this production. Extension = path ; path is defined in section 3.3 of
This section describes changes that are likely to result in implementation changes due to tightened requirements or changed behavior. A more complete list of changes has been published in a separate document.
Tightened requirements for storing property values when "xml:lang" appears and also when values are XML fragments (specifically on preserving prefixes, namespaces and whitespace.) Several tightened requirements for general response handling, including response bodies for use with errors, use of Date header, ETag and Location header. Tightened requirements for URL construction in PROPFIND responses. Tightened requirements for checking identity of lock owners during operations affected by locks. Tightened requirements for copying properties and moving properties. Tightened requirements on preserving owner field in locks. Added "lockroot" element to lockdiscovery information. New value for "DAV:" header to advertise support for this specification. Tightened requirement for "Destination:" header to work with path values New "Force-Authentication:" header added. Several changes for "If:" header, including requirement to accept commas and "DAV:no-lock" state token. Support for UTF-16 now required (ref). Removed definition of "source" property and special handling for dynamic resources Replaced lock-null resources with simpler locked empty resources. Encouraged servers to change ETags only when body of resource changes.
Tightened requirements for supporting WebDAV collections within resources that do not support WebDAV (e.g. servlet containers). Redefined 'allprop' PROPFIND requests so that the server does not have to return all properties. Required to handle empty multistatus responses in PROPFIND responses No more "propertybehavior" specification allowed in MOVE and COPY requests Support for UTF-16 now required (ref). Removed definition of "source" property and special handling for dynamic resources.
Specified that a successful LOCK request to an unmapped URL creates a new, empty locked resource. Resolved UNLOCK_NEEDS_IF_HEADER by clarifying that only Lock-Token header is needed on UNLOCK. Added on preconditions and postconditions and defined a number of preconditions and postconditions. The 'missing-lock-token' precondition resolves the REPORT_OTHER_RESOURCE_LOCKED issue. Added example of matching lock token to URI in the case of a collection lock in the If header section. Removed ability for Destination header to take "abs_path" in order to keep consistent with other places where client provides URLs (If header, href element in request body) Clarified the href element - that it generally contains HTTP URIs but not always. Attempted to fix the BNF describing the If header to allow commas Clarified presence of Depth header on LOCK refresh requests.
Added text to "COPY and the Overwrite Header" section to resolve issue OVERWRITE_DELETE_ALL_TOO_STRONG. Added text to "HTTP URL Namespace Model" section to provide more clarification and examples on what consistency means and what is not required, to resolve issue CONSISTENCY. Resolve DEFINE_PRINCIPAL by importing definition of principal from RFC3744. Resolve INTEROP_DELETE_AND_MULTISTATUS by adding appendix 3 discussing backward-compatibility concerns. Resolve DATE_FORMAT_GETLASTMODIFIED by allowing only rfc1123-date, not HTTP-date for getlastmodified. Resolve COPY_INTO_YOURSELF_CLARIFY by adding sentence to first para. of COPY section. Confirm that WHEN_TO_MULTISTATUS_FOR_DELETE_1 and WHEN_TO_MULTISTATUS_FOR_DELETE_2 are resolved and tweak language in DELETE section slightly to be clearly consistent. More text clarifications to deal with several of the issues in LOCK_ISSUES. This may not completely resolve that set but we need feedback from the originator of the issues at this point. Resolved COPY_INTO_YOURSELF_CLARIFY with new sentence in Copy For Collections section. Double checked that LEVEL_OR_CLASS is resolved by using class, not level. Further work to resolve IF_AND_AUTH and LOCK_SEMANTICS, clarifying text on using locks and being authenticated. Added notes on use of 503 status response to resolve issue PROPFIND_INFINITY Removed section on other uses of Metadata (and associated references) Added reference to RFC4122 for lock tokens and removed section on generating UUIDs Explained that even with language variation, a property has only one value (section 4.5). Added section on lock owner (7.1) and what to do if lock requested by unauthenticated user Removed section 4.2 -- justification on why to have metadata, not needed now Removed paragraph in section 5.2 about collections with resource type "DAV:collection" but which are non-WebDAV compliant -- not implemented.
Added security considerations section on scripts and cookie sessions, suggested by Barry Lind Clarified which error codes are defined and undefined in MultiStatus Moved opaquelocktoken definition to an appendix and refer to RFC4122 for use of 'urn:uuid:' URI scheme; fix all lock token examples to use this. Multi-status responses contain URLs which MUST either be absolute (and begin with the Request-URI or MUST be relative with new limitations. (bug 12) Moved status code sections before example sections within PROPFIND section for section ordering consistency. Clarified use of Location header with Multi-Status Bugzilla issue resolutions: bugs 9, 12, 14, 19, 20, 29, 30, 34, 36, 102 and 172.
--------------020801060708040008040807-- From w3c-dist-auth-request@frink.w3.org Mon Nov 21 08:44:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeByd-0004jz-RS for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 08:44:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00991 for ; Mon, 21 Nov 2005 08:44:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeBxv-0000aI-G5 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 13:44:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeBxu-0000ZE-P5 for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 13:44:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeBxk-00055Q-Vo for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 13:44:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALDhwWL004387; Mon, 21 Nov 2005 05:43:58 -0800 Date: Mon, 21 Nov 2005 05:43:58 -0800 Message-Id: <200511211343.jALDhwWL004387@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeBxk-00055Q-Vo fa1679b73e7f0fe3c807ea26b73f3722 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 189] New: "RFC2518bis" in spec text X-Archived-At: http://www.w3.org/mid/200511211343.jALDhwWL004387@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10538 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 13:44:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=189 Summary: "RFC2518bis" in spec text Product: WebDAV-RFC2518-bis Version: -08 Platform: Other OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org There are at least two places where the term "RFC2518bis" is used in the document. These should be replaced by something like "this specification". It also appears in the document title, which really should be unchanged from RFC2518. Finally, RFC2518 currently occurs in the references section (where it should really appear as "informational"), but xml2rfc doesn't find any actual reference from the text (that is, XML markup may need to be added for that purpose). ------- 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@frink.w3.org Mon Nov 21 10:20:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDTH-0004rG-0V for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:20:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07296 for ; Mon, 21 Nov 2005 10:20:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeDRu-0001Bm-Fy for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 15:19:18 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeDRp-0001BC-EB for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 15:19:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeDRj-0000f8-Mk for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 15:19:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALFJ4I1004471; Mon, 21 Nov 2005 07:19:04 -0800 Date: Mon, 21 Nov 2005 07:19:04 -0800 Message-Id: <200511211519.jALFJ4I1004471@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeDRj-0000f8-Mk 0af7b0a804d790a53db30a016378e12f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 190] New: HTTP examples using RFC2629 markup X-Archived-At: http://www.w3.org/mid/200511211519.jALFJ4I1004471@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10539 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 15:19:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=190 Summary: HTTP examples using RFC2629 markup Product: WebDAV-RFC2518-bis Version: -08 Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Currently the spec puts all (or most) HTTP request/response examples into a single RCF2629 artwork element. This has several disadvantages: - xm2rfc processors will not be aware that the whitespace between request and response is a good place for a page break - automatic XML checks in artwork fail (see , "parse-xml-in-artwork") Also, putting the strings ">>> Request" and ">>> Response" into the figure preambles will make it easier to read in non-plain-ASCII versions of the spec (yes, this is cosmetic). Should we have consensus for this change, I'm volunteering to make it. ------- 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@frink.w3.org Mon Nov 21 10:51:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDww-0002n4-EE for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:51:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10337 for ; Mon, 21 Nov 2005 10:50:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeDw3-0003GG-HY for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 15:50:27 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeDvy-0003FW-1r for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 15:50:22 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeDvp-00078e-CF for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 15:50:20 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jALFo9gL007499 for ; Mon, 21 Nov 2005 10:50:09 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jALFoAfM103248 for ; Mon, 21 Nov 2005 10:50:10 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jALFoAoe023846 for ; Mon, 21 Nov 2005 10:50:10 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jALFo9Bp023843 for ; Mon, 21 Nov 2005 10:50:09 -0500 In-Reply-To: <200511211519.jALFJ4I1004471@ietf.cse.ucsc.edu> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 21 Nov 2005 10:50:29 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/21/2005 10:50:09, Serialize complete at 11/21/2005 10:50:09 Content-Type: multipart/alternative; boundary="=_alternative 00570361852570C0_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeDvp-00078e-CF 3befa8cb8cee337072e083726ce7bc33 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 190] New: HTTP examples using RFC2629 markup X-Archived-At: http://www.w3.org/mid/OF222E9533.A67BE79B-ON852570C0.0056F381-852570C0.005703E9@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10540 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 15:50:27 +0000 This is a multipart message in MIME format. --=_alternative 00570361852570C0_= Content-Type: text/plain; charset="US-ASCII" That change sounds good to me. +1 Cheers, Geoff Julian wrote on 11/21/2005 10:19:04 AM: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=190 > > Summary: HTTP examples using RFC2629 markup > Product: WebDAV-RFC2518-bis > Version: -08 > Platform: Other > OS/Version: other > Status: NEW > Severity: enhancement > Priority: P2 > Component: Other > AssignedTo: joe-bugzilla@cursive.net > ReportedBy: julian.reschke@greenbytes.de > QAContact: w3c-dist-auth@w3.org > > > Currently the spec puts all (or most) HTTP request/response examples into a > single RCF2629 artwork element. This has several disadvantages: > > - xm2rfc processors will not be aware that the whitespace between request and > response is a good place for a page break > > - automatic XML checks in artwork fail (see > >, > "parse-xml-in-artwork") > > Also, putting the strings ">>> Request" and ">>> Response" into the figure > preambles will make it easier to read in non-plain-ASCII versions of the spec > (yes, this is cosmetic). > > Should we have consensus for this change, I'm volunteering to make it. > > > > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. > --=_alternative 00570361852570C0_= Content-Type: text/html; charset="US-ASCII"
That change sounds good to me.
+1

Cheers,
Geoff

Julian wrote on 11/21/2005 10:19:04 AM:

>
> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=190
>
>            Summary: HTTP examples using RFC2629 markup
>            Product: WebDAV-RFC2518-bis
>            Version: -08
>           Platform: Other
>         OS/Version: other
>             Status: NEW
>           Severity: enhancement
>           Priority: P2
>          Component: Other
>         AssignedTo: joe-bugzilla@cursive.net
>         ReportedBy: julian.reschke@greenbytes.de
>          QAContact: w3c-dist-auth@w3.org
>
>
> Currently the spec puts all (or most) HTTP request/response examples into a
> single RCF2629 artwork element. This has several disadvantages:
>
> - xm2rfc processors will not be aware that the whitespace between request and
> response is a good place for a page break
>
> - automatic XML checks in artwork fail (see
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#rfc.section.3.3
> >,
> "parse-xml-in-artwork")
>
> Also, putting the strings ">>> Request" and ">>> Response" into the figure
> preambles will make it easier to read in non-plain-ASCII versions of the spec
> (yes, this is cosmetic).
>
> Should we have consensus for this change, I'm volunteering to make it.
>
>
>
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug, or are watching the QA contact.
>
--=_alternative 00570361852570C0_=-- From w3c-dist-auth-request@frink.w3.org Mon Nov 21 12:26:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFR1-00029F-3V for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:26:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16903 for ; Mon, 21 Nov 2005 12:25:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFPh-0005hk-9G for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:25:09 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeFPc-0005fG-AZ for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:25:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeFPN-0001Zz-Rg for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:25:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHOkbA004611; Mon, 21 Nov 2005 09:24:46 -0800 Date: Mon, 21 Nov 2005 09:24:46 -0800 Message-Id: <200511211724.jALHOkbA004611@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeFPN-0001Zz-Rg 484e363b5271df2e23c70c80f0718b11 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 191] New: LOCK_ISSUES_ACCESS_RIGHTS X-Archived-At: http://www.w3.org/mid/200511211724.jALHOkbA004611@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10541 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:25:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=191 Summary: LOCK_ISSUES_ACCESS_RIGHTS Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://http://lists.w3.org/Archives/Public/w3c-dist- auth/1999AprJun/0246.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Reported by Jason Crawford in : Section 6.3: ""Having a lock token provides no special access rights..." I suggest that the phrase "owned by another party" be added in this first sentence to distinguish between owning and having. It speaks of "having" in this sentence but not subsequently. In fact "submitting" might be an even better word than having. ------- 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@frink.w3.org Mon Nov 21 12:27:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFRh-0002Fd-VC for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:27:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16944 for ; Mon, 21 Nov 2005 12:26:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFQw-0005sF-C3 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:26:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeFQv-0005qx-8o for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:26:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeFQn-0008Cu-8u for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:26:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHQFfr004627; Mon, 21 Nov 2005 09:26:15 -0800 Date: Mon, 21 Nov 2005 09:26:15 -0800 Message-Id: <200511211726.jALHQFfr004627@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeFQn-0008Cu-8u 3ebee1dd2fc3e5f42c260467a2585326 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 192] New: LOCK_ISSUES_LOCK_URI_TYPE X-Archived-At: http://www.w3.org/mid/200511211726.jALHQFfr004627@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10542 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:26:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=192 Summary: LOCK_ISSUES_LOCK_URI_TYPE Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/1999AprJun/0246.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Reported by Jason Crawford in : Section 6.3: "... However resource are free to return any URI scheme so long as it meets the uniqueness requirements." This is technically correct, but it might also be useful to say that the scheme should make the URI be readily recognizable as a *LOCK* state token in the event that other types of state tokens exist. I mention this because we seem to have created the possibility of other types of state tokens. -- Your call. :-) ------- 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@frink.w3.org Mon Nov 21 12:28:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFT2-0002bk-Qb for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:28:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17066 for ; Mon, 21 Nov 2005 12:27:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFSM-00064K-7B for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:27:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeFSL-00063m-N7 for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:27:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeFSH-0008VE-Eh for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:27:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHRmOH004643; Mon, 21 Nov 2005 09:27:48 -0800 Date: Mon, 21 Nov 2005 09:27:48 -0800 Message-Id: <200511211727.jALHRmOH004643@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeFSH-0008VE-Eh a0efd23db6fe373ef3cdac0b8c5a2b2a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 193] New: LOCK_ISSUES_WRITE_LOCK X-Archived-At: http://www.w3.org/mid/200511211727.jALHRmOH004643@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10543 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:27:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=193 Summary: LOCK_ISSUES_WRITE_LOCK Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/1999AprJun/0246.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 07. Write Lock AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Reported by Jason Crawford in : Section 7.1 Write lock. I believe this definition of a write lock is not right... or not complete... judging from what I read elsewhere. I believe one can do these operations without a write lock... as long as someone else doesn't have a write lock on the resources effected. I also believe it doesn't prevent LOCK requests in the case of shared locks. ------- 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@frink.w3.org Mon Nov 21 12:29:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFUN-0002o2-JP for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:29:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17137 for ; Mon, 21 Nov 2005 12:29:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFTl-0006Ga-CF for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:29:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeFTk-0006Fr-SO for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:29:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeFTd-0000Jd-1P for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:29:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHTBt4004660; Mon, 21 Nov 2005 09:29:11 -0800 Date: Mon, 21 Nov 2005 09:29:11 -0800 Message-Id: <200511211729.jALHTBt4004660@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeFTd-0000Jd-1P c7b13ce3e2422fee891142f79ee53cb5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 194] New: LOCK_ISSUES_WRITE_LOCKS_AND_COLLECTIONS X-Archived-At: http://www.w3.org/mid/200511211729.jALHTBt4004660@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10544 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:29:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=194 Summary: LOCK_ISSUES_WRITE_LOCKS_AND_COLLECTIONS Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/1999AprJun/0246.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 07. Write Lock AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Reported by Jason Crawford in : Section 7.5 Write Locks and Collections. It says that if members are locked in a conflicting manner, then their collection can't be locked. That seems ambiguously safe to say, but I suspect that text should mention depth since if the parent lock request is depth 0, I don't think we let the members lock state effect the success of the LOCK request. The possible exception is what we said about protecting a URI that was used to perform a lock (of a member of the collection). I'm not sure what we'd like to say for that. In the advanced collection meetings we refered to these being "protected" and avoided speaking about "lock"ing the URI. This creates an odd situation though. ------- 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@frink.w3.org Mon Nov 21 12:30:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFV7-0002ye-DD for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:30:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17181 for ; Mon, 21 Nov 2005 12:30:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFUU-0006vr-R3 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:30:06 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeFUT-0006qY-TW for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:30:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeFUQ-0002gj-NT for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:30:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHU2un004676; Mon, 21 Nov 2005 09:30:02 -0800 Date: Mon, 21 Nov 2005 09:30:02 -0800 Message-Id: <200511211730.jALHU2un004676@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeFUQ-0002gj-NT 30209f9f319eff623844535588375de8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 195] New: LOCK_ISSUES_WRITE_LOCKS_AND_COPYMOVE X-Archived-At: http://www.w3.org/mid/200511211730.jALHU2un004676@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10545 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:30:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=195 Summary: LOCK_ISSUES_WRITE_LOCKS_AND_COPYMOVE Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/1999AprJun/0246.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 07. Write Lock AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Reported by Jason Crawford in : 7.7 Write Locks and COPY/MOVE It says that a lock doesn't move with a moved resource. Of course if the lock is on the resource, not the URI, it should move with the resource. But then we have the caveat that we are also protecting the LOCK'd URI. I think the rule should be that if we submit the locktoken with the MOVE request, we are allowed to have the LOCK move with the resource and the lock will now protect a different URI. Also, ALL locks in the subtree must be submitted or the MOVE must fail because otherwise it would break our URI protection rule. ------- 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@frink.w3.org Mon Nov 21 12:32:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFWP-00039S-2s for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:32:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17266 for ; Mon, 21 Nov 2005 12:31:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFVd-0000LL-PL for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:31:17 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeFVc-0000Kn-VJ for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:31:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeFVZ-0002x4-GW for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:31:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHVDB7004692; Mon, 21 Nov 2005 09:31:13 -0800 Date: Mon, 21 Nov 2005 09:31:13 -0800 Message-Id: <200511211731.jALHVDB7004692@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeFVZ-0002x4-GW 0e988576bccf93aed1d8a7bd3df10236 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 196] New: LOCK_ISSUES_ERROR_CODES X-Archived-At: http://www.w3.org/mid/200511211731.jALHVDB7004692@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10546 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:31:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=196 Summary: LOCK_ISSUES_ERROR_CODES Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/1999AprJun/0246.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 QAContact: w3c-dist-auth@w3.org Reported by Jason Crawford in : Upon cursory reading of the rfc 2518 sec 8.10.4 through 8.11 I was confused by the plethoria of error codes. Nothing seems to unify them. 8.10.4 speaks of a return code of 409 Conflict if a lock can't be granted. - Firstly, I can't tell if it is saying that the 409 is within the multistatus body... or in the response header. - Secondly, later text seems to use a different status codes and never mentions this one again. 8.10.7 lists status codes - 200 OK, 412 Precondition Failed, and 423 Locked are listed, but 409 Conflict (mentioned above) is not. - In the case of 412 Precondition Failed, the description the follows doesn't seem to describe a "precondition failed". And it sounds like it's talking about an access request that includes a "locktoken", not a LOCK request that generates one. - The 423 Locked condition also sort of sounds like it's talking about an access request rather than a LOCK request. 8.10.10 lists LOCK status codes - 207 Multistatus which was not mentioned above - 403 Forbidden which was not mentioned above. - 424 Failed dependency which was not mentioned above. 8.11 UNLOCK - we don't mention what the failure response should look like. - comment: 200 OK seems like a better response than 204 No Content. The brief explanation isn't persuasive and seems to say that the response code should serve the purpose of the Content-Length. header. - we should probably explicitly say if an UNLOCK can only be done on the original resource... and will fail even if the resource specified is locked by virtue of being a child of the original resource. Or is this too obvious? I know it's something easy to goof up in an implementation. ------- 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@frink.w3.org Mon Nov 21 12:33:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFXk-0003Ra-J0 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:33:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17376 for ; Mon, 21 Nov 2005 12:32:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFX2-0000aU-Pp for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:32:44 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeFX2-0000Zm-0O for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:32:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeFWy-0003Hq-Ng for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:32:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHWekO004708; Mon, 21 Nov 2005 09:32:40 -0800 Date: Mon, 21 Nov 2005 09:32:40 -0800 Message-Id: <200511211732.jALHWekO004708@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeFWy-0003Hq-Ng 33f0d5e9d783ba9756242e295811690f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 197] New: LOCK_ISSUES_IF_HEADER X-Archived-At: http://www.w3.org/mid/200511211732.jALHWekO004708@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10547 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:32:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=197 Summary: LOCK_ISSUES_IF_HEADER Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/1999AprJun/0246.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 QAContact: w3c-dist-auth@w3.org Reported by Jason Crawford in : 9.4 If header - BNF suggests that IF's content must be all tagged or all untagged. - doesn't say if there can be two If headers in a request. Might we want a tagged one and an untagged one? - I must be misunderstanding this, but it sounds to me like that state of a resource(s) must match one of the locktokens listed in the request. But what if some of the resources are locked and others are not. The unlocked resources definitely won't contain state that's listed. Are we precluding operations on regions that might not be entirely locked? -- Is this a valid observation or a red herring? 9.4.1.1 If header - untagged example - See my comment about regions that are not entirely locked. 9.4.2 If header -tagged state - So if we've applied a lock with depth.... and now we're doing a DELETE on a subtree of that tree and we've tagged the locktoken we've submitted, will this prevent that locktoken from apply'ing to ALL the resources of the subtree... and thus prevent the COPY from succeeding? Or are we supposed to tag the lock token with the root of the LOCK even if that is not part of what we are deleting? Or should the request use untagged locktokens? 9.4.3 If header - NOT operator - Why do we want this? of course... why not? :-) Overall, the If header seems backwards for locktokens. It's client driven rather than server semantics driven. The only feature it seems to provide is perhaps the ability for the client to request that the request be aborted if the resource no longer is locked. Other than that it seems to complicate the simple process of letting the server know what tokens you hold. I'd think we'd just want a different header to declare what lock tokens we hold and let the server (not the client) decide how they affect the success of the request. ------- 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@frink.w3.org Mon Nov 21 12:34:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFYj-0003p2-3s for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:34:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17459 for ; Mon, 21 Nov 2005 12:33:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFXx-0000j3-E2 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:33:41 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeFXw-0000iQ-Kb for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:33:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeFXs-0003TT-W7 for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:33:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHXaup004725; Mon, 21 Nov 2005 09:33:36 -0800 Date: Mon, 21 Nov 2005 09:33:36 -0800 Message-Id: <200511211733.jALHXaup004725@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeFXs-0003TT-W7 3ac64c80be6d221b6b802a60b07a558a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 198] New: LOCK_ISSUES_SHARED_LOCKS X-Archived-At: http://www.w3.org/mid/200511211733.jALHXaup004725@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10548 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:33:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=198 Summary: LOCK_ISSUES_SHARED_LOCKS Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/1999AprJun/0246.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Reported by Jason Crawford in : Shared locks... read locks... Our justifcation for shared locks ("Shared locks are included because....") seems faulty. It's not a mechansim for dealing with programs that forget to release their locks. That remains a problem with shared locks. In this case they'd forget to release a shared lock and block exclusive lock users. Timeouts and administrative action are the solutions to this problem... not shared locks. BTW, I'd think that the use of exclusive locks is just fine. I do have a problem with shared locks though... or at least shared write locks. Although they were relatively easy to define, I see them as solving a red herring problem of multiple entites cooperatively writing using distinct locks. I say it's a red herring because they don't know each other well enough to use the same lock but they do know each other well enough to not step on each other. This seems unlikely. As does the managing a compatibility matrix and getting all the entities to abide by it. OTOH I see another more common problem that is being overlooked. I see a class of folks whose purpose is to not actually write to a (set of) resource(s), but to simply prevent others from writing to it while they are looking at it. Shared write locks do not necessarily do that because with a shared write lock. someone else could grab a shared lock and go ahead and write. The only way to block that is to get an exclusive write lock. But doing that prevents anyone else from doing what you're doing despite it being pretty benign. An expedient solution is to say that a shared write lock should not necessarily give one the right to modify a resource. All it should do is prevent others from writing. And then the purpose of an exclusive write lock is just to insure that others can't get a lock and block you from writing. Now is this the right solution? Probably not. There probably should be something called a read lock that actually prevents writes as a side effect.... and would tend to get used in shared mode. Anyway, as it is, I think the shared write locks are a red herring and we're missing something we are more likely to need... shared read locks. ------- 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@frink.w3.org Mon Nov 21 12:35:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFZp-0003ye-7K for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:35:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17543 for ; Mon, 21 Nov 2005 12:34:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeFZC-0000xS-EH for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 17:34:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeFZB-0000wu-TB for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 17:34:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeFZ8-0002KU-Rn for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 17:34:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALHYrcF004751; Mon, 21 Nov 2005 09:34:53 -0800 Date: Mon, 21 Nov 2005 09:34:53 -0800 Message-Id: <200511211734.jALHYrcF004751@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EeFZ8-0002KU-Rn 2a60574a8e776e97027b50ba4d784ab9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 122] LOCK_ISSUES X-Archived-At: http://www.w3.org/mid/200511211734.jALHYrcF004751@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10549 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 17:34:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=122 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-21 09:34 ------- I believe this issue can be closed; 8 distinct new issues have been added instead. ------- 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@frink.w3.org Mon Nov 21 13:35:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGVl-0008Rg-AU for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 13:35:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20929 for ; Mon, 21 Nov 2005 13:34:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGUb-0008QG-Qy for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 18:34:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGUX-0008Od-2I for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 18:34:13 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeGUU-00061r-TE for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 18:34:12 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2DC6D14229E; Mon, 21 Nov 2005 10:34:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28982-05; Mon, 21 Nov 2005 10:34:09 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B376A14229D; Mon, 21 Nov 2005 10:34:09 -0800 (PST) In-Reply-To: <4381CCFD.8040706@gmx.de> References: <4381CCFD.8040706@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-6--327984340 Message-Id: Cc: webdav WG From: Lisa Dusseault Date: Mon, 21 Nov 2005 10:33:58 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EeGUU-00061r-TE 767678d8b8909434a1d01e34cb0bf843 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fixes for editorial issues X-Archived-At: http://www.w3.org/mid/c2795ce13b5c4eceb172f84549c8dddf@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10550 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 18:34:17 +0000 --Apple-Mail-6--327984340 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Thanks for the help, I've incorporated many of these changes, and the diff format was especially useful for the whitespace-after-hyphen problem as well as for the symbolic references. Here's what I haven't entirely incorporated: - Bug 30, I didn't apply the XML line breaks exactly as you did but tried to retain the indentation as much as possible for readability. Still I think it achieves valid XML-ness now. - Bug 41, Nesting XML definition subsections, e.g. moving "depth XML element" as a subsection of "activelock XML element" and similar sub-section moves: This wasn't an error in RFC2518bis, it was an intentional editorial choice to flatten the subsection hierarchy. It's just a list of definitions, and a flat list seems more readable. Plus, with the nesting subsections, some section headers (like "propstat" definition section in your version) start to have four section numbers ("Section 13.9.1.1.") and either get lost or confusing in the TOC. - Bug 168 I applied the symbolic references changes, but I may make further changes in the future. Sometimes it's not very helpful to the reader just to have an RFC number and not a spec name or even acronym -- but we can have both. And perhaps you can suggest how to fix this ugly one: The XML namespace extension [W3C.REC-xml-names-19990114] is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. - Bug 174 is not strictly editorial, it actually changes the meaning of a requirement. Here's your suggested text: When the property value contains further XML elements, namespace declarations that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. In the context of the whole sentence, your change would state that the namespace declarations... MUST be preserved in server storage. Previously the sentence only stated that the namespace must be preserved in server storage. Perhaps we can find another phrasing entirely. Lisa On Nov 21, 2005, at 5:34 AM, Julian Reschke wrote: > Hi, > > the attachment fixes many editorial issues: 30, 41, 57, 63, 68, 88, > 89, 168, 174, 180, 182, 185, 187. > > Hopefully this is useful in reducing the number of open issues, and > concentrating on non-editorial ones. --Apple-Mail-6--327984340 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Thanks for the help, I've incorporated many of these changes, and the diff format was especially useful for the whitespace-after-hyphen problem as well as for the symbolic references. Here's what I haven't entirely incorporated: - Bug 30, I didn't apply the XML line breaks exactly as you did but tried to retain the indentation as much as possible for readability. Still I think it achieves valid XML-ness now. - Bug 41, Nesting XML definition subsections, e.g. moving "depth XML element" as a subsection of "activelock XML element" and similar sub-section moves: This wasn't an error in RFC2518bis, it was an intentional editorial choice to flatten the subsection hierarchy. It's just a list of definitions, and a flat list seems more readable. Plus, with the nesting subsections, some section headers (like "propstat" definition section in your version) start to have four section numbers ("Section 13.9.1.1.") and either get lost or confusing in the TOC. - Bug 168 I applied the symbolic references changes, but I may make further changes in the future. Sometimes it's not very helpful to the reader just to have an RFC number and not a spec name or even acronym -- but we can have both. And perhaps you can suggest how to fix this ugly one: The XML namespace extension [W3C.REC-xml-names-19990114] is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. - Bug 174 is not strictly editorial, it actually changes the meaning of a requirement. Here's your suggested text: When the property value contains further XML elements, namespace declarations that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. In the context of the whole sentence, your change would state that the namespace declarations... MUST be preserved in server storage. Previously the sentence only stated that the namespace must be preserved in server storage. Perhaps we can find another phrasing entirely. Lisa On Nov 21, 2005, at 5:34 AM, Julian Reschke wrote: Hi, the attachment fixes many editorial issues: 30, 41, 57, 63, 68, 88, 89, 168, 174, 180, 182, 185, 187. Hopefully this is useful in reducing the number of open issues, and concentrating on non-editorial ones. --Apple-Mail-6--327984340-- From w3c-dist-auth-request@frink.w3.org Mon Nov 21 13:59:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGsy-0007qI-Ti for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 13:59:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23789 for ; Mon, 21 Nov 2005 13:58:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGsE-0005SD-Uv for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 18:58:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGsA-0005R3-5h for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 18:58:38 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EeGs6-0000OA-17 for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 18:58:37 +0000 Received: (qmail invoked by alias); 21 Nov 2005 18:58:31 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp013) with SMTP; 21 Nov 2005 19:58:31 +0100 X-Authenticated: #1915285 Message-ID: <438218A0.4070405@gmx.de> Date: Mon, 21 Nov 2005 19:57:36 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: webdav WG References: <4381CCFD.8040706@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EeGs6-0000OA-17 87a060a9053b94f3a95c956c5d950241 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fixes for editorial issues X-Archived-At: http://www.w3.org/mid/438218A0.4070405@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10551 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 18:58:42 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Thanks for the help, I've incorporated many of these changes, and the > diff format was especially useful for the whitespace-after-hyphen > problem as well as for the symbolic references. Here's what I haven't > entirely incorporated: > > - Bug 30, I didn't apply the XML line breaks exactly as you did but > tried to retain the indentation as much as possible for readability. > Still I think it achieves valid XML-ness now. Well, it still doesn't parse because of http://example.com/workspace/webdav/proposal.doc< /D:href> Dunno why I didn't catch it, but it's a good indicator why the XML in the spec should be checked by an XML parser, not us. > - Bug 41, Nesting XML definition subsections, e.g. moving "depth XML > element" as a subsection of "activelock XML element" and similar > sub-section moves: This wasn't an error in RFC2518bis, it was an > intentional editorial choice to flatten the subsection hierarchy. It's > just a list of definitions, and a flat list seems more readable. Plus, > with the nesting subsections, some section headers (like "propstat" > definition section in your version) start to have four section numbers > ("Section 13.9.1.1.") and either get lost or confusing in the TOC. The elements were grouped in RFC2518, and I think that was fine. If there was consensus for this change, it would also need to be re-sorted. Anyway, I think this change should be reverted. The TOC is not an issue here, the TOC depth can be configured (although I personally prefer to have all entries in the TOC, that's the place where I look first, after all). > - Bug 168 I applied the symbolic references changes, but I may make > further changes in the future. Sometimes it's not very helpful to the > reader just to have an RFC number and not a spec name or even acronym -- > but we can have both. And perhaps you can suggest how to fix this ugly one: > > The XML namespace extension [W3C.REC-xml-names-19990114] is also used > in this specification in order to allow for new XML elements to be > added without fear of colliding with other element names. Just like for XML. In-line the reference and choose a good anchor name, preferably the same as in RFC2518. > - Bug 174 is not strictly editorial, it actually changes the meaning of > a requirement. Here's your suggested text: > > When the property value contains > further XML elements, namespace declarations that are in scope for that > part of > the XML document apply within the property value as well, and MUST > be preserved in server storage for retransmission later. I would have classified it as editorial. Could you please explain why you changed it in the first place? Anyway, I think that "namespace declarations" are to be preserved. > In the context of the whole sentence, your change would state that the > namespace *declarations*... MUST be preserved in server storage. > Previously the sentence only stated that the namespace must be preserved > in server storage. Perhaps we can find another phrasing entirely. Could you please explain what "preserving the namespace name" actually means? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Nov 21 13:59:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGtG-0007vw-R4 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 13:59:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23799 for ; Mon, 21 Nov 2005 13:59:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGsh-0005fY-P0 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 18:59:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGsh-0005eQ-7V for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 18:59:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeGsX-0000TF-Uz for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 18:59:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALIwxRK004831; Mon, 21 Nov 2005 10:58:59 -0800 Date: Mon, 21 Nov 2005 10:58:59 -0800 Message-Id: <200511211858.jALIwxRK004831@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeGsX-0000TF-Uz e1138abe68af0bfe133efb8c6cf247ea X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 185] Missing interpunction in "previous authors" subsection X-Archived-At: http://www.w3.org/mid/200511211858.jALIwxRK004831@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10552 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 18:59:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=185 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 10:58 ------- Fixed in early post-08 draft. ------- 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@frink.w3.org Mon Nov 21 14:00:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGta-00080S-O2 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:00:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23816 for ; Mon, 21 Nov 2005 13:59:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGsz-0005m5-P0 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 18:59:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGsz-0005lW-CD for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 18:59:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeGsx-0002OC-8m for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 18:59:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALIxR7A004849; Mon, 21 Nov 2005 10:59:27 -0800 Date: Mon, 21 Nov 2005 10:59:27 -0800 Message-Id: <200511211859.jALIxR7A004849@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EeGsx-0002OC-8m 06958e6e2f2a7f5376db7d21c33cca35 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 187] Changes section organization X-Archived-At: http://www.w3.org/mid/200511211859.jALIxR7A004849@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10553 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 18:59:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=187 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 10:59 ------- Fixed in early post-08 draft. ------- 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@frink.w3.org Mon Nov 21 14:00:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGto-000869-Pt for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:00:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23836 for ; Mon, 21 Nov 2005 13:59:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGtG-0005t5-5R for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 18:59:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGtF-0005sS-LP for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 18:59:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeGtC-0000cN-7j for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 18:59:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALIxfnZ004867; Mon, 21 Nov 2005 10:59:41 -0800 Date: Mon, 21 Nov 2005 10:59:41 -0800 Message-Id: <200511211859.jALIxfnZ004867@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeGtC-0000cN-7j b770fec61044223ac66172fa6e381b72 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 182] whitespace in lock token in example X-Archived-At: http://www.w3.org/mid/200511211859.jALIxfnZ004867@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10554 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 18:59:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=182 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 10:59 ------- Fixed in early post-08 draft. ------- 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@frink.w3.org Mon Nov 21 14:00:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGu3-000879-Hi for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:00:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23850 for ; Mon, 21 Nov 2005 13:59:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGtU-0005y1-5o for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:00:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGtT-0005xT-P2 for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 18:59:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeGtR-0002V6-Ox for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 18:59:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALIxv28004885; Mon, 21 Nov 2005 10:59:57 -0800 Date: Mon, 21 Nov 2005 10:59:57 -0800 Message-Id: <200511211859.jALIxv28004885@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EeGtR-0002V6-Ox bb2f2ba165211222a89cd69274b6a5dc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 180] Typo in 13.18, enhance reference X-Archived-At: http://www.w3.org/mid/200511211859.jALIxv28004885@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10555 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:00:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=180 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 10:59 ------- Fixed in early post-08 draft. ------- 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@frink.w3.org Mon Nov 21 14:01:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGur-0008Bk-61 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:01:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23876 for ; Mon, 21 Nov 2005 14:00:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGuI-0008Ey-6g for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:00:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGuH-0008EN-Me for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:00:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeGuE-0000qA-3e for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:00:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ0iSb004907; Mon, 21 Nov 2005 11:00:44 -0800 Date: Mon, 21 Nov 2005 11:00:44 -0800 Message-Id: <200511211900.jALJ0iSb004907@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeGuE-0000qA-3e 64606903f8c586b6180a28dc3ba542c5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 168] Revert to original reference style X-Archived-At: http://www.w3.org/mid/200511211900.jALJ0iSb004907@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10556 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:00:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=168 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:00 ------- Fixed in early post-08 draft. ------- 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@frink.w3.org Mon Nov 21 14:01:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGvJ-0008Cm-3R for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:01:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23903 for ; Mon, 21 Nov 2005 14:01:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGuj-0008KI-SW for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:01:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGuj-0008Jk-BD for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:01:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeGuc-0002ks-K9 for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:01:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ1AU4004935; Mon, 21 Nov 2005 11:01:10 -0800 Date: Mon, 21 Nov 2005 11:01:10 -0800 Message-Id: <200511211901.jALJ1AU4004935@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EeGuc-0002ks-K9 db68f57231d57e463b4dd27a81b785e1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 89] whitespace introduced into hyphenated words X-Archived-At: http://www.w3.org/mid/200511211901.jALJ1AU4004935@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10557 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:01:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=89 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:01 ------- Fixed in early post-08 draft. ------- 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@frink.w3.org Mon Nov 21 14:02:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGvf-0008EX-Lu for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:02:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23910 for ; Mon, 21 Nov 2005 14:01:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGv6-0008QI-7t for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:01:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGv5-0008Pf-MG for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:01:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeGux-00010p-S5 for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:01:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ1Vgf004953; Mon, 21 Nov 2005 11:01:31 -0800 Date: Mon, 21 Nov 2005 11:01:31 -0800 Message-Id: <200511211901.jALJ1Vgf004953@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeGux-00010p-S5 42da7a3977a615dbae161450ed9c7b4e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 88] typo in list X-Archived-At: http://www.w3.org/mid/200511211901.jALJ1Vgf004953@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10558 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:01:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=88 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:01 ------- Fixed in early post-08 draft. ------- 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@frink.w3.org Mon Nov 21 14:02:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGw3-0008GC-4l for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:02:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23932 for ; Mon, 21 Nov 2005 14:02:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGvU-000063-Gx for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:02:04 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeGvT-00005T-U0 for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:02:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeGvO-0004UN-2j for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:02:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ1tOe004973; Mon, 21 Nov 2005 11:01:55 -0800 Date: Mon, 21 Nov 2005 11:01:55 -0800 Message-Id: <200511211901.jALJ1tOe004973@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeGvO-0004UN-2j 0a71c4a1d378e3111f91b3ba1fae3d6c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 88] typo in list X-Archived-At: http://www.w3.org/mid/200511211901.jALJ1tOe004973@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10559 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:02:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=88 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Mon Nov 21 14:02:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGwL-0008I7-1B for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:02:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23945 for ; Mon, 21 Nov 2005 14:02:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGvk-0000By-RW for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:02:20 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeGvk-0000BQ-8F for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:02:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeGvg-0004Yr-SH for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:02:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ2GM9004991; Mon, 21 Nov 2005 11:02:16 -0800 Date: Mon, 21 Nov 2005 11:02:16 -0800 Message-Id: <200511211902.jALJ2GM9004991@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeGvg-0004Yr-SH a04ae40cd7f5cbfb18decd029bf0c6f0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 68] Reference to XML spec X-Archived-At: http://www.w3.org/mid/200511211902.jALJ2GM9004991@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10560 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:02:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=68 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:02 ------- Fixed in early post-08 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@frink.w3.org Mon Nov 21 14:04:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGxl-0008Uq-01 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:04:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24152 for ; Mon, 21 Nov 2005 14:03:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGx8-0000Kw-O6 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:03:46 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeGx8-0000KO-47 for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:03:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeGwv-0004on-CI for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:03:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ3WBP005010; Mon, 21 Nov 2005 11:03:32 -0800 Date: Mon, 21 Nov 2005 11:03:32 -0800 Message-Id: <200511211903.jALJ3WBP005010@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeGwv-0004on-CI 73d4f011961580270c5bccc340d78fc1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 63] typo in 13.16 "name" line X-Archived-At: http://www.w3.org/mid/200511211903.jALJ3WBP005010@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10561 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:03:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=63 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:03 ------- Fixed in early post-08 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@frink.w3.org Mon Nov 21 14:04:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGxw-0008W1-Ue for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:04:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24161 for ; Mon, 21 Nov 2005 14:03:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGxN-0000RO-B7 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:04:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGxM-0000Ql-Qh for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:04:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeGxF-0001Z6-0Z for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:04:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ3pLm005028; Mon, 21 Nov 2005 11:03:51 -0800 Date: Mon, 21 Nov 2005 11:03:51 -0800 Message-Id: <200511211903.jALJ3pLm005028@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EeGxF-0001Z6-0Z f72df0012463bd939f80a88d6c934e12 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 57] incorrect section reference X-Archived-At: http://www.w3.org/mid/200511211903.jALJ3pLm005028@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10562 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:04:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=57 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:03 ------- Fixed in early post-08 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@frink.w3.org Mon Nov 21 14:05:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGyX-0000F5-Ob for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:05:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24199 for ; Mon, 21 Nov 2005 14:04:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGxy-0000b0-Gn for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:04:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeGxy-0000aS-3w for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:04:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeGxv-0003Yd-UR for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:04:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ4ZA7005046; Mon, 21 Nov 2005 11:04:35 -0800 Date: Mon, 21 Nov 2005 11:04:35 -0800 Message-Id: <200511211904.jALJ4ZA7005046@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EeGxv-0003Yd-UR ea84f2403e950bebee20a0535a5c73f9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 30] incorrect XML in example X-Archived-At: http://www.w3.org/mid/200511211904.jALJ4ZA7005046@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10563 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:04:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=30 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:04 ------- Fixed in early post-08 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@frink.w3.org Mon Nov 21 14:06:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeH04-0000xe-5p for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:06:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24399 for ; Mon, 21 Nov 2005 14:06:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeGzS-0001JV-Dw for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:06:10 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeGzR-0001Iq-Pz for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:06:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EeGzM-0005TL-2k for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:06:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jALJ63u0005064; Mon, 21 Nov 2005 11:06:03 -0800 Date: Mon, 21 Nov 2005 11:06:03 -0800 Message-Id: <200511211906.jALJ63u0005064@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EeGzM-0005TL-2k 8143d2b9d96e635ac255712378d158a5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 41] Paragraph numbering/nesting broken in Section 13 X-Archived-At: http://www.w3.org/mid/200511211906.jALJ63u0005064@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10564 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:06:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:06 ------- There's nothing wrong with a flat list of XML element definition sections. It's not a bug. I propose that we close this bugzilla issue "won't fix". ------- 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@frink.w3.org Mon Nov 21 14:28:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHKf-0006G0-R8 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:28:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27239 for ; Mon, 21 Nov 2005 14:27:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeHJs-0008Bb-1i for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 19:27:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeHJm-00088z-Gw for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 19:27:10 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeHJd-0008Pi-OD for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 19:27:10 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 42B4F142280; Mon, 21 Nov 2005 11:26:45 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03695-03; Mon, 21 Nov 2005 11:26:44 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 81D8114229B; Mon, 21 Nov 2005 11:26:43 -0800 (PST) In-Reply-To: <438218A0.4070405@gmx.de> References: <4381CCFD.8040706@gmx.de> <438218A0.4070405@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5792588e0eb82355ed2980900b44c918@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: webdav WG From: Lisa Dusseault Date: Mon, 21 Nov 2005 11:26:27 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EeHJd-0008Pi-OD b80759cf0471f9dfab22ebae1b5e15a5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fixes for editorial issues X-Archived-At: http://www.w3.org/mid/5792588e0eb82355ed2980900b44c918@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10565 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 19:27:16 +0000 Content-Transfer-Encoding: 7bit On Nov 21, 2005, at 10:57 AM, Julian Reschke wrote: > >> - Bug 168 I applied the symbolic references changes, but I may make >> further changes in the future. Sometimes it's not very helpful to the >> reader just to have an RFC number and not a spec name or even acronym >> -- but we can have both. And perhaps you can suggest how to fix this >> ugly one: >> The XML namespace extension [W3C.REC-xml-names-19990114] is also used >> in this specification in order to allow for new XML elements to be >> added without fear of colliding with other element names. > > Just like for XML. In-line the reference and choose a good anchor > name, preferably the same as in RFC2518. Ah, I see. What a pain to have to have the whole reference inline -- I like having references in some external place, safe from my typos. Both ugly choices, sadly. > >> - Bug 174 is not strictly editorial, it actually changes the meaning >> of a requirement. Here's your suggested text: >> When the property value contains >> further XML elements, namespace declarations that are in scope for >> that part of >> the XML document apply within the property value as well, and MUST >> be preserved in server storage for retransmission later. > > I would have classified it as editorial. Could you please explain why > you changed it in the first place? Anyway, I think that "namespace > declarations" are to be preserved. If we state that namespace declarations must be preserved, doesn't that mean that the server must return the property value with the same namespace declarations it was originally sent with, on the same element, and even including the prefix? Because the namespace declaration includes the prefix, as I understand. > >> In the context of the whole sentence, your change would state that >> the namespace *declarations*... MUST be preserved in server storage. >> Previously the sentence only stated that the namespace must be >> preserved in server storage. Perhaps we can find another phrasing >> entirely. > > Could you please explain what "preserving the namespace name" actually > means? > Presumably if we require the server to store the namespace (the text no longer says to store the namespace name), then that means that the server can remember that the element "foo" was declared in namespace "bar" without having to remember what element namespace "bar" was declared on or what prefix was used in the declaration. But like I said, perhaps we can come up with better wording overall, perhaps even simpler. Here's a stab at it: "When a property value contains XML elements with qualified names, servers retransmitting the property value MUST include namespaces and equivalently scoped element names. " I'm really struggling with a way to state this -- I'm not happy at all with "equivalently scoped element names" but I don't think we want to require that the server use the exact same qualified names (that would also imply preserving the prefix). Here's another stab: "When a property value contains XML elements with namespaces either declared or in scope, and that property value is retransmitted later by the server, the property value MUST continue to apply the same namespaces to all elements, even if the declarations have changed." Soliciting other suggestions here, Lisa From w3c-dist-auth-request@frink.w3.org Mon Nov 21 15:41:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeITn-0008WK-1z for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 15:41:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06134 for ; Mon, 21 Nov 2005 15:40:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeISI-0005LC-6d for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 20:40:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeISD-0005KM-7C for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 20:39:57 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EeIS8-00059v-AK for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 20:39:56 +0000 Received: (qmail invoked by alias); 21 Nov 2005 20:39:50 -0000 Received: from p508FBBEC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.187.236] by mail.gmx.net (mp026) with SMTP; 21 Nov 2005 21:39:50 +0100 X-Authenticated: #1915285 Message-ID: <43823063.3080805@gmx.de> Date: Mon, 21 Nov 2005 21:38:59 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200511211906.jALJ63u0005064@ietf.cse.ucsc.edu> In-Reply-To: <200511211906.jALJ63u0005064@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EeIS8-00059v-AK 2d9b0eb331e350a45e89c9f6dc2c1dfd X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 41] Paragraph numbering/nesting broken in Section 13 X-Archived-At: http://www.w3.org/mid/43823063.3080805@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10566 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 20:40:02 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 > > > > > > ------- Additional Comments From lisa@osafoundation.org 2005-11-21 11:06 ------- > There's nothing wrong with a flat list of XML element definition sections. It's > not a bug. I propose that we close this bugzilla issue "won't fix". Well, RFC2518 had an alphabetical list, with sub elements appearing subsections. I think this made a lot of sense, and AFAIK nobody asked for a change. The new format uses a flatted list, but it wasn't sorted again, resulting in a TOC like: 13. XML Element Definitions * 13.1 activelock XML Element * 13.2 depth XML Element * 13.3 locktoken XML Element * 13.4 lockroot XML Element * 13.5 timeout XML Element * 13.6 collection XML Element * 13.7 href XML Element * 13.8 lockentry XML Element * 13.9 lockinfo XML Element * 13.10 lockscope XML Element * 13.11 exclusive XML Element * 13.12 shared XML Element * 13.13 locktype XML Element * 13.14 write XML Element * 13.15 multistatus XML Element * 13.16 response XML Element * 13.17 propstat XML Element * 13.18 status XML Element * 13.19 responsedescription XML Element * 13.20 owner XML Element * 13.21 prop XML element * 13.22 propertyupdate XML element * 13.23 remove XML element * 13.24 set XML element * 13.25 propfind XML Element * 13.26 allprop XML Element * 13.27 propname XML Element * 13.28 dead-props XML Element * 13.29 error XML Element which I think is less accessible than what we used to have in RFC2518: 12. XML Element Definitions * 12.1 activelock XML Element o 12.1.1 depth XML Element o 12.1.2 locktoken XML Element o 12.1.3 timeout XML Element * 12.2 collection XML Element * 12.3 href XML Element * 12.4 link XML Element o 12.4.1 dst XML Element o 12.4.2 src XML Element * 12.5 lockentry XML Element * 12.6 lockinfo XML Element * 12.7 lockscope XML Element o 12.7.1 exclusive XML Element o 12.7.2 shared XML Element * 12.8 locktype XML Element o 12.8.1 write XML Element * 12.9 multistatus XML Element o 12.9.1 response XML Element + 12.9.1.1 propstat XML Element + 12.9.1.2 status XML Element o 12.9.2 responsedescription XML Element * 12.10 owner XML Element * 12.11 prop XML element * 12.12 propertybehavior XML element o 12.12.1 keepalive XML element o 12.12.2 omit XML element * 12.13 propertyupdate XML element o 12.13.1 remove XML element o 12.13.2 set XML element * 12.14 propfind XML Element o 12.14.1 allprop XML Element o 12.14.2 propname XML Element Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Nov 21 15:48:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIaL-0002Vn-RL for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 15:48:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06868 for ; Mon, 21 Nov 2005 15:47:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeIZh-0008U0-94 for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 20:47:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeIZg-0008T8-JH; Mon, 21 Nov 2005 20:47:40 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeIZM-0002bY-8W; Mon, 21 Nov 2005 20:47:39 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jALKkogs026831; Mon, 21 Nov 2005 15:46:50 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jALKkofM120488; Mon, 21 Nov 2005 15:46:50 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jALKkoig017714; Mon, 21 Nov 2005 15:46:50 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jALKkouu017710; Mon, 21 Nov 2005 15:46:50 -0500 In-Reply-To: <43823063.3080805@gmx.de> To: Julian Reschke Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 21 Nov 2005 15:47:09 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/21/2005 15:46:50, Serialize complete at 11/21/2005 15:46:50 Content-Type: multipart/alternative; boundary="=_alternative 00722C78852570C0_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EeIZM-0002bY-8W 4aeea5d19344f38dbeae0ffe377ea910 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 41] Paragraph numbering/nesting broken in Section 13 X-Archived-At: http://www.w3.org/mid/OFDAF94ADD.288CDBB2-ON852570C0.007222D0-852570C0.00722CF2@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10567 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 20:47:41 +0000 This is a multipart message in MIME format. --=_alternative 00722C78852570C0_= Content-Type: text/plain; charset="US-ASCII" I agree that the orginal 2518 formatting is superior. Cheers, Geoff Julian wrote on 11/21/2005 03:38:59 PM: > > bugzilla@soe.ucsc.edu wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 > > > > > > > > > > > > ------- Additional Comments From lisa@osafoundation.org > 2005-11-21 11:06 ------- > > There's nothing wrong with a flat list of XML element definition > sections. It's > > not a bug. I propose that we close this bugzilla issue "won't fix". > > Well, RFC2518 had an alphabetical list, with sub elements appearing > subsections. I think this made a lot of sense, and AFAIK nobody asked > for a change. > > The new format uses a flatted list, but it wasn't sorted again, > resulting in a TOC like: > > 13. XML Element Definitions > > * 13.1 activelock XML Element > * 13.2 depth XML Element > * 13.3 locktoken XML Element > * 13.4 lockroot XML Element > * 13.5 timeout XML Element > * 13.6 collection XML Element > * 13.7 href XML Element > * 13.8 lockentry XML Element > * 13.9 lockinfo XML Element > * 13.10 lockscope XML Element > * 13.11 exclusive XML Element > * 13.12 shared XML Element > * 13.13 locktype XML Element > * 13.14 write XML Element > * 13.15 multistatus XML Element > * 13.16 response XML Element > * 13.17 propstat XML Element > * 13.18 status XML Element > * 13.19 responsedescription XML Element > * 13.20 owner XML Element > * 13.21 prop XML element > * 13.22 propertyupdate XML element > * 13.23 remove XML element > * 13.24 set XML element > * 13.25 propfind XML Element > * 13.26 allprop XML Element > * 13.27 propname XML Element > * 13.28 dead-props XML Element > * 13.29 error XML Element > > which I think is less accessible than what we used to have in RFC2518: > > 12. XML Element Definitions > > * 12.1 activelock XML Element > o 12.1.1 depth XML Element > o 12.1.2 locktoken XML Element > o 12.1.3 timeout XML Element > * 12.2 collection XML Element > * 12.3 href XML Element > * 12.4 link XML Element > o 12.4.1 dst XML Element > o 12.4.2 src XML Element > * 12.5 lockentry XML Element > * 12.6 lockinfo XML Element > * 12.7 lockscope XML Element > o 12.7.1 exclusive XML Element > o 12.7.2 shared XML Element > * 12.8 locktype XML Element > o 12.8.1 write XML Element > * 12.9 multistatus XML Element > o 12.9.1 response XML Element > + 12.9.1.1 propstat XML Element > + 12.9.1.2 status XML Element > o 12.9.2 responsedescription XML Element > * 12.10 owner XML Element > * 12.11 prop XML element > * 12.12 propertybehavior XML element > o 12.12.1 keepalive XML element > o 12.12.2 omit XML element > * 12.13 propertyupdate XML element > o 12.13.1 remove XML element > o 12.13.2 set XML element > * 12.14 propfind XML Element > o 12.14.1 allprop XML Element > o 12.14.2 propname XML Element > > Best regards, Julian > > > > > --=_alternative 00722C78852570C0_= Content-Type: text/html; charset="US-ASCII"
I agree that the orginal 2518 formatting is superior.

Cheers,
Geoff


Julian wrote on 11/21/2005 03:38:59 PM:

>
> bugzilla@soe.ucsc.edu wrote:
> > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41
> >
> >
> >
> >
> >
> > ------- Additional Comments From lisa@osafoundation.org  
> 2005-11-21 11:06 -------
> > There's nothing wrong with a flat list of XML element definition
> sections. It's
> > not a bug.  I propose that we close this bugzilla issue "won't fix".
>
> Well, RFC2518 had an alphabetical list, with sub elements appearing
> subsections. I think this made a lot of sense, and AFAIK nobody asked
> for a change.
>
> The new format uses a flatted list, but it wasn't sorted again,
> resulting in a TOC like:
>
> 13.   XML Element Definitions
>
>      * 13.1   activelock XML Element
>      * 13.2   depth XML Element
>      * 13.3   locktoken XML Element
>      * 13.4   lockroot XML Element
>      * 13.5   timeout XML Element
>      * 13.6   collection XML Element
>      * 13.7   href XML Element
>      * 13.8   lockentry XML Element
>      * 13.9   lockinfo XML Element
>      * 13.10   lockscope XML Element
>      * 13.11   exclusive XML Element
>      * 13.12   shared XML Element
>      * 13.13   locktype XML Element
>      * 13.14   write XML Element
>      * 13.15   multistatus XML Element
>      * 13.16   response XML Element
>      * 13.17   propstat XML Element
>      * 13.18   status XML Element
>      * 13.19   responsedescription XML Element
>      * 13.20   owner XML Element
>      * 13.21   prop XML element
>      * 13.22   propertyupdate XML element
>      * 13.23   remove XML element
>      * 13.24   set XML element
>      * 13.25   propfind XML Element
>      * 13.26   allprop XML Element
>      * 13.27   propname XML Element
>      * 13.28   dead-props XML Element
>      * 13.29   error XML Element
>
> which I think is less accessible than what we used to have in RFC2518:
>
> 12.   XML Element Definitions
>
>      * 12.1   activelock XML Element
>            o 12.1.1   depth XML Element
>            o 12.1.2   locktoken XML Element
>            o 12.1.3   timeout XML Element
>      * 12.2   collection XML Element
>      * 12.3   href XML Element
>      * 12.4   link XML Element
>            o 12.4.1   dst XML Element
>            o 12.4.2   src XML Element
>      * 12.5   lockentry XML Element
>      * 12.6   lockinfo XML Element
>      * 12.7   lockscope XML Element
>            o 12.7.1   exclusive XML Element
>            o 12.7.2   shared XML Element
>      * 12.8   locktype XML Element
>            o 12.8.1   write XML Element
>      * 12.9   multistatus XML Element
>            o 12.9.1   response XML Element
>                  + 12.9.1.1   propstat XML Element
>                  + 12.9.1.2   status XML Element
>            o 12.9.2   responsedescription XML Element
>      * 12.10   owner XML Element
>      * 12.11   prop XML element
>      * 12.12   propertybehavior XML element
>            o 12.12.1   keepalive XML element
>            o 12.12.2   omit XML element
>      * 12.13   propertyupdate XML element
>            o 12.13.1   remove XML element
>            o 12.13.2   set XML element
>      * 12.14   propfind XML Element
>            o 12.14.1   allprop XML Element
>            o 12.14.2   propname XML Element
>
> Best regards, Julian
>
>
>
>
>
--=_alternative 00722C78852570C0_=-- From w3c-dist-auth-request@frink.w3.org Mon Nov 21 16:03:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIp8-0006J3-HR for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 16:03:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10058 for ; Mon, 21 Nov 2005 16:03:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeIoN-0003sy-5r for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 21:02:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeIoK-0003ro-I2 for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 21:02:48 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EeIoF-0007QK-KS for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 21:02:47 +0000 Received: (qmail invoked by alias); 21 Nov 2005 21:02:40 -0000 Received: from p508FBBEC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.187.236] by mail.gmx.net (mp036) with SMTP; 21 Nov 2005 22:02:40 +0100 X-Authenticated: #1915285 Message-ID: <438235BC.3080508@gmx.de> Date: Mon, 21 Nov 2005 22:01:48 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: webdav WG References: <4381CCFD.8040706@gmx.de> <438218A0.4070405@gmx.de> <5792588e0eb82355ed2980900b44c918@osafoundation.org> In-Reply-To: <5792588e0eb82355ed2980900b44c918@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EeIoF-0007QK-KS 50e93513543ada2a59a555fb32d9ac83 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fixes for editorial issues X-Archived-At: http://www.w3.org/mid/438235BC.3080508@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10568 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 21:02:51 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > On Nov 21, 2005, at 10:57 AM, Julian Reschke wrote: >> >>> - Bug 168 I applied the symbolic references changes, but I may make >>> further changes in the future. Sometimes it's not very helpful to the >>> reader just to have an RFC number and not a spec name or even acronym >>> -- but we can have both. And perhaps you can suggest how to fix this >>> ugly one: >>> The XML namespace extension [W3C.REC-xml-names-19990114] is also used >>> in this specification in order to allow for new XML elements to be >>> added without fear of colliding with other element names. >> >> Just like for XML. In-line the reference and choose a good anchor >> name, preferably the same as in RFC2518. > > Ah, I see. What a pain to have to have the whole reference inline -- I > like having references in some external place, safe from my typos. Both > ugly choices, sadly. Just copy the definition once, fixing it where needed (and the automatically generated once frequently need fixing). They are safe from typos as long as changes to the documents are controlled (for instance, by a working revision control system). That being said, here's the entry for XMLNS I used on RFC2518.xml: Namespaces in XML Textuality
tbray@textuality.com
Hewlett-Packard Company
dmh@corp.hp.com
Microsoft
andrewl@microsoft.com
>>> - Bug 174 is not strictly editorial, it actually changes the meaning >>> of a requirement. Here's your suggested text: >>> When the property value contains >>> further XML elements, namespace declarations that are in scope for >>> that part of >>> the XML document apply within the property value as well, and MUST >>> be preserved in server storage for retransmission later. >> >> I would have classified it as editorial. Could you please explain why >> you changed it in the first place? Anyway, I think that "namespace >> declarations" are to be preserved. > > If we state that namespace declarations must be preserved, doesn't that > mean that the server must return the property value with the same > namespace declarations it was originally sent with, on the same element, > and even including the prefix? Because the namespace declaration > includes the prefix, as I understand. Well, I would have preferred that instead of silently changing the document, you would have explained why you think it needs to be changed so that the problem can be discussed. I don't see how the current text "namespace names in scope" makes any sense. If you don't like "namespace declarations" (which may imply something about prefixes, granted), just stick with the text we had before. What was wrong with it? >>> In the context of the whole sentence, your change would state that >>> the namespace *declarations*... MUST be preserved in server storage. >>> Previously the sentence only stated that the namespace must be >>> preserved in server storage. Perhaps we can find another phrasing >>> entirely. >> >> Could you please explain what "preserving the namespace name" actually >> means? >> > > Presumably if we require the server to store the namespace (the text no > longer says to store the namespace name), then that means that the > server can remember that the element "foo" was declared in namespace > ... OK, case closed. The previous text is back in. No further discussion is needed. > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Nov 21 17:39:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKJY-00033t-OK for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 17:39:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21570 for ; Mon, 21 Nov 2005 17:38:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeKIL-0004NL-LT for w3c-dist-auth-dist@listhub.w3.org; Mon, 21 Nov 2005 22:37:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeKIG-0004Mk-2L for w3c-dist-auth@listhub.w3.org; Mon, 21 Nov 2005 22:37:48 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EeKI8-00087W-Dv for w3c-dist-auth@w3.org; Mon, 21 Nov 2005 22:37:47 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E97D81422A3; Mon, 21 Nov 2005 14:37:37 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21098-06; Mon, 21 Nov 2005 14:37:37 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 885101422A1; Mon, 21 Nov 2005 14:37:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) To: Julian Reschke Message-Id: <6afe73f812e0332e98ff9bae7ac7953b@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-7--313373348 Cc: webdav WG From: Lisa Dusseault Date: Mon, 21 Nov 2005 14:37:29 -0800 X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EeKI8-00087W-Dv 338074f8190180f3476a5caff8ea23ad X-Original-To: w3c-dist-auth@w3.org Subject: Fwd: [Bug 190] New: HTTP examples using RFC2629 markup X-Archived-At: http://www.w3.org/mid/6afe73f812e0332e98ff9bae7ac7953b@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10569 X-Loop: w3c-dist-auth@w3.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, 21 Nov 2005 22:37:53 +0000 --Apple-Mail-7--313373348 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I'm in favour of this change, and were you to supply me with a diff, it would happen all the sooner. Thanks ! Lisa Begin forwarded message: > Resent-From: w3c-dist-auth@w3.org > From: bugzilla@soe.ucsc.edu > Date: November 21, 2005 7:19:04 AM PST > To: w3c-dist-auth@w3.org > Subject: [Bug 190] New: HTTP examples using RFC2629 markup > > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=190 > > Summary: HTTP examples using RFC2629 markup > Product: WebDAV-RFC2518-bis > Version: -08 > Platform: Other > OS/Version: other > Status: NEW > Severity: enhancement > Priority: P2 > Component: Other > AssignedTo: joe-bugzilla@cursive.net > ReportedBy: julian.reschke@greenbytes.de > QAContact: w3c-dist-auth@w3.org > > > Currently the spec puts all (or most) HTTP request/response examples > into a > single RCF2629 artwork element. This has several disadvantages: > > - xm2rfc processors will not be aware that the whitespace between > request and > response is a good place for a page break > > - automatic XML checks in artwork fail (see > rfc2629xslt.html#rfc.section.3.3>, > "parse-xml-in-artwork") > > Also, putting the strings ">>> Request" and ">>> Response" into the > figure > preambles will make it easier to read in non-plain-ASCII versions of > the spec > (yes, this is cosmetic). > > Should we have consensus for this change, I'm volunteering to make it. > > > > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. > --Apple-Mail-7--313373348 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit I'm in favour of this change, and were you to supply me with a diff, it would happen all the sooner. Thanks ! Lisa Begin forwarded message: 0000,0000,0000Resent-From: w3c-dist-auth@w3.org 0000,0000,0000From: bugzilla@soe.ucsc.edu 0000,0000,0000Date: November 21, 2005 7:19:04 AM PST 0000,0000,0000To: w3c-dist-auth@w3.org 0000,0000,0000Subject: [Bug 190] New: HTTP examples using RFC2629 markup http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=190 Summary: HTTP examples using RFC2629 markup Product: WebDAV-RFC2518-bis Version: -08 Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Currently the spec puts all (or most) HTTP request/response examples into a single RCF2629 artwork element. This has several disadvantages: - xm2rfc processors will not be aware that the whitespace between request and response is a good place for a page break - automatic XML checks in artwork fail (see <, "parse-xml-in-artwork") Also, putting the strings ">>> Request" and ">>> Response" into the figure preambles will make it easier to read in non-plain-ASCII versions of the spec (yes, this is cosmetic). Should we have consensus for this change, I'm volunteering to make it. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. --Apple-Mail-7--313373348-- From arodland@globalpcdirect.com Mon Nov 21 18:18:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKvV-0000Ii-U5 for webdav-archive@megatron.ietf.org; Mon, 21 Nov 2005 18:18:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25457 for ; Mon, 21 Nov 2005 18:17:43 -0500 (EST) Received: from cpe-155-143-63-122.vic.bigpond.net.au ([155.143.63.122] helo=-1215107152) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeLE0-00072g-Uz for webdav-archive@ietf.org; Mon, 21 Nov 2005 18:37:31 -0500 Received: from globalpcdirect.com (-1214730048 [-1215094064]) by cpe-155-143-63-122.vic.bigpond.net.au (Qmailv1) with ESMTP id E24A36EF90 for ; Mon, 21 Nov 2005 17:11:49 -0500 Date: Mon, 21 Nov 2005 17:11:49 -0500 From: Doctor X-Mailer: The Bat! (v2.00.6) Personal X-Priority: 3 Message-ID: <7088407446.20051121171149@globalpcdirect.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------0809156CC54A620" X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. X-Spam-Score: 1.2 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------0809156CC54A620 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlangra $3.3 Levidtra $3.3 Ciaxlis $3.7 Imitsrex $16.4 Flomeax $2.2 Ultrsam $0.78 Viouxx $4.75 Ambbien $2.2 Valjium $0.97 Xanalx $1.09 Soima $3 Merizdia $2.2 visit our website http://haacoper.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals qwefgfgjs RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------0809156CC54A620 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlagfra - $3.3
Lexvitra - $3.3
Cialils - $3.7
Imuitrex - $16.4
Flwomax - $2.2
Uletram - $0.78
Vijoxx - $4.75
Amcbien - $2.2
Vawlium - $0.97
Xaqnax - $1.09
Sjoma - $3
Maeridia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

qwefgfgjs RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------0809156CC54A620-- From w3c-dist-auth-request@frink.w3.org Tue Nov 22 09:09:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYpu-0007Fr-Ev for webdav-archive@megatron.ietf.org; Tue, 22 Nov 2005 09:09:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20938 for ; Tue, 22 Nov 2005 09:08:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeYnz-00010q-RF for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Nov 2005 14:07:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EeYns-00010A-Qm for w3c-dist-auth@listhub.w3.org; Tue, 22 Nov 2005 14:07:25 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EeYld-0003wJ-WD for w3c-dist-auth@w3.org; Tue, 22 Nov 2005 14:07:24 +0000 Received: (qmail invoked by alias); 22 Nov 2005 14:04:38 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp003) with SMTP; 22 Nov 2005 15:04:38 +0100 X-Authenticated: #1915285 Message-ID: <43832539.5010803@gmx.de> Date: Tue, 22 Nov 2005 15:03:37 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: webdav WG CC: Lisa Dusseault References: <6afe73f812e0332e98ff9bae7ac7953b@osafoundation.org> In-Reply-To: <6afe73f812e0332e98ff9bae7ac7953b@osafoundation.org> Content-Type: multipart/mixed; boundary="------------040305080801000400010008" X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EeYld-0003wJ-WD 00c95b8703643c738c97f0d6e23a46e1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fwd: [Bug 190] New: HTTP examples using RFC2629 markup X-Archived-At: http://www.w3.org/mid/43832539.5010803@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10570 X-Loop: w3c-dist-auth@w3.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, 22 Nov 2005 14:07:31 +0000 This is a multi-part message in MIME format. --------------040305080801000400010008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I'm in favour of this change, and were you to supply me with a diff, it > would happen all the sooner. Thanks ! OK, the attached source (+ diff) fixes: - artwork as discussed (also making indentation consistent and fixing XML errors) - makes the LOCK compatibility table a proper table (rfc2629 style) While doing this, I had also to re-add subsections for the examples (this was lost in an earlier draft; I suspect that was an error due to the conversion to XML source). Best regards, Julian --------------040305080801000400010008 Content-Type: text/plain; name="diffs" Content-Disposition: inline; filename="diffs" Content-Transfer-Encoding: 7bit Index: draft-ietf-webdav-rfc2518bis-latest.xml =================================================================== RCS file: /var/cvsroot/xml2rfc/draft-ietf-webdav-rfc2518bis-latest.xml,v retrieving revision 1.9 diff -r1.9 draft-ietf-webdav-rfc2518bis-latest.xml 24a25 > 1021,1038c1022,1037 <
< Example - Write Lock < >Request < < COPY /~fielding/index.html HTTP/1.1 < Host: www.ics.uci.edu < Destination: http://www.ics.uci.edu/users/f/fielding/index.html < If: < () < < < >>Response < < HTTP/1.1 204 No Content < < ]]> --- >
>
> >>Request > > COPY /~fielding/index.html HTTP/1.1 > Host: www.ics.uci.edu > Destination: http://www.ics.uci.edu/users/f/fielding/index.html > If: <http://www.ics.uci.edu/users/f/fielding/index.html> > (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>) > >
>
> >>Response > > HTTP/1.1 204 No Content > 1040d1038 < 1050a1049 >
1218,1225c1217,1224 < HTTP/1.1 403 Forbidden < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < --- > HTTP/1.1 403 Forbidden > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > > > > 1358a1358 > >>Request 1360,1361d1359 < >>Request < 1376,1378c1374,1378 < < >>Response < --- > ]]> >
>
> >>Response > >>Request 1425c1425,1429 < >>Request --- > PROPFIND /mycol/ HTTP/1.1 > Host: www.example.com > Depth: 1 > Content-type: text/xml; charset="utf-8" > Content-Length: xxxx 1427,1440c1431,1438 < PROPFIND /mycol/ HTTP/1.1 < Host: www.example.com < Depth: 1 < Content-type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < < < < < --- > > > > > > > > 1451a1450,1456 >
> >>Request > PROPFIND /container/ HTTP/1.1 > Host: www.example.com > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx 1452a1458,1463 > > > > > ]]> >
1453a1465 > >>Response 1455,1505c1467,1504 < >>Request < PROPFIND /container/ HTTP/1.1 < Host: www.example.com < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < < < >>Response < < HTTP/1.1 207 Multi-Status < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < http://www.example.com/container/ < < < < < < < < < < HTTP/1.1 200 OK < < < < http://www.example.com/container/front.html < < < < < < < < < < < < < HTTP/1.1 200 OK < < < --- > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > > > > http://www.example.com/container/ > > > > > > > > > > HTTP/1.1 200 OK > > > > http://www.example.com/container/front.html > > > > > > > > > > > > > HTTP/1.1 200 OK > > > 1612a1612 > >>Request 1614,1635c1614,1617 < >>Request < < PROPPATCH /bar.html HTTP/1.1 < Host: www.example.com < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < < < Jim Whitehead < Roy Fielding < < < < < < < --- > PROPPATCH /bar.html HTTP/1.1 > Host: www.example.com > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx 1637c1619,1641 < >>Response --- > > xmlns:Z="http://www.w3.com/standards/z39.50/"> > > > > Jim Whitehead > Roy Fielding > > > > > > > > ]]> >
>
> >>Response > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx 1639,1659c1643,1659 < HTTP/1.1 207 Multi-Status < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < http://www.example.com/bar.html < < < HTTP/1.1 424 Failed Dependency < < < < HTTP/1.1 409 Conflict < < Copyright Owner can not be deleted or < altered. < < --- > > xmlns:Z="http://www.w3.com/standards/z39.50"> > > http://www.example.com/bar.html > > > HTTP/1.1 424 Failed Dependency > > > > HTTP/1.1 409 Conflict > > Copyright Owner can not be deleted or > altered. > > 1748d1747 < 1749a1749 > >>Request 1751,1759c1751,1758 < >>Request < < MKCOL /webdisc/xfiles/ HTTP/1.1 < Host: www.example.com < < >>Response < < HTTP/1.1 201 Created < --- > MKCOL /webdisc/xfiles/ HTTP/1.1 > Host: www.example.com > ]]> >
>
> >>Response > HTTP/1.1 201 Created 1859a1859 > >>Request 1860a1861,1870 > DELETE /container/ HTTP/1.1 > Host: www.example.com > ]]> >
>
> >>Response > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx 1862,1879c1872,1878 < >>Request < < DELETE /container/ HTTP/1.1 < Host: www.example.com < < >>Response < < HTTP/1.1 207 Multi-Status < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < http://www.example.com/container/resource3 < HTTP/1.1 423 Locked < < --- > > > > http://www.example.com/container/resource3 > HTTP/1.1 423 Locked > > 2129c2128 <
--- >
2138c2137 < COPY with Overwrite --- > >>Request 2140,2148c2139,2141 < >>Request < < COPY /~fielding/index.html HTTP/1.1 < Host: www.ics.uci.edu < Destination: http://www.ics.uci.edu/users/f/fielding/index.html < < >>Response < < HTTP/1.1 204 No Content --- > COPY /~fielding/index.html HTTP/1.1 > Host: www.ics.uci.edu > Destination: http://www.ics.uci.edu/users/f/fielding/index.html 2151c2144,2152 < --- >
> >>Response > HTTP/1.1 204 No Content > ]]> >
>
> >
2158d2158 < 2160c2160 < COPY with No Overwrite --- > >>Request 2161a2162,2174 > COPY /~fielding/index.html HTTP/1.1 > Host: www.ics.uci.edu > Destination: http://www.ics.uci.edu/users/f/fielding/index.html > Overwrite: F > ]]> >
>
> >>Response > HTTP/1.1 412 Precondition Failed > ]]> >
>
2163,2172c2176,2183 < >>Request < < COPY /~fielding/index.html HTTP/1.1 < Host: www.ics.uci.edu < Destination: http://www.ics.uci.edu/users/f/fielding/index.html < Overwrite: F < < >>Response < < HTTP/1.1 412 Precondition Failed --- >
>
> >>Request > COPY /container/ HTTP/1.1 > Host: www.example.com > Destination: http://www.example.com/othercontainer/ > Depth: infinity 2175d2185 < 2177c2187 < Example - COPY of a Collection --- > >>Response 2179c2189,2191 < >>Request --- > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx 2181,2186c2193 < COPY /container/ HTTP/1.1 < Host: www.example.com < Destination: http://www.example.com/othercontainer/ < Depth: infinity < < >>Response --- > 2188,2199c2195,2200 < HTTP/1.1 207 Multi-Status < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < < http://www.example.com/othercontainer/R2/ < HTTP/1.1 423 Locked < < --- > > > http://www.example.com/othercontainer/R2/ > HTTP/1.1 423 Locked > > 2202d2202 < 2381c2381 <
--- >
2393c2393 < MOVE of a Non-Collection --- > >>Request 2395,2404c2395,2397 < >>Request < < MOVE /~fielding/index.html HTTP/1.1 < Host: www.ics.uci.edu < Destination: http://www.ics.uci.edu/users/f/fielding/index.html < < >>Response < < HTTP/1.1 201 Created < Location: http://www.ics.uci.edu/users/f/fielding/index.html --- > MOVE /~fielding/index.html HTTP/1.1 > Host: www.ics.uci.edu > Destination: http://www.ics.uci.edu/users/f/fielding/index.html 2407c2400,2410 < --- >
> >>Response > HTTP/1.1 201 Created > Location: http://www.ics.uci.edu/users/f/fielding/index.html > ]]> >
> >
> >
2409c2412 < MOVE of a Collection --- > >>Request 2411,2421c2414,2427 < >>Request < < MOVE /container/ HTTP/1.1 < Host: www.example.com < Destination: http://www.example.com/othercontainer/ < Overwrite: F < If: () < () < < < >>Response --- > MOVE /container/ HTTP/1.1 > Host: www.example.com > Destination: http://www.example.com/othercontainer/ > Overwrite: F > If: () > () > ]]> >
>
> >>Response > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx 2423,2433c2429,2435 < HTTP/1.1 207 Multi-Status < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < http://www.example.com/othercontainer/C2/ < HTTP/1.1 423 Locked < < --- > > > > http://www.example.com/othercontainer/C2/ > HTTP/1.1 423 Locked > > 2435c2437,2438 < --- >
> 2448,2449c2451 < < --- > 2568,2569c2570 < <
--- > 2571,2598c2572,2591 < < The table below describes the behavior that occurs when a lock < request is made on a resource. < < < < Current State Shared Lock Request Exclusive Lock Request < ---------------------------------------------------------------- < None True True < Shared Lock True False < Exclusive Lock False False* < < < < Legend: True = lock may be granted. False = lock MUST NOT be < granted. *=It is illegal for a principal to request the same lock < twice. < <
< < < < The current lock state of a resource is given in the leftmost < column, and lock requests are listed in the first row. The < intersection of a row and column gives the result of a lock request. < For example, if a shared lock is held on a resource, and an < exclusive lock is requested, the table entry is "false", indicating < the lock must not be granted. --- > The table below describes the behavior that occurs when a lock > request is made on a resource. > > Current lock state / Lock requestShared LockExclusive Lock > NoneTrueTrue > Shared LockTrueFalse > Exclusive LockFalseFalse* > > Legend: True = lock may be granted. False = lock MUST NOT be > granted. *=It is illegal for a principal to request the same lock > twice. > > > > The current lock state of a resource is given in the leftmost column, > and lock requests are listed in the first row. The intersection of a > row and column gives the result of a lock request. For example, if a > shared lock is held on a resource, and an exclusive lock is > requested, the table entry is "false", indicating the lock must not > be granted. 2634a2628 > >>Request 2636,2637d2629 < >>Request < 2656,2658c2648,2653 < < >>Response < --- > ]]> > > >
> >>Response > http://example.com/workspace/webdav/proposal.doc< < /D:href> --- > >http://example.com/workspace/webdav/proposal.doc 2710a2705 > >>Request 2712,2713d2706 < >>Request < 2722,2724c2715,2720 < < >>Response < --- > ]]> > >
>
> >>Response > < http://www.ics.uci.edu/~ejw/contact.html < --- > >http://www.ics.uci.edu/~ejw/contact.html 2743,2744c2738,2739 < urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4< < /D:href> --- > >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 2747,2749c2742 < http://example.com/workspace/webdav/proposal.doc< < /D:href> --- > /workspace/webdav/proposal.doc 2756c2749,2750 < --- >
> 2762,2763c2756 < < --- > 2767a2761,2785 > >>Request > LOCK /webdav/ HTTP/1.1 > Host: example.com > Timeout: Infinite, Second-4100000000 > Depth: infinity > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > Authorization: Digest username="ejw", > realm="ejw@example.com", nonce="...", > uri="/workspace/webdav/proposal.doc", > response="...", opaque="..." > > > > > > > http://www.ics.uci.edu/~ejw/contact.html > > > ]]> > >
> >>Response 2769c2787,2789 < >>Request --- > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx 2771,2813c2791,2805 < LOCK /webdav/ HTTP/1.1 < Host: example.com < Timeout: Infinite, Second-4100000000 < Depth: infinity < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < Authorization: Digest username="ejw", < realm="ejw@example.com", nonce="...", < uri="/workspace/webdav/proposal.doc", < response="...", opaque="..." < < < < < < < http://www.ics.uci.edu/~ejw/contact.html < < < < >>Response < < HTTP/1.1 207 Multi-Status < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < http://example.com/webdav/secret < HTTP/1.1 403 Forbidden < < < http://example.com/webdav/ < < < HTTP/1.1 424 Failed Dependency < < < < < ]]> < --- > > > > http://example.com/webdav/secret > HTTP/1.1 403 Forbidden > > > http://example.com/webdav/ > > > HTTP/1.1 424 Failed Dependency > > > > ]]> 2887a2880 > >>Request 2889,2890d2881 < >>Request < 2898,2900c2889,2893 < < >>Response < --- > ]]> >
>
> >>Response > >
3188d3180 < Example - Tagged List If header 3190,3197c3182,3189 < COPY /resource1 HTTP/1.1 < Host: www.example.com < Destination: http://www.example.com/resource2 < If: < ( < [W/"A weak ETag"]), (["strong ETag"]), < < (["another strong ETag"]) --- > COPY /resource1 HTTP/1.1 > Host: www.example.com > Destination: http://www.example.com/resource2 > If: > ( > [W/"A weak ETag"]), (["strong ETag"]), > > (["another strong ETag"]) 3215a3208 >
3268,3269c3261,3263 <
< Example - Matching lock tokens with collection locks --- > >
>
3271,3274c3265,3268 < DELETE /specs/rfc2518.txt HTTP/1.1 < Host: www.example.com < If: < () --- > DELETE /specs/rfc2518.txt HTTP/1.1 > Host: www.example.com > If: > () 3276c3270,3272 < For this example, the lock token must be compared to the --- >
> > For this example, the lock token must be compared to the 3285,3287c3281,3283 < in the If header could also succeed. <
< --- > in the If header could also succeed. > >
4419a4416 > >>Request 4420a4418,4421 > PROPFIND /container/ HTTP/1.1 > Host: www.example.com > Content-Length: xxxx > Content-Type: text/xml; charset="utf-8" 4422c4423,4434 < >>Request --- > > > > > ]]> > >
> >>Response > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx 4424,4466c4436,4462 < PROPFIND /container/ HTTP/1.1 < Host: www.example.com < Content-Length: xxxx < Content-Type: text/xml; charset="utf-8" < < < < < < < >>Response < < HTTP/1.1 207 Multi-Status < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < http://www.example.com/container/ < < < < < < < 0 < Jane Smith < Infinite < < urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 < < < http://www.example.com/container/ < < < < < HTTP/1.1 200 OK < < < --- > > > > http://www.example.com/container/ > > > > > > > 0 > Jane Smith > Infinite > > >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 > > > http://www.example.com/container/ > > > > > HTTP/1.1 200 OK > > > 4468c4464,4465 < --- >
> 4471,4473c4468 < < < --- > 4539a4535 > >>Request 4541c4537,4540 < >>Request --- > PROPFIND /container/ HTTP/1.1 > Host: www.example.com > Content-Length: xxxx > Content-Type: text/xml; charset="utf-8" 4543,4579c4542,4575 < PROPFIND /container/ HTTP/1.1 < Host: www.example.com < Content-Length: xxxx < Content-Type: text/xml; charset="utf-8" < < < < < < < >>Response < < HTTP/1.1 207 Multi-Status < Content-Type: text/xml; charset="utf-8" < Content-Length: xxxx < < < < < http://www.example.com/container/ < < < < < < < < < < < < < < HTTP/1.1 200 OK < < < --- > > > > > ]]> > >
> >>Response > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > > > > http://www.example.com/container/ > > > > > > > > > > > > > > HTTP/1.1 200 OK > > > 5390,5391c5386,5387 < xmlns:E="http://www.example.com/standards/props/"> < --- > xmlns:E="http://www.example.com/standards/props/"> > 5421d5416 < 5425,5426c5420,5421 < < *boss* --- > > *boss* --------------040305080801000400010008 Content-Type: text/xml; name="draft-ietf-webdav-rfc2518bis-latest.xml" Content-Disposition: inline; filename="draft-ietf-webdav-rfc2518bis-latest.xml" Content-Transfer-Encoding: 7bit ]> HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis Open Source Application Foundation
2064 Edgewood Dr. Palo Alto CA 94303 US lisa@osafoundation.org
Applications WebDAV webdav http authoring web WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes minor revisions mostly due to interoperability experience.
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for: Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Also, the ability to link pages of any media type to related pages. Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system). Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem", in which modifications are lost as first one author then another writes changes without merging the other author's changes. Namespace Operations: The ability to instruct the server to copy and move Web resources. Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" . This standard does not specify the versioning operations suggested by . That work was done in a separate document, "Versioning Extensions to WebDAV" . The sections below provide a detailed introduction to resource properties, collections of resources, and locking operations. These sections introduce the abstractions manipulated by the WebDAV-specific HTTP methods and the new HTTP headers used with WebDAV methods. While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines new status codes developed for WebDAV methods and describes existing HTTP status codes as used in WebDAV. Since some WebDAV methods may operate over many resources, the Multi-Status response has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces XML elements in error response bodies in . WebDAV uses to marshal complicated request and response information, as well as to express metadata, so this specification contains definitions of all XML elements used. WebDAV includes a few special rules on how to process XML appearing in WebDAV so that it truly is extensible. Finishing off the specification are sections on what it means for a resource to be compliant with this specification, on internationalization support, and on security.
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in section 2.1 of , including the rules about implied linear white-space. Since this augmented BNF uses the basic production rules provided in section 2.2 of , these rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Note that in natural language, a property like the "creationdate" property in the "DAV:" namespace is sometimes referred to as "DAV:creationdate" for brevity.
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in . Collection - A resource that contains a set of URLs, which identify and locate member resources and which meet the collections requirements. Member URL - A URL which is a member of the set of URLs contained by a collection. Internal Member URL - A Member URL that is immediately relative to the URL of the collection (the definition of immediately relative is given later). Property - A name/value pair that contains descriptive information about a resource. Live Property - A property whose semantics and syntax are enforced by the server. For example, the live "getcontentlength" property has its value, the length of the entity returned by a GET request, automatically calculated by the server. Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property. Principal - A "principal" is a distinct human or computational actor that initiates access to network resources.
Properties are pieces of data that describe the state of a resource. Properties are data about data. Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents. The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics. There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is read-only, maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus a mechanism is needed which allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support. In addition to encoding method parameters, XML is used in WebDAV to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input. The XML namespace extension is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group. Note that "DAV:" uses a scheme name defined solely for the purpose of creating this namespace. Defining new schemes for namespaces is discouraged. "DAV:" was defined before standard best practices emerged, and this namespace is still used only because of significant existing deployments.
The value of a property is always a (well-formed) XML fragment. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. A property is always represented in XML with an XML element consisting of the property name. The simplest example is an empty property, which is different from a property that does not exist. <R:title xmlns:R="http://www.example.com/ns/"></R:title> The value of a property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. When the property value contains further XML elements, namespaces that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. Namespace prefixes need not be preserved due to the rules of prefix declaration in XML. Attributes on the property name element may convey information about the property, but are not considered part of the value. However, when language information appears in the 'xml:lang' attribute on the property name element, the language information MUST be preserved in server storage for retransmission later. Note that a property only has one value, in one language (or language MAY be left undefined), not multiple values in different languages or a single value in multiple languages. The XML attribute xml:space MUST NOT be used to change white space handling. White space in property values is significant.
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property. Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition. The XML namespace mechanism, which is based on URIs (), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control. The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced which will address issues relating to hierarchical properties. Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
This section provides a description of a new type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace. All DAV compliant resources MUST support the HTTP URL namespace model specified herein.
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character. An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. The root, or top-level collection of the namespace under consideration is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/', it may be identified by one or more path segments (e.g. /servlets/webdav/...) Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies. Although implicit in and , any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
A collection is a resource whose state consists of at least a list of internal member URLs and a set of properties, but which may have additional state such as entity bodies returned by GET. An internal member URL MUST be immediately relative to a base URL of the collection. That is, the internal member URL is equal to a containing collection's URL plus an additional segment for non-collection resources, or additional segment plus trailing slash "/" for collection resources, where segment is defined in section 3.3 of . Any given internal member URL MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URL in a collection. Properties defined on collections behave exactly as do properties on non-collection resources. For all WebDAV compliant resources A and B, identified by URLs U and V, for which U is immediately relative to V, B MUST be a collection that has U as an internal member URL. So, if the resource with URL http://example.com/bar/blah is WebDAV compliant and if the resource with URL http://example.com/bar/ is WebDAV compliant then the resource with URL http://example.com/bar/ must be a collection and must contain URL http://example.com/bar/blah as an internal member. Collection resources MAY list the URLs of non-WebDAV compliant children in the HTTP URL namespace hierarchy as internal members but are not required to do so. For example, if the resource with URL http://example.com/bar/blah is not WebDAV compliant and the URL http://example.com/bar/ identifies a collection then URL http://example.com/bar/blah may or may not be an internal member of the collection with URL http://example.com/bar/. If a WebDAV compliant resource has no WebDAV compliant children in the HTTP URL namespace hierarchy then the WebDAV compliant resource is not required to be a collection. There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. In this case it SHOULD return a Content-Location header in the response, pointing to the URL ending with the "/". For example, if a client invokes a method on http://example.com/blah (no trailing slash), the server may respond as if the operation were invoked on http://example.com/blah/ (trailing slash), and should return a Content-Location header with the value http://example.com/blah/. Wherever a server produces a URL referring to a collection, the server MUST include the trailing slash. In general clients SHOULD use the "/" form of collection names. Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if a OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections.
The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem. This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.
The most basic form of lock is an exclusive lock. Only one exclusive lock may exist on any resource, whether it is directly or indirectly locked. Exclusive locks avoid having to merge results, without requiring any coordination other than the methods described in this specification. However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal with appropriate access can use the lock. With shared locks there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set. Starting with every possible principal on the Internet, in most situations the vast majority of these principals will not have write access to a given resource. Of the small number who do have write access, some principals may decide to guarantee their edits are free from overwrite conflicts by using exclusive write locks. Others may decide they trust their collaborators will not overwrite their work (the potential set of collaborators being the set of principals who have write permission) and use a shared lock, which informs their collaborators that a principal may be working on the resource. The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out of band communication channel to coordinate their work (e.g., face-to-face interaction, written notes, post-it notes on the screen, telephone conversation, Email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource. Shared locks are included because experience from web distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example when a program crashes, or when a lock owner leaves without unlocking a resource. While both timeouts and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
A WebDAV compliant resource is not required to support locking in any form. If the resource does support locking it may choose to support any combination of exclusive and shared locks for any access types. The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks while others only provide support for exclusive write locks while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
A lock token is a type of state token, represented as a URI, which identifies a particular lock. Each lock has exactly one unique lock token generated by the server. Clients MUST NOT attempt to interpret lock tokens in any way. Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in , and also in the body of the response. Submitting a lock token does not confer full privilege to use the lock token or modify the locked resource. Anyone can find out anyone else's lock token by performing lock discovery. Write access and other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the slight obscurity of lock token values. Since lock tokens are unique, a client MAY submit a lock token in an If header on a resource other than the one that returned it. This specification encourages servers to create UUIDs for lock tokens, and to use the URI form defined by "A Universally Unique Identifier (UUID) URN Namespace" (). However servers are free to use another valid URI so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in an appendix of this document. Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. A client can determine what lock types the server supports by retrieving the supportedlock property. Any DAV compliant resource that supports the LOCK method MUST support the supportedlock property.
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and where available, provides their lock token. Any DAV compliant resource that supports the LOCK method MUST support the lockdiscovery property.
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 section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification. An exclusive write lock will prevent parallel changes to a resource by any principal other than the write lock holder. In general terms, changes affected by write locks include changes to: the content of the resource any dead property of the resource any live property defined to be lockable (all properties defined in this specification are lockable) the direct membership of the resource, if it is a collection the URL/location of a resource The next few sections describe in more specific terms how write locks interact with various operations.
The creator of the lock is the lock owner. The server MUST restrict the usage of the lock token to the lock owner (both for shared and exclusive locks -- for multi-user shared lock cases, each authenticated principal MUST obtain its own shared lock). The server MAY allow privileged users other than the lock owner to destroy a lock (for example, the resource owner or an administrator) as a special case of lock usage. If an anonymous user requests a lock, the server MAY refuse the request.
A server MUST reject any write request that alters a write-locked resource unless a valid lock token is provided. The write operations defined in HTTP and WebDAV are PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL. All other HTTP/WebDAV methods, GET in particular, function independently of the lock. A shared write lock prevents the same operations, however it also allows access by any principal that has a shared write lock on the same resource. Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.
A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal.
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked.
Although the write locks provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario: Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking. Client A doesn't lock the document, but does a GET and begins editing. Client B does LOCK, performs a GET and begins editing. Client B finishes editing, performs a PUT, then an UNLOCK. Client A performs a PUT, overwriting and losing all of B's changes. There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK. WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources. WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking. HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources. Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.
It is possible to lock an unmapped URL in order to lock the name for use. This is a simple way to avoid the lost-update problem on the creation of a new resource (another way is to use If-None-Match header specified in HTTP 1.1). It has the side benefit of locking the new resource immediately for use of the creator. 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. When trying to lock a collection upon creation, clients may attempt to increase the likelihood of this by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation there's no guarantee this will work). A lock request to an unmapped URL SHOULD result in the creation of an locked resource with empty content. A subsequent PUT request with the correct lock token SHOULD normally succeed, and this new request provides the content, content-type, content-language and other information as appropriate. In this situation, a WebDAV server that was implemented from RFC2518 MAY create "lock-null" resources which are special and unusual resources. Historically, a lock-null resource: Responds with a 404 or 405 to any DAV method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. Appears as a member of its parent collection. Disappears (URI becomes unmapped) if its lock goes away before it is converted to a regular resource. (This must also happen if it is renamed or moved, or if any parent collection is renamed or moved, because locks are tied to URLs). May be turned into a regular resource when a PUT request to the URL is successful. Ceases to be a lock-null resource. May be turned into a collection when a MKCOL request to the URL is successful. Ceases to be a lock-null resource. Has defined values for lockdiscovery and supportedlock properties. However, interoperability and compliance problems have been found with lock-null resources. Therefore, they are deprecated. WebDAV servers SHOULD create regular locked empty resources, which are and behave in every way as normal resources. A locked empty resource: Can be read, deleted, moved, copied, and in all ways behave as a regular resource, not a lock-null resource. Appears as a member of its parent collection. SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation) SHOULD default to having no content type. MAY NOT have values for properties like getcontentlanguage which haven't been specified yet by the client. May have content added with a PUT request. MUST be able to change content type. MUST NOT be turned into a collection. A MKCOL request must fail as it would to any existing resource. MUST have defined values for lockdiscovery and supportedlock properties. The response MUST indicate that a resource was created, by use of the "201 Created" response code (a LOCK request to an existing resource instead will result in 200 OK). The body must still include the lockdiscovery property, as with a LOCK request to an existing resource. The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH. When the client uses PUT to overwrite a locked empty resource the client MUST supply a Content-Type if any is known. If the client supplies a Content-Type value the server MUST set that value (this requirement actually applies to any resource that is overwritten but is particularly necessary for locked empty resources which are initially created with no Content-Type. Clients can easily interoperate both with servers that support the deprecated lock-null resources and servers that support simpler locked empty resources by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET.
A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URLs of the collection by non-lock owners. A zero-depth lock on a collection affects changes to the direct membership of that collection. When a principal issues a write request to create a new resource in a write locked collection, or isses a DELETE, MOVE or other request that would remove an existing internal member URL of a write locked collection or change the binding name, this request MUST fail if the principal does not provide the correct lock token for the locked collection. This means that if a collection is locked (depth 0 or infinity), its lock-token is required in all these cases: DELETE a collection's direct internal member MOVE a member out of the collection MOVE a member into the collection, unless it overwrites a pre-existing member MOVE to rename it within a collection, COPY a member into a collection, unless it overwrites a pre-existing member PUT or MKCOL request which would create a new member. The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately. In addition, a depth-infinity lock affects all write operations to all descendents of the locked collection. With a depth-infinity lock, the root of the lock is directly locked, and all its descendants are indirectly locked. Any new resource added as a descendent of a depth-infinity locked collection becomes indirectly locked. Any indirectly locked resource moved out of the locked collection into an unlocked collection is thereafter unlocked. Any indirectly locked resource moved out of a locked source collection into a depth-infinity locked target collection remains indirectly locked but is now within the scope of the lock on the target collection (the target collection's lock token will thereafter be required to make further changes). If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'missing-lock-token' precondition. If a lock owner causes the URL of a resource to be added as an internal member URL of a depth-infinity locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock.
If a user agent is not required to have knowledge about a lock when requesting an operation on a locked resource, the following scenario might occur. Program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by Program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization. In order to prevent these collisions a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted in the if header, one for the source and the other for the destination.
>>Request COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html If: <http://www.ics.uci.edu/users/f/fielding/index.html> (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
>>Response HTTP/1.1 204 No Content
In this example, even though both the source and destination are locked, only one lock token must be submitted, for the lock on the destination. This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with "Depth: infinity", then the resource will be added to the lock. A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, the resource is subject to being added to an existing lock at the destination (see ). For example, if the MOVE makes the resource a child of a collection that is locked with "Depth: infinity", then the resource will be added to that collection's lock. Additionally, if a resource locked with "Depth: infinity" is moved to a destination that is within the scope of the same lock (e.g., within the namespace tree covered by the lock), the moved resource will again be a added to the lock. In both these examples, as specified in , an If header must be submitted containing a lock token for both the source and destination.
A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked. However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set. A server may return a Timeout header with a lock refresh that is different than the Timeout header returned when the lock was originally requested. Additionally clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client. Note that timeout is measured in seconds remaining until expiration. If an error is received in response to a refresh LOCK request the client MUST NOT assume that the lock was refreshed.
Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with and XML Namespaces. All XML used in either requests or responses MUST be, at minimum, well formed and use namespaces correctly. If a server receives non-wellformed XML in a request it MUST reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response then it MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as they intended.
HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible.
HTTP 1.1 recommends the use of the ETag header in responses to GET and PUT requests. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem. A client might fail to renew a lock, for example when the lock times out and the client is accidentally offline or in the middle of a long upload. When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user whether it has changed. Timestamps do not solve this problem nearly as well as ETags. WebDAV servers SHOULD support strong ETags for all resources that may be PUT. If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the 'getetag' property. Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or getlastmodified value) for a resource that has an unchanged body. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed.
HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of ). The mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This mechanism does not take the place of using a correct numeric error code as defined here or in HTTP, because the client MUST always be able to take a reasonable course of action based only on the numeric error. However, it does remove the need to define new numeric error codes, avoiding the confusion of who is allowed to define such new codes. The codes used in this mechanism are XML elements in a namespace, so naturally any group defining a new error code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups. A server supporting "bis" SHOULD include a specific XML error code in a "DAV:error" response body element, when a specific XML error code is defined in this document. The DAV:error element may contain multiple elements describing specific errors. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank.
]]>
In this specification, both the numeric and the XML error code are defined for some failure situations, in which case the XML error code must have the "DAV:" namespace, appear in the "error" root element, and be returned in a body with the numeric error code specified.
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs. All DAV compliant resources MUST support the PROPFIND method and the propfind XML element () along with all XML elements defined for use with that element. A client may submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND on a collection resource. Servers MUST support the "0", "1" and "infinity" behaviors on WebDAV-compliant resources. By default, the PROPFIND method without a Depth header MUST act as if a "Depth: infinity" header was included. A client may submit a propfind XML element in the body of the request method describing what information is being requested. It is possible to: Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by server) Request all dead property values, by using 'dead-props' element. This can be combined with retrieving specific live properties named as above. Servers advertising support for RFC2518bis MUST support this feature. Request property values for those properties defined in this specification plus dead properties, by using 'allprop' element Request a list of names of all the properties defined on the resource, by using the 'propname' element. A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request. Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see and ) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. A WebDAV server MAY omit certain live properties from other specifications when responding to an allprop request from an older client, and MAY return only custom (dead) properties and those defined in this specification. All servers MUST support returning a response of content type text/xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties. If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element which contains a 404 (Not Found) status value. Consequently, the multistatus XML element for a collection resource with member URLs MUST include a response XML element for each member URL of the collection, to whatever depth was requested. Each response XML element MUST contain an href XML element that gives the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URLs are returned as a flat list whose order of entries is not significant. Properties may be subject to access control. In the case of allprop and propname, if a principal does not have the right to know whether a particular property exists then the property MAY be silently excluded from the response. The results of this method SHOULD NOT be cached.
A server MAY fail an entire PROPFIND request with an appropriate status code and MAY redirect the entire request. In addition, the following error codes are specifically defined for PROPFIND requests: 403 Forbidden - A server MAY reject all PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the element 'propfind-infinite-depth-forbidden' inside the error body.
The following status codes are defined for use within the PROPFIND Multi-Status response: 200 OK - A property exists and/or its value is successfully returned. 401 Unauthorized - The property cannot be viewed without appropriate authorization. 403 Forbidden - The property cannot be viewed regardless of authentication. 404 Not Found - The property does not exist.
>>Request ]]>
>>Response http://www.example.com/file Box type A J.J. Johnson HTTP/1.1 200 OK HTTP/1.1 403 Forbidden The user does not have access to the DingALing property. There has been an access violation error. ]]>
In this example, PROPFIND is executed on a non-collection resource http://www.example.com/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
>>Request ]]>
In this example, PROPFIND is executed on a collection resource http://www.example.com/mycol/. The client requests the values of two specific live properties plus all dead properties (names and values). The response is not shown.
>>Request ]]>
>>Response http://www.example.com/container/ HTTP/1.1 200 OK http://www.example.com/container/front.html HTTP/1.1 200 OK ]]>
In this example, PROPFIND is invoked on the collection resource http://www.example.com/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its descendents should be returned. Consistent with the previous example, resource http://www.example.com/container/ has six properties defined on it: bigbox and author in the "http://www.example.com/boxschema/" namespace, and creationdate, displayname, resourcetype, and supportedlock in the "DAV:" namespace. The resource http://www.example.com/container/index.html, a member of the "container" collection, has nine properties defined on it, bigbox in the "http://www.example.com/boxschema/" namespace and, creationdate, displayname, getcontentlength, getcontenttype, getetag, getlastmodified, resourcetype, and supportedlock in the "DAV:" namespace. This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI. All DAV compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV compliant resources SHOULD support the setting of arbitrary dead properties. The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Instruction processing MUST occur in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus if any error occurs during processing all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in sections 13.23 and section 13.24.
The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. 200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate. 403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties. 403 (Forbidden): The client has attempted to set a read-only property, such as getetag. If returning this error, the server SHOULD use 'read-only-property' inside the response body. 409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. 423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it. This response SHOULD contain the 'missing-lock-token' precondition element. 424 (Failed Dependency) - The property change could not be made because of another property change that failed. 507 (Insufficient Storage) - The server did not have sufficient space to record the property.
>>Request Jim Whitehead Roy Fielding ]]>
>>Response http://www.example.com/bar.html HTTP/1.1 424 Failed Dependency HTTP/1.1 409 Conflict Copyright Owner can not be deleted or altered. ]]>
In this example, the client requests the server to set the value of the "Authors" property in the "http://www.w3.com/standards/z39.50/" namespace, and to remove the property "Copyright-Owner" in the "http://www.w3.com/standards/z39.50/" namespace. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
The MKCOL method is used to create a new collection. All WebDAV compliant resources MUST support the MKCOL method. MKCOL creates a new collection resource at the location specified by the Request-URI. If the resource identified by the Request-URI is non-null then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI a member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the request must fail. When MKCOL is invoked without a request body, the newly created collection SHOULD have no members. A MKCOL request message may contain a message body. The precise behavior of a MKCOL request when the body is present is undefined, but limited to creating collections, members of a collection, bodies of members and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand it MUST respond with a 415 (Unsupported Media Type) status code. If the server decides to reject the request based on the presence of an entity or the type of an entity, it should use the 415 (Unsupported Media Type) status code.
Responses from a MKCOL request MUST NOT be cached as MKCOL has non-idempotent semantics. 201 (Created) - The collection was created. 403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its namespace, or 2) the parent collection of the Request-URI exists but cannot accept members. 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL. 409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 415 (Unsupported Media Type) - The server does not support the request type of the body. 507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
This example creates a collection called /webdisc/xfiles/ on the server www.example.com.
>>Request
>>Response
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET when applied to a collection may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection. Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection.
Locks rooted on a resource MUST be destroyed in a successful DELETE of that resource.
When a client issues a DELETE request to a Request-URI mapping to a non-collection resource, if the operation is successful the server MUST remove that mapping. Thus, after a successful DELETE operation (and in the absence of other actions) a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found).
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity. DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted. If any resource identified by a member URL cannot be deleted then all of the member's ancestors MUST NOT be deleted, so as to maintain namespace consistency. Any headers included with DELETE MUST be applied in processing every resource to be deleted. When the DELETE method has completed processing it MUST result in a consistent namespace. If an error occurs deleting an internal resource (a resource other than the resource identified in the Request-URI) then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked. The server MAY return a 4xx status response, rather than a Multi-Status, if the request failed. 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
>>Request
>>Response http://www.example.com/container/resource3 HTTP/1.1 423 Locked ]]>
In this example the attempt to delete http://www.example.com/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.example.com/container/ also failed. Thus the client knows that the attempt to delete http://www.example.com/container/ must have also failed since the parent can not be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties. A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
As defined in , the "PUT method requests that the enclosed entity be stored under the supplied Request-URI." Since submission of an entity representing a collection would implicitly encode creation and deletion of resources, this specification intentionally does not define a transmission format for creating a collection using PUT. Instead, the MKCOL method is defined to create collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed).
The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource. The state of the resource to be copied is fixed at the point the server begins processing the COPY request. All WebDAV compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
When the source resource is not a collection the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
After a successful COPY invocation, all dead properties on the source resource MUST be duplicated on the destination resource, along with all properties as appropriate. Live properties described in this document SHOULD be duplicated as identically behaving live properties at the destination resource, but not necessarily with the same values. 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. A COPY operation creates a new resource, much like a PUT operation does. Live properties which are related to resource creation (such as creationdate) should have their values set accordingly.
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". Servers MUST support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources. A COPY of depth infinity instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy. Servers should of course avoid infinite recursion, and can do so by copying the source resource as it existed at the point where processing started. A COPY of "Depth: 0" only instructs that the collection and its properties but not resources identified by its internal member URLs, are to be copied. Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header. The Destination header only specifies the destination URI for the Request-URI. When applied to members of the collection identified by the Request-URI the value of Destination is to be modified to reflect the current location in the hierarchy. So, if the Request-URI is /a/ with Host header value http://example.com/ and the Destination is http://example.com/b/ then when http://example.com/a/c/d is processed it must use a Destination of http://example.com/b/c/d. When the COPY method has completed processing it MUST have created a consistent namespace at the destination (see for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite depth copy, the server SHOULD try to finish as much of the original copy operation as possible. If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status), and the URL of the resource causing the failure MUST appear with the specific error. The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail. (Extensions to WebDAV might not follow this rule to the letter but must consider backwards compatibility with clients that expect COPY to work this way.) Interoperability testing has shown that some clients expect a collection COPY to actually do a merge if a destination collection exists. That behavior is appropriate for file system folders but not necessarily for other data objects modelled as collections. Thus, implementors are urged to comply with the standard language above, and leave clients to perform a manual merge if that's the expected behavior when copying a collection over another collection.
201 (Created) - The source resource was successfully copied. The copy operation resulted in the creation of a new resource. 204 (No Content) - The source resource was successfully copied to a pre-existing destination resource. 207 (Multi-Status) - Multiple resources were to be affected by the COPY, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. E.g. if a destination resource was locked and could not be overwritten, then the destination resource URL appears with the 423 (Locked) status. 403 (Forbidden) - The operation is forbidden. Possibly this is because the source and destination resources are the same resource. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 412 (Precondition Failed) - A precondition failed, e.g. the Overwrite header is "F" and the state of the destination resource is non-null. 423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response SHOULD contain the 'missing-lock-token' precondition element. 502 (Bad Gateway) - This may occur when the destination is on another server, repository or namespace. Either the source namespace does not support copying to the destination namespace, or the destination namespace refuses to accept the resource. The client may wish to try GET/PUT and PROPFIND/PROPPATCH instead. 507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
This example shows resource http://www.ics.uci.edu/~fielding/index.html being copied to the location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No Content) status code indicates the existing resource at the destination was overwritten.
>>Request
>>Response
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination resource has a non-null state.
>>Request
>>Response
>>Request
>>Response http://www.example.com/othercontainer/R2/ HTTP/1.1 423 Locked ]]>
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example most of the resources, along with the collection, were copied successfully. However the collection R2 failed because the destination R2 is locked. Because there was an error copying R2, none of R2's members were copied. However no errors were listed for those members due to the error minimization rules.
The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs other than the Request-URI which identify the source resource, to point to the new destination resource. Consequently, the Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV compliant resources MUST support the MOVE method. However, support for the MOVE method does not guarantee the ability to move a resource to a particular destination. For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server. If a resource exists at the destination, the destination resource will be deleted as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
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 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. MOVE is frequently used by clients to rename a file without changing its parent collection, 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 after a MOVE. Dead properties must be moved along with the resource.
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the address specified in the Destination header, and all resources identified by its internal member URLs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy. The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity". Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header. The behavior of the Destination header is the same as given for COPY on collections. When the MOVE method has completed processing it MUST have created a consistent namespace at both the source and destination (see section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible. If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status), and the errored resource's URL MUST appear with the specific error. The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the move the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail.
201 (Created) - The source resource was successfully moved, and a new resource was created at the destination. 204 (No Content) - The source resource was successfully moved to a pre-existing destination resource. 207 (Multi-Status) - Multiple resources were to be affected by the MOVE, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. E.g. if a source resource was locked and could not be moved, then the source resource URL appears with the 423 (Locked) status. 403 (Forbidden) - The source and destination resources are the same. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. Or, the server was unable to preserve the behavior of the live properties and still move the resource to the destination (see 'live-properties-not-preserved' postcondition). 412 (Precondition Failed) - A condition failed, e.g. the Overwrite header is "F" and the state of the destination resource is non-null. 423 (Locked) - The source or the destination resource, or some resource within the source or destination collection, was locked. This response SHOULD contain the 'missing-lock-token' precondition element. 502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource. This could also occur when the destination is on another sub-section of the same server namespace.
This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the location http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination resource had been non-null. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
>>Request
>>Response
>>Request ) () ]]>
>>Response http://www.example.com/othercontainer/C2/ HTTP/1.1 423 Locked ]]>
In this example the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case the proper lock token was not submitted for the destination http://www.example.com/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error moving /container/C2/, none of /container/C2's members were moved. However no errors were listed for those members due to the error minimization rules. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested. Any resource which supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein. A LOCK method invocation to an unlocked resource creates a lock on the resource identified by the Request-URI, which becomes the root of the lock. Lock method requests to create a new lock MUST have a XML request body which contains an owner XML element and other information for this lock request. The server MUST preserve the information provided by the client in the owner field when the lock information is requested. The LOCK request MAY have a Timeout header. Clients MUST assume that locks may arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if extraordinary circumstances do not occur. For example, a sufficiently privileged user may remove a lock at any time or the system may crash in such a way that it loses the record of the lock's existence. When a new lock is created, the LOCK response: MUST contain a body with the value of the lockdiscovery property in a prop XML element. MUST include the Lock-Token response header with the token associated with the new lock.
A lock is refreshed by sending a LOCK request without a request body to the URL of a resource within the scope 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). It MAY contain a Timeout header, which a server MAY accept to change the duration remaining on the lock to the new value. A server MUST ignore the Depth header on a LOCK refresh. If the resource has other (shared) locks, those locks are unaffected by a lock refresh. Additionally, those locks do not prevent the named lock from being refreshed. Note that in RFC2518, clients were indicated through the example in the text to use the If header to specify what lock to refresh (rather than the Lock-Token header). Servers are encouraged to continue to support this as well as the Lock-Token header. Note that the Lock-Token header is not be returned in the response for a successful refresh LOCK request, but the LOCK response body MUST contain the new value for the lockdiscovery body.
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK method. All resources that support the LOCK method MUST support the Depth header. A Depth header of value 0 means to just lock the resource specified by the Request-URI. If the Depth header is set to infinity then the resource specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token which represents all the resources that have been locked. If an UNLOCK is successfully executed on this token, all associated resources are unlocked. If the lock cannot be granted to all resources, a 207 (Multi-Status) status code MUST be returned with a response entity body containing a multistatus XML element describing which resource(s) prevented the lock from being granted. Hence, partial success is not an option. Either the entire hierarchy is locked or no resources are locked. If no Depth header is submitted on a LOCK request then the request MUST act as if a "Depth:infinity" had been submitted.
A successful LOCK method MUST result in the creation of an empty resource which is locked (and which is not a collection), when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length and no Content-Type.
The table below describes the behavior that occurs when a lock request is made on a resource. Current lock state / Lock requestShared LockExclusive Lock NoneTrueTrue Shared LockTrueFalse Exclusive LockFalseFalse* Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice. The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating the lock must not be granted.
200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 423 (Locked) - The resource is locked already. For consistency's sake, this response SHOULD contain the 'missing-lock-token' precondition element. 400 (Bad Request), with 'request-uri-must-match-lock-token' precondition - The LOCK request was made with a Lock-Token header, indicating that the client wishes to refresh the given lock. However, the Request-URI did not fall within the scope of the lock identified by the token. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid. 424 (Failed Dependency) - This may appear inside a 207 response to a LOCK request, to indicate that a resource could not be locked because of a failure on another resource.
>>Request http://www.ics.uci.edu/~ejw/contact.html ]]>
>>Response Content-Type: text/xml; charset="utf-8" Content-Length: xxxx infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 http://example.com/workspace/webdav/proposal.doc ]]>
This example shows the successful creation of an exclusive write lock on resource http://example.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header. Note that the locktoken and lockroot href elements would not contain any whitespace. The line return appearing in this document is only for formatting.
>>Request Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." ]]>
>>Response infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 /workspace/webdav/proposal.doc ]]>
This request would refresh the lock, attempting to reset the timeout to the new value specified in the timeout header. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
>>Request http://www.ics.uci.edu/~ejw/contact.html ]]>
>>Response http://example.com/webdav/secret HTTP/1.1 403 Forbidden http://example.com/webdav/ HTTP/1.1 424 Failed Dependency ]]>
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock, in this case a web page URL. The error is a 403 (Forbidden) response on the resource http://example.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the lockdiscovery property for the Request-URI has been included as required. In this example the lockdiscovery property is empty which means that there are no outstanding locks on the resource. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock. 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. For a successful response to this method, the server MUST remove the lock from the resource identified by the Request-URI and from all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. A successful response to an UNLOCK method does not mean that the resource is necessarily unlocked. It means that the specific lock corresponding to the specified token no longer exists. Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method.
204 (No Content) - Normal success response (rather than 200 OK, since 200 OK would imply a response body, and an UNLOCK success response does not normally contain a body) 400 (Bad Request) - No lock token was provided (see 'missing-lock-token' precondition), or request was made to a Request-URI that was not within the scope of the lock (see 'requesturi-must-match-lock-token' precondition). 403 (Forbidden) - The currently authenticated principal does not have permission to remove the lock (the server SHOULD use the 'need-privileges' precondition element). 412 (Precondition Failed) - The resource was not locked.
>>Request Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." ]]>
>>Response
In this example, the lock identified by the lock token "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas.
DAV = "DAV" ":" #( compliance-code ) compliance-code = ( "1" | "2" | "bis" | extend ) extend = Coded-URL | token
This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources MUST return the DAV header on all OPTIONS responses. The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs to encourage uniqueness. A resource must show class 1 compliance if it shows class 2 or "bis" compliance. In general, support for one compliance class does not entail support for any other. Please refer to section 16 for more details on compliance classes defined in this specification. 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. 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.
Depth = "Depth" ":" ("0" | "1" | "infinity")
The Depth request header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity"). The Depth header is only supported if a method's definition explicitly provides for such support. The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition. Methods which support the Depth header may choose not to support all of the header's values and may define, on a case by case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity" and if a Depth header is not present will act as if a "Depth: infinity" header had been applied. Clients MUST NOT rely upon methods executing on members of their hierarchies in any particular order or on the execution being atomic unless the particular method explicitly provides such guarantees. Upon execution, a method with a Depth header will perform as much of its assigned task as possible and then return a response specifying what it was able to accomplish and what it failed to do. So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not. Any headers on a method that has a defined interaction with the Depth header MUST be applied to all resources in the scope of the method except where alternative behavior is explicitly defined. For example, an If-Match header will have its value applied against every resource in the method's scope and will cause the method to fail if the header fails to match. If a resource, source or destination, within the scope of the method with a Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header. The Depth header only specifies the behavior of the method with regards to internal children. If a resource does not have internal children then the Depth header MUST be ignored. Please note, however, that it is always an error to submit a value for the Depth header that is not allowed by the method's definition. Thus submitting a "Depth: 1" on a COPY, even if the resource does not have internal members, will result in a 400 (Bad Request). The method should fail not because the resource doesn't have internal members, but because of the illegal value in the header.
Destination = "Destination" ":" ( absolute-URI ) The Destination request header specifies the URI which identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters. Note that the absolute-URI production is defined in . If the Destination value is an absolute URI, it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request with a 502 (Bad Gateway) response. Servers MAY attempt to copy the resource to the remote server using PUT/PROPPATCH or another mechanism.
Force-Authentication = "Force-Authentication" ":" Method The Force-Authentication request header is used with the OPTIONS method to specify that the client wants to be challenged for authentication credentials to the resource identified by the Request-URI. If present on a request to a WebDAV-compliant resource, the server MUST respond with either 401 (Unauthorized) or 501 (Not Implemented) status code. The Method value is used for the client to indicate what method it intends to use first on the resource identified in the Request-URI.
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) No-tag-list = List Tagged-list = Resource 1*List Resource = Coded-URL List = #( "(" List | Clause ")" ) Clause = ["Not"] State-token | State-token State-token = Coded-URL | "[" entity-tag "]" Coded-URL = "<" absolute-URI ">"
The If request header is intended to have similar functionality to the If-Match header defined in section 14.24 of . However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. The <DAV:no-lock> state token is an example of a state token that will never match an actual valid lock token. The purpose of this is described in . The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). If one of the described state lists matches the state of the resource then the request may succeed. The server must parse the If header when it appears on any request, evaluate all the clauses, and if the conditional evaluates to false, fail the request. Note that the absolute-URI production is defined in . RFC2518 originally defined the If header without comma separators. This oversight meant that the If header couldn't be divided up among multiple lines according to the HTTP header manipulation rules. Servers supporting "bis" MUST be able to accept commas in If header values. If the header has commas between tokens or clauses, the header can be evaluated simply by removing the commas and proceeding with the evaluation rules.
The No-tag-list production describes a series of state tokens and ETags. If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue. All untagged tokens apply to the resource identified in the Request-URI.
Example - no-tag-list production ["I am an ETag"]), (["I am another ETag"]) ]]>
The previous header would require that the resource identified in the Request-URI be locked with the specified lock token and in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag". To put the matter more plainly one can think of the previous If header as being in the form (or (and <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> ["I am an ETag"]) (and ["I am another ETag"])).
The tagged-list production may be used instead of the no-tag-list production, in order to scope each token to a specific resource. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any. All clauses must be evaluated. If the state of the resource named in the tag does not match any of the associated state lists then the request MUST fail with a 412 (Precondition Failed). The tagged-list production MUST NOT be used together with the no-tag-list production, either in the same If header or in a continuation. The same URI MUST NOT appear more than once in a resource production in an If header.
( [W/"A weak ETag"]), (["strong ETag"]), (["another strong ETag"]) ]]>
In this example http://www.example.com/resource1 is being copied to http://www.example.com/resource2. When the method is first applied to http://www.example.com/resource1, resource1 must be in the state specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag". That is the only success condition since the resource http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.example.com/resource2 is not listed in the If header.
Every state token or ETag is either current, and hence describes the state of a resource, or is not current, and does not describe the state of a resource. The boolean operation of matching a state token or ETag to the current state of a resource thus resolves to a true or false value. The "Not" production is used to reverse that value. The scope of the not production is the state-token or entity-tag immediately following it.
) ]]>
When submitted with a request, this If header requires that all operand resources must not be locked with urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked with urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092. The Not production is particularly useful with the "<DAV:no-lock>" state token. The clause "Not <DAV:no-lock>" MUST evaluate to true. Thus, any "OR" statement containing the clause "Not <DAV:no-lock>" MUST also evaluate to true.
When performing If header processing, the definition of a matching state token or entity tag is as follows. Identifying a resource: The resource is identified by the URI along with the token, in tagged list production, or by the Request-URI in untagged list production. Matching entity tag: Where the entity tag matches an entity tag associated with the identified resource. Matching state token: Where there is an exact match between the state token in the If header and any state token on the identified resource. A lock state token is considered to match if the resource is anywhere in the scope of the lock.
() ]]>
For this example, the lock token must be compared to the identified resource, which is the 'specs' collection identified by the URL in the tagged list production. If the 'specs' collection is not locked or has a lock with a different token, the request MUST fail. If the 'specs' collection is locked (depth infinity) with that lock token, then this request could succeed, both because the If header evaluates to true, and because the lock token for the lock affecting the affected resource has been provided. Alternatively, a request where the 'rfc2518.txt' URL is associated with the lock token in the If header could also succeed.
Non-DAV aware proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: no-cache" request header MUST be used so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" request header MUST be used for the same reason.
Lock-Token = "Lock-Token" ":" Coded-URL The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member. The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
Overwrite = "Overwrite" ":" ("T" | "F") The Overwrite request header specifies whether the server should overwrite the state of a non-null destination resource during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the state of the destination resource is non-null. If the overwrite header is not included in a COPY or MOVE request then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of the If-Match: * header of HTTP/1.1, If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE. If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. All DAV compliant resources MUST support the Overwrite header.
TimeOut = "Timeout" ":" 1#TimeType TimeType = ("Second-" DAVTimeOutVal | "Infinite") DAVTimeOutVal = 1*digit
Clients may include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method. Timeout response values MUST use a Second value or Infinite. The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1. The timeout counter MUST be restarted if a refresh LOCK request is successful. The timeout counter SHOULD NOT be restarted at any other time. If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request. Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going off-line. A client MUST NOT assume that just because the time-out has expired the lock has been lost. Likewise, a client MUST NOT assume that just because the time-out has not expired, the lock still exists (and for this reason, clients are strongly advised to use ETags as well).
The following status codes are added to those defined in HTTP/1.1 .
The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed. Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.
The 207 (Multi-Status) status code provides status for multiple independent operations (see for more information).
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain the 'missing-lock-token' element and corresponding href in the error body.
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request which received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
These HTTP codes are not redefined, but this section serves as a reminder that these HTTP codes may be used in responses to WebDAV methods and clients must be appropriately prepared to handle them.
A server MAY use this status code in response to any request.
A server MAY use this status code in response to any request.
A server MAY use this status code in response to any request. Some possible reasons: the Host header is missing in any request The protocol version is HTTP/1.0 Any header is improperly formatted The request method line is improperly formatted
A server MAY use this status code in response to any request. An appropriate use example would be in response to a PUT request to a collection, if the server does not ever allow PUT to a collection.
A server MAY use this status code in response to any request. In base WebDAV, the 409 Conflict is most typically returned when a method that attempts to create a new resource must fail, because one of the collections that resource depends on does not exist. However, other types of conflicts are defined in specifications extending RFC2518.
Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or the "If" conditional header defined in this specification. If the request contains a conditional header, and if that condition fails to hold, then this error code MUST be returned unless some other error is returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this error.
This status code is used in HTTP 1.1 only for Request-URIs, because full URIs aren't used in other headers. WebDAV specifies full URLs in other headers, therefore this error may be used if the URI is too long in other locations as well. A server MAY use this status code in response to any request.
This status code is particularly useful to respond to requests that the server considers a denial-of-service attack, such as excessively large PROPFIND depth infinity requests or requests in quick succession. A server MAY use this status code in response to any request, provided that the request did not partially or completely succeed.
A Multi-Status response 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. The default 207 (Multi-Status) response body is a text/xml or application/xml HTTP entity that contains a single XML element called multistatus, which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a response XML element. The 207 status code itself MUST NOT be considered a success response, it is only completely successful if all response elements inside contain success status codes. The body of a 207 Multi-Status response MUST contain a URL associated with each specific status code, so that the client can tell whether the error occurred with the source resource, destination resource or some other resource in the scope of the request.
Use of the Location header with the Multi-Status response is intentionally undefined. Note that this specification does not define a way to redirect requests for individual resources within the scope of a Multi-Status response. The server MAY always redirect the entire request by responding with a 300 level status response instead of a Multi-Status response.
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. If the URLs are absolute, then the server MUST ensure that the URLs have the same prefix (scheme, host, port, and path) as the URL of the requested resource. If the URLs are relative, they MUST be resolved against the Request-URI. When a Multi-Status body is returned in response to MOVE or COPY, relative URI 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. Servers MUST NOT return "." or ".." within an absolute or relative URI returned within a Multi-Status response. URLs for collections appearing in the results SHOULD end in a '/' character. If a server allows resource names to include characters that aren't legal in HTTP URL paths, these characters must be URI-escaped on the wire. For example, it is illegal to use a space character or double-quote in a URI. URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in this specification) are still subject to all URI rules, including forbidden characters.
, , , and define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses.
In this section, the final line of each section gives the element type declaration using the format defined in . The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). The "Extensibility" field discusses how the element may be extended in the future (or in existing extensions to WebDAV. All of the elements defined here may be extended by the addition of attributes and child elements not defined in this specification.
activelock DAV: Describes a lock on a resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
depth DAV: The value of the Depth header. "0" | "1" | "infinity" MAY be extended with attributes which SHOULD be ignored.
]]>
locktoken DAV: The lock token associated with a lock. The href contains a single lock token URI which refers to the lock. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockroot DAV: Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request. The href contains a URL with the address of the root of the lock. The server SHOULD include this in all lockdiscovery property values and the response to LOCK requests. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
timeout DAV: The number of seconds remaining before a lock expires. TimeType (defined in ). MAY be extended with attributes which SHOULD be ignored.
]]>
collection DAV: Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST contain this element. It is normally empty but extensions may add sub-elements. MAY be extended with child elements or attributes which SHOULD be ignored if not recognized.
]]>
href DAV: 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. URI (See section 3.2.1 of ) MAY be extended with attributes which SHOULD be ignored.
<!ELEMENT href (#PCDATA)>
lockentry DAV: Defines the types of locks that can be used with the resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockinfo DAV: The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockscope DAV: Specifies whether a lock is an exclusive lock, or a shared lock. SHOULD NOT be extended with child elements. MAY be extended with attributes which SHOULD be ignored.
]]>
exclusive DAV: Specifies an exclusive lock Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
shared DAV: Specifies a shared lock Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
locktype DAV: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
write DAV: Specifies a write lock. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
multistatus DAV: Contains multiple response messages. The responsedescription at the top level is used to provide a general message describing the overarching nature of the response. If this value is available an application may use it instead of presenting the individual response descriptions contained within the responses. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
response DAV: Holds a single response describing the effect of a method on resource and/or its properties. A particular href MUST NOT appear more than once as the child of a response XML element under a multistatus XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by href. There are, however, no requirements regarding ordering based on href values. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
propstat DAV: Groups together a prop and status element that is associated with a particular href element. The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
status DAV: Holds a single HTTP status-line status-line (status-line defined in Section 6.1 of ) MAY be extended with attributes which SHOULD be ignored.
]]>
responsedescription DAV: Contains a message that can be displayed to the user explaining the nature of the response. This XML element provides information suitable to be presented to a user. MAY be extended with attributes which SHOULD be ignored.
]]>
owner DAV: Provides information about the principal taking out a lock. The owner XML element provides information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who owns a lock. This information is provided by the client, and may only be altered by the server if the owner value provided by the client is empty. MAY be extended with child elements, mixed content, text content or attributes. Structured content, for example one or more <href> child elements containing URLs, is RECOMMENDED.
]]>
prop DAV: Contains properties related to a resource. The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element MUST define properties related to the resource. No other elements may be used inside of a prop element. MAY be extended with attributes which SHOULD be ignored if not recognized. Any child element of this element must be considered to be a property name, however these are not restricted to the property names defined in this document or other standards.
]]>
propertyupdate DAV: Contains a request to alter the properties on a resource. This XML element is a container for the information required to modify the properties on the resource. This XML element is multi-valued. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
remove DAV: Lists the DAV properties to be removed from a resource. Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a prop XML element inside of a remove XML element MUST be empty, as only the names of properties to be removed are required. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
set DAV: Lists the DAV property values to be set for a resource. The set XML element MUST contain only a prop XML element. The elements contained by the prop XML element inside the set XML element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists then its value is replaced. Language tagging information appearing in the scope of the prop element (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
<!ELEMENT set (prop) >
propfind DAV: Specifies the properties to be returned from a PROPFIND method. Four special elements are specified for use with propfind: prop, dead-props, allprop and propname. If prop is used inside propfind it MUST NOT contain property values. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized, as long as it still contains one of the required elements.
]]>
allprop DAV: The allprop XML element specifies that all names and values of dead properties and the live properties defined by this document existing on the resource are to be returned. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
propname DAV: The propname XML element specifies that only a list of property names on the resource is to be returned. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
dead-props DAV: The dead-props XML element specifies that all dead properties, names and values, should be returned in the response. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
error DAV: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. When an error response contains a body in WebDAV, the body is in XML with the root element 'error'. The 'error' tag SHOULD include a standard error tag defined in this specification or another specification. The 'error' tag MAY include custom error tags (in custom namespaces) which a client can safely ignore. Contains any XML element Fully extensible with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
For DAV properties, the name of the property is also the same as the name of the XML element that contains its value. In the section below, the final line of each section gives the element type declaration using the format defined in . The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses or PROPPATCH requests. 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.
creationdate DAV: Records the time and date the resource was created. date-time (defined in , see the ABNF in section 5.6.) MAY be protected. Some servers allow creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use getetag instead). This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY. 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). MAY contain attributes which SHOULD be ignored if not recognized.
]]>
displayname DAV: Provides a name for the resource that is suitable for presentation to a user. Any text Possibly This property value SHOULD be preserved in local COPY and MOVE operations. It MAY be attempted to be set in a COPY operation to a remote server. The displayname property should be defined on all DAV compliant resources. If present, the property contains a description of the resource that is suitable for presentation to a user. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontentlanguage DAV: Contains the Content-Language header returned by a GET without accept headers language-tag (language-tag is defined in section 14.13 of ) SHOULD NOT be protected, so that clients can reset the language. This property value SHOULD be preserved in local COPY and MOVE operations. It SHOULD be attempted to be set in a COPY operation to a remote server. The getcontentlanguage property MUST be defined on any DAV compliant resource that returns the Content-Language header on a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontentlength DAV: Contains the Content-Length header returned by a GET without accept headers. content-length (see section 14.14 of ) SHOULD be protected so clients cannot set to misleading values The getcontentlength property MUST be defined on any DAV compliant resource that returns the Content-Length header in response to a GET. This property value is dependent on the size of the destination resource, not the value of the property on the source resource. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontenttype DAV: Contains the Content-Type header returned by a GET without accept headers. media-type (defined in section 3.7 of ) SHOULD NOT be protected, so clients may fix this value This property value SHOULD be preserved in local COPY and MOVE operations. In a remote COPY operation that is implemented through a PUT request, the PUT request must have the appropriate Content-Type header. This getcontenttype property MUST be defined on any DAV compliant resource that returns the Content-Type header in response to a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getetag DAV: Contains the ETag header returned by a GET without accept headers. entity-tag (defined in section 3.11 of ) MUST be protected because this value is created and controlled by the server. This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Refer to RFC2616 for a complete definition of the semantics of an ETag. Note that changes in properties or lock state MUST not cause a resource's ETag to change. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getlastmodified DAV: Contains the Last-Modified header returned by a GET method without accept headers. rfc1123-date (defined in section 3.3.1 of ) SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked. This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the 'getlastmodified' value, and this is preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Thus, clients cannot rely on this value for caching and SHOULD use ETags. Note that the last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body. The getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
lockdiscovery DAV: Describes the active locks on a resource MUST be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH. The value of this property depends on the lock state of the destination, not on the locks of the source resource. Recall that locks are not moved in a MOVE operation. The lockdiscovery property returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there is one or more lock, an 'activelock' element appears for each lock on the resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
>>Request ]]>
>>Response http://www.example.com/container/ 0 Jane Smith Infinite urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 http://www.example.com/container/ HTTP/1.1 200 OK ]]>
This resource has a single exclusive write lock on it, with an infinite timeout.
resourcetype DAV: Specifies the nature of the resource. SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH. Generally a COPY/MOVE of a resource results in the same type of resource at the destination. In a remote COPY, the source server SHOULD NOT attempt to set this property. The resourcetype property MUST be defined on all DAV compliant resources. The default value is empty. MAY be extended with any child elements or attributes which SHOULD be ignored if not recognized. If the element contains the 'collection' child element plus additional unrecognized elements/attributes, it should generally be treated as a collection. If the element contains no recognized child elements it should be treated as a non-collection WebDAV-compliant resource.
Example: (fictional example to show extensibility) ]]>
supportedlock DAV: To provide a listing of the lock capabilities supported by the resource. MUST be protected. Servers determine what lock mechanisms are supported, not clients. This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination. The supportedlock property of a resource returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to see. MAY be extended with any child elements or attributes which SHOULD be ignored if not recognized.
]]>
>>Request ]]>
>>Response http://www.example.com/container/ HTTP/1.1 200 OK ]]>
The numerical status codes used in HTTP responses are not sufficiently granular or informative for all purposes. Some extensions to HTTP have used the error response body along with some status codes in order to provide additiona machine-readable response detail. The machine-readable codes are XML elements classified as preconditions (generally client error or failure to meet the conditions in order for the request to be considered) and postconditions (generally server error or failure to respond successfully to an otherwise valid request). The precondition or postcondition XML element appears inside an 'error' element which is the root of the XML body of the response. The 'error' root element or the precondition or postcondition elements MAY contain additional XML elements or attributes not defined in this specification. XML elements in error response bodies were not used in RFC2518, but were introduced in RFC2518bis. Thus, use of these informative elements is RECOMMENDED. Even if clients do not automatically recognize the error bodies they can be quite useful in interoperability testing and debugging. external-entities-forbidden DAV: 403 Forbidden (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.
]]>
requesturi-must-match-lock-token DAV: 400 Bad Request (precondition) -- A request may include a Lock-Token header to identify a lock for the purposes of an operation such as refresh LOCK or UNLOCK. However, if the Request-URI doe not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
]]>
missing-lock-token DAV: 400 Bad Request (precondition) -- If the server rejects a request because the request MUST have a lock token and is missing the lock token header or header value (e.g. on an UNLOCK request), the server SHOULD use this error. The 'missing-lock-token' element MUST contain at least one URL of a locked resource for which a lock token was expected.
]]>
live-properties-not-preserved DAV: 409 Conflict (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server only supports some live properties in some parts of the repository, or simply has an internal error.
]]>
read-only-property DAV: 403 Forbidden (precondition) -- The client attempted to set a read-only property in a PROPPATCH (such as 'getetag').
]]>
propfind-infinite-depth-forbidden DAV: 403 Forbidden (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.
]]>
need-privileges DAV: 403 Forbidden (precondition) -- The currently authenticated user simply does not have the privileges required to do the requested operation (e.g. UNLOCK a lock created by someone else).
]]>
missing-lock-token DAV: 423 Locked (precondition) -- The request could not succeed because a lock token should have been provided. This element, if present, MUST contain the URL of a locked resource that prevented the request. In cases of MOVE, COPY and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only resonsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all.
]]>
All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language. This restriction also applies to the processing, by clients, of DAV property values where unknown XML elements SHOULD be ignored unless the property's schema declares otherwise. This restriction does not apply to setting dead DAV properties on the server where the server MUST record unknown XML elements. Additionally, this restriction does not apply to the use of XML where XML happens to be the content type of the entity body, for example, when used as the body of a PUT. Since XML can be transported as text/xml or application/xml, a DAV server MUST accept DAV method requests with XML parameters transported as either text/xml or application/xml, and a DAV client MUST accept XML responses using either text/xml or application/xml. XML DTD fragments are included for all the XML elements defined in this specification. However, legal XML may not be valid according to any DTD due to namespace usage and extension rules, so the DTD is only informational. A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.
A DAV compliant resource can advertise several classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource, and examining the "DAV" header which is returned. Note particularly that resources are spoken of as being compliant, rather than servers. That is because theoretically some resources on a server could support different feature sets. E.g. a server could have a sub-repository where an advanced feature like server was supported, even if that feature was not supported on all servers. Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies MUST be compliant with . A resource that is class 2 compliant must also be class 1 compliant, and a resource that is compliant with "bis" must also be class 1 compliant.
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document. Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the supportedlock property, the lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element. Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
A resource can explicitly advertise its support for the revisions to RFC2518 made in this document. In particular, this allows clients to use the Force-Authentication header on requests. Class 1 must be supported as well. Class 2 MAY be supported. A resource that supports bis MUST support: the Force-Authentication header. Any behavior that it supports, in the manner specified in this document, rather than in the manner specified in RFC2518, for all client requests. A server MAY use an older behavior for specific clients that are discovered to have interoperability problems with the requirements of this specification, but MUST NOT use an older behavior indiscriminately.
Example: DAV: 1, bis
In the realm of internationalization, this specification complies with the IETF Character Set Policy . In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 and UTF-16 encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in , as well as the XML declarations which provide charset identification information for MIME and XML processors. XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See for definitions of values and scoping. WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header. Names used within this specification fall into four categories: names of protocol elements such as methods and headers, names of XML elements, names of properties, and names of conditions. Naming of protocol elements follows the precedent of HTTP, using English names encoded in USASCII for methods and headers. Since these protocol elements are not visible to users, and are simply long token identifiers, they do not need to support multiple languages. Similarly, the names of XML elements used in this specification are not visible to the user and hence do not need to support multiple languages. WebDAV property names are qualified XML names (pairs of XML namespace name and local name). Although some applications (e.g., a generic property viewer) will display property names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name and namespace to a human-readable field when displaying the property name to a user. 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 to a user. We recommend that applications provide human-readable property names wherever feasible. For error reporting, we follow the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 (Locked)). While the possibility exists that a poorly crafted user agent would display this message to a user, internationalized applications will ignore this message, and display an appropriate message in the user's language and character set. Since interoperation of clients and servers does not require locale information, this specification does not specify any mechanism for transmission of this information.
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware. All of the security considerations of HTTP/1.1 (discussed in ) and XML (discussed in ) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication. A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send Basic authentication credentials in a WWW-Authenticate header unless the connection is secure. Examples of secure connections include a Transport Layer Security (TLS) connection employing a strong cipher suite with mutual authentication of client and server, or a connection over a network which is physically secure, for example, an isolated network in a building with restricted access. WebDAV applications MUST support the Digest authentication scheme . Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication which is useful in a wide range of scenarios.
Denial of service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial of service attacks on every part of a system's resources. The underlying storage can be attacked by PUTting extremely large files. Asking for recursive operations on large collections can attack processing time. Making multiple pipelined requests on multiple connections can attack network connections. WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.
WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.
When submitting a lock request a user agent may also submit an owner XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.
XML supports a facility known as "external entities", defined in section 4.2.2 of , which instruct an XML processor to retrieve and include additional XML. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non-validating XML, such as the XML used in this specification, including an external XML entity is not required by XML. However, XML does state that an XML processor may, at its discretion, include the external XML entity. External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case significantly modifying its semantics, or exposing the XML processor to the security risks discussed in . Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server implementor chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the precondition defined above (external-entities-forbidden). There is also the scalability risk that would accompany a widely deployed application which made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any server which fields requests for the resource containing the external XML entity.
This specification requires the use of "A Universally Unique Identifier (UUID) URN Namespace" () for lock tokens, in order to guarantee their uniqueness across space and time. The security considerations for UUIDs do not apply because WebDAV does not assume that lock tokens are supposed to be hard to guess or require integrity. In addition, UUIDs MAY contain a IEEE 802 node ID, usually the host address. Since a WebDAV server will issue many locks over its lifetime, the use of node IDs might cause the WebDAV server to reveal its IEEE 802 address. Several risks are related to this: It is possible to track the movement of hardware from subnet to subnet. It may be possible to identify the manufacturer of the hardware running a WebDAV server. It may be possible to determine the number of each type of computer running WebDAV.
HTTP has the ability to host scripts which are executed on client machines. These scripts can be used to read another user's cookies and therefore may provide an attacker the ability to use another user's session, assume their identity temporarily and gain access to their resources. Other attacks are also possible with client-executed scripts. WebDAV may worsen this situation only by making it easier for a Web server to host content provided by many different authors (making it harder to trust the content providers) and to host content with restricted access alongside public pages (see particularly RFC3744). HTTP servers may mitigate some of these threats by filtering content in areas where many authors contribute pages -- the server could, for example, remove script from HTML pages. This vulnerability should provide yet another reason for server implementors and administrators not to replace authentication mechanisms with cookie-based session tokens if there's any sensitive information relying on the authenticated identity. HTTP and WebDAV client implementors might consider locking down the use of scripts and cookies based on these considerations.
This specification defines two URI schemes: the "opaquelocktoken" scheme defined in , and the "DAV" URI scheme, which historically was used in RFC2518 to disambiguate WebDAV property and XML element names and which continues to be used for that purpose in this specification and others extending WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by the IETF. XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names or element names.
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work. Contributors to RFC2518 Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable, both in helping the formation of the working group and in patiently coaching the authors along the way. In so many ways he has set high standards we have toiled to meet. The contributions of Judith Slein in clarifying the requirements, and in patiently reviewing draft after draft, both improved this specification and expanded our minds on document management. We would also like to thank John Turner for developing the XML DTD. The authors of RFC2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter and D. Jensen. Although their names had to be removed due to IETF author count restrictions they can take credit for the majority of the design of WebDAV. Additional Contributors to This Specification Valuable contributions to RFC2518 bis came from some already named. New contributors must also be gratefully acknowledged. Julian Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out specific text on the list or in meetings. Ilya Kirnos supplied text for Force-Authentication header. Joe Hildebrand contributed as co-chair. Barry Lind described an additional security consideration. Jason Crawford tracked issue status for this document for a period of years, followed by Elias Sinderson.
Y. Y. Goland, Microsoft Corporation, One Microsoft Way, Redmond, WA 98052-6399. Email: yarong@microsoft.com. E. J. Whitehead, Jr., Dept. Of Information and Computer Science, University of California, Irvine, Irvine, CA 92697-3425. Email: ejw@ics.uci.edu. A. Faizi, Netscape, 685 East Middlefield Road, Mountain View, CA 94043. Email: asad@netscape.com. S. R. Carter, Novell, 1555 N. Technology Way, M/S ORM F111, Orem, UT 84097-2399. Email: srcarter@novell.com. D. Jensen, Novell, 1555 N. Technology Way, M/S ORM F111, Orem, UT 84097-2399. Email: dcjensen@novell.com.
&rfc2069; &rfc2119; &rfc2277; &rfc2279; &rfc2518; &rfc2616; &rfc3339; &rfc3986; &rfc4122; &w3cXMLNS; Extensible Markup Language (XML) 1.0 (Third Edition) Textuality and Netscape
tbray@textuality.com
Microsoft
jeanpa@microsoft.com
University of Illinois at Chicago and Text Encoding Initiative
cmsmcq@uic.edu
Sun Microsystems
eve.maler@east.sun.com
francois@yergeau.com
&rfc2291; &rfc2376; &rfc3253; &rfc3744;
XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.
XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of white space, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements. There is no kindness in accepting illegal combinations of XML elements. At best it will cause an unwanted result and at worst it can cause real damage.
The following request body for a PROPFIND method is illegal.
]]>
The definition of the propfind element only allows for the allprop or the propname element, not both. Thus the above is an error and must be responded to with a 400 (Bad Request). Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop. Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
]]>
To understand why a 400 (Bad Request) is returned let us look at the request body as the server unfamiliar with expired-props sees it.
]]>
As the server does not understand the expired-props element, according to the WebDAV-specific XML processing rules specified in , it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal. Please note that had the extension been additive it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
*boss* ]]>
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with leave-out, the only result would be that the leave-out element would be ignored and a propname would be executed.
The PUT and DELETE methods are defined in HTTP and thus may be used by HTTP clients, but the responses to PUT and DELETE have been extended in this specification, so some special consideration on backward compatibility is worthwhile. First, if a PUT or DELETE request includes a header defined in this specification (Depth or If), the server can assume the request comes from a WebDAV-compatible client. The server may even be able to track a number of requests across a session and know that a client is a WebDAV client. However, this kind of detection may not be necessary. Since any HTTP client ought to handle unrecognized 400-level and 500-level status codes as errors, the following new status codes should not present any issues: 422, 423 and 507. 424 is also a new status code but it appears only in the body of a Multistatus response. So, for example, if a HTTP client attempted to PUT or DELETE a locked resource, the 423 Locked response ought to result in a generic error presented to the user. The 102 Processing response code is new, and indicates that the client may wish to extend its normal timeout period. However, the choice to extend the timeout period is entirely optional, and thus a HTTP client receiving a 102 Processing status response may time out anyway, with no avoidable adverse effects. The 207 Multistatus response is interesting because a HTTP client issuing a DELETE request to a collection might interpret a 207 response as a success, even though it does not realize the resource is a collection and cannot understand that the DELETE operation might have been a complete or partial failure. Thus, a server MAY choose to treat a DELETE of a collection as an atomic operation, and use either 204 No Content in case of success, or some appropriate error response (400 or 500 level) depending on what the error was. This approach would maximize backward compatibility. However, since interoperability tests and working group discussions have not turned up any instances of HTTP clients issuing a DELETE request against a WebDAV collection, this concern may be more theoretical than practical. Thus, servers MAY instead choose to treat any such DELETE request as a WebDAV request, and send a 207 Multistatus containing more detail about what resources could not be deleted.
The 'opaquelocktoken' URI scheme was defined in RFC2518 (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time. This scheme has been obsoleted by , but is re-defined here for clarity. A server MAY generate one ore more UUIDs to use with the 'opaquelocktoken' scheme as lock tokens. A server MAY reuse a UUID with extension characters added. If the server does this then the algorithm generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID. OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID. Note that white space (LWS) is not allowed between elements of this production. Extension = path ; path is defined in section 3.3 of
This section describes changes that are likely to result in implementation changes due to tightened requirements or changed behavior. A more complete list of changes has been published in a separate document.
Tightened requirements for storing property values when "xml:lang" appears and also when values are XML fragments (specifically on preserving prefixes, namespaces and whitespace.) Several tightened requirements for general response handling, including response bodies for use with errors, use of Date header, ETag and Location header. Tightened requirements for URL construction in PROPFIND responses. Tightened requirements for checking identity of lock owners during operations affected by locks. Tightened requirements for copying properties and moving properties. Tightened requirements on preserving owner field in locks. Added "lockroot" element to lockdiscovery information. New value for "DAV:" header to advertise support for this specification. Tightened requirement for "Destination:" header to work with path values New "Force-Authentication:" header added. Several changes for "If:" header, including requirement to accept commas and "DAV:no-lock" state token. Support for UTF-16 now required (ref). Removed definition of "source" property and special handling for dynamic resources Replaced lock-null resources with simpler locked empty resources. Encouraged servers to change ETags only when body of resource changes.
Tightened requirements for supporting WebDAV collections within resources that do not support WebDAV (e.g. servlet containers). Redefined 'allprop' PROPFIND requests so that the server does not have to return all properties. Required to handle empty multistatus responses in PROPFIND responses No more "propertybehavior" specification allowed in MOVE and COPY requests Support for UTF-16 now required (ref). Removed definition of "source" property and special handling for dynamic resources.
Specified that a successful LOCK request to an unmapped URL creates a new, empty locked resource. Resolved UNLOCK_NEEDS_IF_HEADER by clarifying that only Lock-Token header is needed on UNLOCK. Added on preconditions and postconditions and defined a number of preconditions and postconditions. The 'missing-lock-token' precondition resolves the REPORT_OTHER_RESOURCE_LOCKED issue. Added example of matching lock token to URI in the case of a collection lock in the If header section. Removed ability for Destination header to take "abs_path" in order to keep consistent with other places where client provides URLs (If header, href element in request body) Clarified the href element - that it generally contains HTTP URIs but not always. Attempted to fix the BNF describing the If header to allow commas Clarified presence of Depth header on LOCK refresh requests.
Added text to "COPY and the Overwrite Header" section to resolve issue OVERWRITE_DELETE_ALL_TOO_STRONG. Added text to "HTTP URL Namespace Model" section to provide more clarification and examples on what consistency means and what is not required, to resolve issue CONSISTENCY. Resolve DEFINE_PRINCIPAL by importing definition of principal from RFC3744. Resolve INTEROP_DELETE_AND_MULTISTATUS by adding appendix 3 discussing backward-compatibility concerns. Resolve DATE_FORMAT_GETLASTMODIFIED by allowing only rfc1123-date, not HTTP-date for getlastmodified. Resolve COPY_INTO_YOURSELF_CLARIFY by adding sentence to first para. of COPY section. Confirm that WHEN_TO_MULTISTATUS_FOR_DELETE_1 and WHEN_TO_MULTISTATUS_FOR_DELETE_2 are resolved and tweak language in DELETE section slightly to be clearly consistent. More text clarifications to deal with several of the issues in LOCK_ISSUES. This may not completely resolve that set but we need feedback from the originator of the issues at this point. Resolved COPY_INTO_YOURSELF_CLARIFY with new sentence in Copy For Collections section. Double checked that LEVEL_OR_CLASS is resolved by using class, not level. Further work to resolve IF_AND_AUTH and LOCK_SEMANTICS, clarifying text on using locks and being authenticated. Added notes on use of 503 status response to resolve issue PROPFIND_INFINITY Removed section on other uses of Metadata (and associated references) Added reference to RFC4122 for lock tokens and removed section on generating UUIDs Explained that even with language variation, a property has only one value (section 4.5). Added section on lock owner (7.1) and what to do if lock requested by unauthenticated user Removed section 4.2 -- justification on why to have metadata, not needed now Removed paragraph in section 5.2 about collections with resource type "DAV:collection" but which are non-WebDAV compliant -- not implemented.
Added security considerations section on scripts and cookie sessions, suggested by Barry Lind Clarified which error codes are defined and undefined in MultiStatus Moved opaquelocktoken definition to an appendix and refer to RFC4122 for use of 'urn:uuid:' URI scheme; fix all lock token examples to use this. Multi-status responses contain URLs which MUST either be absolute (and begin with the Request-URI or MUST be relative with new limitations. (bug 12) Moved status code sections before example sections within PROPFIND section for section ordering consistency. Clarified use of Location header with Multi-Status Bugzilla issue resolutions: bugs 9, 12, 14, 19, 20, 29, 30, 34, 36, 102 and 172.
Bugzilla editorial issues: bugs 30, 57, 63, 68, 88, 89, 168, 180, 182, 185, 187.
--------------040305080801000400010008-- From w3c-dist-auth-request@frink.w3.org Tue Nov 22 13:53:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedGW-0007lG-D4 for webdav-archive@megatron.ietf.org; Tue, 22 Nov 2005 13:53:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25415 for ; Tue, 22 Nov 2005 13:52:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EedD9-0004f1-2Z for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Nov 2005 18:49:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EedD3-0004cm-56 for w3c-dist-auth@listhub.w3.org; Tue, 22 Nov 2005 18:49:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EedCx-0003F6-Hb for w3c-dist-auth@w3.org; Tue, 22 Nov 2005 18:49:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAMInXhn007016; Tue, 22 Nov 2005 10:49:33 -0800 Date: Tue, 22 Nov 2005 10:49:33 -0800 Message-Id: <200511221849.jAMInXhn007016@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EedCx-0003F6-Hb 0fdf8cef7f030e747414e064f203b3ef X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 195] LOCK_ISSUES_WRITE_LOCKS_AND_COPYMOVE X-Archived-At: http://www.w3.org/mid/200511221849.jAMInXhn007016@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10571 X-Loop: w3c-dist-auth@w3.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, 22 Nov 2005 18:49:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=195 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-22 10:49 ------- See also : "No change: LOCKs are lost then the locked resource is moved. Will also be clearer once GULP is incorporated." ------- 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@frink.w3.org Tue Nov 22 13:53:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedGW-0007lS-JM for webdav-archive@megatron.ietf.org; Tue, 22 Nov 2005 13:53:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25416 for ; Tue, 22 Nov 2005 13:52:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EedDz-0005HT-A3 for w3c-dist-auth-dist@listhub.w3.org; Tue, 22 Nov 2005 18:50:39 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EedDy-0005Gq-MC for w3c-dist-auth@listhub.w3.org; Tue, 22 Nov 2005 18:50:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EedDs-0007bA-M8 for w3c-dist-auth@w3.org; Tue, 22 Nov 2005 18:50:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAMIlKlN007003; Tue, 22 Nov 2005 10:47:20 -0800 Date: Tue, 22 Nov 2005 10:47:20 -0800 Message-Id: <200511221847.jAMIlKlN007003@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EedDs-0007bA-M8 9a068c40eb7fdb5422d778e528fb2687 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 192] LOCK_ISSUES_LOCK_URI_TYPE X-Archived-At: http://www.w3.org/mid/200511221847.jAMIlKlN007003@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10572 X-Loop: w3c-dist-auth@w3.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, 22 Nov 2005 18:50:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=192 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-22 10:47 ------- From : julian.reschke@greenbytes.de, 2004-04-24: Disagreement: any URI scheme can be used as a lock token. Specifications that define other types of state tokens will have to take care of distinguishing them inside an "If" header. Proposal: reject issue. ------- 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@frink.w3.org Wed Nov 23 12:05:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eey49-0000h8-GX for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:05:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27542 for ; Wed, 23 Nov 2005 12:05:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eey2N-000220-Hk for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 17:04:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eey2I-000211-7L for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 17:03:58 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1Eey2H-000606-Lu for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 17:03:57 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eey1m-0005px-NM for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 17:03:32 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2005 09:02:50 -0800 X-IronPort-AV: i="3.97,364,1125903600"; d="scan'208"; a="233636771:sNHT38025292096" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jANH2n6a018706; Wed, 23 Nov 2005 09:02:49 -0800 (PST) Received: from 128.107.139.141 ([128.107.139.141]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Nov 2005 17:03:30 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 23 Nov 2005 09:02:54 -0800 From: Cullen Jennings To: , WebDav Message-ID: Thread-Topic: [Bug 184] New: Section 19.8 added with no open issue nor WG consensus Thread-Index: AcXwT76O/Q168VxCEdqisgARJEEJ/A== In-Reply-To: <200511202041.jAKKfADM003372@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eey1m-0005px-NM 66682d9792e32730ec2edc46d2ecfd29 Received-SPF: softfail (lisa.w3.org: transitioning domain of fluffy@cisco.com does not designate 133.27.228.225 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 184] New: Section 19.8 added with no open issue nor WG consensus X-Archived-At: http://www.w3.org/mid/BFA9E0BE.61D92%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10573 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 17:04:03 +0000 Content-Transfer-Encoding: 7bit Do you think it is wrong? On 11/20/05 12:41 PM, "bugzilla@soe.ucsc.edu" wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=184 > > Summary: Section 19.8 added with no open issue nor WG consensus > Product: WebDAV-RFC2518-bis > Version: -08 > Platform: Other > URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- > rfc2518bis-08.html#rfc.section.19.8 > OS/Version: other > Status: NEW > Severity: normal > Priority: P2 > Component: 19. Security Considerations > AssignedTo: joe-bugzilla@cursive.net > ReportedBy: julian.reschke@greenbytes.de > QAContact: w3c-dist-auth@w3.org > > > I don't recall any WG consensus for adding the stuff in > tion.19.8> > . > > > > ------- 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@frink.w3.org Wed Nov 23 12:33:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyUf-0005bp-W4 for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:33:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01325 for ; Wed, 23 Nov 2005 12:32:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeyTz-0004oH-6b for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 17:32:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeyTu-0004mu-F7 for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 17:32:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeyTq-0002P8-8C for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 17:32:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANHW57n008060; Wed, 23 Nov 2005 09:32:05 -0800 Date: Wed, 23 Nov 2005 09:32:05 -0800 Message-Id: <200511231732.jANHW57n008060@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EeyTq-0002P8-8C 62ff1862fb7d53967cf651757f0e2dc4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200511231732.jANHW57n008060@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10574 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 17:32:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-23 09:32 ------- Discussed on Nov 23 2005: - keep the extension mechanism - clarify that Coded-URL is for vendor extensions, and tokens are for standard-track drafts ------- 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@frink.w3.org Wed Nov 23 12:54:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeyoo-0001v5-Ks for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:54:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03964 for ; Wed, 23 Nov 2005 12:53:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eeyo3-0003g1-Uh for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 17:53:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eeyny-0003eQ-Lx for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 17:53:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eeyjc-0003xo-NT for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 17:53:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANHmRpV008131; Wed, 23 Nov 2005 09:48:27 -0800 Date: Wed, 23 Nov 2005 09:48:27 -0800 Message-Id: <200511231748.jANHmRpV008131@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Eeyjc-0003xo-NT 451a2d2ff183da4974a2b56616a1639a 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/200511231748.jANHmRpV008131@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10575 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 17:53:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-23 09:48 ------- Teleconference consensus is to add language stating that a server receiving wht it considers to be a denial of service attack MAY return a 400 status code, or MAY drop the connection, at its discretion. The benefit of returning the status code is that it makes it possible for client implementors to have some insight into why a request was rejected (more so than if the connection was just dropped). However, the specification does not want to establish a strong policy here, because server implementations need flexibility in setting their own DoS handling policies. ------- 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@frink.w3.org Wed Nov 23 12:57:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeysD-0002eO-Uy for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:57:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04197 for ; Wed, 23 Nov 2005 12:56:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eeyrc-0007IV-HW for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 17:57:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EeylP-0003G2-2n for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 17:50:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EeyXs-0004Bf-TD for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 17:37:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANHa7YP008100; Wed, 23 Nov 2005 09:36:07 -0800 Date: Wed, 23 Nov 2005 09:36:07 -0800 Message-Id: <200511231736.jANHa7YP008100@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EeyXs-0004Bf-TD c81a1b4df8365b176a1eaf0e1c9c5122 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 39] Syntax of property names in text content X-Archived-At: http://www.w3.org/mid/200511231736.jANHa7YP008100@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10576 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 17:57:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=39 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-23 09:36 ------- Consensus from the teleconference is to consistently use DAV:foo. Lisa will double-check that it doesn't make the text in the draft unduly awkward, and will report back on instances where this is the case (if this is indeed the case). ------- 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@frink.w3.org Wed Nov 23 13:06:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eez19-0005qr-3o for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:06:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05274 for ; Wed, 23 Nov 2005 13:06:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eez09-00059Z-Ko for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:05:49 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eez09-000590-3m for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:05:49 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eez01-00014K-Fq for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:05:49 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2005 10:05:08 -0800 X-IronPort-AV: i="3.97,365,1125903600"; d="scan'208"; a="233658185:sNHT463771468" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jANI57Op027067 for ; Wed, 23 Nov 2005 10:05:08 -0800 (PST) Received: from 128.107.139.141 ([128.107.139.141]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Nov 2005 18:05:48 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 23 Nov 2005 10:05:12 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Question on bug 15 Thread-Index: AcXwWHKTsT6DpVxLEdqisgARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: maggie.w3.org 1Eez01-00014K-Fq 751b6f5313784836a889dc78e84c4954 X-Original-To: w3c-dist-auth@w3.org Subject: Question on bug 15 X-Archived-At: http://www.w3.org/mid/BFA9EF58.61DC5%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10577 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:05:49 +0000 Content-Transfer-Encoding: 7bit I am going to call consensus on this one in a week so give me your input before then.... The basic issue is that the names are sort of reverse what people think because they are based on post conditions. ACL (and others) already exists and do it the reverse way. The question is we should we define future stuff in the "forward" way... Proposal 1: Stay consistent with ACL - put in note for implementers that points out this is reverse of what they might expect. Proposal 2: Switch the way we do it. Leave old document reverse and make new documents forward. Pros/Cons - It is a questions of it having both reverse and forward will be more or less confusing to implementers that just having it all reverse. From w3c-dist-auth-request@frink.w3.org Wed Nov 23 13:11:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eez5A-0007eL-6p for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:11:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05978 for ; Wed, 23 Nov 2005 13:10:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eez4W-0006mw-Rh for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:10:20 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eez4W-0006lp-8Q for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:10:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eez4L-0001qv-It for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:10:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANIA1Mi008194; Wed, 23 Nov 2005 10:10:01 -0800 Date: Wed, 23 Nov 2005 10:10:01 -0800 Message-Id: <200511231810.jANIA1Mi008194@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eez4L-0001qv-It ff429acddd6643052094301415ce8df9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200511231810.jANIA1Mi008194@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10578 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:10:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-23 10:10 ------- Teleconference consensus is to add the paragraph back into the introduction. It does appear to be missing from the -08 specification. ------- 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@frink.w3.org Wed Nov 23 13:11:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eez5i-0007td-R7 for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:11:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06091 for ; Wed, 23 Nov 2005 13:10:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eez5A-00070m-07 for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:11:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eez59-0006zO-EX for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:10:59 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by maggie.w3.org with esmtp (Exim 4.50) id 1Eez52-0002sC-G9 for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:10:59 +0000 Received: from [192.168.1.3] (H342c.h.pppool.de [85.72.52.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 26FBD33D24; Wed, 23 Nov 2005 19:12:02 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDav From: Stefan Eissing Date: Wed, 23 Nov 2005 19:10:28 +0100 To: Cullen Jennings X-Mailer: Apple Mail (2.623) Received-SPF: none (maggie.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Eez52-0002sC-G9 242034d02d15403af4dd6dbf98b197a3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on bug 15 X-Archived-At: http://www.w3.org/mid/e3fc24a3cee676f538e01c78c1ef31b0@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10579 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:11:00 +0000 Content-Transfer-Encoding: 7bit Am 23.11.2005 um 19:05 schrieb Cullen Jennings: > > > I am going to call consensus on this one in a week so give me your > input > before then.... > > The basic issue is that the names are sort of reverse what people think > because they are based on post conditions. ACL (and others) already > exists > and do it the reverse way. The question is we should we define future > stuff > in the "forward" way... > > Proposal 1: Stay consistent with ACL - put in note for implementers > that > points out this is reverse of what they might expect. +1. > Proposal 2: Switch the way we do it. Leave old document reverse and > make new > documents forward. -1. From w3c-dist-auth-request@frink.w3.org Wed Nov 23 13:13:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eez77-00006z-8B for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:13:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06206 for ; Wed, 23 Nov 2005 13:12:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eez6R-0007Q9-SC for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:12:19 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eez6R-0007P4-8C for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:12:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eez6G-0002x0-11 for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:12:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANIC7Zf008219; Wed, 23 Nov 2005 10:12:07 -0800 Date: Wed, 23 Nov 2005 10:12:07 -0800 Message-Id: <200511231812.jANIC7Zf008219@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eez6G-0002x0-11 1c766f3bd20234471dfecf1d576a4d10 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200511231812.jANIC7Zf008219@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10580 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:12:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-23 10:12 ------- Teleconference consensus changed. Add in forward reference to Section 14 and Section 15. ------- 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@frink.w3.org Wed Nov 23 13:14:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eez8F-0000VU-Ls for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:14:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06297 for ; Wed, 23 Nov 2005 13:13:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eez7c-0007bE-9T for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:13:32 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eez7b-0007ag-L1 for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:13:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eez7Y-0003jO-Hy for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:13:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANIDRRd008255; Wed, 23 Nov 2005 10:13:27 -0800 Date: Wed, 23 Nov 2005 10:13:27 -0800 Message-Id: <200511231813.jANIDRRd008255@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eez7Y-0003jO-Hy e5cd668426a72869cc9a1cd1c00e2e4a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 43] "ill-formed" XML X-Archived-At: http://www.w3.org/mid/200511231813.jANIDRRd008255@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10581 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:13:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=43 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-23 10:13 ------- Teleconference consensus is to use "not wellformed". ------- 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@frink.w3.org Wed Nov 23 13:33:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezRL-0005W8-N4 for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:33:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08479 for ; Wed, 23 Nov 2005 13:33:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EezQX-0007Ui-Sn for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:33:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EezQV-0007U5-5s for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:33:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EezQQ-0005eX-9m for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:33:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANIWdR4008303; Wed, 23 Nov 2005 10:32:39 -0800 Date: Wed, 23 Nov 2005 10:32:39 -0800 Message-Id: <200511231832.jANIWdR4008303@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EezQQ-0005eX-9m 486a52e032a6fd93e04312874d1e1a9f 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/200511231832.jANIWdR4008303@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10582 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:33:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From fluffy@cisco.com 2005-11-23 10:32 ------- Go with text based on idea > 1) On the property element itself: [possible namespace name], [local name], > [children] of type element or character, plus [attributes] named > "xml:lang" present on the element itself or it's closest ancestor > > 2) On all children of the property element: [possible namespace name], [local > name], [attributes] and [children] of type element or character. add text that points out clients can not count on preservation o comments, processing instruction On the topic of namespace, we not going to require that you preserver them today (because many servers done) but say that future version of spec probably will require this and server SHOULD do it. Clients SHOULD NOT assume that servers do it. ------- 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@frink.w3.org Wed Nov 23 13:34:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezRY-0005jX-W6 for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:34:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08537 for ; Wed, 23 Nov 2005 13:33:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EezQz-0007bH-Pe for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:33:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EezQz-0007aj-CH for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:33:33 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1EezQz-0005xO-1M for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:33:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EezQf-00067i-VV for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:33:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANIXBLl008319; Wed, 23 Nov 2005 10:33:11 -0800 Date: Wed, 23 Nov 2005 10:33:11 -0800 Message-Id: <200511231833.jANIXBLl008319@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EezQf-00067i-VV d164278de635c2f712efc65adc577d73 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/200511231833.jANIXBLl008319@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10583 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:33:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 fluffy@cisco.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Wed Nov 23 13:34:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezS8-00066W-Qi for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:34:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08637 for ; Wed, 23 Nov 2005 13:34:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EezRY-0007iZ-77 for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:34:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EezRX-0007hd-MI for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:34:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EezRQ-0003aR-FT for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:34:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANIXIOO008339; Wed, 23 Nov 2005 10:33:18 -0800 Date: Wed, 23 Nov 2005 10:33:18 -0800 Message-Id: <200511231833.jANIXIOO008339@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EezRQ-0003aR-FT 372cbdd052f0f875adebc940b05a2927 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511231833.jANIXIOO008339@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10584 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:34:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 fluffy@cisco.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW ------- 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@frink.w3.org Wed Nov 23 13:52:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeziy-0000b2-RW for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:52:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10714 for ; Wed, 23 Nov 2005 13:51:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EeziG-0004y9-DV for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:51:24 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EeziD-0004xU-FR for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:51:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eezi3-0007I3-Ol for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:51:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANIpBsu008405; Wed, 23 Nov 2005 10:51:11 -0800 Date: Wed, 23 Nov 2005 10:51:11 -0800 Message-Id: <200511231851.jANIpBsu008405@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eezi3-0007I3-Ol bd1d43ac0d42282c316a168c2d6323b5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 45] DAV request header X-Archived-At: http://www.w3.org/mid/200511231851.jANIpBsu008405@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10585 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:51:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=45 ------- Additional Comments From fluffy@cisco.com 2005-11-23 10:51 ------- Bug 45 - Cache-ability is effected by what we choose here. Go with.... The client SHOULD not send it unless an standards track specification requires it. Any specification that requires it need to carefully consider the cache ability issue if what it is suggesting. ------- 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@frink.w3.org Wed Nov 23 13:53:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eezjq-00019U-LY for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 13:53:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10873 for ; Wed, 23 Nov 2005 13:52:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EezjI-00056J-Li for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 18:52:28 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EezjI-00055i-2G for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 18:52:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eezj9-0007pD-5Q for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 18:52:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANIqHOl008437; Wed, 23 Nov 2005 10:52:17 -0800 Date: Wed, 23 Nov 2005 10:52:17 -0800 Message-Id: <200511231852.jANIqHOl008437@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eezj9-0007pD-5Q ccbd3b143d0b16cfd4981a6dfb854650 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 45] DAV request header X-Archived-At: http://www.w3.org/mid/200511231852.jANIqHOl008437@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10586 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 18:52:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=45 fluffy@cisco.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- 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@frink.w3.org Wed Nov 23 14:05:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezvW-000567-Hw for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 14:05:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11895 for ; Wed, 23 Nov 2005 14:04:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eezum-0008WO-29 for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 19:04:20 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eezul-0008Vq-H1 for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 19:04:19 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1Eezuj-0008Rm-EF for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 19:04:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eezu3-0005Rq-RJ for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 19:03:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANJ3UiI008478; Wed, 23 Nov 2005 11:03:30 -0800 Date: Wed, 23 Nov 2005 11:03:30 -0800 Message-Id: <200511231903.jANJ3UiI008478@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Eezuj-0008Rm-EF ee745805a827ea1ae6b548f23a272b61 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200511231903.jANJ3UiI008478@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10587 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 19:04:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 ------- Additional Comments From fluffy@cisco.com 2005-11-23 11:03 ------- Bug 46 - First sentence or two of 12.2 is unclear. Main point is implementer knows what get a relative URL, and the answer is that it relative to request URL. Perhaps ref the the draft on URI handling. Need to loose the term "single scope". If destination header in the request, then MAY be better to use absolute instead of any relative. Julian to propose text. ------- 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@frink.w3.org Wed Nov 23 14:08:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezyT-0006mV-US for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 14:08:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12217 for ; Wed, 23 Nov 2005 14:07:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EezxZ-0000wD-UX for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 19:07:13 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EezxZ-0000vX-Dw for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 19:07:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EezxW-0001Gz-C6 for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 19:07:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANJ6dKo008504; Wed, 23 Nov 2005 11:06:39 -0800 Date: Wed, 23 Nov 2005 11:06:39 -0800 Message-Id: <200511231906.jANJ6dKo008504@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EezxW-0001Gz-C6 a76c0621b7442fcf0bab2917c29cd894 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200511231906.jANJ6dKo008504@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10588 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 19:07:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- 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@frink.w3.org Wed Nov 23 14:08:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eezyn-00076h-HK for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 14:08:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12271 for ; Wed, 23 Nov 2005 14:07:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EezyF-000148-Fg for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 19:07:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EezyE-00013a-Uy for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 19:07:55 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1EezyE-0001YI-Qh for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 19:07:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eezxf-0007Hp-2m for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 19:07:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jANJ7IRB008519; Wed, 23 Nov 2005 11:07:18 -0800 Date: Wed, 23 Nov 2005 11:07:18 -0800 Message-Id: <200511231907.jANJ7IRB008519@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eezxf-0007Hp-2m e7ef238ae0ff2e83145da6b46dbe8017 Received-SPF: none (maggie.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] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200511231907.jANJ7IRB008519@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10589 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 19:07:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Wed Nov 23 15:11:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef0y1-0000Gg-4d for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 15:11:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22443 for ; Wed, 23 Nov 2005 15:11:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef0wy-00012D-6l for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 20:10:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ef0wr-00010g-RW for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 20:10:34 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ef0wo-0003HT-MH for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 20:10:33 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jANKAPTm023138 for ; Wed, 23 Nov 2005 15:10:25 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jANKAP2T114540 for ; Wed, 23 Nov 2005 15:10:25 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jANKAPfg008466 for ; Wed, 23 Nov 2005 15:10:25 -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 jANKAPue008463 for ; Wed, 23 Nov 2005 15:10:25 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 23 Nov 2005 15:10:58 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/23/2005 15:10:24, Serialize complete at 11/23/2005 15:10:24 Content-Type: multipart/alternative; boundary="=_alternative 006ED243852570C2_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ef0wo-0003HT-MH 31c0917a917059c6892d63df57d7f922 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on bug 15 X-Archived-At: http://www.w3.org/mid/OF2E2681D9.2F507B00-ON852570C2.006EB9F4-852570C2.006ED27F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10590 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 20:10:40 +0000 This is a multipart message in MIME format. --=_alternative 006ED243852570C2_= Content-Type: text/plain; charset="US-ASCII" I agree with Stefan that we should stay consistent (i.e. +1 for Proposal 1). Cheers, Geoff Stefan wrote on 11/23/2005 01:10:28 PM: > > Am 23.11.2005 um 19:05 schrieb Cullen Jennings: > > > > > > > I am going to call consensus on this one in a week so give me your > > input > > before then.... > > > > The basic issue is that the names are sort of reverse what people think > > because they are based on post conditions. ACL (and others) already > > exists > > and do it the reverse way. The question is we should we define future > > stuff > > in the "forward" way... > > > > Proposal 1: Stay consistent with ACL - put in note for implementers > > that > > points out this is reverse of what they might expect. > > +1. > > > Proposal 2: Switch the way we do it. Leave old document reverse and > > make new > > documents forward. > > -1. > > --=_alternative 006ED243852570C2_= Content-Type: text/html; charset="US-ASCII"
I agree with Stefan that we should stay consistent (i.e. +1
for Proposal 1).

Cheers,
Geoff


Stefan wrote on 11/23/2005 01:10:28 PM:
>
> Am 23.11.2005 um 19:05 schrieb Cullen Jennings:
>
> >
> >
> > I am going to call consensus on this one in a week so give me your
> > input
> > before then....
> >
> > The basic issue is that the names are sort of reverse what people think
> > because they are based on post conditions. ACL (and others) already
> > exists
> > and do it the reverse way. The question is we should we define future
> > stuff
> > in the "forward" way...
> >
> > Proposal 1: Stay consistent with ACL - put in note for implementers
> > that
> > points out this is reverse of what they might expect.
>
> +1.
>
> > Proposal 2: Switch the way we do it. Leave old document reverse and
> > make new
> > documents forward.
>
> -1.
>
>
--=_alternative 006ED243852570C2_=-- From w3c-dist-auth-request@frink.w3.org Wed Nov 23 15:25:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef1Az-0008Fe-2t for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 15:25:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24054 for ; Wed, 23 Nov 2005 15:24:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef1AK-00069c-VP for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 20:24:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ef1AK-000694-EQ for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 20:24:28 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ef1AI-00014q-5X for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 20:24:28 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C7CE21422BB; Wed, 23 Nov 2005 12:24:01 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18505-08; Wed, 23 Nov 2005 12:24:01 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2B3E01422B6; Wed, 23 Nov 2005 12:24:01 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDav From: Lisa Dusseault Date: Wed, 23 Nov 2005 12:23:58 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ef1AI-00014q-5X ecd82a8363db96c3240aae09ddb5a2e9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on bug 15 X-Archived-At: http://www.w3.org/mid/e739e4a8a1b5138d91ef8fc5b07fd026@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10591 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 20:24:28 +0000 Content-Transfer-Encoding: 7bit I've heard so many people (at interops, at meetings, readers of my book) complain about the confusion of the "success condition" wording that I'd love to do something about that if we can. Unfortunately it seems we designed something which made sense only to people involved in the design. First time readers are particularly confused and I think it takes a while for them to get it (if ever). Is there anything we can do about that? Will any of those people who spoke to me, or others, about the confusion of this design, speak up now if you're following the list? Lisa On Nov 23, 2005, at 10:05 AM, Cullen Jennings wrote: > > > I am going to call consensus on this one in a week so give me your > input > before then.... > > The basic issue is that the names are sort of reverse what people think > because they are based on post conditions. ACL (and others) already > exists > and do it the reverse way. The question is we should we define future > stuff > in the "forward" way... > > Proposal 1: Stay consistent with ACL - put in note for implementers > that > points out this is reverse of what they might expect. > > Proposal 2: Switch the way we do it. Leave old document reverse and > make new > documents forward. > > > Pros/Cons - It is a questions of it having both reverse and forward > will be > more or less confusing to implementers that just having it all reverse. > > > From w3c-dist-auth-request@frink.w3.org Wed Nov 23 16:25:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef26s-000847-OA for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 16:25:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01462 for ; Wed, 23 Nov 2005 16:24:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef25b-0000iA-7k for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 21:23:39 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ef25V-0000h6-V0 for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 21:23:34 +0000 Received: from agminet01.oracle.com ([141.146.126.228]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ef25Q-00077B-Jh for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 21:23:32 +0000 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jANLbRpX004287 for ; Wed, 23 Nov 2005 15:37:28 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jANLNM2U007988 for ; Wed, 23 Nov 2005 14:23:22 -0700 Received: from [144.23.219.186] (bdesruis-ca.ca.oracle.com [144.23.219.186]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jANLNJSZ007969 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 23 Nov 2005 14:23:20 -0700 Message-ID: <4384DDC5.7060809@oracle.com> Date: Wed, 23 Nov 2005 16:23:17 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of bernard.desruisseaux@oracle.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ef25Q-00077B-Jh d4c2e5239d1b5fd903a0cbd149d1edfe X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on bug 15 X-Archived-At: http://www.w3.org/mid/4384DDC5.7060809@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10592 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 21:23:39 +0000 Content-Transfer-Encoding: 7bit Me too. +1 for Proposal 1. Cheers, Bernard Geoffrey M Clemm wrote: > > I agree with Stefan that we should stay consistent (i.e. +1 > for Proposal 1). > > Cheers, > Geoff > > > Stefan wrote on 11/23/2005 01:10:28 PM: > > > > Am 23.11.2005 um 19:05 schrieb Cullen Jennings: > > > > > > > > > > > I am going to call consensus on this one in a week so give me your > > > input > > > before then.... > > > > > > The basic issue is that the names are sort of reverse what people think > > > because they are based on post conditions. ACL (and others) already > > > exists > > > and do it the reverse way. The question is we should we define future > > > stuff > > > in the "forward" way... > > > > > > Proposal 1: Stay consistent with ACL - put in note for implementers > > > that > > > points out this is reverse of what they might expect. > > > > +1. > > > > > Proposal 2: Switch the way we do it. Leave old document reverse and > > > make new > > > documents forward. > > > > -1. > > > > From w3c-dist-auth-request@frink.w3.org Wed Nov 23 16:30:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef2By-0004P6-9t for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 16:30:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02029 for ; Wed, 23 Nov 2005 16:29:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef2BK-0001tC-7B for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 21:29:34 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ef2BJ-0001se-Ds for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 21:29:33 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ef2BA-0001SF-3D for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 21:29:32 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2005 13:29:20 -0800 X-IronPort-AV: i="3.97,367,1125903600"; d="scan'208"; a="233802415:sNHT23934448" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jANLTI6a010920 for ; Wed, 23 Nov 2005 13:29:19 -0800 (PST) Received: from 128.107.139.141 ([128.107.139.141]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Nov 2005 21:29:59 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 23 Nov 2005 13:29:23 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Notes on call from today ... Thread-Index: AcXwdPi9NzNQ7FxoEdqisgARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ef2BA-0001SF-3D c4a3844bea023c636ff225a11c9dfbb0 X-Original-To: w3c-dist-auth@w3.org Subject: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/BFAA1F33.61ED4%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10593 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 21:29:34 +0000 Content-Transfer-Encoding: 7bit Things I think agreed on Where not clear, will use XML Namespace instead of Namespace on bug 9 - explain allow vendor extension using URL that vendor owns token based strings are ok defined in RFC on bug 39 - use DAV:foo on bug 11 - need to tell server implementers there are problems with recursive xml and DOS attacks and they need to consider what to do. MAY return 400 class error with explanation with what is wrong. MAY just close connection. on bug 15 - Cullen need to send question to list on bug 37 - add back in forward reference to 14 (and perhaps 15) on bug 43 - Move to using "not wellformed" on bug 10 - proposal Go with text based on idea > 1) On the property element itself: [possible namespace name], [local name], > [children] of type element or character, plus [attributes] named > "xml:lang" present on the element itself or it's closest ancestor > > 2) On all children of the property element: [possible namespace name], [local > name], [attributes] and [children] of type element or character. add text that points out clients can not count on preservation o comments, processing instruction On the topic of namespace, we not going to require that you preserver them today (because many servers done) but say that future version of spec probably will require this and server SHOULD do it. Clients SHOULD NOT assume that servers do it. Bug 45 - Cache-ability is effected by what we choose here. Go with.... The client SHOULD not send it unless an standards track specification requires it. Any specification that requires it need to carefully consider the cache ability issue if what it is suggesting. Bug 46 - First sentence or two of 12.2 is unclear. Main point is implementer knows what get a relative URL, and the answer is that it relative to request URL. Perhaps ref the the draft on URI handling. Need to loose the term "single scope". If destination header in the request, then MAY be better to use absolute instead of any relative. Julian to propose text. Bug 47 - Will add back in and Lisa will try to clarify. Clients don't have to implement this. From w3c-dist-auth-request@frink.w3.org Wed Nov 23 17:34:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3CT-0006FU-AH for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 17:34:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09346 for ; Wed, 23 Nov 2005 17:34:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef3BJ-000474-Nr for w3c-dist-auth-dist@listhub.w3.org; Wed, 23 Nov 2005 22:33:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ef3B4-00045I-VE for w3c-dist-auth@listhub.w3.org; Wed, 23 Nov 2005 22:33:22 +0000 Received: from scanner2.ics.uci.edu ([128.195.1.36]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ef3B4-0001WH-In for w3c-dist-auth@w3.org; Wed, 23 Nov 2005 22:33:22 +0000 Received: from [128.195.20.215] (doric.ics.uci.edu [128.195.20.215]) by scanner2.ics.uci.edu (8.12.10/8.12.10) with ESMTP id jANMWNTp005239; Wed, 23 Nov 2005 14:32:23 -0800 (PST) Message-ID: <4384EDF6.30809@ics.uci.edu> Date: Wed, 23 Nov 2005 14:32:22 -0800 From: Joachim Feise Reply-To: jfeise@ics.uci.edu Organization: University of California, Irvine User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8) Gecko/20051025 Thunderbird/1.5 Mnenhy/0.7.2.0 MIME-Version: 1.0 To: webdav References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 X-Message: MS Outlook is evil. X-Face: ".VkfaZ'q>9U9_]JOTykMM^88emlx:rG{m-5JHhsQ~\Cj43sZOq"rZTWsJG+%+R8#r_/o 6-TIJFfgXwgkDmCFG-v/3Gkt%k3%HwA#d&j6.R,7gb?UXNP0B;\npi/_a>x"(RyBjiOw*I.;8=.l {N[OuH;-p8LW0>]4$OW!z`-!Iy%2^?v9r.hn6$R+,dpC_zU+}91L{x_!4PK,P7\mv)`w{h(QTE)Z ?(p>OgR}}e!`'4jJ`b|$?lppz@wmLaLi[ Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEUNEwyOlI2nraUABQD N08x9g3xRV1Ds8usABAAAAgBs7OnJAAACQ0lEQVR4nF2TMW/cMAyFBRgQkFFGlF2EjawCBBTJmIN ar/U10uxLYu4NXGgtkMXZOvb+bZ9k52KX8HDmd3yUyGdxXmJ+c0JUzt2t72fxAZDP4f4Ha15Ud3v wZlcg7CeYEb+RYoQU1f0OWCF5DCHyIHbgDfmglNJxEGsTkdPOCeRrMiqwqLbAirGvicjkkgtwzlk eFeUwgeX9BkhGQeMPRJrl1R6Qz0EmcvW+BcemgMMK5jkPDmCsV0CRn5cKAOv4E9zwsEo59yRkuAC dwZ+rs4DQ47PsN0Cg4r2AFwActksTmi/gXIB1slwj+YNSIVbz/L4AZ2XfqxpKRukdEFEdm3LzxoQ 43P+dM7Co0ErdnMiTYkgNsMQMcMLydN1i6lST0n0cZFHBljMwRAdSeCgO1uHWIjOp86EMqcYTZSl RnlKB+xWAYX3P/3XlHnYDzAY4F/I6TNOWuf+wdgWVGwvwGWh+ttXSw1WVzIB822RQXQBGosu1QwZ DPs3afGx6HNSYQM0hAMCoVRn75AMsFeoQ6gwEjIoaJ6+T1zXmSjooEwZ4exBSfMFWU2ph3KBCBqe mBWBx7BJ29zUcMS1CXXzxU8xS3qfUpZ/jkbJ54epb71uGlJ9SmtIrhzx1WHdMnX/QkUUHgIhjbRQ h8YgXmIJFzoJ9g62Visy3eM/b/wC/8CFgrczdAnwBiFfmHp35tAfwWuSADuMxFTBdKlLLWShcF+k teIAO+nSlotuAV3QYVVEC+GyeklK9Uo/l57QDMLRalEr7f0PUUat8ZcMkAAAAAElFTkSuQmCC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-100, required 5, USER_IN_WHITELIST) Received-SPF: none (lisa.w3.org: domain of jfeise@ics.uci.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on bug 15 X-Archived-At: http://www.w3.org/mid/4384EDF6.30809@ics.uci.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10594 X-Loop: w3c-dist-auth@w3.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, 23 Nov 2005 22:33:37 +0000 Content-Transfer-Encoding: 7bit +1 for proposal 1. -1 for proposal 2. back to lurking... -Joe Geoffrey M Clemm wrote on 11/23/2005 12:10: > I agree with Stefan that we should stay consistent (i.e. +1 > for Proposal 1). > > Cheers, > Geoff > > > Stefan wrote on 11/23/2005 01:10:28 PM: >> Am 23.11.2005 um 19:05 schrieb Cullen Jennings: >> >>> >>> I am going to call consensus on this one in a week so give me your >>> input >>> before then.... >>> >>> The basic issue is that the names are sort of reverse what people > think >>> because they are based on post conditions. ACL (and others) already >>> exists >>> and do it the reverse way. The question is we should we define future >>> stuff >>> in the "forward" way... >>> >>> Proposal 1: Stay consistent with ACL - put in note for implementers >>> that >>> points out this is reverse of what they might expect. >> +1. >> >>> Proposal 2: Switch the way we do it. Leave old document reverse and >>> make new >>> documents forward. >> -1. >> >> > From w3c-dist-auth-request@frink.w3.org Wed Nov 23 19:52:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef5M7-0004Qm-8w for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 19:52:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23797 for ; Wed, 23 Nov 2005 19:52:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef5Ki-00033z-Oy for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 00:51:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ef5Kd-00033O-Gn for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 00:51:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ef5Kb-00018e-3S for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 00:51:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAO0p4eH008770; Wed, 23 Nov 2005 16:51:04 -0800 Date: Wed, 23 Nov 2005 16:51:04 -0800 Message-Id: <200511240051.jAO0p4eH008770@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Ef5Kb-00018e-3S df331de2dd20c28d1362035465b9a3b4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/200511240051.jAO0p4eH008770@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10595 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 00:51:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=24 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-23 16:51 ------- Good point -- it's getting the lock that clients want a high likelihood of achieving, so: When trying to lock a collection upon creation, clients may attempt to increase the likelihood of getting the lock by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation there's no guarantee this will work). ------- 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@frink.w3.org Wed Nov 23 20:51:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef6Ga-0006SI-Lw for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 20:51:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28365 for ; Wed, 23 Nov 2005 20:50:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef6Fh-0001uz-7S for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 01:50:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ef6Fc-0001uR-4z for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 01:50:16 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1Ef6Fb-0000A5-KB for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 01:50:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ef6FT-0007Yz-5W for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 01:50:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAO1o4SF008815; Wed, 23 Nov 2005 17:50:04 -0800 Date: Wed, 23 Nov 2005 17:50:04 -0800 Message-Id: <200511240150.jAO1o4SF008815@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ef6FT-0007Yz-5W 0a11031a00386877ab1ad5450a424ab3 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 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200511240150.jAO1o4SF008815@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10596 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 01:50:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-23 17:50 ------- I've reworked this slightly to make more sense overall, and to be sure to cover all the 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@frink.w3.org Wed Nov 23 20:57:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef6MO-0007dG-Db for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 20:57:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28722 for ; Wed, 23 Nov 2005 20:56:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef6LS-0002uy-Se for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 01:56:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ef6LS-0002uQ-C0 for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 01:56:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ef6LP-0004sQ-4B for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 01:56:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAO1taKi008836; Wed, 23 Nov 2005 17:55:36 -0800 Date: Wed, 23 Nov 2005 17:55:36 -0800 Message-Id: <200511240155.jAO1taKi008836@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Ef6LP-0004sQ-4B cde2bf9540b4520cbea7e5716f34cb7b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 39] Syntax of property names in text content X-Archived-At: http://www.w3.org/mid/200511240155.jAO1taKi008836@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10597 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 01:56:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=39 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-23 17:55 ------- I've attempted to fix this for properties. Note, however, that XML element names are referred to in text without "DAV:" and instead in single quotes. I think this is reasonably readable. ------- 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@frink.w3.org Wed Nov 23 20:57:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef6MO-0007dS-J2 for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 20:57:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28721 for ; Wed, 23 Nov 2005 20:56:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef6Li-0002wV-En for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 01:56:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ef6Lh-0002vs-SH for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 01:56:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ef6Lf-0004zC-Pm for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 01:56:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAO1tq55008852; Wed, 23 Nov 2005 17:55:52 -0800 Date: Wed, 23 Nov 2005 17:55:52 -0800 Message-Id: <200511240155.jAO1tq55008852@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Ef6Lf-0004zC-Pm a8f80a403bc9f55a96264b12b399a756 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 43] "ill-formed" XML X-Archived-At: http://www.w3.org/mid/200511240155.jAO1tq55008852@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10598 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 01:56:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=43 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Wed Nov 23 20:59:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef6Of-0008BH-Gu for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 20:59:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28880 for ; Wed, 23 Nov 2005 20:58:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef6O6-0003K7-HY for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 01:59:02 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ef6O5-0003JU-KS for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 01:59:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ef6Nv-0002Yw-I6 for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 01:59:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAO1word008869; Wed, 23 Nov 2005 17:58:50 -0800 Date: Wed, 23 Nov 2005 17:58:50 -0800 Message-Id: <200511240158.jAO1word008869@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ef6Nv-0002Yw-I6 74d4ddd39dcf9ece284ab8590e18fcc7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 45] DAV request header X-Archived-At: http://www.w3.org/mid/200511240158.jAO1word008869@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10599 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 01:59:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=45 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-23 17:58 ------- New: As a request header, this header allows the client to advertise compliance with named features when the server needs that information. Clients SHOULD NOT send this header unless a standards track specification requires it. Any extension that makes use of this as a request header will need to carefully consider caching implications. ------- 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@frink.w3.org Wed Nov 23 21:03:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef6S0-0000O1-Qn for webdav-archive@megatron.ietf.org; Wed, 23 Nov 2005 21:03:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29193 for ; Wed, 23 Nov 2005 21:02:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ef6RN-0005Ay-Et for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 02:02:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ef6RM-0005AQ-V8 for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 02:02:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ef6RI-0004Ux-1v for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 02:02:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAO22HWE008901; Wed, 23 Nov 2005 18:02:17 -0800 Date: Wed, 23 Nov 2005 18:02:17 -0800 Message-Id: <200511240202.jAO22HWE008901@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ef6RI-0004Ux-1v 3f0e2142e63aad0781e807925bb26505 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/200511240202.jAO22HWE008901@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10600 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 02:02:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|lisa@osafoundation.org |julian.reschke@greenbytes.de Status|REOPENED |NEW ------- Additional Comments From lisa@osafoundation.org 2005-11-23 18:02 ------- This bug is only assigned to me because the bug was reopened. Assigning to Julian to get confirmation of the consensus if that's at issue. ------- 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@frink.w3.org Thu Nov 24 06:57:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFjR-0008Dt-Gb for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 06:57:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19939 for ; Thu, 24 Nov 2005 06:56:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfFhU-0008SI-Bu for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 11:55:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfFhN-0008PD-0s for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 11:55:35 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EfFgF-00007R-9j for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 11:55:31 +0000 Received: (qmail invoked by alias); 24 Nov 2005 11:54:16 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 24 Nov 2005 12:54:16 +0100 X-Authenticated: #1915285 Message-ID: <4385A9AF.1090403@gmx.de> Date: Thu, 24 Nov 2005 12:53:19 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDAV Content-Type: multipart/mixed; boundary="------------020605060908010606040101" X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfFgF-00007R-9j efb365c12fd3246e0f2bab6d3866e9ed X-Original-To: w3c-dist-auth@w3.org Subject: More mainly editorial changes X-Archived-At: http://www.w3.org/mid/4385A9AF.1090403@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10601 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 11:55:40 +0000 This is a multi-part message in MIME format. --------------020605060908010606040101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, the attached diffs (+ XML) implement some more mainly editorial enhancements I hope we can agree upon: - update references that were outdated; some minor tweaks in citing the XML spec (it really doesn't need to be a reference every time we mentionn it, also point to the section for xml:lang explicitly) - front matter: obsoletes RFC2518, fix title and abbreviated title - intro: do not say "this draft" - more broken XML fixed (I'm really getting tired having to fix those again and again) - lock compatibility table made an RFC2629-style table Best regards, Julian --------------020605060908010606040101 Content-Type: text/xml; name="draft-ietf-webdav-rfc2518bis-latest.xml" Content-Disposition: inline; filename="draft-ietf-webdav-rfc2518bis-latest.xml" Content-Transfer-Encoding: 7bit ]> HTTP Extensions for Distributed Authoring - WebDAV Open Source Application Foundation
2064 Edgewood Dr. Palo Alto CA 94303 US lisa@osafoundation.org
Applications WebDAV webdav http authoring web WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1999, and this document makes minor revisions mostly due to interoperability experience.
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for: Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Also, the ability to link pages of any media type to related pages. Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system). Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem", in which modifications are lost as first one author then another writes changes without merging the other author's changes. Namespace Operations: The ability to instruct the server to copy and move Web resources, operations which change the URL. Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" . This standard does not specify the versioning operations suggested by . That work was done in a separate document, "Versioning Extensions to WebDAV" . The sections below provide a detailed introduction to various WebDAV abstractions: resource properties, collections of resources, locks in general and write locks specifically. These abstractions are manipulated by the WebDAV-specific HTTP methods and the new HTTP headers used with WebDAV methods. While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines new status codes developed for WebDAV methods and describes existing HTTP status codes as used in WebDAV. Since some WebDAV methods may operate over many resources, the Multi-Status response has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces precondition and postcondition XML elements in error response bodies. WebDAV uses XML for property names and some values, and also uses XML to marshal complicated request and response. This specification contains DTD and text definitions of all all properties and all other XML elements used in marshalling. WebDAV includes a few special rules on how to process XML appearing in WebDAV so that it truly is extensible. Finishing off the specification are sections on what it means for a resource to be compliant with this specification, on internationalization support, and on security.
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in section 2.1 of , including the rules about implied linear white-space. Since this augmented BNF uses the basic production rules provided in section 2.2 of , these rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Note that in natural language, a property like the "creationdate" property in the "DAV:" XML namespace is sometimes referred to as "DAV:creationdate" for brevity.
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in . Collection - A resource that contains a set of URLs, which identify and locate member resources and which meet the collections requirements. Member URL - A URL which is a member of the set of URLs contained by a collection. Internal Member URL - A Member URL that is immediately relative to the URL of the collection (the definition of immediately relative is given later). Property - A name/value pair that contains descriptive information about a resource. Live Property - A property whose semantics and syntax are enforced by the server. For example, the live property DAV:getcontentlength has its value, the length of the entity returned by a GET request, automatically calculated by the server. Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property. Principal - A "principal" is a distinct human or computational actor that initiates access to network resources.
Properties are pieces of data that describe the state of a resource. Properties are data about data. Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents. The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics. There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is read-only, maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus a mechanism is needed which allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an XML request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support. In addition to encoding method parameters, XML is used in WebDAV to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input. The XML namespace extension is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group. Note that "DAV:" uses a scheme name defined solely for the purpose of creating this XML namespace. Defining new schemes for namespaces is discouraged. "DAV:" was defined before standard best practices emerged, and this namespace is still used only because of significant existing deployments.
The value of a property is always a (well-formed) XML fragment. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. A property is always represented in XML with an XML element consisting of the property name. The simplest example is an empty property, which is different from a property that does not exist. <R:title xmlns:R="http://www.example.com/ns/"></R:title> The value of a property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. When the property value contains further XML elements, XML namespaces that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. Namespace prefixes need not be preserved due to the rules of prefix declaration in XML. Attributes on the property name element may convey information about the property, but are not considered part of the value. However, when language information appears in the 'xml:lang' attribute on the property name element, the language information MUST be preserved in server storage for retransmission later. Note that a property only has one value, in one language (or language MAY be left undefined), not multiple values in different languages or a single value in multiple languages. The XML attribute xml:space MUST NOT be used to change white space handling. White space in property values is significant.
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property. Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition. The XML namespace mechanism, which is based on URIs (), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control. The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced which will address issues relating to hierarchical properties. Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
This section provides a description of a new type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace. All DAV compliant resources MUST support the HTTP URL namespace model specified herein.
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character. An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. The root, or top-level collection of the namespace under consideration is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/', it may be identified by one or more path segments (e.g. /servlets/webdav/...) Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies. Although implicit in and , any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
A collection is a resource whose state consists of at least a list of internal member URLs and a set of properties, but which may have additional state such as entity bodies returned by GET. An internal member URL MUST be immediately relative to a base URL of the collection. That is, the internal member URL is equal to a containing collection's URL plus an additional segment for non-collection resources, or additional segment plus trailing slash "/" for collection resources, where segment is defined in section 3.3 of . Any given internal member URL MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URL in a collection. Properties defined on collections behave exactly as do properties on non-collection resources. For all WebDAV compliant resources A and B, identified by URLs U and V, for which U is immediately relative to V, B MUST be a collection that has U as an internal member URL. So, if the resource with URL http://example.com/bar/blah is WebDAV compliant and if the resource with URL http://example.com/bar/ is WebDAV compliant then the resource with URL http://example.com/bar/ must be a collection and must contain URL http://example.com/bar/blah as an internal member. Collection resources MAY list the URLs of non-WebDAV compliant children in the HTTP URL namespace hierarchy as internal members but are not required to do so. For example, if the resource with URL http://example.com/bar/blah is not WebDAV compliant and the URL http://example.com/bar/ identifies a collection then URL http://example.com/bar/blah may or may not be an internal member of the collection with URL http://example.com/bar/. If a WebDAV compliant resource has no WebDAV compliant children in the HTTP URL namespace hierarchy then the WebDAV compliant resource is not required to be a collection. There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. In this case it SHOULD return a Content-Location header in the response, pointing to the URL ending with the "/". For example, if a client invokes a method on http://example.com/blah (no trailing slash), the server may respond as if the operation were invoked on http://example.com/blah/ (trailing slash), and should return a Content-Location header with the value http://example.com/blah/. Wherever a server produces a URL referring to a collection, the server MUST include the trailing slash. In general clients SHOULD use the "/" form of collection names. Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if a OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections.
The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem. This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.
The most basic form of lock is an exclusive lock. Only one exclusive lock may exist on any resource, whether it is directly or indirectly locked. Exclusive locks avoid having to merge results, without requiring any coordination other than the methods described in this specification. However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal with appropriate access can use the lock. With shared locks there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set. Starting with every possible principal on the Internet, in most situations the vast majority of these principals will not have write access to a given resource. Of the small number who do have write access, some principals may decide to guarantee their edits are free from overwrite conflicts by using exclusive write locks. Others may decide they trust their collaborators will not overwrite their work (the potential set of collaborators being the set of principals who have write permission) and use a shared lock, which informs their collaborators that a principal may be working on the resource. The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out of band communication channel to coordinate their work (e.g., face-to-face interaction, written notes, post-it notes on the screen, telephone conversation, Email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource. Shared locks are included because experience from web distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example when a program crashes, or when a lock owner leaves without unlocking a resource. While both timeouts and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
A WebDAV compliant resource is not required to support locking in any form. If the resource does support locking it may choose to support any combination of exclusive and shared locks for any access types. The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks while others only provide support for exclusive write locks while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
A lock token is a type of state token, represented as a URI, which identifies a particular lock. Each lock has exactly one unique lock token generated by the server. Clients MUST NOT attempt to interpret lock tokens in any way. Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in , and also in the body of the response. Submitting a lock token does not confer full privilege to use the lock token or modify the locked resource. Anyone can find out anyone else's lock token by performing lock discovery. Write access and other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the slight obscurity of lock token values. Since lock tokens are unique, a client MAY submit a lock token in an If header on a resource other than the one that returned it. This specification encourages servers to create UUIDs for lock tokens, and to use the URI form defined by "A Universally Unique Identifier (UUID) URN Namespace" (). However servers are free to use another valid URI so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in an appendix of this document. Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. A client can determine what lock types the server supports by retrieving the DAV:supportedlock property. Any DAV compliant resource that supports the LOCK method MUST support the DAV:supportedlock property.
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the DAV:lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and where available, provides their lock token. Any DAV compliant resource that supports the LOCK method MUST support the DAV:lockdiscovery property.
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 section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification. An exclusive write lock will prevent parallel changes to a resource by any principal other than the write lock holder. In general terms, changes affected by write locks include changes to: the content of the resource any dead property of the resource any live property defined to be lockable (all properties defined in this specification are lockable) the direct membership of the resource, if it is a collection the URL/location of a resource The next few sections describe in more specific terms how write locks interact with various operations.
The creator of the lock is the lock owner. The server MUST restrict the usage of the lock token to the lock owner (both for shared and exclusive locks -- for multi-user shared lock cases, each authenticated principal MUST obtain its own shared lock). The server MAY allow privileged users other than the lock owner to destroy a lock (for example, the resource owner or an administrator) as a special case of lock usage. If an anonymous user requests a lock, the server MAY refuse the request.
A server MUST reject any write request that alters a write-locked resource unless a valid lock token is provided. The write operations defined in HTTP and WebDAV are PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL. All other HTTP/WebDAV methods, GET in particular, function independently of the lock. A shared write lock prevents the same operations, however it also allows access by any principal that has a shared write lock on the same resource. Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.
A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal.
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked.
Although the write locks provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario: Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking. Client A doesn't lock the document, but does a GET and begins editing. Client B does LOCK, performs a GET and begins editing. Client B finishes editing, performs a PUT, then an UNLOCK. Client A performs a PUT, overwriting and losing all of B's changes. There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK. WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources. WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking. HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources. Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.
It is possible to lock an unmapped URL in order to lock the name for use. This is a simple way to avoid the lost-update problem on the creation of a new resource (another way is to use If-None-Match header specified in HTTP 1.1). It has the side benefit of locking the new resource immediately for use of the creator. 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. When trying to lock a collection upon creation, clients may attempt to increase the likelihood of getting the lock by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation there's no guarantee this will work). A lock request to an unmapped URL SHOULD result in the creation of an locked resource with empty content. A subsequent PUT request with the correct lock token SHOULD normally succeed, and this new request provides the content, content-type, content-language and other information as appropriate. In this situation, a WebDAV server that was implemented from RFC2518 MAY create "lock-null" resources which are special and unusual resources. Historically, a lock-null resource: Responds with a 404 or 405 to any DAV method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. Appears as a member of its parent collection. Disappears (URI becomes unmapped) if its lock goes away before it is converted to a regular resource. (This must also happen if it is renamed or moved, or if any parent collection is renamed or moved, because locks are tied to URLs). May be turned into a regular resource when a PUT request to the URL is successful. Ceases to be a lock-null resource. May be turned into a collection when a MKCOL request to the URL is successful. Ceases to be a lock-null resource. Has defined values for DAV:lockdiscovery and DAV:supportedlock properties. However, interoperability and compliance problems have been found with lock-null resources. Therefore, they are deprecated. WebDAV servers SHOULD create regular locked empty resources, which are and behave in every way as normal resources. A locked empty resource: Can be read, deleted, moved, copied, and in all ways behave as a regular resource, not a lock-null resource. Appears as a member of its parent collection. SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation) SHOULD default to having no content type. MAY NOT have values for properties like DAV:getcontentlanguage which haven't been specified yet by the client. May have content added with a PUT request. MUST be able to change content type. MUST NOT be turned into a collection. A MKCOL request must fail as it would to any existing resource. MUST have defined values for DAV:lockdiscovery and DAV:supportedlock properties. The response MUST indicate that a resource was created, by use of the "201 Created" response code (a LOCK request to an existing resource instead will result in 200 OK). The body must still include the DAV:lockdiscovery property, as with a LOCK request to an existing resource. The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH. When the client uses PUT to overwrite a locked empty resource the client MUST supply a Content-Type if any is known. If the client supplies a Content-Type value the server MUST set that value (this requirement actually applies to any resource that is overwritten but is particularly necessary for locked empty resources which are initially created with no Content-Type. Clients can easily interoperate both with servers that support the deprecated lock-null resources and servers that support simpler locked empty resources by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET.
A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URLs of the collection by non-lock owners. A zero-depth lock on a collection affects changes to the direct membership of that collection. When a principal issues a write request to create a new resource in a write locked collection, or isses a DELETE, MOVE or other request that would remove an existing internal member URL of a write locked collection or change the binding name, this request MUST fail if the principal does not provide the correct lock token for the locked collection. This means that if a collection is locked (depth 0 or infinity), its lock-token is required in all these cases: DELETE a collection's direct internal member MOVE a member out of the collection MOVE a member into the collection, unless it overwrites a pre-existing member MOVE to rename it within a collection, COPY a member into a collection, unless it overwrites a pre-existing member PUT or MKCOL request which would create a new member. The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately. In addition, a depth-infinity lock affects all write operations to all descendents of the locked collection. With a depth-infinity lock, the root of the lock is directly locked, and all its descendants are indirectly locked. Any new resource added as a descendent of a depth-infinity locked collection becomes indirectly locked. Any indirectly locked resource moved out of the locked collection into an unlocked collection is thereafter unlocked. Any indirectly locked resource moved out of a locked source collection into a depth-infinity locked target collection remains indirectly locked but is now within the scope of the lock on the target collection (the target collection's lock token will thereafter be required to make further changes). If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'missing-lock-token' precondition. If a lock owner causes the URL of a resource to be added as an internal member URL of a depth-infinity locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock.
If a user agent is not required to have knowledge about a lock when requesting an operation on a locked resource, the following scenario might occur. Program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by Program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization. In order to prevent these collisions a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted in the if header, one for the source and the other for the destination.
>>Request () ]]>
>>Response
In this example, even though both the source and destination are locked, only one lock token must be submitted, for the lock on the destination. This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with "Depth: infinity", then the resource will be added to the lock. A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, the resource is subject to being added to an existing lock at the destination (see ). For example, if the MOVE makes the resource a child of a collection that is locked with "Depth: infinity", then the resource will be added to that collection's lock. Additionally, if a resource locked with "Depth: infinity" is moved to a destination that is within the scope of the same lock (e.g., within the URL namespace tree covered by the lock), the moved resource will again be a added to the lock. In both these examples, as specified in , an If header must be submitted containing a lock token for both the source and destination.
A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked. However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set. A server may return a Timeout header with a lock refresh that is different than the Timeout header returned when the lock was originally requested. Additionally clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client. Note that timeout is measured in seconds remaining until expiration. If an error is received in response to a refresh LOCK request the client MUST NOT assume that the lock was refreshed.
Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with and . All XML used in either requests or responses MUST be, at minimum, well formed and use namespaces correctly. If a server receives XML that is not well-formed then the server MUST reject the entire request with a 400 (Bad Request). If a client receives XML that is not well-formed in a response then the client MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as they intended.
HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible.
HTTP 1.1 recommends the use of the ETag header in responses to GET and PUT requests. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem. A client might fail to renew a lock, for example when the lock times out and the client is accidentally offline or in the middle of a long upload. When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user whether it has changed. Timestamps do not solve this problem nearly as well as ETags. WebDAV servers SHOULD support strong ETags for all resources that may be PUT. If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the DAV:getetag property. Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or DAV:getlastmodified value) for a resource that has an unchanged body. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed.
HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of ). The mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This mechanism does not take the place of using a correct numeric error code as defined here or in HTTP, because the client MUST always be able to take a reasonable course of action based only on the numeric error. However, it does remove the need to define new numeric error codes, avoiding the confusion of who is allowed to define such new codes. The codes used in this mechanism are XML elements in a namespace, so naturally any group defining a new error code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups. A server supporting "bis" SHOULD include a specific XML error code in a "DAV:error" response body element, when a specific XML error code is defined in this document. The DAV:error element may contain multiple elements describing specific errors. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank.
>>Response ]]>
In this specification, both the numeric and the XML error code are defined for some failure situations, in which case the XML error code must have the "DAV:" namespace, appear in the "error" root element, and be returned in a body with the numeric error code specified.
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs. All DAV compliant resources MUST support the PROPFIND method and the propfind XML element () along with all XML elements defined for use with that element. A client may submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND on a collection resource. Servers MUST support the "0", "1" and "infinity" behaviors on WebDAV-compliant resources. By default, the PROPFIND method without a Depth header MUST act as if a "Depth: infinity" header was included. A client may submit a 'propfind' XML element in the body of the request method describing what information is being requested. It is possible to: Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by server) Request all dead property values, by using 'dead-props' element. This can be combined with retrieving specific live properties named as above. Servers advertising support for RFC2518bis MUST support this feature. Request property values for those properties defined in this specification plus dead properties, by using 'allprop' element Request a list of names of all the properties defined on the resource, by using the 'propname' element. A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request. Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see and ) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. A WebDAV server MAY omit certain live properties from other specifications when responding to an 'allprop' request from an older client, and MAY return only custom (dead) properties and those defined in this specification. All servers MUST support returning a response of content type text/xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties. If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a 'multistatus' XML element, with a 'response' XML element which contains a 404 (Not Found) status value. Consequently, the 'multistatus' XML element for a collection resource with member URLs MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. Each 'response' XML element MUST contain an href XML element that gives the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URLs are returned as a flat list whose order of entries is not significant. Properties may be subject to access control. In the case of 'allprop' and 'propname' requests, if a principal does not have the right to know whether a particular property exists then the property MAY be silently excluded from the response. The results of this method SHOULD NOT be cached.
A server MAY fail an entire PROPFIND request with an appropriate status code and MAY redirect the entire request. In addition, the following error codes are specifically defined for PROPFIND requests: 403 Forbidden - A server MAY reject all PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-infinite-depth-forbidden' inside the error body.
The following status codes are defined for use within the PROPFIND Multi-Status response: 200 OK - A property exists and/or its value is successfully returned. 401 Unauthorized - The property cannot be viewed without appropriate authorization. 403 Forbidden - The property cannot be viewed regardless of authentication. 404 Not Found - The property does not exist.
>>Request ]]>
>>Response http://www.example.com/file Box type A J.J. Johnson HTTP/1.1 200 OK HTTP/1.1 403 Forbidden The user does not have access to the DingALing property. There has been an access violation error. ]]>
In this example, PROPFIND is executed on a non-collection resource http://www.example.com/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
>>Request ]]>
In this example, PROPFIND is executed on a collection resource http://www.example.com/mycol/. The client requests the values of two specific live properties plus all dead properties (names and values). The response is not shown.
>>Request ]]>
>>Response http://www.example.com/container/ HTTP/1.1 200 OK http://www.example.com/container/front.html HTTP/1.1 200 OK ]]>
In this example, PROPFIND is invoked on the collection resource http://www.example.com/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its descendents should be returned. Consistent with the previous example, resource http://www.example.com/container/ has six properties defined on it: bigbox and author in the "http://www.example.com/boxschema/" namespace, and creationdate, displayname, resourcetype, and supportedlock in the "DAV:" namespace. The resource http://www.example.com/container/index.html, a member of the "container" collection, has nine properties defined on it, bigbox in the "http://www.example.com/boxschema/" namespace and, creationdate, displayname, getcontentlength, getcontenttype, getetag, getlastmodified, resourcetype, and supportedlock in the "DAV:" namespace. This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI. All DAV compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV compliant resources SHOULD support the setting of arbitrary dead properties. The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Instruction processing MUST occur in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus if any error occurs during processing all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in sections 13.23 and section 13.24.
The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. 200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate. 403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties. 403 (Forbidden): The client has attempted to set a read-only property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'read-only-property' inside the response body. 409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. 423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it. This response SHOULD contain the 'missing-lock-token' precondition code. 424 (Failed Dependency) - The property change could not be made because of another property change that failed. 507 (Insufficient Storage) - The server did not have sufficient space to record the property.
>>Request Jim Whitehead Roy Fielding ]]>
>>Response http://www.example.com/bar.html HTTP/1.1 424 Failed Dependency HTTP/1.1 409 Conflict Copyright Owner can not be deleted or altered. ]]>
In this example, the client requests the server to set the value of the "Authors" property in the "http://www.w3.com/standards/z39.50/" namespace, and to remove the property "Copyright-Owner" in the "http://www.w3.com/standards/z39.50/" namespace. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
The MKCOL method is used to create a new collection. All WebDAV compliant resources MUST support the MKCOL method. MKCOL creates a new collection resource at the location specified by the Request-URI. If the resource identified by the Request-URI is non-null then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI a member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the request must fail. When MKCOL is invoked without a request body, the newly created collection SHOULD have no members. A MKCOL request message may contain a message body. The precise behavior of a MKCOL request when the body is present is undefined, but limited to creating collections, members of a collection, bodies of members and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand it MUST respond with a 415 (Unsupported Media Type) status code. If the server decides to reject the request based on the presence of an entity or the type of an entity, it should use the 415 (Unsupported Media Type) status code.
Responses from a MKCOL request MUST NOT be cached as MKCOL has non-idempotent semantics. 201 (Created) - The collection was created. 403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members. 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL. 409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 415 (Unsupported Media Type) - The server does not support the request type of the body. 507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
This example creates a collection called /webdisc/xfiles/ on the server www.example.com.
>>Request
>>Response
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET when applied to a collection may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection. Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection.
Locks rooted on a resource MUST be destroyed in a successful DELETE of that resource.
When a client issues a DELETE request to a Request-URI mapping to a non-collection resource, if the operation is successful the server MUST remove that mapping. Thus, after a successful DELETE operation (and in the absence of other actions) a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found).
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity. DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted. If any resource identified by a member URL cannot be deleted then all of the member's ancestors MUST NOT be deleted, so as to maintain URL namespace consistency. Any headers included with DELETE MUST be applied in processing every resource to be deleted. When the DELETE method has completed processing it MUST result in a consistent URL namespace. If an error occurs deleting an internal resource (a resource other than the resource identified in the Request-URI) then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked. The server MAY return a 4xx status response, rather than a Multi-Status, if the request failed. 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
>>Request
>>Response http://www.example.com/container/resource3 HTTP/1.1 423 Locked ]]>
In this example the attempt to delete http://www.example.com/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.example.com/container/ also failed. Thus the client knows that the attempt to delete http://www.example.com/container/ must have also failed since the parent can not be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties. A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
As defined in , the "PUT method requests that the enclosed entity be stored under the supplied Request-URI." Since submission of an entity representing a collection would implicitly encode creation and deletion of resources, this specification intentionally does not define a transmission format for creating a collection using PUT. Instead, the MKCOL method is defined to create collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed).
The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource. The state of the resource to be copied is fixed at the point the server begins processing the COPY request. All WebDAV compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
When the source resource is not a collection the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
After a successful COPY invocation, all dead properties on the source resource MUST be duplicated on the destination resource, along with all properties as appropriate. Live properties described in this document SHOULD be duplicated as identically behaving live properties at the destination resource, but not necessarily with the same values. 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. A COPY operation creates a new resource, much like a PUT operation does. Live properties which are related to resource creation (such as DAV:creationdate) should have their values set accordingly.
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". Servers MUST support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources. A COPY of depth infinity instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy. Servers should of course avoid infinite recursion, and can do so by copying the source resource as it existed at the point where processing started. A COPY of "Depth: 0" only instructs that the collection and its properties but not resources identified by its internal member URLs, are to be copied. Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header. The Destination header only specifies the destination URI for the Request-URI. When applied to members of the collection identified by the Request-URI the value of Destination is to be modified to reflect the current location in the hierarchy. So, if the Request-URI is /a/ with Host header value http://example.com/ and the Destination is http://example.com/b/ then when http://example.com/a/c/d is processed it must use a Destination of http://example.com/b/c/d. When the COPY method has completed processing it MUST have created a consistent URL namespace at the destination (see for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite depth copy, the server SHOULD try to finish as much of the original copy operation as possible. If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status), and the URL of the resource causing the failure MUST appear with the specific error. The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail. (Extensions to WebDAV might not follow this rule to the letter but must consider backwards compatibility with clients that expect COPY to work this way.) Interoperability testing has shown that some clients expect a collection COPY to actually do a merge if a destination collection exists. That behavior is appropriate for file system folders but not necessarily for other data objects modelled as collections. Thus, implementors are urged to comply with the standard language above, and leave clients to perform a manual merge if that's the expected behavior when copying a collection over another collection.
201 (Created) - The source resource was successfully copied. The copy operation resulted in the creation of a new resource. 204 (No Content) - The source resource was successfully copied to a pre-existing destination resource. 207 (Multi-Status) - Multiple resources were to be affected by the COPY, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. E.g. if a destination resource was locked and could not be overwritten, then the destination resource URL appears with the 423 (Locked) status. 403 (Forbidden) - The operation is forbidden. Possibly this is because the source and destination resources are the same resource. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 412 (Precondition Failed) - A precondition failed, e.g. the Overwrite header is "F" and the state of the destination resource is non-null. 423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response SHOULD contain the 'missing-lock-token' precondition element. 502 (Bad Gateway) - This may occur when the destination is on another server, repository or URL namespace. Either the source namespace does not support copying to the destination namespace, or the destination namespace refuses to accept the resource. The client may wish to try GET/PUT and PROPFIND/PROPPATCH instead. 507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
This example shows resource http://www.ics.uci.edu/~fielding/index.html being copied to the location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No Content) status code indicates the existing resource at the destination was overwritten.
>>Request
>>Response
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination resource has a non-null state.
>>Request
>>Response
>>Request
>>Response http://www.example.com/othercontainer/R2/ HTTP/1.1 423 Locked ]]>
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example most of the resources, along with the collection, were copied successfully. However the collection R2 failed because the destination R2 is locked. Because there was an error copying R2, none of R2's members were copied. However no errors were listed for those members due to the error minimization rules.
The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs other than the Request-URI which identify the source resource, to point to the new destination resource. Consequently, the Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV compliant resources MUST support the MOVE method. However, support for the MOVE method does not guarantee the ability to move a resource to a particular destination. For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server. If a resource exists at the destination, the destination resource will be deleted as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
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 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. MOVE is frequently used by clients to rename a file without changing its parent collection, so it's not appropriate to reset live properties which are set at resource creation. For example, the DAV:creationdate property value SHOULD remain the same after a MOVE. Dead properties must be moved along with the resource.
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the address specified in the Destination header, and all resources identified by its internal member URLs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy. The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity". Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header. The behavior of the Destination header is the same as given for COPY on collections. When the MOVE method has completed processing it MUST have created a consistent URL namespace at both the source and destination (see section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible. If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status), and the errored resource's URL MUST appear with the specific error. The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the move the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail.
201 (Created) - The source resource was successfully moved, and a new resource was created at the destination. 204 (No Content) - The source resource was successfully moved to a pre-existing destination resource. 207 (Multi-Status) - Multiple resources were to be affected by the MOVE, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. E.g. if a source resource was locked and could not be moved, then the source resource URL appears with the 423 (Locked) status. 403 (Forbidden) - The source and destination resources are the same. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. Or, the server was unable to preserve the behavior of the live properties and still move the resource to the destination (see 'live-properties-not-preserved' postcondition). 412 (Precondition Failed) - A condition failed, e.g. the Overwrite header is "F" and the state of the destination resource is non-null. 423 (Locked) - The source or the destination resource, or some resource within the source or destination collection, was locked. This response SHOULD contain the 'missing-lock-token' precondition element. 502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource. This could also occur when the destination is on another sub-section of the same server namespace.
This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the location http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination resource had been non-null. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
>>Request
>>Response
>>Request ) () ]]>
>>Response http://www.example.com/othercontainer/C2/ HTTP/1.1 423 Locked ]]> In this example the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case the proper lock token was not submitted for the destination http://www.example.com/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error moving /container/C2/, none of /container/C2's members were moved. However no errors were listed for those members due to the error minimization rules. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested. Any resource which supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein. A LOCK method invocation to an unlocked resource creates a lock on the resource identified by the Request-URI, which becomes the root of the lock. Lock method requests to create a new lock MUST have a XML request body which contains an owner XML element and other information for this lock request. The server MUST preserve the information provided by the client in the 'owner' field when the lock information is requested. The LOCK request MAY have a Timeout header. Clients MUST assume that locks may arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if extraordinary circumstances do not occur. For example, a sufficiently privileged user may remove a lock at any time or the system may crash in such a way that it loses the record of the lock's existence. When a new lock is created, the LOCK response: MUST contain a body with the value of the DAV:lockdiscovery property in a prop XML element. MUST include the Lock-Token response header with the token associated with the new lock.
A lock is refreshed by sending a LOCK request without a request body to the URL of a resource within the scope 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). It MAY contain a Timeout header, which a server MAY accept to change the duration remaining on the lock to the new value. A server MUST ignore the Depth header on a LOCK refresh. If the resource has other (shared) locks, those locks are unaffected by a lock refresh. Additionally, those locks do not prevent the named lock from being refreshed. Note that in RFC2518, clients were indicated through the example in the text to use the If header to specify what lock to refresh (rather than the Lock-Token header). Servers are encouraged to continue to support this as well as the Lock-Token header. Note that the Lock-Token header is not be returned in the response for a successful refresh LOCK request, but the LOCK response body MUST contain the new value for the DAV:lockdiscovery body.
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK method. All resources that support the LOCK method MUST support the Depth header. A Depth header of value 0 means to just lock the resource specified by the Request-URI. If the Depth header is set to infinity then the resource specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token which represents all the resources that have been locked. If an UNLOCK is successfully executed on this token, all associated resources are unlocked. If the lock cannot be granted to all resources, a 207 (Multi-Status) status code MUST be returned with a response entity body containing a multistatus XML element describing which resource(s) prevented the lock from being granted. Hence, partial success is not an option. Either the entire hierarchy is locked or no resources are locked. If no Depth header is submitted on a LOCK request then the request MUST act as if a "Depth:infinity" had been submitted.
A successful LOCK method MUST result in the creation of an empty resource which is locked (and which is not a collection), when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length and no Content-Type.
The table below describes the behavior that occurs when a lock request is made on a resource. Current lock state / Lock requestShared LockExclusive Lock NoneTrueTrue Shared LockTrueFalse Exclusive LockFalseFalse* Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice. The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating the lock must not be granted.
200 (OK) - The lock request succeeded and the value of the DAV:lockdiscovery property is included in the body. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. 423 (Locked) - The resource is locked already. For consistency's sake, this response SHOULD contain the 'missing-lock-token' precondition element. 400 (Bad Request), with 'request-uri-must-match-lock-token' precondition code - The LOCK request was made with a Lock-Token header, indicating that the client wishes to refresh the given lock. However, the Request-URI did not fall within the scope of the lock identified by the token. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid. 424 (Failed Dependency) - This may appear inside a 207 response to a LOCK request, to indicate that a resource could not be locked because of a failure on another resource.
>>Request http://www.ics.uci.edu/~ejw/contact.html ]]>
>>Response Content-Type: text/xml; charset="utf-8" Content-Length: xxxx infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 http://example.com/workspace/webdav/proposal.doc ]]>
This example shows the successful creation of an exclusive write lock on resource http://example.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header. Note that the locktoken and lockroot href elements would not contain any whitespace. The line return appearing in this document is only for formatting.
>>Request Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." ]]>
>>Response infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 http://example.com/workspace/webdav/proposal.doc ]]> This request would refresh the lock, attempting to reset the timeout to the new value specified in the timeout header. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
>>Request http://www.ics.uci.edu/~ejw/contact.html ]]>
>>Response http://example.com/webdav/secret HTTP/1.1 403 Forbidden http://example.com/webdav/ HTTP/1.1 424 Failed Dependency ]]>
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock, in this case a web page URL. The error is a 403 (Forbidden) response on the resource http://example.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the DAV:lockdiscovery property for the Request-URI has been included as required. In this example the DAV:lockdiscovery property is empty which means that there are no outstanding locks on the resource. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock. 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. For a successful response to this method, the server MUST remove the lock from the resource identified by the Request-URI and from all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. A successful response to an UNLOCK method does not mean that the resource is necessarily unlocked. It means that the specific lock corresponding to the specified token no longer exists. Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method.
204 (No Content) - Normal success response (rather than 200 OK, since 200 OK would imply a response body, and an UNLOCK success response does not normally contain a body) 400 (Bad Request) - No lock token was provided (see 'missing-lock-token' precondition), or request was made to a Request-URI that was not within the scope of the lock (see 'requesturi-must-match-lock-token' precondition). 403 (Forbidden) - The currently authenticated principal does not have permission to remove the lock (the server SHOULD use the 'need-privileges' precondition element). 412 (Precondition Failed) - The resource was not locked.
>>Request Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." ]]>
>>Response
In this example, the lock identified by the lock token "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas.
DAV = "DAV" ":" #( compliance-code ) compliance-code = ( "1" | "2" | "bis" | extend ) extend = Coded-URL | token
This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources MUST return the DAV header on all OPTIONS responses. The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs to encourage uniqueness. A resource must show class 1 compliance if it shows class 2 or "bis" compliance. In general, support for one compliance class does not entail support for any other. Please refer to section 16 for more details on compliance classes defined in this specification. 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 URL namespaces. As a request header, this header allows the client to advertise compliance with named features when the server needs that information. Clients SHOULD NOT send this header unless a standards track specification requires it. Any extension that makes use of this as a request header will need to carefully consider caching implications.
Depth = "Depth" ":" ("0" | "1" | "infinity")
The Depth request header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity"). The Depth header is only supported if a method's definition explicitly provides for such support. The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition. Methods which support the Depth header may choose not to support all of the header's values and may define, on a case by case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity" and if a Depth header is not present will act as if a "Depth: infinity" header had been applied. Clients MUST NOT rely upon methods executing on members of their hierarchies in any particular order or on the execution being atomic unless the particular method explicitly provides such guarantees. Upon execution, a method with a Depth header will perform as much of its assigned task as possible and then return a response specifying what it was able to accomplish and what it failed to do. So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not. Any headers on a method that has a defined interaction with the Depth header MUST be applied to all resources in the scope of the method except where alternative behavior is explicitly defined. For example, an If-Match header will have its value applied against every resource in the method's scope and will cause the method to fail if the header fails to match. If a resource, source or destination, within the scope of the method with a Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header. The Depth header only specifies the behavior of the method with regards to internal children. If a resource does not have internal children then the Depth header MUST be ignored. Please note, however, that it is always an error to submit a value for the Depth header that is not allowed by the method's definition. Thus submitting a "Depth: 1" on a COPY, even if the resource does not have internal members, will result in a 400 (Bad Request). The method should fail not because the resource doesn't have internal members, but because of the illegal value in the header.
Destination = "Destination" ":" ( absolute-URI )
The Destination request header specifies the URI which identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters. Note that the absolute-URI production is defined in . If the Destination value is an absolute URI, it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request with a 502 (Bad Gateway) response. Servers MAY attempt to copy the resource to the remote server using PUT/PROPPATCH or another mechanism.
Force-Authentication = "Force-Authentication" ":" Method
The Force-Authentication request header is used with the OPTIONS method to specify that the client wants to be challenged for authentication credentials to the resource identified by the Request-URI. If present on a request to a WebDAV-compliant resource, the server MUST respond with either 401 (Unauthorized) or 501 (Not Implemented) status code. The Method value is used for the client to indicate what method it intends to use first on the resource identified in the Request-URI.
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) No-tag-list = List Tagged-list = Resource 1*List Resource = Coded-URL List = #( "(" List | Clause ")" ) Clause = ["Not"] State-token | State-token State-token = Coded-URL | "[" entity-tag "]" Coded-URL = "<" absolute-URI ">"
The If request header is intended to have similar functionality to the If-Match header defined in section 14.24 of . However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. The <DAV:no-lock> state token is an example of a state token that will never match an actual valid lock token. The purpose of this is described in . The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). If one of the described state lists matches the state of the resource then the request may succeed. The server must parse the If header when it appears on any request, evaluate all the clauses, and if the conditional evaluates to false, fail the request. Note that the absolute-URI production is defined in . RFC2518 originally defined the If header without comma separators. This oversight meant that the If header couldn't be divided up among multiple lines according to the HTTP header manipulation rules. Servers supporting "bis" MUST be able to accept commas in If header values. If the header has commas between tokens or clauses, the header can be evaluated simply by removing the commas and proceeding with the evaluation rules.
The No-tag-list production describes a series of state tokens and ETags. If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue. All untagged tokens apply to the resource identified in the Request-URI.
Example - no-tag-list production ["I am an ETag"]), (["I am another ETag"]) ]]>
The previous header would require that the resource identified in the Request-URI be locked with the specified lock token and in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag". To put the matter more plainly one can think of the previous If header as being in the form (or (and <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> ["I am an ETag"]) (and ["I am another ETag"])).
The tagged-list production may be used instead of the no-tag-list production, in order to scope each token to a specific resource. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any. All clauses must be evaluated. If the state of the resource named in the tag does not match any of the associated state lists then the request MUST fail with a 412 (Precondition Failed). The tagged-list production MUST NOT be used together with the no-tag-list production, either in the same If header or in a continuation. The same URI MUST NOT appear more than once in a resource production in an If header.
>>Request ( [W/"A weak ETag"]), (["strong ETag"]), (["another strong ETag"]) ]]>
In this example http://www.example.com/resource1 is being copied to http://www.example.com/resource2. When the method is first applied to http://www.example.com/resource1, resource1 must be in the state specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag". That is the only success condition since the resource http://www.example.com/random never has the method applied to it (the only other resource listed in the If header) and http://www.example.com/resource2 is not listed in the If header.
Every state token or ETag is either current, and hence describes the state of a resource, or is not current, and does not describe the state of a resource. The boolean operation of matching a state token or ETag to the current state of a resource thus resolves to a true or false value. The "Not" production is used to reverse that value. The scope of the not production is the state-token or entity-tag immediately following it.
) ]]>
When submitted with a request, this If header requires that all operand resources must not be locked with urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked with urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092. The Not production is particularly useful with the "<DAV:no-lock>" state token. The clause "Not <DAV:no-lock>" MUST evaluate to true. Thus, any "OR" statement containing the clause "Not <DAV:no-lock>" MUST also evaluate to true.
When performing If header processing, the definition of a matching state token or entity tag is as follows. Identifying a resource: The resource is identified by the URI along with the token, in tagged list production, or by the Request-URI in untagged list production. Matching entity tag: Where the entity tag matches an entity tag associated with the identified resource. Matching state token: Where there is an exact match between the state token in the If header and any state token on the identified resource. A lock state token is considered to match if the resource is anywhere in the scope of the lock.
Example - Matching lock tokens with collection locks () ]]> For this example, the lock token must be compared to the identified resource, which is the 'specs' collection identified by the URL in the tagged list production. If the 'specs' collection is not locked or has a lock with a different token, the request MUST fail. If the 'specs' collection is locked (depth infinity) with that lock token, then this request could succeed, both because the If header evaluates to true, and because the lock token for the lock affecting the affected resource has been provided. Alternatively, a request where the 'rfc2518.txt' URL is associated with the lock token in the If header could also succeed.
Non-DAV aware proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: no-cache" request header MUST be used so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" request header MUST be used for the same reason.
Lock-Token = "Lock-Token" ":" Coded-URL
The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member. The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
Overwrite = "Overwrite" ":" ("T" | "F")
The Overwrite request header specifies whether the server should overwrite the state of a non-null destination resource during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the state of the destination resource is non-null. If the overwrite header is not included in a COPY or MOVE request then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of the If-Match: * header of HTTP/1.1, If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE. If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. All DAV compliant resources MUST support the Overwrite header.
TimeOut = "Timeout" ":" 1#TimeType TimeType = ("Second-" DAVTimeOutVal | "Infinite") DAVTimeOutVal = 1*digit
Clients may include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method. Timeout response values MUST use a Second value or Infinite. The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1. The timeout counter MUST be restarted if a refresh LOCK request is successful. The timeout counter SHOULD NOT be restarted at any other time. If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request. Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going off-line. A client MUST NOT assume that just because the time-out has expired the lock has been lost. Likewise, a client MUST NOT assume that just because the time-out has not expired, the lock still exists (and for this reason, clients are strongly advised to use ETags as well).
The following status codes are added to those defined in HTTP/1.1 .
The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed. Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.
The 207 (Multi-Status) status code provides status for multiple independent operations (see for more information).
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain the 'missing-lock-token' precondition element and corresponding 'href' in the error body.
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request which received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
These HTTP codes are not redefined, but this section serves as a reminder that these HTTP codes may be used in responses to WebDAV methods and clients must be appropriately prepared to handle them.
A server MAY use this status code in response to any request.
A server MAY use this status code in response to any request.
A server MAY use this status code in response to any request. Some possible reasons: the Host header is missing in any request The protocol version is HTTP/1.0 Any header is improperly formatted The request method line is improperly formatted
A server MAY use this status code in response to any request. An appropriate use example would be in response to a PUT request to a collection, if the server does not ever allow PUT to a collection.
A server MAY use this status code in response to any request. In base WebDAV, the 409 Conflict is most typically returned when a method that attempts to create a new resource must fail, because one of the collections that resource depends on does not exist. However, other types of conflicts are defined in specifications extending RFC2518.
Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or the "If" conditional header defined in this specification. If the request contains a conditional header, and if that condition fails to hold, then this error code MUST be returned unless some other error is returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this error.
This status code is used in HTTP 1.1 only for Request-URIs, because full URIs aren't used in other headers. WebDAV specifies full URLs in other headers, therefore this error may be used if the URI is too long in other locations as well. A server MAY use this status code in response to any request.
This status code is particularly useful to respond to requests that the server considers a denial-of-service attack, such as excessively large PROPFIND depth infinity requests or requests in quick succession. A server MAY use this status code in response to any request, provided that the request did not partially or completely succeed.
A Multi-Status response 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. The default 207 (Multi-Status) response body is a text/xml or application/xml HTTP entity that contains a single XML element called 'multistatus', which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element. The 207 status code itself MUST NOT be considered a success response, it is only completely successful if all 'response' elements inside contain success status codes. The body of a 207 Multi-Status response MUST contain a URL associated with each specific status code, so that the client can tell whether the error occurred with the source resource, destination resource or some other resource in the scope of the request.
Use of the Location header with the Multi-Status response is intentionally undefined. Note that this specification does not define a way to redirect requests for individual resources within the scope of a Multi-Status response. The server MAY always redirect the entire request by responding with a 300 level status response instead of a Multi-Status response.
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. If the URLs are absolute, then the server MUST ensure that the URLs have the same prefix (scheme, host, port, and path) as the URL of the requested resource. If the URLs are relative, they MUST be resolved against the Request-URI. When a Multi-Status body is returned in response to MOVE or COPY, relative URI 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. Servers MUST NOT return "." or ".." within an absolute or relative URI returned within a Multi-Status response. URLs for collections appearing in the results SHOULD end in a '/' character. If a server allows resource names to include characters that aren't legal in HTTP URL paths, these characters must be URI-escaped on the wire. For example, it is illegal to use a space character or double-quote in a URI. URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in this specification) are still subject to all URI rules, including forbidden characters.
, , , and define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses.
In this section, the final line of each section gives the element type declaration using the format defined in . The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). The "Extensibility" field discusses how the element may be extended in the future (or in existing extensions to WebDAV. All of the elements defined here may be extended by the addition of attributes and child elements not defined in this specification.
activelock DAV: Describes a lock on a resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
depth DAV: The value of the Depth header. "0" | "1" | "infinity" MAY be extended with attributes which SHOULD be ignored.
]]>
locktoken DAV: The lock token associated with a lock. The href contains a single lock token URI which refers to the lock. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockroot DAV: Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request. The href contains a URL with the address of the root of the lock. The server SHOULD include this in all DAV:lockdiscovery property values and the response to LOCK requests. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
timeout DAV: The number of seconds remaining before a lock expires. TimeType (defined in ). MAY be extended with attributes which SHOULD be ignored.
]]>
collection DAV: Identifies the associated resource as a collection. The DAV:resourcetype property of a collection resource MUST contain this element. It is normally empty but extensions may add sub-elements. MAY be extended with child elements or attributes which SHOULD be ignored if not recognized.
]]>
href DAV: 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 DAV: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. URI (See section 3.2.1 of ) MAY be extended with attributes which SHOULD be ignored.
<!ELEMENT href (#PCDATA)>
lockentry DAV: Defines the types of locks that can be used with the resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockinfo DAV: The 'lockinfo' XML element is used with a LOCK method to specify the type of lock the client wishes to have created. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
lockscope DAV: Specifies whether a lock is an exclusive lock, or a shared lock. SHOULD NOT be extended with child elements. MAY be extended with attributes which SHOULD be ignored.
]]>
exclusive DAV: Specifies an exclusive lock Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
shared DAV: Specifies a shared lock Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
locktype DAV: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
write DAV: Specifies a write lock. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
multistatus DAV: Contains multiple response messages. The 'responsedescription' element at the top level is used to provide a general message describing the overarching nature of the response. If this value is available an application may use it instead of presenting the individual response descriptions contained within the responses. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
response DAV: Holds a single response describing the effect of a method on resource and/or its properties. A particular 'href' value MUST NOT appear more than once as the child of a 'response' XML element under a 'multistatus' XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by href. There are, however, no requirements regarding ordering based on href values. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
propstat DAV: Groups together a prop and status element that is associated with a particular href element. The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
status DAV: Holds a single HTTP status-line status-line (status-line defined in Section 6.1 of ) MAY be extended with attributes which SHOULD be ignored.
]]>
responsedescription DAV: Contains a message that can be displayed to the user explaining the nature of the response. This XML element provides information suitable to be presented to a user. MAY be extended with attributes which SHOULD be ignored.
]]>
owner DAV: Provides information about the principal taking out a lock. Provides information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who owns a lock. This information is provided by the client, and may only be altered by the server if the owner value provided by the client is empty. MAY be extended with child elements, mixed content, text content or attributes. Structured content, for example one or more 'href' child elements containing URLs, is RECOMMENDED.
]]>
prop DAV: Contains properties related to a resource. A generic container for properties defined on resources. All elements inside a 'prop' XML element MUST define properties related to the resource. No other elements may be used inside of a 'prop' element. MAY be extended with attributes which SHOULD be ignored if not recognized. Any child element of this element must be considered to be a property name, however these are not restricted to the property names defined in this document or other standards.
]]>
propertyupdate DAV: Contains a request to alter the properties on a resource. This XML element is a container for the information required to modify the properties on the resource. This XML element is multi-valued. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
remove DAV: Lists the DAV properties to be removed from a resource. Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a 'prop' XML element inside of a 'remove' XML element MUST be empty, as only the names of properties to be removed are required. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
set DAV: Lists the DAV property values to be set for a resource. The 'set' XML element MUST contain only a prop XML element. The elements contained by the prop XML element inside the 'set' XML element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists then its value is replaced. Language tagging information appearing in the scope of the 'prop' element (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
<!ELEMENT set (prop) >
propfind DAV: Specifies the properties to be returned from a PROPFIND method. Four special elements are specified for use with 'propfind': 'prop', 'dead-props', 'allprop' and 'propname'. If 'prop' is used inside 'propfind' it MUST NOT contain property values. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized, as long as it still contains one of the required elements.
]]>
allprop DAV: Specifies that all names and values of dead properties and the live properties defined by this document existing on the resource are to be returned. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
propname DAV: Specifies that only a list of property names on the resource is to be returned. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
dead-props DAV: Specifies that all dead properties, names and values, should be returned in the response. Normally empty, but MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
error DAV: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. When an error response contains a body in WebDAV, the body is in XML with the root element 'error'. The 'error' element SHOULD include a standard precondition element defined in this specification or another specification. The 'error' tag MAY include custom error tags (in custom XML namespaces) which a client can safely ignore. Contains any XML element Fully extensible with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
For DAV properties, the name of the property is also the same as the name of the XML element that contains its value. In the section below, the final line of each section gives the element type declaration using the format defined in . The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses or PROPPATCH requests. 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.
creationdate DAV: Records the time and date the resource was created. date-time (defined in , see the ABNF in section 5.6.) MAY be protected. Some servers allow DAV:creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use DAV:getetag instead). This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY. The DAV: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). MAY contain attributes which SHOULD be ignored if not recognized.
]]>
displayname DAV: Provides a name for the resource that is suitable for presentation to a user. Any text Possibly This property value SHOULD be preserved in local COPY and MOVE operations. It MAY be attempted to be set in a COPY operation to a remote server. The DAV:displayname property should be defined on all DAV compliant resources. If present, the property contains a description of the resource that is suitable for presentation to a user. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontentlanguage DAV: Contains the Content-Language header returned by a GET without accept headers language-tag (language-tag is defined in section 14.13 of ) SHOULD NOT be protected, so that clients can reset the language. This property value SHOULD be preserved in local COPY and MOVE operations. It SHOULD be attempted to be set in a COPY operation to a remote server. The DAV:getcontentlanguage property MUST be defined on any DAV compliant resource that returns the Content-Language header on a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontentlength DAV: Contains the Content-Length header returned by a GET without accept headers. content-length (see section 14.14 of ) SHOULD be protected so clients cannot set to misleading values The DAV:getcontentlength property MUST be defined on any DAV compliant resource that returns the Content-Length header in response to a GET. This property value is dependent on the size of the destination resource, not the value of the property on the source resource. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getcontenttype DAV: Contains the Content-Type header returned by a GET without accept headers. media-type (defined in section 3.7 of ) SHOULD NOT be protected, so clients may fix this value This property value SHOULD be preserved in local COPY and MOVE operations. In a remote COPY operation that is implemented through a PUT request, the PUT request must have the appropriate Content-Type header. This property MUST be defined on any DAV compliant resource that returns the Content-Type header in response to a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getetag DAV: Contains the ETag header returned by a GET without accept headers. entity-tag (defined in section 3.11 of ) MUST be protected because this value is created and controlled by the server. This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Refer to RFC2616 for a complete definition of the semantics of an ETag. Note that changes in properties or lock state MUST not cause a resource's ETag to change. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
getlastmodified DAV: Contains the Last-Modified header returned by a GET method without accept headers. rfc1123-date (defined in section 3.3.1 of ) SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked. This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this is preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Thus, clients cannot rely on this value for caching and SHOULD use ETags. Note that the last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body. The DAV:getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET. MAY contain attributes which SHOULD be ignored if not recognized.
]]>
lockdiscovery DAV: Describes the active locks on a resource MUST be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH. The value of this property depends on the lock state of the destination, not on the locks of the source resource. Recall that locks are not moved in a MOVE operation. Returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there is one or more lock, an 'activelock' element appears for each lock on the resource. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized.
]]>
>>Request ]]>
>>Response http://www.example.com/container/ 0 Jane Smith Infinite urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 http://www.example.com/container/ HTTP/1.1 200 OK ]]> This resource has a single exclusive write lock on it, with an infinite timeout.
resourcetype DAV: Specifies the nature of the resource. SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH. Generally a COPY/MOVE of a resource results in the same type of resource at the destination. In a remote COPY, the source server SHOULD NOT attempt to set this property. MUST be defined on all DAV compliant resources. The default value is empty. MAY be extended with any child elements or attributes which SHOULD be ignored if not recognized. If the element contains the 'collection' child element plus additional unrecognized elements/attributes, it should generally be treated as a collection. If the element contains no recognized child elements it should be treated as a non-collection WebDAV-compliant resource.
Example: (fictional example to show extensibility) ]]>
supportedlock DAV: To provide a listing of the lock capabilities supported by the resource. MUST be protected. Servers determine what lock mechanisms are supported, not clients. This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination. Returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to see. MAY be extended with any child elements or attributes which SHOULD be ignored if not recognized.
]]>
>>Request ]]>
>>Response http://www.example.com/container/ HTTP/1.1 200 OK ]]>
The numerical status codes used in HTTP responses are not sufficiently granular or informative for all purposes. Some extensions to HTTP have used the error response body along with some status codes in order to provide additiona machine-readable response detail. The machine-readable codes are XML elements classified as preconditions (generally client error or failure to meet the conditions in order for the request to be considered) and postconditions (generally server error or failure to respond successfully to an otherwise valid request). The precondition or postcondition XML element appears inside an 'error' element which is the root of the XML body of the response. The 'error' root element or the precondition or postcondition elements MAY contain additional XML elements or attributes not defined in this specification. XML elements in error response bodies were not used in RFC2518, but were introduced in RFC2518bis. Thus, use of these informative elements is RECOMMENDED. Even if clients do not automatically recognize the error bodies they can be quite useful in interoperability testing and debugging. external-entities-forbidden DAV: 403 Forbidden (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.
]]>
requesturi-must-match-lock-token DAV: 400 Bad Request (precondition) -- A request may include a Lock-Token header to identify a lock for the purposes of an operation such as refresh LOCK or UNLOCK. However, if the Request-URI doe not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
]]>
missing-lock-token DAV: 400 Bad Request (precondition) -- If the server rejects a request because the request MUST have a lock token and is missing the lock token header or header value (e.g. on an UNLOCK request), the server SHOULD use this error. The 'missing-lock-token' precondition element MUST contain at least one URL of a locked resource for which a lock token was expected.
]]>
live-properties-not-preserved DAV: 409 Conflict (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server only supports some live properties in some parts of the repository, or simply has an internal error.
]]>
read-only-property DAV: 403 Forbidden (precondition) -- The client attempted to set a read-only property in a PROPPATCH (such as DAV:getetag).
]]>
propfind-infinite-depth-forbidden DAV: 403 Forbidden (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.
]]>
need-privileges DAV: 403 Forbidden (precondition) -- The currently authenticated user simply does not have the privileges required to do the requested operation (e.g. UNLOCK a lock created by someone else).
]]>
missing-lock-token DAV: 423 Locked (precondition) -- The request could not succeed because a lock token should have been provided. This element, if present, MUST contain the URL of a locked resource that prevented the request. In cases of MOVE, COPY and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only resonsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all.
]]>
All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language. This restriction also applies to the processing, by clients, of DAV property values where unknown XML elements SHOULD be ignored unless the property's schema declares otherwise. This restriction does not apply to setting dead DAV properties on the server where the server MUST record unknown XML elements. Additionally, this restriction does not apply to the use of XML where XML happens to be the content type of the entity body, for example, when used as the body of a PUT. Since XML can be transported as text/xml or application/xml, a DAV server MUST accept DAV method requests with XML parameters transported as either text/xml or application/xml, and a DAV client MUST accept XML responses using either text/xml or application/xml. XML DTD fragments are included for all the XML elements defined in this specification. However, legal XML may not be valid according to any DTD due to namespace usage and extension rules, so the DTD is only informational. A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.
A DAV compliant resource can advertise several classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource, and examining the "DAV" header which is returned. Note particularly that resources are spoken of as being compliant, rather than servers. That is because theoretically some resources on a server could support different feature sets. E.g. a server could have a sub-repository where an advanced feature like server was supported, even if that feature was not supported on all servers. Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies MUST be compliant with . A resource that is class 2 compliant must also be class 1 compliant, and a resource that is compliant with "bis" must also be class 1 compliant.
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document. Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the DAV:supportedlock property, the DAV:lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element. Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
A resource can explicitly advertise its support for the revisions to RFC2518 made in this document. In particular, this allows clients to use the Force-Authentication header on requests. Class 1 must be supported as well. Class 2 MAY be supported. A resource that supports bis MUST support: the Force-Authentication header. Any behavior that it supports, in the manner specified in this document, rather than in the manner specified in RFC2518, for all client requests. A server MAY use an older behavior for specific clients that are discovered to have interoperability problems with the requirements of this specification, but MUST NOT use an older behavior indiscriminately.
Example: DAV: 1, bis
In the realm of internationalization, this specification complies with the IETF Character Set Policy . In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 and UTF-16 encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in , as well as the XML declarations which provide charset identification information for MIME and XML processors. XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See Section 2.12 of for definitions of values and scoping. WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header. Names used within this specification fall into four categories: names of protocol elements such as methods and headers, names of XML elements, names of properties, and names of conditions. Naming of protocol elements follows the precedent of HTTP, using English names encoded in USASCII for methods and headers. Since these protocol elements are not visible to users, and are simply long token identifiers, they do not need to support multiple languages. Similarly, the names of XML elements used in this specification are not visible to the user and hence do not need to support multiple languages. WebDAV property names are qualified XML names (pairs of XML namespace name and local name). Although some applications (e.g., a generic property viewer) will display property names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name and namespace to a human-readable field when displaying the property name to a user. 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 to a user. We recommend that applications provide human-readable property names wherever feasible. For error reporting, we follow the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 (Locked)). While the possibility exists that a poorly crafted user agent would display this message to a user, internationalized applications will ignore this message, and display an appropriate message in the user's language and character set. Since interoperation of clients and servers does not require locale information, this specification does not specify any mechanism for transmission of this information.
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware. All of the security considerations of HTTP/1.1 (discussed in ) and XML (discussed in ) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication. A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send Basic authentication credentials in a WWW-Authenticate header unless the connection is secure. Examples of secure connections include a Transport Layer Security (TLS) connection employing a strong cipher suite with mutual authentication of client and server, or a connection over a network which is physically secure, for example, an isolated network in a building with restricted access. WebDAV applications MUST support the Digest authentication scheme . Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication which is useful in a wide range of scenarios.
Denial of service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial of service attacks on every part of a system's resources. The underlying storage can be attacked by PUTting extremely large files. Asking for recursive operations on large collections can attack processing time. Making multiple pipelined requests on multiple connections can attack network connections. WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.
WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.
When submitting a lock request a user agent may also submit an owner XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a DAV:lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the DAV:lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.
XML supports a facility known as "external entities", defined in Section 4.2.2 of , which instruct an XML processor to retrieve and include additional XML. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non-validating XML, such as the XML used in this specification, including an external XML entity is not required by XML. However, XML does state that an XML processor may, at its discretion, include the external XML entity. External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case significantly modifying its semantics, or exposing the XML processor to the security risks discussed in . Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server implementor chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the precondition defined above (external-entities-forbidden). There is also the scalability risk that would accompany a widely deployed application which made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any server which fields requests for the resource containing the external XML entity.
This specification requires the use of "A Universally Unique Identifier (UUID) URN Namespace" () for lock tokens, in order to guarantee their uniqueness across space and time. The security considerations for UUIDs do not apply because WebDAV does not assume that lock tokens are supposed to be hard to guess or require integrity. In addition, UUIDs MAY contain a IEEE 802 node ID, usually the host address. Since a WebDAV server will issue many locks over its lifetime, the use of node IDs might cause the WebDAV server to reveal its IEEE 802 address. Several risks are related to this: It is possible to track the movement of hardware from subnet to subnet. It may be possible to identify the manufacturer of the hardware running a WebDAV server. It may be possible to determine the number of each type of computer running WebDAV.
HTTP has the ability to host scripts which are executed on client machines. These scripts can be used to read another user's cookies and therefore may provide an attacker the ability to use another user's session, assume their identity temporarily and gain access to their resources. Other attacks are also possible with client-executed scripts. WebDAV may worsen this situation only by making it easier for a Web server to host content provided by many different authors (making it harder to trust the content providers) and to host content with restricted access alongside public pages (see particularly RFC3744). HTTP servers may mitigate some of these threats by filtering content in areas where many authors contribute pages -- the server could, for example, remove script from HTML pages. This vulnerability should provide yet another reason for server implementors and administrators not to replace authentication mechanisms with cookie-based session tokens if there's any sensitive information relying on the authenticated identity. HTTP and WebDAV client implementors might consider locking down the use of scripts and cookies based on these considerations.
This specification defines two URI schemes: the "opaquelocktoken" scheme defined in , and the "DAV" URI scheme, which historically was used in RFC2518 to disambiguate WebDAV property and XML element names and which continues to be used for that purpose in this specification and others extending WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by the IETF. XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names or element names.
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work. Contributors to RFC2518 Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable, both in helping the formation of the working group and in patiently coaching the authors along the way. In so many ways he has set high standards we have toiled to meet. The contributions of Judith Slein in clarifying the requirements, and in patiently reviewing draft after draft, both improved this specification and expanded our minds on document management. We would also like to thank John Turner for developing the XML DTD. The authors of RFC2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter and D. Jensen. Although their names had to be removed due to IETF author count restrictions they can take credit for the majority of the design of WebDAV. Additional Contributors to This Specification Valuable contributions to RFC2518 bis came from some already named. New contributors must also be gratefully acknowledged. Julian Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out specific text on the list or in meetings. Ilya Kirnos supplied text for Force-Authentication header. Joe Hildebrand contributed as co-chair. Barry Lind described an additional security consideration. Jason Crawford tracked issue status for this document for a period of years, followed by Elias Sinderson.
Y. Y. Goland, Microsoft Corporation, One Microsoft Way, Redmond, WA 98052-6399. Email: yarong@microsoft.com. E. J. Whitehead, Jr., Dept. Of Information and Computer Science, University of California, Irvine, Irvine, CA 92697-3425. Email: ejw@ics.uci.edu. A. Faizi, Netscape, 685 East Middlefield Road, Mountain View, CA 94043. Email: asad@netscape.com. S. R. Carter, Novell, 1555 N. Technology Way, M/S ORM F111, Orem, UT 84097-2399. Email: srcarter@novell.com. D. Jensen, Novell, 1555 N. Technology Way, M/S ORM F111, Orem, UT 84097-2399. Email: dcjensen@novell.com.
&rfc2119; &rfc2277; &rfc2518; &rfc2616; &rfc3339; &rfc3986; &rfc4122; Extensible Markup Language (XML) 1.0 (Third Edition) Textuality and Netscape
tbray@textuality.com
Microsoft
jeanpa@microsoft.com
University of Illinois at Chicago and Text Encoding Initiative
cmsmcq@uic.edu
Sun Microsystems
eve.maler@east.sun.com
francois@yergeau.com
Namespaces in XML Textuality
tbray@textuality.com
Hewlett-Packard Company
dmh@corp.hp.com
Microsoft
andrewl@microsoft.com
HTTP Authentication: Basic and Digest Access Authentication Northwestern University, Department of Mathematics
john@math.nwu.edu
Verisign Inc.
pbaker@verisign.com
AbiSource, Inc.
jeff@AbiSource.com
Agranat Systems, Inc.
lawrence@agranat.com
Microsoft Corporation
paulle@microsoft.com
Netscape Communications Corporation Open Market, Inc.
stewart@OpenMarket.com
XML Media Types IBM Tokyo Research Laboratory
mmurata@trl.ibm.co.jp
 simonstl.com
simonstl@simonstl.com
 Skymoon Ventures
dan@dankohn.com
 UTF-8, a transformation format of ISO 10646 Alis Technologies
fyergeau@alis.com
 &rfc2291; &rfc3253; &rfc3744;
XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.
XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of white space, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements. There is no kindness in accepting illegal combinations of XML elements. At best it will cause an unwanted result and at worst it can cause real damage.
The following request body for a PROPFIND method is illegal.
]]>
The definition of the propfind element only allows for the allprop or the propname element, not both. Thus the above is an error and must be responded to with a 400 (Bad Request). Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop. Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
]]>
To understand why a 400 (Bad Request) is returned let us look at the request body as the server unfamiliar with expired-props sees it.
]]>
As the server does not understand the 'expired-props' element, according to the WebDAV-specific XML processing rules specified in , it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal. Please note that had the extension been additive it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
*boss* ]]>
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with 'leave-out', the only result would be that the 'leave-out' element would be ignored and a propname would be executed.
The PUT and DELETE methods are defined in HTTP and thus may be used by HTTP clients, but the responses to PUT and DELETE have been extended in this specification, so some special consideration on backward compatibility is worthwhile. First, if a PUT or DELETE request includes a header defined in this specification (Depth or If), the server can assume the request comes from a WebDAV-compatible client. The server may even be able to track a number of requests across a session and know that a client is a WebDAV client. However, this kind of detection may not be necessary. Since any HTTP client ought to handle unrecognized 400-level and 500-level status codes as errors, the following new status codes should not present any issues: 422, 423 and 507. 424 is also a new status code but it appears only in the body of a Multistatus response. So, for example, if a HTTP client attempted to PUT or DELETE a locked resource, the 423 Locked response ought to result in a generic error presented to the user. The 102 Processing response code is new, and indicates that the client may wish to extend its normal timeout period. However, the choice to extend the timeout period is entirely optional, and thus a HTTP client receiving a 102 Processing status response may time out anyway, with no avoidable adverse effects. The 207 Multistatus response is interesting because a HTTP client issuing a DELETE request to a collection might interpret a 207 response as a success, even though it does not realize the resource is a collection and cannot understand that the DELETE operation might have been a complete or partial failure. Thus, a server MAY choose to treat a DELETE of a collection as an atomic operation, and use either 204 No Content in case of success, or some appropriate error response (400 or 500 level) depending on what the error was. This approach would maximize backward compatibility. However, since interoperability tests and working group discussions have not turned up any instances of HTTP clients issuing a DELETE request against a WebDAV collection, this concern may be more theoretical than practical. Thus, servers MAY instead choose to treat any such DELETE request as a WebDAV request, and send a 207 Multistatus containing more detail about what resources could not be deleted.
The 'opaquelocktoken' URI scheme was defined in RFC2518 (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time. This scheme has been obsoleted by , but is re-defined here for clarity. A server MAY generate one ore more UUIDs to use with the 'opaquelocktoken' scheme as lock tokens. A server MAY reuse a UUID with extension characters added. If the server does this then the algorithm generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID. OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID. Note that white space (LWS) is not allowed between elements of this production. Extension = path ; path is defined in section 3.3 of
This section describes changes that are likely to result in implementation changes due to tightened requirements or changed behavior. A more complete list of changes has been published in a separate document.
Tightened requirements for storing property values when "xml:lang" appears and also when values are XML fragments (specifically on preserving prefixes, namespaces and whitespace.) Several tightened requirements for general response handling, including response bodies for use with errors, use of Date header, ETag and Location header. Tightened requirements for URL construction in PROPFIND responses. Tightened requirements for checking identity of lock owners during operations affected by locks. Tightened requirements for copying properties and moving properties. Tightened requirements on preserving owner field in locks. Added "lockroot" element to lockdiscovery information. New value for "DAV:" header to advertise support for this specification. Tightened requirement for "Destination:" header to work with path values New "Force-Authentication:" header added. Several changes for "If:" header, including requirement to accept commas and "DAV:no-lock" state token. Support for UTF-16 now required (ref). Removed definition of "source" property and special handling for dynamic resources Replaced lock-null resources with simpler locked empty resources. Encouraged servers to change ETags only when body of resource changes.
Tightened requirements for supporting WebDAV collections within resources that do not support WebDAV (e.g. servlet containers). Redefined 'allprop' PROPFIND requests so that the server does not have to return all properties. Required to handle empty multistatus responses in PROPFIND responses No more "propertybehavior" specification allowed in MOVE and COPY requests Support for UTF-16 now required (ref). Removed definition of "source" property and special handling for dynamic resources.
Specified that a successful LOCK request to an unmapped URL creates a new, empty locked resource. Resolved UNLOCK_NEEDS_IF_HEADER by clarifying that only Lock-Token header is needed on UNLOCK. Added on preconditions and postconditions and defined a number of preconditions and postconditions. The 'missing-lock-token' precondition resolves the REPORT_OTHER_RESOURCE_LOCKED issue. Added example of matching lock token to URI in the case of a collection lock in the If header section. Removed ability for Destination header to take "abs_path" in order to keep consistent with other places where client provides URLs (If header, href element in request body) Clarified the href element - that it generally contains HTTP URIs but not always. Attempted to fix the BNF describing the If header to allow commas Clarified presence of Depth header on LOCK refresh requests.
Added text to "COPY and the Overwrite Header" section to resolve issue OVERWRITE_DELETE_ALL_TOO_STRONG. Added text to "HTTP URL Namespace Model" section to provide more clarification and examples on what consistency means and what is not required, to resolve issue CONSISTENCY. Resolve DEFINE_PRINCIPAL by importing definition of principal from RFC3744. Resolve INTEROP_DELETE_AND_MULTISTATUS by adding appendix 3 discussing backward-compatibility concerns. Resolve DATE_FORMAT_GETLASTMODIFIED by allowing only rfc1123-date, not HTTP-date for getlastmodified. Resolve COPY_INTO_YOURSELF_CLARIFY by adding sentence to first para. of COPY section. Confirm that WHEN_TO_MULTISTATUS_FOR_DELETE_1 and WHEN_TO_MULTISTATUS_FOR_DELETE_2 are resolved and tweak language in DELETE section slightly to be clearly consistent. More text clarifications to deal with several of the issues in LOCK_ISSUES. This may not completely resolve that set but we need feedback from the originator of the issues at this point. Resolved COPY_INTO_YOURSELF_CLARIFY with new sentence in Copy For Collections section. Double checked that LEVEL_OR_CLASS is resolved by using class, not level. Further work to resolve IF_AND_AUTH and LOCK_SEMANTICS, clarifying text on using locks and being authenticated. Added notes on use of 503 status response to resolve issue PROPFIND_INFINITY Removed section on other uses of Metadata (and associated references) Added reference to RFC4122 for lock tokens and removed section on generating UUIDs Explained that even with language variation, a property has only one value (section 4.5). Added section on lock owner (7.1) and what to do if lock requested by unauthenticated user Removed section 4.2 -- justification on why to have metadata, not needed now Removed paragraph in section 5.2 about collections with resource type "DAV:collection" but which are non-WebDAV compliant -- not implemented.
Added security considerations section on scripts and cookie sessions, suggested by Barry Lind Clarified which error codes are defined and undefined in MultiStatus Moved opaquelocktoken definition to an appendix and refer to RFC4122 for use of 'urn:uuid:' URI scheme; fix all lock token examples to use this. Multi-status responses contain URLs which MUST either be absolute (and begin with the Request-URI or MUST be relative with new limitations. (bug 12) Moved status code sections before example sections within PROPFIND section for section ordering consistency. Clarified use of Location header with Multi-Status Bugzilla issue resolutions: bugs 9, 12, 14, 19, 20, 29, 30, 34, 36, 102 and 172.
Bugzilla editorial issues: bugs 30, 57, 63, 68, 88, 89, 168, 180, 182, 185, 187. More clarity between URL namespaces and XML namespaces, particularly at the beginning of paragraphs using the word namespace More consistency in referring to properties with the namespace, as in "DAV:lockdiscovery", and referring to XML element names in single quotes, e.g. 'allprop' element. Figure (example) formatting fixes Bugzilla issues: bugs 24, 37, 39, 43, 45
--------------020605060908010606040101 Content-Type: text/plain; name="diffs" Content-Disposition: inline; filename="diffs" Content-Transfer-Encoding: 7bit Index: draft-ietf-webdav-rfc2518bis-latest.xml =================================================================== RCS file: /var/cvsroot/xml2rfc/draft-ietf-webdav-rfc2518bis-latest.xml,v retrieving revision 1.10 diff -r1.10 draft-ietf-webdav-rfc2518bis-latest.xml 4d3 < 7d5 < 9d6 < 17,18d13 < < 26c21 < --- > 30,32c25 < < HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis < --- > HTTP Extensions for Distributed Authoring - WebDAV 62c55 < RFC2518 was published in February 1998, and this draft makes minor --- > RFC2518 was published in February 1999, and this document makes minor 137c130 < WebDAV uses for property names and some values, and also uses --- > WebDAV uses XML for property names and some values, and also uses 272,273c265 < information either in an < request entity body, or in an HTTP header. The use of XML to encode --- > information either in an XML request entity body, or in an HTTP header. The use of XML to encode 286c278 < The XML namespace extension --- > The XML namespace extension 1120,1121c1112,1113 < XML parsers that are compliant with < and XML Namespaces. All --- > XML parsers that are compliant with > and . All 2601c2593 <
--- > 2603d2594 < 2607,2615c2598,2601 < < < Current State Shared Lock Request Exclusive Lock Request < ---------------------------------------------------------------- < None True True < Shared Lock True False < Exclusive Lock False False* < < --- > Current lock state / Lock requestShared LockExclusive Lock > NoneTrueTrue > Shared LockTrueFalse > Exclusive LockFalseFalse* 2621,2622c2607 <
< --- > 2624d2608 < 2778,2779c2762,2763 < urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4< < /D:href> --- > >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 2783,2784c2767 < >http://example.com/workspace/webdav/proposal.doc< < /D:href> --- > >http://example.com/workspace/webdav/proposal.doc 3718c3701 < . The --- > . The 4230c4213 < declaration using the format defined in . --- > declaration using the format defined in . 4903c4886 < encoded, at minimum, using the UTF-8 and UTF-16 encodings of --- > encoded, at minimum, using the UTF-8 and UTF-16 encodings of 4906c4889 < Content-Type header, as defined in , as well as the XML --- > Content-Type header, as defined in , as well as the XML 4914c4897 < language of its content and attributes. See for --- > language of its content and attributes. See Section 2.12 of for 4921c4904 < strongly encouraged to read "XML Media Types" for --- > strongly encouraged to read "XML Media Types" for 4974c4957 < ) also apply to WebDAV. In --- > ) also apply to WebDAV. In 5007c4990 < . Since Digest authentication verifies that both parties to --- > . Since Digest authentication verifies that both parties to 5091c5074 < section 4.2.2 of , which instruct an XML processor to --- > Section 4.2.2 of , which instruct an XML processor to 5107c5090 < XML processor to the security risks discussed in . --- > XML processor to the security risks discussed in . 5307d5289 < &rfc2069; 5310d5291 < &rfc2279; 5316d5296 < &w3cXMLNS; 5318,5322c5298,5366 < < < Extensible Markup Language (XML) 1.0 (Third Edition) < < Textuality and Netscape --- > > > Extensible Markup Language (XML) 1.0 (Third Edition) > > Textuality and Netscape >
> tbray@textuality.com >
> > > Microsoft >
> jeanpa@microsoft.com >
> > > University of Illinois at Chicago and Text Encoding Initiative >
> cmsmcq@uic.edu >
> > > Sun Microsystems >
> eve.maler@east.sun.com >
> > > >
> francois@yergeau.com >
> > > > > > > > > Namespaces in XML > > Textuality >
> tbray@textuality.com >
> > > Hewlett-Packard Company >
> dmh@corp.hp.com >
> > > Microsoft >
> andrewl@microsoft.com >
> > > > > > > > > HTTP Authentication: Basic and Digest Access Authentication > > Northwestern University, Department of Mathematics 5324c5368 < tbray@textuality.com --- > john@math.nwu.edu 5327,5328c5371,5372 < < Microsoft --- > > Verisign Inc. 5330c5374 < jeanpa@microsoft.com --- > pbaker@verisign.com 5333,5334c5377,5378 < < University of Illinois at Chicago and Text Encoding Initiative --- > > AbiSource, Inc. 5336c5380 < cmsmcq@uic.edu --- > jeff@AbiSource.com 5339,5340c5383,5384 < < Sun Microsystems --- > > Agranat Systems, Inc. 5342c5386 < eve.maler@east.sun.com --- > lawrence@agranat.com 5345,5346c5389,5390 < < --- > > Microsoft Corporation 5348c5392 < francois@yergeau.com --- > paulle@microsoft.com 5351,5355c5395,5441 < < < < < --- > > Netscape Communications Corporation > > > Open Market, Inc. >
> stewart@OpenMarket.com >
> > > > > > > > > XML Media Types > > IBM Tokyo Research Laboratory >
mmurata@trl.ibm.co.jp
> > > simonstl.com >
simonstl@simonstl.com
> > > Skymoon Ventures >
dan@dankohn.com
> > > > > > > > > UTF-8, a transformation format of ISO 10646 > > Alis Technologies >
fyergeau@alis.com
> > > > > > > 5361d5446 < &rfc2376; --------------020605060908010606040101-- From w3c-dist-auth-request@frink.w3.org Thu Nov 24 08:34:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHFV-000419-53 for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 08:34:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00100 for ; Thu, 24 Nov 2005 08:34:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfHE9-0002ej-PG for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 13:33:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfHE4-0002e5-Nl for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 13:33:24 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EfHE1-0008SX-UB for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 13:33:24 +0000 Received: (qmail invoked by alias); 24 Nov 2005 13:32:16 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 24 Nov 2005 14:32:16 +0100 X-Authenticated: #1915285 Message-ID: <4385C0A2.4030004@gmx.de> Date: Thu, 24 Nov 2005 14:31:14 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EfHE1-0008SX-UB bdacba94020d12063e605a090a256040 X-Original-To: w3c-dist-auth@w3.org Subject: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/4385C0A2.4030004@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10602 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 13:33:29 +0000 Content-Transfer-Encoding: 7bit Hi, two more things. 1) Next call is *tomorrow*, Friday, 9am Pacific time (2005-11-25T17:00Z). 2) We also talked about issue 13 (): I'd like to clarify that yes, I also do prefer resources that support strong ETags, and do that upon PUT. I also realize that a huge class of clients will have trouble synchronizing when a server behaves differently. On the other hand, WebDAV is *not* a remote file system protocol. This is important! There is a big spectrum of Web servers that may have WebDAV support, and those that effectively can be used as a file system replacement are only a subset. Baking new requirements into the base spec that would make other servers non-compliant is IMHO an extremely bad idea. For example, vendors (Software AG, Oracle?) have implemented (or may be implementing) WebDAV on top of XML-based stores. These stores may support strong ETags, but not guarantee octet-for-octet equivalence between those things you PUT, and those you'll GET later. This is OK in HTTP, and it currently is in WebDAV. Do we really want to make it impossible to run WebDAV on top of these stores??? So what I would propose is to a) agree on a certain set of server features that those clients expect (strong ETag on PUT, octet-for-octet identity of representations, ...), then b) define a profile for WebDAV that covers this, and a simple way for clients to discover whether any given resource supports this. IMHO this definition should go into a separate document. This will also reduce the amount of open issues on RFC2518bis for now. Best regards, Julian From Quinot@goosegarb.com Thu Nov 24 09:20:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHxU-0003a5-OY for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 09:20:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05497 for ; Thu, 24 Nov 2005 09:19:40 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfIGZ-0007h8-DX for webdav-archive@ietf.org; Thu, 24 Nov 2005 09:40:03 -0500 Received: from c-71-194-103-76.hsd1.il.comcast.net ([71.194.103.76] helo=-1213166472) by mx2.foretec.com with smtp (Exim 4.24) id 1EfHxP-0004Sw-5Z for webdav-archive@ietf.org; Thu, 24 Nov 2005 09:20:16 -0500 Received: from goosegarb.com (-1212678720 [-1212563496]) by c-71-194-103-76.hsd1.il.comcast.net (Qmailv1) with ESMTP id C21B226F05 for ; Thu, 24 Nov 2005 09:12:24 -0500 Date: Thu, 24 Nov 2005 09:12:24 -0500 From: Doctor X-Mailer: The Bat! (v2.00.2) Personal X-Priority: 3 Message-ID: <8902511594.20051124091224@goosegarb.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------994D3B3A23A3958" X-Virus-Scanned: by amavisd-milter at c-71-194-103-76.hsd1.il.comcast.net X-Spam-Score: 1.2 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------994D3B3A23A3958 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlangra $3.3 Levietra $3.3 Ciaxlis $3.7 Imitqrex $16.4 Flomfax $2.2 Ultrqam $0.78 Vioyxx $4.75 Ambdien $2.2 Valaium $0.97 Xanaqx $1.09 Souma $3 Meriydia $2.2 visit our website http://asciatini.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals qwefgfgjs RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------994D3B3A23A3958 Content-Type: text/html Content-Transfer-Encoding: 7bit Lelvitra - $3.3
Cialits - $3.7
Imkitrex - $16.4
Fluomax - $2.2
Ulctram - $0.78
Vijoxx - $4.75
Amebien - $2.2
Vadlium - $0.97
Xajnax - $1.09
Sloma - $3
Mjeridia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

qwefgfgjs RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------994D3B3A23A3958-- From w3c-dist-auth-request@frink.w3.org Thu Nov 24 10:33:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJ6M-0001q0-FZ for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 10:33:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17289 for ; Thu, 24 Nov 2005 10:32:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJ59-0001it-Q7 for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 15:32:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfJ54-0001i5-Id for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 15:32:14 +0000 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1EfJ51-0004QB-2d for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 15:32:13 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 24 Nov 2005 07:31:52 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="678285574:sNHT32965328" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAOFVns2009466 for ; Thu, 24 Nov 2005 07:31:50 -0800 (PST) Received: from 10.21.114.12 ([10.21.114.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 15:32:46 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 07:31:54 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Twice Weekly Conference Call Thread-Index: AcXxDDKOcQpwiFz/EdqD+AARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.71.176.70 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfJ51-0004QB-2d 6f3f49b841fb43cf8059f5778799edbf X-Original-To: w3c-dist-auth@w3.org Subject: Twice Weekly Conference Call X-Archived-At: http://www.w3.org/mid/BFAB1CEA.61FFD%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10603 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 15:32:19 +0000 Content-Transfer-Encoding: 7bit We made reasonable progress on the last 3 hour conference call so we are going to try to have a bunch of them between now and the end of the year. Date/Time: Wednesday and Thursday at 9:00 AM America/Los_Angeles Length: 180 minutes Meeting ID: 251807 Phone Numbers: 1-866-MEETME9 (US Toll-free) 1-650-260-9030 (Local/International) For Cisco MeetingPlace Help Desk assistance, please call: 866-631-5313 (US Toll-free) or 408-450-7637 (Local/International) or email mailto:at.help@meetingplace.net. From w3c-dist-auth-request@frink.w3.org Thu Nov 24 10:34:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJ7c-00028n-4N for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 10:34:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17450 for ; Thu, 24 Nov 2005 10:34:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJ70-0002Cz-IX for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 15:34:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfJ70-0002Bt-01 for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 15:34:14 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by maggie.w3.org with esmtp (Exim 4.50) id 1EfJ6v-0000vL-Kt for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 15:34:12 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2005 07:34:04 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="369840538:sNHT23140028" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAOFY4CJ022914; Thu, 24 Nov 2005 07:34:04 -0800 (PST) Received: from 10.21.114.12 ([10.21.114.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 15:35:01 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 07:34:09 -0800 From: Cullen Jennings To: , WebDav Message-ID: Thread-Topic: [Bug 12] Destination header "consistent" Thread-Index: AcXxDIMFwYN1slz/EdqD+AARJEEJ/A== In-Reply-To: <200511231833.jANIXIOO008339@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.71.176.72 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EfJ6v-0000vL-Kt 6603b2100f8c78568756e25793f1029f X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/BFAB1D71.61FFF%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10604 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 15:34:14 +0000 Content-Transfer-Encoding: 7bit Can someone check if this is in the right state - this may have been my mess up when I did not understand that Bugzilla auto advanced to next bug. On 11/23/05 10:33 AM, "bugzilla@soe.ucsc.edu" wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 > > fluffy@cisco.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REOPENED |NEW > > > > > > ------- 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@frink.w3.org Thu Nov 24 10:38:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJB9-0003IY-9V for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 10:38:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17731 for ; Thu, 24 Nov 2005 10:37:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJAW-0003Gr-Mr for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 15:37:52 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfJAW-0003GJ-2i for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 15:37:52 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfJAP-0000A9-E4 for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 15:37:50 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2005 07:37:28 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="234055941:sNHT2530423710" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAOFbPOp008032; Thu, 24 Nov 2005 07:37:26 -0800 (PST) Received: from 10.21.114.12 ([10.21.114.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 15:38:23 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 07:37:30 -0800 From: Cullen Jennings To: , WebDav Message-ID: Thread-Topic: [Bug 160] IF_HEADERS_CAN_GET_LONG Thread-Index: AcXxDPrTOXGixl0AEdqD+AARJEEJ/A== In-Reply-To: <200511191220.jAJCKqRD022153@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfJAP-0000A9-E4 5295b41f5d187a3162bb113570d5b503 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/BFAB1E3A.62005%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10605 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 15:37:52 +0000 Content-Transfer-Encoding: 7bit Just to educate me, what is the limit on header length and where is that defined? On 11/19/05 4:20 AM, "bugzilla@soe.ucsc.edu" wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=160 > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-19 > 04:20 ------- > bis changes the grammar with the intent to allow multi-line If headers, but I > think it fails to do that properly. See also bug 171 > () > > > > ------- 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@frink.w3.org Thu Nov 24 10:40:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJDG-0003QU-Sr for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 10:40:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17851 for ; Thu, 24 Nov 2005 10:40:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJCf-00041Q-Sm for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 15:40:05 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfJCf-000407-6L for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 15:40:05 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EfJCW-0001JA-59 for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 15:40:03 +0000 Received: (qmail invoked by alias); 24 Nov 2005 15:39:46 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 24 Nov 2005 16:39:46 +0100 X-Authenticated: #1915285 Message-ID: <4385DE7B.1090003@gmx.de> Date: Thu, 24 Nov 2005 16:38:35 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfJCW-0001JA-59 8f543093ccef1931438dd479b7189680 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/4385DE7B.1090003@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10606 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 15:40:05 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Can someone check if this is in the right state - this may have been my mess > up when I did not understand that Bugzilla auto advanced to next bug. Hi Cullen, I think the right thing would be to set it back to "reopened". Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 10:57:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJTv-0001xb-Na for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 10:57:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19726 for ; Thu, 24 Nov 2005 10:57:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJT6-0002Nr-R8 for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 15:57:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfJT3-0002Mf-AD for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 15:57:01 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1EfJT2-0007W8-Gq for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 15:57:01 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EfJSg-0002Y2-Kg for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 15:56:47 +0000 Received: (qmail invoked by alias); 24 Nov 2005 15:56:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 24 Nov 2005 16:56:36 +0100 X-Authenticated: #1915285 Message-ID: <4385E26A.2070807@gmx.de> Date: Thu, 24 Nov 2005 16:55:22 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfJSg-0002Y2-Kg 5d3fc1d8b86706997cb1e448bebb134d Received-SPF: fail (lisa.w3.org: domain of julian.reschke@gmx.de does not designate 133.27.228.225 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/4385E26A.2070807@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10607 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 15:57:04 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Just to educate me, what is the limit on header length and where is that > defined? I don't think that there is a defined limit (see ). The concern was that clients/proxies/servers may indeed be limited, and because the "If" header in theory can get very complex, that would become a problem. What I would like to understand *before* changing RFC2518 is whether the potential implementation limits are in header length, or in header *line* length. In the latter case, the solution would be to just use CRLF inside header lines, as allowed by RFC2616. Did anybody actually ever experience a problem? If not, I'd recommend just leave things as they are in RFC2518. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:01:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJX6-0002nX-BH for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:01:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20093 for ; Thu, 24 Nov 2005 11:00:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJWQ-0004Ys-R1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:00:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfJWP-0004RM-0e for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:00:29 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfJWM-0002bd-KC for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:00:29 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2005 08:00:04 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="234058953:sNHT24721020" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAOG026a004024; Thu, 24 Nov 2005 08:00:03 -0800 (PST) Received: from 10.21.114.12 ([10.21.114.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 16:00:59 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 08:00:06 -0800 From: Cullen Jennings To: , WebDav Message-ID: Thread-Topic: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it Thread-Index: AcXxECMQYXwUzF0DEdqD+AARJEEJ/A== In-Reply-To: <200511240202.jAO22HWE008901@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1EfJWM-0002bd-KC 1637828ddd60e5b2cfd5e25efdac0fd0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/BFAB2386.62012%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10608 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:00:30 +0000 Content-Transfer-Encoding: 7bit I think the problem we are having here is a confusion about IANA and I think I can help resolve it. I believe we all are fine with the text in section 6. (If we are not, well then the rest of this may be mute). Note this text does not stop someone from using opaquelocktoken URI. Julian would like to make sure that the IANA registration of opaquelocktoken at http://www.iana.org/assignments/uri-schemes does not go away. My recommendation is that you remove Apendix C from the draft and that you change the IANA consideration to say that this specification does not require any IANA actions. This will not cause the opaquelocktoken to be removed from IANA. It will not deprecate it. It will not make it illegal to use. It will not mean that servers can't use it. Cullen On 11/23/05 6:02 PM, "bugzilla@soe.ucsc.edu" wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > AssignedTo|lisa@osafoundation.org |julian.reschke@greenbytes.de > Status|REOPENED |NEW > > > > ------- Additional Comments From lisa@osafoundation.org 2005-11-23 18:02 > ------- > This bug is only assigned to me because the bug was reopened. Assigning to > Julian to get confirmation of the consensus if that's at issue. > > > > ------- 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@frink.w3.org Thu Nov 24 11:09:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJfD-0006o5-G3 for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:09:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21377 for ; Thu, 24 Nov 2005 11:08:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJeT-0007Wa-US for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:08:49 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfJeQ-0007Uy-Tx for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:08:47 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfJeG-0008QQ-1n for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:08:45 +0000 Received: from [192.168.1.3] (H48d6.h.pppool.de [85.72.72.214]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 0F91D44C12; Thu, 24 Nov 2005 17:10:17 +0100 (CET) In-Reply-To: <4385E26A.2070807@gmx.de> References: <4385E26A.2070807@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDav , Cullen Jennings From: Stefan Eissing Date: Thu, 24 Nov 2005 17:08:26 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfJeG-0008QQ-1n 0800bb0e50e7a8017d771f43d9e3a7db X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/ecaeb5a7603875528ca4291b5bc1aa8f@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10609 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:08:49 +0000 Content-Transfer-Encoding: 7bit I have yet to hear of a concrete field problem for this. +1 to leave as it it. Am 24.11.2005 um 16:55 schrieb Julian Reschke: > > Cullen Jennings wrote: >> Just to educate me, what is the limit on header length and where is >> that >> defined? > > I don't think that there is a defined limit (see > ). > > The concern was that clients/proxies/servers may indeed be limited, > and because the "If" header in theory can get very complex, that would > become a problem. > > What I would like to understand *before* changing RFC2518 is whether > the potential implementation limits are in header length, or in header > *line* length. In the latter case, the solution would be to just use > CRLF inside header lines, as allowed by RFC2616. > > Did anybody actually ever experience a problem? If not, I'd recommend > just leave things as they are in RFC2518. > > Best regards, Julian > > > From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:13:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJiY-0007v7-5B for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:13:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21657 for ; Thu, 24 Nov 2005 11:12:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJhw-000094-6n for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:12:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfJhv-00008W-Iy for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:12:23 +0000 Received: from ispmxmta05-srv.alltel.net ([166.102.165.166]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfJhs-00071V-Uc for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:12:23 +0000 Received: from [192.168.1.101] (really [151.213.119.96]) by ispmxmta05-srv.alltel.net with ESMTP id <20051124161217.OLQG18995.ispmxmta05-srv.alltel.net@[192.168.1.101]> for ; Thu, 24 Nov 2005 10:12:17 -0600 Mime-Version: 1.0 Message-Id: Date: Thu, 24 Nov 2005 11:11:46 -0500 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" Received-SPF: none (maggie.w3.org: domain of frank.lowney@gcsu.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1EfJhs-00071V-Uc dd65303151bc1e9237227c6397c4b7da X-Original-To: w3c-dist-auth@w3.org Subject: HTTP Upload X-Archived-At: http://www.w3.org/mid/p06230907bfab94acd159@%5B192.168.1.101%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10610 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:12:24 +0000 We think that we need to ask several vendors (RDBMS, web server, etc.) to provide us with ways and means to do HTTP uploads via HTTP 1.1 methods, namely WebDAV, via a web forms interface similar to what is available presently via HTTP 1.0. The goals vary by project but include: multiple file uploads, more robust uploading, reduced timeout sensitivity, etc. Is this a sensible request? That is, would using HTTP 1.1 WebDAV features provide us with significant advantages over HTTP 1.0? Does the WebDAV standard support uploads via web interfaces? If so, are there examples that we could point to? Thanks in advance for your answers. -- ================================================================== Dr. Frank Lowney Georgia College & State University Manager, Web Enabled Resources, a unit of the Division of Technology Solutions E-Mail: frank.lowney@gcsu.edu Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 NOTICE: Please be advised that I am hearing impaired and communicate most effectively via e-mail. Follow-up summaries of telephone conversations by e-mail are most appreciated. ================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:20:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJph-0001By-C6 for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:20:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22514 for ; Thu, 24 Nov 2005 11:19:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJoy-0003Qx-9g for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:19:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfJox-0003QB-Rs for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:19:39 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfJoq-0000tv-I1 for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:19:38 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2005 08:19:10 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="234061659:sNHT24371020" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAOGJ96a008265; Thu, 24 Nov 2005 08:19:09 -0800 (PST) Received: from 10.21.114.12 ([10.21.114.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 16:20:06 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 08:19:13 -0800 From: Cullen Jennings To: , WebDav Message-ID: Thread-Topic: [Bug 181] New: error element Thread-Index: AcXxEs67DWb8qV0GEdqD+AARJEEJ/A== In-Reply-To: <200511202032.jAKKWXXR003321@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 181] New: error element X-Archived-At: http://www.w3.org/mid/BFAB2801.6202A%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10611 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:19:40 +0000 Content-Transfer-Encoding: 7bit I don't understand this bug. What's the problem? On 11/20/05 12:32 PM, "bugzilla@soe.ucsc.edu" wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 > > Summary: error element > Product: WebDAV-RFC2518-bis > Version: -08 > Platform: Other > URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- > rfc2518bis-08.html#rfc.section.13.29 > OS/Version: other > Status: NEW > Severity: normal > Priority: P2 > Component: 13. XML Element Definitions > AssignedTo: joe-bugzilla@cursive.net > ReportedBy: julian.reschke@greenbytes.de > QAContact: w3c-dist-auth@w3.org > > > tion.13.29>: > > "Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need > more information to indicate what went wrong. When an error response contains > a > body in WebDAV, the body is in XML with the root element 'error'. The 'error' > tag SHOULD include a standard error tag defined in this specification or > another > specification. The 'error' tag MAY include custom error tags (in custom > namespaces) which a client can safely ignore." > > Clients MAY ignore everything here. And that doesn't depend on where the > condition code is defined. > > Of course the better resolution is just to copy the text from RFC3253, and to > use it's terminology to be consistent with RFC3253, RFC3648 and RFC3744. > > > > ------- 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@frink.w3.org Thu Nov 24 11:27:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJw6-00051g-8B for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:27:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23299 for ; Thu, 24 Nov 2005 11:26:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJvR-0004vF-UO for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:26:21 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfJvR-0004uc-9x for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:26:21 +0000 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfJvL-0000Y1-BI for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:26:20 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 24 Nov 2005 08:26:03 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="678301827:sNHT23242828" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAOGPuOp017450; Thu, 24 Nov 2005 08:26:01 -0800 (PST) Received: from 10.21.114.12 ([10.21.114.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 16:26:53 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 08:26:01 -0800 From: Cullen Jennings To: , WebDav Message-ID: Thread-Topic: [Bug 177] New: "PROPFIND status codes" section Thread-Index: AcXxE8HqAFzxql0HEdqD+AARJEEJ/A== In-Reply-To: <200511202013.jAKKD8Y6003234@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.71.176.70 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfJvL-0000Y1-BI 9ea61af8f1343145c79f24c2de1019bd X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 177] New: "PROPFIND status codes" section X-Archived-At: http://www.w3.org/mid/BFAB2999.62033%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10612 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:26:21 +0000 Content-Transfer-Encoding: 7bit On 11/20/05 12:13 PM, "bugzilla@soe.ucsc.edu" wrote: > ) There's an IESG-accepted spec that already shows another status code that > can > be used here > ( est.html#rfc.section.4.2>), Is that really and IESG reviewed spec? I thought it was an individual submission to the RFC editor? From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:29:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJyM-00064A-Ua for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:29:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23565 for ; Thu, 24 Nov 2005 11:28:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJxi-0005H7-7z for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:28:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfJxh-0005GZ-Mp for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:28:41 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EfJxe-0005Me-La for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:28:41 +0000 Received: (qmail invoked by alias); 24 Nov 2005 16:28:12 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 24 Nov 2005 17:28:12 +0100 X-Authenticated: #1915285 Message-ID: <4385E9D3.9070000@gmx.de> Date: Thu, 24 Nov 2005 17:26:59 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Stefan Eissing CC: WebDav , Cullen Jennings References: <4385E26A.2070807@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EfJxe-0005Me-La b6c3b781f0a481f55f37bf9462d399f6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/4385E9D3.9070000@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10613 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:28:42 +0000 Content-Transfer-Encoding: 7bit Stefan Eissing wrote: > > I have yet to hear of a concrete field problem for this. > > +1 to leave as it it. ...where "leave as it is" means undo the changes done to RFC2518, right? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:30:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJzi-0006Qz-BC for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:30:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23783 for ; Thu, 24 Nov 2005 11:30:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfJz5-0006FN-73 for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:30:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfJz4-0006B6-Ng for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:30:06 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EfJz1-0005gr-OM for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:30:06 +0000 Received: (qmail invoked by alias); 24 Nov 2005 16:30:00 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 24 Nov 2005 17:30:00 +0100 X-Authenticated: #1915285 Message-ID: <4385EA3D.9040902@gmx.de> Date: Thu, 24 Nov 2005 17:28:45 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Frank Lowney CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EfJz1-0005gr-OM 24803f89809b5ef9e4e056e498361f43 X-Original-To: w3c-dist-auth@w3.org Subject: Re: HTTP Upload X-Archived-At: http://www.w3.org/mid/4385EA3D.9040902@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10614 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:30:07 +0000 Content-Transfer-Encoding: 7bit Frank Lowney wrote: > We think that we need to ask several vendors (RDBMS, web server, etc.) to provide us with ways and means to do HTTP uploads via HTTP 1.1 methods, namely WebDAV, via a web forms interface similar to what is available presently via HTTP 1.0. The goals vary by project but include: multiple file uploads, more robust uploading, reduced timeout sensitivity, etc. > > Is this a sensible request? That is, would using HTTP 1.1 WebDAV features provide us with significant advantages over HTTP 1.0? > > Does the WebDAV standard support uploads via web interfaces? If so, are there examples that we could point to? > > Thanks in advance for your answers. Hi, actually, WebDAV doesn't help you at all here. The only relevant methods here are POST and PUT, and these are defined in RFC2616 (HTTP), not RFC2518 (WebDAV). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:37:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfK5m-0007a8-0L for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:37:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24919 for ; Thu, 24 Nov 2005 11:36:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfK4s-0008NK-9Z for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:36:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfK4r-0008M9-5U for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:36:05 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EfK4q-0008Gc-Nh for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:36:04 +0000 Received: (qmail invoked by alias); 24 Nov 2005 16:35:49 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 24 Nov 2005 17:35:49 +0100 X-Authenticated: #1915285 Message-ID: <4385EB9B.6000003@gmx.de> Date: Thu, 24 Nov 2005 17:34:35 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/4385EB9B.6000003@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10615 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:36:06 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I think the problem we are having here is a confusion about IANA and I think > I can help resolve it. I believe we all are fine with the text in section 6. > (If we are not, well then the rest of this may be mute). Note this text > does not stop someone from using opaquelocktoken URI. > > Julian would like to make sure that the IANA registration of opaquelocktoken > at http://www.iana.org/assignments/uri-schemes does not go away. > > My recommendation is that you remove Apendix C from the draft and that you > change the IANA consideration to say that this specification does not > require any IANA actions. > > This will not cause the opaquelocktoken to be removed from IANA. It will not > deprecate it. It will not make it illegal to use. It will not mean that > servers can't use it. > > Cullen Cullen, this option (removing the URI scheme definition from the spec) was discussed in the conference call, and rejected after long discussion. The problem here is that if RFC2518bis indeed "obsoletes" RFC2518, this will mean that the IANA registration will live in a spec that is marked "obsolete" in the RFC database. That is, people looking for the definition may first go to the RFC database, find out that RFCxxxx obsoletes RFC2518, and then wonder where the definition is gone. The consensus I recall is that we keep the URI scheme registration, but strip it to minimal text (referring normatively to all the good stuff in the URN:UUID spec). The only open issue left in draft 08 (mod. editorial questions) is that is says that the scheme was obsoleted. It wasn't, so just dropping the statement would be sufficient. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:38:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfK6s-0000Lg-Qa for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:38:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24997 for ; Thu, 24 Nov 2005 11:37:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfK6I-00009q-1l for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:37:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfK6H-00009E-HS for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:37:33 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EfK6F-0000cY-93 for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:37:33 +0000 Received: (qmail invoked by alias); 24 Nov 2005 16:37:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 24 Nov 2005 17:37:05 +0100 X-Authenticated: #1915285 Message-ID: <4385EBE8.80505@gmx.de> Date: Thu, 24 Nov 2005 17:35:52 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: bugzilla@soe.ucsc.edu, WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EfK6F-0000cY-93 ff277d8010898580fec36e4081afd0a7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 177] New: "PROPFIND status codes" section X-Archived-At: http://www.w3.org/mid/4385EBE8.80505@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10616 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:37:34 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 11/20/05 12:13 PM, "bugzilla@soe.ucsc.edu" wrote: > >> ) There's an IESG-accepted spec that already shows another status code that >> can >> be used here >> (> est.html#rfc.section.4.2>), > > Is that really and IESG reviewed spec? I thought it was an individual > submission to the RFC editor? ...that was approved by the IESG a few months ago. See . Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:41:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfK9c-0001O0-Hs for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:41:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25294 for ; Thu, 24 Nov 2005 11:40:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfK8r-0001Bz-GK for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:40:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfK8r-0001BR-2n for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:40:13 +0000 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1EfK8p-0002jw-QV for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:40:12 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 24 Nov 2005 08:39:59 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAOGduOp020155 for ; Thu, 24 Nov 2005 08:39:57 -0800 (PST) Received: from 10.21.114.12 ([10.21.114.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 16:40:53 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 08:39:59 -0800 From: Cullen Jennings To: Cullen Jennings , WebDav Message-ID: Thread-Topic: Twice Weekly Conference Call Thread-Index: AcXxDDKOcQpwiFz/EdqD+AARJEEJ/AACYLbM In-Reply-To: X-Priority: 1 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.71.176.71 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Twice Weekly Conference Call X-Archived-At: http://www.w3.org/mid/BFAB2CDF.62047%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10617 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:40:13 +0000 Content-Transfer-Encoding: 7bit I totally blew the email below. The call is on Wednesday and Friday. (not Thursday). Thank you Julian for catching this. On 11/24/05 7:31 AM, "Cullen Jennings" wrote: > > > We made reasonable progress on the last 3 hour conference call so we are going > to try to have a bunch of them between now and the end of the year. > > > Date/Time: Wednesday and Thursday at 9:00 AM America/Los_Angeles > Length: 180 minutes Meeting ID: 251807 Phone Numbers: > 1-866-MEETME9 (US Toll-free) 1-650-260-9030 (Local/International) > > For Cisco MeetingPlace Help Desk assistance, please call: 866-631-5313 (US > Toll-free) or 408-450-7637 (Local/International) or email > mailto:at.help@meetingplace.net. From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:42:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfKAd-0001bQ-3j for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:42:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25418 for ; Thu, 24 Nov 2005 11:41:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfK9x-0001Kp-8B for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:41:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfK9w-0001KC-Mj for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:41:20 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by maggie.w3.org with esmtp (Exim 4.50) id 1EfK9t-0001va-Qu for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:41:20 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2005 08:40:55 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="369864141:sNHT24688200" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAOGerOp020392; Thu, 24 Nov 2005 08:40:54 -0800 (PST) Received: from 10.21.114.12 ([10.21.114.12]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 16:41:50 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 08:40:58 -0800 From: Cullen Jennings To: Julian Reschke CC: , WebDav Message-ID: Thread-Topic: [Bug 177] New: "PROPFIND status codes" section Thread-Index: AcXxFdiSFvPQw10JEdqD+AARJEEJ/A== In-Reply-To: <4385EBE8.80505@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.71.176.72 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EfK9t-0001va-Qu 4ef94e83515aac1ec86e2aa840625f77 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 177] New: "PROPFIND status codes" section X-Archived-At: http://www.w3.org/mid/BFAB2D1A.6204B%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10618 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:41:21 +0000 Content-Transfer-Encoding: 7bit On 11/24/05 8:35 AM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> On 11/20/05 12:13 PM, "bugzilla@soe.ucsc.edu" wrote: >> >>> ) There's an IESG-accepted spec that already shows another status code that >>> can >>> be used here >>> (>> at >>> est.html#rfc.section.4.2>), >> >> Is that really and IESG reviewed spec? I thought it was an individual >> submission to the RFC editor? > > ...that was approved by the IESG a few months ago. See > > . > > Best regards, Julian Cool - thanks. From w3c-dist-auth-request@frink.w3.org Thu Nov 24 11:47:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfKGA-0003kK-0N for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:47:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26462 for ; Thu, 24 Nov 2005 11:47:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfKFS-00046y-4H for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 16:47:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfKFP-00045r-Rw for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 16:46:59 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by maggie.w3.org with esmtp (Exim 4.50) id 1EfKFI-0003l8-DW for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 16:46:59 +0000 Received: from [192.168.1.3] (H48d6.h.pppool.de [85.72.72.214]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 6953B44CF4; Thu, 24 Nov 2005 17:48:21 +0100 (CET) In-Reply-To: <4385E9D3.9070000@gmx.de> References: <4385E26A.2070807@gmx.de> <4385E9D3.9070000@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDav , Cullen Jennings From: Stefan Eissing Date: Thu, 24 Nov 2005 17:46:29 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: none (maggie.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EfKFI-0003l8-DW 0f41e9f63fa3255493d61d39526205f7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/bb4d3d95b92a949bb4dceeea8e041c0b@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10619 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 16:47:02 +0000 Content-Transfer-Encoding: 7bit Leave the syntax of the IF header as it is in 2518. Am 24.11.2005 um 17:26 schrieb Julian Reschke: > Stefan Eissing wrote: >> I have yet to hear of a concrete field problem for this. >> +1 to leave as it it. > > ...where "leave as it is" means undo the changes done to RFC2518, > right? > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 12:43:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfL83-0001Ea-Ty for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 12:43:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03467 for ; Thu, 24 Nov 2005 12:42:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfL71-0005gZ-7I for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 17:42:23 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfL6v-0005fL-Hn for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 17:42:17 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfL6p-0003MF-Fa for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 17:42:16 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CB02D142275; Thu, 24 Nov 2005 09:42:07 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31258-03; Thu, 24 Nov 2005 09:42:07 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1642D1422BE; Thu, 24 Nov 2005 09:42:07 -0800 (PST) In-Reply-To: <4385E26A.2070807@gmx.de> References: <4385E26A.2070807@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3c9338ae51ab95559945564dc9fbfe9a@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , WebDav WG , Joel Soderberg From: Lisa Dusseault Date: Thu, 24 Nov 2005 09:42:05 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfL6p-0003MF-Fa 15081892f2edfcd7dd98c18823c75a53 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/3c9338ae51ab95559945564dc9fbfe9a@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10620 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 17:42:23 +0000 Content-Transfer-Encoding: 7bit Joel Soderberg brought this up; it should be part of those interop notes, and yes, it was an actual experienced problem as far as I can remember. Lisa On Nov 24, 2005, at 7:55 AM, Julian Reschke wrote: > > Cullen Jennings wrote: >> Just to educate me, what is the limit on header length and where is >> that >> defined? > > I don't think that there is a defined limit (see > ). > > The concern was that clients/proxies/servers may indeed be limited, > and because the "If" header in theory can get very complex, that would > become a problem. > > What I would like to understand *before* changing RFC2518 is whether > the potential implementation limits are in header length, or in header > *line* length. In the latter case, the solution would be to just use > CRLF inside header lines, as allowed by RFC2616. > > Did anybody actually ever experience a problem? If not, I'd recommend > just leave things as they are in RFC2518. > > Best regards, Julian > > > From w3c-dist-auth-request@frink.w3.org Thu Nov 24 12:50:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfLEi-0003nJ-68 for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 12:50:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04464 for ; Thu, 24 Nov 2005 12:49:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfLE4-0000CD-20 for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 17:49:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfLE3-0000Bd-Cm for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 17:49:39 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfLE0-00084V-JW for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 17:49:39 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B6441422BB; Thu, 24 Nov 2005 09:49:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14676-09; Thu, 24 Nov 2005 09:49:08 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DA81E142275; Thu, 24 Nov 2005 09:49:07 -0800 (PST) In-Reply-To: <43832539.5010803@gmx.de> References: <6afe73f812e0332e98ff9bae7ac7953b@osafoundation.org> <43832539.5010803@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <263825d4026eb1936156d2612f1ca3f7@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: webdav WG From: Lisa Dusseault Date: Thu, 24 Nov 2005 09:49:06 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EfLE0-00084V-JW dceebf1b224d3202d58b666f1b2f62ce X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 190] New: HTTP examples using RFC2629 markup X-Archived-At: http://www.w3.org/mid/263825d4026eb1936156d2612f1ca3f7@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10621 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 17:49:40 +0000 Content-Transfer-Encoding: 7bit Oops, wrote this up yesterday when I posted an interim version of the draft, but forgot to hit 'send'. ... I ended up not using this diff because I got distracted making other changes before remembering this diff. However, I did find it useful to refer to, to see exactly what you had in mind. The removal of subsections was not a conversion error originally but an editorial choice, deeming that inlined short examples can sometimes be good for readability. Nevertheless, I can go back to using subsections for every example, but in that case there are more examples (the example of using a precondition code in a 403 Forbidden was the first such one in 08) which are new, and which should also be sections on their own if that's our choice. Also note I indented some of the examples less as I went along -- consistently going for indentation of 2 spaces from the normal edge of text, and 2 spaces for each XML structural indentation. Lisa On Nov 22, 2005, at 6:03 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> I'm in favour of this change, and were you to supply me with a diff, >> it would happen all the sooner. Thanks ! > > OK, > > the attached source (+ diff) fixes: > > - artwork as discussed (also making indentation consistent and fixing > XML errors) > - makes the LOCK compatibility table a proper table (rfc2629 style) > > While doing this, I had also to re-add subsections for the examples > (this was lost in an earlier draft; I suspect that was an error due to > the conversion to XML source). From w3c-dist-auth-request@frink.w3.org Thu Nov 24 12:50:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfLF5-0003rv-7F for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 12:50:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04475 for ; Thu, 24 Nov 2005 12:50:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfLEX-0000th-JY for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 17:50:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfLEX-0000ss-3y for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 17:50:09 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EfLEU-0003eO-54 for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 17:50:07 +0000 Received: (qmail invoked by alias); 24 Nov 2005 17:49:45 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 24 Nov 2005 18:49:45 +0100 X-Authenticated: #1915285 Message-ID: <4385FCEA.8020502@gmx.de> Date: Thu, 24 Nov 2005 18:48:26 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: Cullen Jennings , WebDav WG , Joel Soderberg References: <4385E26A.2070807@gmx.de> <3c9338ae51ab95559945564dc9fbfe9a@osafoundation.org> In-Reply-To: <3c9338ae51ab95559945564dc9fbfe9a@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/4385FCEA.8020502@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10622 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 17:50:09 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Joel Soderberg brought this up; it should be part of those interop > notes, and yes, it was an actual experienced problem as far as I can > remember. So again, - was this a question of header length oder header line length?, and - is the problem still present? Unless we can answer those, I'm -1 on making a change, in particular as the current definition doesn't work (). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 12:54:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfLIc-0005va-R5 for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 12:54:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04651 for ; Thu, 24 Nov 2005 12:53:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfLHy-0001Zx-B3 for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 17:53:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfLHx-0001YM-NI for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 17:53:41 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EfLHv-00011J-0a for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 17:53:41 +0000 Received: (qmail invoked by alias); 24 Nov 2005 17:53:12 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 24 Nov 2005 18:53:12 +0100 X-Authenticated: #1915285 Message-ID: <4385FDBA.5090500@gmx.de> Date: Thu, 24 Nov 2005 18:51:54 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: webdav WG References: <6afe73f812e0332e98ff9bae7ac7953b@osafoundation.org> <43832539.5010803@gmx.de> <263825d4026eb1936156d2612f1ca3f7@osafoundation.org> In-Reply-To: <263825d4026eb1936156d2612f1ca3f7@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EfLHv-00011J-0a 8076bd52d71a9f644dee154009ba33eb X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 190] New: HTTP examples using RFC2629 markup X-Archived-At: http://www.w3.org/mid/4385FDBA.5090500@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10623 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 17:53:42 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Oops, wrote this up yesterday when I posted an interim version of the > draft, but forgot to hit 'send'. > ... > I ended up not using this diff because I got distracted making other > changes before remembering this diff. However, I did find it useful to > refer to, to see exactly what you had in mind. Well, at some point we should figure out a way how to coordinate edits. > The removal of subsections was not a conversion error originally but an > editorial choice, deeming that inlined short examples can sometimes be > good for readability. Nevertheless, I can go back to using subsections > for every example, but in that case there are more examples (the example > of using a precondition code in a 403 Forbidden was the first such one > in 08) which are new, and which should also be sections on their own if > that's our choice. I'm not sure what you're referring to; the draft as of this morning (my time) has the subsections back in. > Also note I indented some of the examples less as I went along -- > consistently going for indentation of 2 spaces from the normal edge of > text, and 2 spaces for each XML structural indentation. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 13:21:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfLix-0007ND-KL for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 13:21:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07409 for ; Thu, 24 Nov 2005 13:20:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfLi7-0000xN-SP for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 18:20:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfLi4-0000w9-TM; Thu, 24 Nov 2005 18:20:40 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfLi4-0007D5-Ng; Thu, 24 Nov 2005 18:20:40 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAOIKN85029365; Thu, 24 Nov 2005 13:20:23 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAOIKNDT025296; Thu, 24 Nov 2005 13:20:23 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAOIKMx9005865; Thu, 24 Nov 2005 13:20:23 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAOIKMYc005859; Thu, 24 Nov 2005 13:20:22 -0500 In-Reply-To: <4385C0A2.4030004@gmx.de> To: Julian Reschke Cc: WebDav , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 24 Nov 2005 13:20:21 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 11/24/2005 13:20:22, Serialize complete at 11/24/2005 13:20:22 Content-Type: multipart/alternative; boundary="=_alternative 0064ADDF852570C3_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/OF1F421FD1.035C9413-ON852570C3.006492FC-852570C3.0064AE1D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10624 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 18:20:43 +0000 This is a multipart message in MIME format. --=_alternative 0064ADDF852570C3_= Content-Type: text/plain; charset="US-ASCII" I agree with this proposal. Cheers, Geoff Julian wrote on 11/24/2005 08:31:14 AM: > So what I would propose is to > > a) agree on a certain set of server features that those clients expect > (strong ETag on PUT, octet-for-octet identity of representations, ...), then > > b) define a profile for WebDAV that covers this, and a simple way for > clients to discover whether any given resource supports this. > > IMHO this definition should go into a separate document. This will also > reduce the amount of open issues on RFC2518bis for now. --=_alternative 0064ADDF852570C3_= Content-Type: text/html; charset="US-ASCII"
I agree with this proposal.

Cheers,
Geoff

Julian wrote on 11/24/2005 08:31:14 AM:

> So what I would propose is to
>
> a) agree on a certain set of server features that those clients expect
> (strong ETag on PUT, octet-for-octet identity of representations, ...), then
>
> b) define a profile for WebDAV that covers this, and a simple way for
> clients to discover whether any given resource supports this.
>
> IMHO this definition should go into a separate document. This will also
>   reduce the amount of open issues on RFC2518bis for now.

 --=_alternative 0064ADDF852570C3_=-- From w3c-dist-auth-request@frink.w3.org Thu Nov 24 15:42:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNvL-0007n6-Rh for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 15:42:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22466 for ; Thu, 24 Nov 2005 15:41:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfNty-0003Nu-JZ for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 20:41:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfNtt-0003NH-BM; Thu, 24 Nov 2005 20:41:01 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfNtq-0000BL-IU; Thu, 24 Nov 2005 20:41:01 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2005 12:40:08 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208,217"; a="234096899:sNHT35021460" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAOKe66a025211; Thu, 24 Nov 2005 12:40:06 -0800 (PST) Received: from 10.21.98.185 ([10.21.98.185]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 20:41:03 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 12:40:10 -0800 From: Cullen Jennings To: Geoffrey M Clemm , Julian Reschke CC: WebDav , Message-ID: Thread-Topic: ETags, next call, was: Notes on call from today ... Thread-Index: AcXxN0MHgVj/aF0qEdqD+AARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3215680810_11587520" Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1EfNtq-0000BL-IU 434490a0f1af35db6157698e61495fb9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/BFAB652A.620EC%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10625 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 20:41:06 +0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3215680810_11587520 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit So the usual IETF thought pattern around profiles is say we have might have profile A and B. Are their clients that want both? Are there reasons a server would only support one? How will this negation and if a server only does A and a client wants B, what will the interoperation be like? On 11/24/05 10:20 AM, "Geoffrey M Clemm" wrote: > > I agree with this proposal. > > Cheers, > Geoff > > Julian wrote on 11/24/2005 08:31:14 AM: > >> > So what I would propose is to >> > >> > a) agree on a certain set of server features that those clients expect >> > (strong ETag on PUT, octet-for-octet identity of representations, ...), >> then >> > >> > b) define a profile for WebDAV that covers this, and a simple way for >> > clients to discover whether any given resource supports this. >> > >> > IMHO this definition should go into a separate document. This will also >> > reduce the amount of open issues on RFC2518bis for now. > > --B_3215680810_11587520 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: ETags, next call, was: Notes on call from today ...
So the usual IETF thought pattern around profiles is say we have might have= profile A and B. Are their clients that want both? Are there reasons a serv= er would only support one? How will this negation and if a server only does = A and a client wants B, what will the interoperation be like?


On 11/24/05 10:20 AM, "Geoffrey M Clemm" <geoffrey.clemm@us.ib= m.com> wrote:


I agree with this proposal.

Cheers,
Geoff

Julian wrote on 11/24/2005 08:31:14 AM:

> So what I would propose is to
>
> a) agree on a certain set of server features that those clients expect=
> (strong ETag on PUT, octet-for-octet identity of representations, ...)= , then
>
> b) define a profile for WebDAV that covers this, and a simple way for =
> clients to discover whether any given resource supports this.
>
> IMHO this definition should go into a separate document. This will als= o
>   reduce the amount of open issues on RFC2518bis for now.


--B_3215680810_11587520-- From w3c-dist-auth-request@frink.w3.org Thu Nov 24 15:43:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNwV-0008Dv-AE for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 15:43:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22681 for ; Thu, 24 Nov 2005 15:43:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfNvw-0003dw-Ca for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 20:43:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfNvv-0003dO-NI for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 20:43:07 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfNvs-00016X-Ou for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 20:43:07 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2005 12:42:46 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="234097312:sNHT25973292" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAOKgg6c025692; Thu, 24 Nov 2005 12:42:44 -0800 (PST) Received: from 10.21.98.185 ([10.21.98.185]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2005 20:43:40 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 24 Nov 2005 12:42:48 -0800 From: Cullen Jennings To: Julian Reschke CC: WebDav Message-ID: Thread-Topic: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it Thread-Index: AcXxN6E0373i7l0qEdqD+AARJEEJ/A== In-Reply-To: <4385EB9B.6000003@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1EfNvs-00016X-Ou f3545f380d305a81eefa66624ccadb6e X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/BFAB65C8.620EE%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10626 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 20:43:08 +0000 Content-Transfer-Encoding: 7bit On 11/24/05 8:34 AM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> >> I think the problem we are having here is a confusion about IANA and I think >> I can help resolve it. I believe we all are fine with the text in section 6. >> (If we are not, well then the rest of this may be mute). Note this text >> does not stop someone from using opaquelocktoken URI. >> >> Julian would like to make sure that the IANA registration of opaquelocktoken >> at http://www.iana.org/assignments/uri-schemes does not go away. >> >> My recommendation is that you remove Apendix C from the draft and that you >> change the IANA consideration to say that this specification does not >> require any IANA actions. >> >> This will not cause the opaquelocktoken to be removed from IANA. It will not >> deprecate it. It will not make it illegal to use. It will not mean that >> servers can't use it. >> >> Cullen > > Cullen, > > this option (removing the URI scheme definition from the spec) was > discussed in the conference call, and rejected after long discussion. More below on I am not arguing this one way or another but just want to comment on IANA .... > > The problem here is that if RFC2518bis indeed "obsoletes" RFC2518, this > will mean that the IANA registration will live in a spec that is marked > "obsolete" in the RFC database. That is, people looking for the > definition may first go to the RFC database, find out that RFCxxxx > obsoletes RFC2518, and then wonder where the definition is gone. Hmm, The IANA registration will say this is defined in 2518 and when people look up 2518, they will find it there. That a later RFC (2518bis) updates 2518 no longer requires or suggests the use of this is OK. It's not like the IANA registration is going to mark the opaquelocktoken as obsolete. > > The consensus I recall is that we keep the URI scheme registration, but > strip it to minimal text (referring normatively to all the good stuff in > the URN:UUID spec). I don't remember exactly but I suspect you are correct that this is what the folks on the call decided to put in the draft. > > The only open issue left in draft 08 (mod. editorial questions) is that > is says that the scheme was obsoleted. It wasn't, so just dropping the > statement would be sufficient. Well if that is how folks want to fix this, great with me, I'm not arguing it should be one way or another. I just wanted to make sure we were not doing something because of a misunderstanding about IANA. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 15:53:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfO6I-0003ab-8T for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 15:53:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23811 for ; Thu, 24 Nov 2005 15:53:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfO5X-0006GE-9r for w3c-dist-auth-dist@listhub.w3.org; Thu, 24 Nov 2005 20:53:03 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfO5W-0006FZ-Lk for w3c-dist-auth@listhub.w3.org; Thu, 24 Nov 2005 20:53:02 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EfO5E-0005Qq-Ft for w3c-dist-auth@w3.org; Thu, 24 Nov 2005 20:53:01 +0000 Received: (qmail invoked by alias); 24 Nov 2005 20:52:37 -0000 Received: from p508FA721.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.167.33] by mail.gmx.net (mp032) with SMTP; 24 Nov 2005 21:52:37 +0100 X-Authenticated: #1915285 Message-ID: <438627DD.9010706@gmx.de> Date: Thu, 24 Nov 2005 21:51:41 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfO5E-0005Qq-Ft 1e8c93049a60ccb97ea680a3ea8777e0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/438627DD.9010706@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10627 X-Loop: w3c-dist-auth@w3.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, 24 Nov 2005 20:53:03 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > So the usual IETF thought pattern around profiles is say we have might > have profile A and B. Are their clients that want both? Are there > reasons a server would only support one? How will this negation and if a > server only does A and a client wants B, what will the interoperation be > like? Let's call that profile "filestore". This profile would be a true subset of WebDAV. A server such as Slide (to take a real-world example) might want to advertise "filestore" on some resources (such as in a FS backend), but not others (such as a Tamino XML database). A client that would absolutely need the features defined as part of the "filestore" would simply refuse to interop with some of the resources on the server. IMHO that would still be far better than to forbid servers to implement useful WebDAV stuff on resources like these (because that's what a MUST or even a SHOULD requirement would essentially mean). We also should keep in mind that we're in HTTP's area here, because we're talking about PUT. We simply can't overrule HTTP here. We *can* define a way for servers to advertise that their PUT support fulfills certain requirement, so that clients can find out. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Nov 24 23:20:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfV4u-0001qI-OF for webdav-archive@megatron.ietf.org; Thu, 24 Nov 2005 23:20:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05815 for ; Thu, 24 Nov 2005 23:20:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfV2l-0007jw-7x for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 04:18:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfV2f-0007iW-KJ for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 04:18:34 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfV2b-0007h5-0M for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 04:18:33 +0000 Received: from [192.168.2.104] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jAP4HxkU020577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Nov 2005 20:17:59 -0800 (PST) Message-ID: <43869077.5090208@cse.ucsc.edu> Date: Thu, 24 Nov 2005 20:17:59 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG Content-Type: multipart/alternative; boundary="------------090102080009040203030106" Received-SPF: none (maggie.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EfV2b-0007h5-0M 240703443d0adc0a6437caafd324656d X-Original-To: w3c-dist-auth@w3.org Subject: Issues for 11/24 Conference Call X-Archived-At: http://www.w3.org/mid/43869077.5090208@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10628 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 04:18:39 +0000 This is a multi-part message in MIME format. --------------090102080009040203030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Enclosed, please find the issue list for Tomorrows' conference call. Although there are a couple more than we got to in the previous call, I think that some of them will be pretty easy to dispatch with, being primarily editorial or terminology issues. Cheers, Elias _____________________ Critical: 27 - Copy vs live properties 40 - definition of null resource gone (Note that this sort of goes along with 25, below) 44 - OPTIONS * 62 - href format 73 - "Changes" section missing (Although 'critical', I think we can dispatch this one rather quickly) 86 - DAV hedear definitions should use RFC3864 templates (Same as for #73) Major: 13 - New ETag requirements 16 - Trailing slash required in collection names? (Should be an easy one do resolve) 18 - no record of consensus for force authenticate 22 - attributes on properties 23 - Lock discovery vs shared locks 25 - Lock to unmapped URL Normal (but fairly easy to resolve): 41 - Paragraph numbering/nesting broken in Section 13 49 - propfind XML description incorrect 50 - Property terminology inconsistent with RFC3253 --------------090102080009040203030106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

Enclosed, please find the issue list for Tomorrows' conference call.  Although there are a couple more than we got to in the previous call, I think that some of them will be pretty easy to dispatch with, being primarily editorial or terminology issues.


Cheers,
Elias
_____________________

Critical:
27 - Copy vs live properties
40 - definition of null resource gone
       (Note that this sort of goes along with 25, below)
44 - OPTIONS *
62 - href format
73 - "Changes" section missing
       (Although 'critical', I think we can dispatch this one rather quickly)
86 - DAV hedear definitions should use RFC3864 templates
       (Same as for #73)

Major:
13 - New ETag requirements
16 - Trailing slash required in collection names?
       (Should be an easy one do resolve)
18 - no record of consensus for force authenticate
22 - attributes on properties
23 - Lock discovery vs shared locks
25 - Lock to unmapped URL

Normal (but fairly easy to resolve):
41 - Paragraph numbering/nesting broken in Section 13
49 - propfind XML description incorrect
50 - Property terminology inconsistent with RFC3253

--------------090102080009040203030106-- From w3c-dist-auth-request@frink.w3.org Fri Nov 25 11:05:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efg54-0006Ha-EF for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:05:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12087 for ; Fri, 25 Nov 2005 11:05:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efg3O-0001KX-9P for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 16:04:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Efg3J-0001Jv-74 for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 16:03:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Efg3B-0005Z9-9U for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 16:03:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPG3SJL011126; Fri, 25 Nov 2005 08:03:28 -0800 Date: Fri, 25 Nov 2005 08:03:28 -0800 Message-Id: <200511251603.jAPG3SJL011126@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Efg3B-0005Z9-9U 1640480c5347742b6ffe709e16a6ab6f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 27] COPY vs live properties X-Archived-At: http://www.w3.org/mid/200511251603.jAPG3SJL011126@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10629 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 16:04:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=27 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-11-25 08:03 ------- Yep, this text from 2518 still existed. Proposed new text: Servers SHOULD NOT convert live properties into dead properties on the destination resource, because clients may then draw incorrect conclusions about the state or functionality of a 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@frink.w3.org Fri Nov 25 11:08:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efg84-0007Cv-1O for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:08:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12517 for ; Fri, 25 Nov 2005 11:08:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efg7S-00020O-TY for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 16:08:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Efg7S-0001zq-Bv for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 16:08:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Efg7P-0001Qv-Ie for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 16:08:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPG7rFc011271; Fri, 25 Nov 2005 08:07:53 -0800 Date: Fri, 25 Nov 2005 08:07:53 -0800 Message-Id: <200511251607.jAPG7rFc011271@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Efg7P-0001Qv-Ie cb75d1711e4c5d1ee2ea2cce3a810efb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 40] Definition of "null resource" gone X-Archived-At: http://www.w3.org/mid/200511251607.jAPG7rFc011271@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10630 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 16:08:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=40 ------- Additional Comments From lisa@osafoundation.org 2005-11-25 08:07 ------- It's true that this definition is removed from the beginning definitions sections. However, I was careful to introduce the concept with an explanation the first time it's mentioned. I think this is more helpful to the user because it avoids making lock-null resources appear like they're still required features. Here's the text currently. In this situation, a WebDAV server that was implemented from RFC2518 MAY create "lock-null" resources which are special and unusual resources. Historically, a lock-null resource: o Responds with a 404 or 405 to any DAV method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. o Appears as a member of its parent collection. o Disappears (URI becomes unmapped) if its lock goes away before it is converted to a regular resource. (This must also happen if it is renamed or moved, or if any parent collection is renamed or moved, because locks are tied to URLs). o May be turned into a regular resource when a PUT request to the URL is successful. Ceases to be a lock-null resource. o May be turned into a collection when a MKCOL request to the URL is successful. Ceases to be a lock-null resource. o Has defined values for DAV:lockdiscovery and DAV:supportedlock properties. ------- 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@frink.w3.org Fri Nov 25 11:41:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfgdL-0003K4-Br for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:41:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15811 for ; Fri, 25 Nov 2005 11:40:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efgbz-0003D1-2o for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 16:39:47 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efgbp-0003BY-UX for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 16:39:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efgbd-0007Sy-Tj for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 16:39:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPGdMWL012204; Fri, 25 Nov 2005 08:39:22 -0800 Date: Fri, 25 Nov 2005 08:39:22 -0800 Message-Id: <200511251639.jAPGdMWL012204@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Efgbd-0007Sy-Tj 4dea744a368321c5df2476b8970abd35 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] OPTIONS * X-Archived-At: http://www.w3.org/mid/200511251639.jAPGdMWL012204@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10631 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 16:39:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 ------- Additional Comments From lisa@osafoundation.org 2005-11-25 08:39 ------- This has been a particularly interesting issue. Some more background: - Jeff Mogul concluded that OPTIONS is "next to useless" as currently specified, and pointed me towards a proposal for fixing that: http://ftp.ics.uci.edu/pub/ietf/http/draft-ietf-http-options-02.txt - As I recall, in interop tests we found that some clients do use OPTIONS *. - It is possible to implement OPTIONS * correctly with Java servlets -- Xythos WFS did so eventually. - A fair amount of discussion on the WebDAV list was on or around Nov 24 2003. - Mark Nottingham took an interesting look at this: http://www.mnot.net/blog/2005/04/03/options - And finally, as Hugh Sloan pointed out on the HTTP mailing list April 26 2004, "there have been some sub-Sahara tribes known to use OPTIONS to induce flatulence prior to the mating ritual" ;) That day also included a broader discussion of use of OPTIONS by a number of HTTP extensions. ------- 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@frink.w3.org Fri Nov 25 11:47:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efgj0-0005rw-MV for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:47:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16566 for ; Fri, 25 Nov 2005 11:46:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfgiE-0005rF-1N for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 16:46:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfgiD-0005qg-FI for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 16:46:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfgiA-0000vk-GP for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 16:46:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPGk1tW012434; Fri, 25 Nov 2005 08:46:01 -0800 Date: Fri, 25 Nov 2005 08:46:01 -0800 Message-Id: <200511251646.jAPGk1tW012434@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfgiA-0000vk-GP ce79403b43a2b839331737ed1687453e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 86] DAV header definitions should use RFC3864 templates X-Archived-At: http://www.w3.org/mid/200511251646.jAPGk1tW012434@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10633 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 16:46:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=86 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |18 ------- Additional Comments From lisa@osafoundation.org 2005-11-25 08:46 ------- While I agree we should register new headers, and possibly existing ones, let's wait until we've decided whether to add new headers. I created a dependency on bug 18 to reflect this. ------- 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@frink.w3.org Fri Nov 25 11:47:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efgj0-0005rx-N2 for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:47:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16567 for ; Fri, 25 Nov 2005 11:46:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfgiA-0005qX-PL for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 16:46:10 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efgi9-0005pu-UP for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 16:46:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efgi4-0001ys-J5 for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 16:46:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPGk1RS012444; Fri, 25 Nov 2005 08:46:01 -0800 Date: Fri, 25 Nov 2005 08:46:01 -0800 Message-Id: <200511251646.jAPGk1RS012444@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Efgi4-0001ys-J5 fc59c15dc4540a83ebccef71fee194ba 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/200511251646.jAPGk1RS012444@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10632 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 16:46:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |86 nThis| | ------- 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@frink.w3.org Fri Nov 25 11:54:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efgqg-0008MT-NL for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:54:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17588 for ; Fri, 25 Nov 2005 11:54:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efgpw-0007C3-JK for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 16:54:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Efgpt-0007BN-Cg for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 16:54:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Efgpq-0005iX-3y for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 16:54:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPGrbGZ012693; Fri, 25 Nov 2005 08:53:37 -0800 Date: Fri, 25 Nov 2005 08:53:37 -0800 Message-Id: <200511251653.jAPGrbGZ012693@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Efgpq-0005iX-3y 6c2211f80b54ac551e814602c8f164ef X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200511251653.jAPGrbGZ012693@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10634 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 16:54:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 ------- Additional Comments From lisa@osafoundation.org 2005-11-25 08:53 ------- How about this: A successful lock request to an unmapped URL SHOULD result in the creation of an locked resource with empty content. Subsequently, a successful PUT request (with the correct lock token) provides the content for the resource, and the server MUST also use the content-type and content-language information from this request. ------- 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@frink.w3.org Fri Nov 25 11:57:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfgtB-0001TK-LC for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:57:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17890 for ; Fri, 25 Nov 2005 11:56:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfgsX-0007pw-I5 for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 16:56:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfgsX-0007oo-1P for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 16:56:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfgsV-0005Pe-U7 for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 16:56:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPGug8o012806; Fri, 25 Nov 2005 08:56:42 -0800 Date: Fri, 25 Nov 2005 08:56:42 -0800 Message-Id: <200511251656.jAPGug8o012806@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 49] propfind XML description incorrect X-Archived-At: http://www.w3.org/mid/200511251656.jAPGug8o012806@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10635 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 16:56:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=49 ------- Additional Comments From lisa@osafoundation.org 2005-11-25 08:56 ------- The definition of dead-props element already exists in its own section. The other change in DTD may well be fine, we should have a brief discussion about whether we all agree what it 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@frink.w3.org Fri Nov 25 11:59:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efgua-00024r-8q for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:59:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18028 for ; Fri, 25 Nov 2005 11:58:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efgtk-00081g-UU for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 16:58:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Efgtk-000818-Gp for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 16:58:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Efgta-0005wg-Vw for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 16:58:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPGvp99012854; Fri, 25 Nov 2005 08:57:51 -0800 Date: Fri, 25 Nov 2005 08:57:51 -0800 Message-Id: <200511251657.jAPGvp99012854@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Efgta-0005wg-Vw f7d382f3d29b88104a6b2776aee59211 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200511251657.jAPGvp99012854@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10636 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 16:58:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 ------- Additional Comments From lisa@osafoundation.org 2005-11-25 08:57 ------- Proposed rewording of this paragraph would be nice. ------- 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@frink.w3.org Fri Nov 25 12:16:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhBW-0004Gb-PY for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:16:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20023 for ; Fri, 25 Nov 2005 12:15:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfhAM-0004Zt-1P for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 17:15:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfhAC-00043Q-HQ for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 17:15:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfhA3-0004nC-KD for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 17:15:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPHEw5T013446; Fri, 25 Nov 2005 09:14:58 -0800 Date: Fri, 25 Nov 2005 09:14:58 -0800 Message-Id: <200511251714.jAPHEw5T013446@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfhA3-0004nC-KD 75eb8211d8522db239351bc04e470897 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 27] COPY vs live properties X-Archived-At: http://www.w3.org/mid/200511251714.jAPHEw5T013446@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10637 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 17:15:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=27 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 09:14 ------- Lisa to add proposed text to next draft, following rough consensus reached on 11/25 telecon. ------- 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@frink.w3.org Fri Nov 25 12:23:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhHv-0007Sk-Pr for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:23:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21081 for ; Fri, 25 Nov 2005 12:22:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfhHF-00077C-NG for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 17:22:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfhHA-00076E-Ev; Fri, 25 Nov 2005 17:22:20 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfhH7-0007tU-AQ; Fri, 25 Nov 2005 17:22:19 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 25 Nov 2005 09:22:05 -0800 X-IronPort-AV: i="3.97,377,1125903600"; d="scan'208"; a="234313871:sNHT25868524" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAPHM2Op017330; Fri, 25 Nov 2005 09:22:03 -0800 (PST) Received: from 10.21.90.107 ([10.21.90.107]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Nov 2005 17:23:00 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 25 Nov 2005 09:22:07 -0800 From: Cullen Jennings To: Julian Reschke CC: Geoffrey M Clemm , WebDav , Message-ID: Thread-Topic: ETags, next call, was: Notes on call from today ... Thread-Index: AcXx5MKfAXrB7F3YEdqJUAARJEEJ/A== In-Reply-To: <438627DD.9010706@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EfhH7-0007tU-AQ 6bdd4236e7ccd28d0769917e208abeef X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/BFAC8840.621E3%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10638 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 17:22:25 +0000 Content-Transfer-Encoding: 7bit I have heard that this is wanted for applications other than a file system. Right now I was sort of looking for examples of applications that did not want to use this. On 11/24/05 12:51 PM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> >> So the usual IETF thought pattern around profiles is say we have might >> have profile A and B. Are their clients that want both? Are there >> reasons a server would only support one? How will this negation and if a >> server only does A and a client wants B, what will the interoperation be >> like? > > Let's call that profile "filestore". > > This profile would be a true subset of WebDAV. A server such as Slide > (to take a real-world example) might want to advertise "filestore" on > some resources (such as in a FS backend), but not others (such as a > Tamino XML database). > > A client that would absolutely need the features defined as part of the > "filestore" would simply refuse to interop with some of the resources on > the server. > > IMHO that would still be far better than to forbid servers to implement > useful WebDAV stuff on resources like these (because that's what a MUST > or even a SHOULD requirement would essentially mean). > > We also should keep in mind that we're in HTTP's area here, because > we're talking about PUT. We simply can't overrule HTTP here. We *can* > define a way for servers to advertise that their PUT support fulfills > certain requirement, so that clients can find out. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Nov 25 12:24:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhJO-0000RL-HT for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:24:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21211 for ; Fri, 25 Nov 2005 12:23:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfhIj-0007Kg-MY for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 17:23:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfhIj-0007K8-8R for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 17:23:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfhIa-00006r-FZ for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 17:23:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPHNcQX013725; Fri, 25 Nov 2005 09:23:38 -0800 Date: Fri, 25 Nov 2005 09:23:38 -0800 Message-Id: <200511251723.jAPHNcQX013725@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfhIa-00006r-FZ de38837378ecd3ee9461cb03e958147c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 27] COPY vs live properties X-Archived-At: http://www.w3.org/mid/200511251723.jAPHNcQX013725@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10639 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 17:23:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=27 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Fri Nov 25 12:25:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhKb-0000x8-SE for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:25:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21252 for ; Fri, 25 Nov 2005 12:25:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfhJz-0007t4-1k for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 17:25:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfhJy-0007sW-Fs for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 17:25:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfhJq-0007Mj-8N for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 17:25:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPHOmnI013790; Fri, 25 Nov 2005 09:24:48 -0800 Date: Fri, 25 Nov 2005 09:24:48 -0800 Message-Id: <200511251724.jAPHOmnI013790@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EfhJq-0007Mj-8N 245a2fa36ff24df1112e1d39ed661111 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 40] Definition of "null resource" gone X-Archived-At: http://www.w3.org/mid/200511251724.jAPHOmnI013790@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10640 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 17:25:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=40 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-25 09:24 ------- Teleconference consensus is to no longer use the term "null resource" (which is distinct from "lock null resource"), and instead use the term "unmapped URI". This involves adding definitions of URI mapping (take this from the binding specification), unmapped URI (easy to define once the URI mapping definition is in place), and then search through the text for uses (search for term "null"). ------- 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@frink.w3.org Fri Nov 25 12:32:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhQm-00055P-CO for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:32:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22097 for ; Fri, 25 Nov 2005 12:31:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfhPv-0001q1-Ni for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 17:31:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfhPv-0001pT-3k for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 17:31:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfhPr-0003Rz-22 for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 17:31:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPHVGQU014025; Fri, 25 Nov 2005 09:31:16 -0800 Date: Fri, 25 Nov 2005 09:31:16 -0800 Message-Id: <200511251731.jAPHVGQU014025@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfhPr-0003Rz-22 6081d208b0ce4d6884123b2728df5583 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200511251731.jAPHVGQU014025@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10641 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 17:31:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 09:31 ------- Telecon consensus: use MUST instead of SHOULD in the proposed text, possibly making note of the new definition in the changes text. ------- 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@frink.w3.org Fri Nov 25 12:33:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhRv-0005Q5-Gy for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:33:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22228 for ; Fri, 25 Nov 2005 12:32:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfhRJ-00020x-4n for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 17:32:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfhRI-00020I-Mf for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 17:32:48 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1EfhRH-00046U-U9 for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 17:32:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfhRB-0006Nf-4K for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 17:32:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPHWcIn014092; Fri, 25 Nov 2005 09:32:38 -0800 Date: Fri, 25 Nov 2005 09:32:38 -0800 Message-Id: <200511251732.jAPHWcIn014092@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfhRB-0006Nf-4K 920221a3b16374d9269b3c550befef87 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 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200511251732.jAPHWcIn014092@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10642 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 17:32:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Fri Nov 25 12:36:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhVI-0000uS-IX for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:36:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22786 for ; Fri, 25 Nov 2005 12:36:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfhUh-0002rM-LA for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 17:36:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfhUe-0002qm-4K for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 17:36:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfhUW-0005Y1-J4 for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 17:36:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPHa6KK014221; Fri, 25 Nov 2005 09:36:06 -0800 Date: Fri, 25 Nov 2005 09:36:06 -0800 Message-Id: <200511251736.jAPHa6KK014221@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfhUW-0005Y1-J4 0a6620ee2222a03dbbe3960a04b5376b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200511251736.jAPHa6KK014221@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10643 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 17:36:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 09:36 ------- ack, wrong state -- sorry! ------- 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@frink.w3.org Fri Nov 25 12:38:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhWT-0001ci-IP for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 12:38:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22908 for ; Fri, 25 Nov 2005 12:37:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfhVn-0003u6-Di for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 17:37:27 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfhVm-0003tO-Nq for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 17:37:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfhVZ-0008Om-8T for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 17:37:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPHbBWH014277; Fri, 25 Nov 2005 09:37:11 -0800 Date: Fri, 25 Nov 2005 09:37:11 -0800 Message-Id: <200511251737.jAPHbBWH014277@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfhVZ-0008Om-8T faad058edd6cb976991fe136e67a6122 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200511251737.jAPHbBWH014277@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10644 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 17:37:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 09:37 ------- marking assigned. ------- 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@frink.w3.org Fri Nov 25 13:17:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efi8w-0007CT-Rw for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 13:17:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27929 for ; Fri, 25 Nov 2005 13:17:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efi7s-0006db-9i for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 18:16:48 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efi7m-0006d0-LZ for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 18:16:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efi7h-0008Pe-0l for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 18:16:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPIGYoY015544; Fri, 25 Nov 2005 10:16:34 -0800 Date: Fri, 25 Nov 2005 10:16:34 -0800 Message-Id: <200511251816.jAPIGYoY015544@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Efi7h-0008Pe-0l 185b68f7c3b19158a995ead288ed39ec X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] OPTIONS * X-Archived-At: http://www.w3.org/mid/200511251816.jAPIGYoY015544@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10645 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 18:16:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 10:16 ------- Jim to ask the HTTP chairs if OPTIONS * will be deprecated in the next revision of 2616, which seems very clear about the expected behavior. Lisa to do same with CalDAV group. Additional comments made during 11/25 telecon: * Current implementations are inconsistent. * Suggestions made to (a) remain silent, or (b) document current state of the world and what clients can expect. * This issue is tangentially related to that of service discovery (i.e. at what URL can I do 'x'), however we should not try to address this in 2518bis. ------- 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@frink.w3.org Fri Nov 25 13:25:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfiFz-0001t6-H5 for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 13:25:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28694 for ; Fri, 25 Nov 2005 13:24:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfiFK-0008KM-8V for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 18:24:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfiFJ-0008Jo-My for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 18:24:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfiFG-0002JV-Pp for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 18:24:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPIO4Qc015811; Fri, 25 Nov 2005 10:24:04 -0800 Date: Fri, 25 Nov 2005 10:24:04 -0800 Message-Id: <200511251824.jAPIO4Qc015811@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EfiFG-0002JV-Pp e4c96f440a44776385b41116c638f48c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] href format X-Archived-At: http://www.w3.org/mid/200511251824.jAPIO4Qc015811@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10646 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 18:24:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From lisa@osafoundation.org 2005-11-25 10:24 ------- Since is extended in several other specs, it's inappropriate to limit its use here. Instead, we can put in other places in the spec contextual limitations on its use. E.g. in the multistatus 'response' containing href it must be either a HTTP URL or relative URL. ------- 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@frink.w3.org Fri Nov 25 13:27:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfiI3-0002z5-OO for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 13:27:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28964 for ; Fri, 25 Nov 2005 13:26:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfiHT-0000bS-4h for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 18:26:43 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfiHS-0000aV-Fx for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 18:26:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfiHK-0004Yc-Aw for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 18:26:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPIQXX1015916; Fri, 25 Nov 2005 10:26:33 -0800 Date: Fri, 25 Nov 2005 10:26:33 -0800 Message-Id: <200511251826.jAPIQXX1015916@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfiHK-0004Yc-Aw d8613ba26c51dbeb38bc1843be315351 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200511251826.jAPIQXX1015916@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10647 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 18:26:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 10:26 ------- Agreed to leave this open as a place holder for things that are missing from the changes section in the 11/25 telecon. ------- 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@frink.w3.org Fri Nov 25 13:39:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfiTc-0006mA-4N for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 13:39:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01043 for ; Fri, 25 Nov 2005 13:38:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfiSv-0004wE-Q7 for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 18:38:33 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfiSu-0004vV-Kj for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 18:38:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfiSo-0000sA-DU for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 18:38:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPIcQuw016326; Fri, 25 Nov 2005 10:38:26 -0800 Date: Fri, 25 Nov 2005 10:38:26 -0800 Message-Id: <200511251838.jAPIcQuw016326@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfiSo-0000sA-DU 0f819ca3f32a27a9ed2762df12ac29ec 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/200511251838.jAPIcQuw016326@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10648 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 18:38:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 ------- Additional Comments From lisa@osafoundation.org 2005-11-25 10:38 ------- Proposed in conf call: Wherever a server produces a URL referring to a collection, the server SHOULD include the trailing slash. In general clients SHOULD use the "/" form of collection names. If clients do not use traliing slash the client be prepared to see redirect. Clients will find DAV:resourcetype a more reliable way of finding out if a resource is a collection. ------- 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@frink.w3.org Fri Nov 25 14:07:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efiud-0001cV-8x for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:07:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04398 for ; Fri, 25 Nov 2005 14:06:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efits-0004D8-EH for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:06:24 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efito-0004CY-1X for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:06:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efite-0004YF-8T for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:06:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJ66MW017238; Fri, 25 Nov 2005 11:06:06 -0800 Date: Fri, 25 Nov 2005 11:06:06 -0800 Message-Id: <200511251906.jAPJ66MW017238@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Efite-0004YF-8T 21ddefa2a72ec3f772e43c74922cf7e1 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/200511251906.jAPJ66MW017238@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10649 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:06:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:06 ------- Rough consensus reached around the approach that Jim sugested in his email of 31, Oct: Briefly, * add appendix documenting the problem, known 'hacks' (If header, 100-continue) and their associated concerns with a preference for the If header approach * don't add normative text * look forward to a better solution in the future Julian to do some testing as he is able, and Lisa to propose text on the list to be hammered out... ------- 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@frink.w3.org Fri Nov 25 14:09:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efiwj-0002Ee-QE for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:09:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04709 for ; Fri, 25 Nov 2005 14:08:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efiw8-0004Rm-DA for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:08:44 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efiw7-0004RE-PH for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:08:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efiw4-0005jX-Gq for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:08:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJ8dTo017344; Fri, 25 Nov 2005 11:08:39 -0800 Date: Fri, 25 Nov 2005 11:08:39 -0800 Message-Id: <200511251908.jAPJ8dTo017344@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Efiw4-0005jX-Gq 20abbfe34c9ea4543d3464dc49a5075d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 22] attributes on properties X-Archived-At: http://www.w3.org/mid/200511251908.jAPJ8dTo017344@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10650 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:08:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=22 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |10 Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:08 ------- no open issue, attributes not preserved. *** This bug has been marked as a duplicate of 10 *** ------- 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@frink.w3.org Fri Nov 25 14:09:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efiwk-0002Er-PX for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:09:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04713 for ; Fri, 25 Nov 2005 14:08:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfiwD-0004SV-IJ for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:08:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfiwD-0004Rx-4V for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:08:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Efiw9-0002Gd-R0 for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:08:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJ8eb1017358; Fri, 25 Nov 2005 11:08:40 -0800 Date: Fri, 25 Nov 2005 11:08:40 -0800 Message-Id: <200511251908.jAPJ8eb1017358@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Efiw9-0002Gd-R0 a18ec9ca5f1a2af4323873ac7ccaeaa8 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/200511251908.jAPJ8eb1017358@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10651 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:08:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |22 nThis| | ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:08 ------- *** Bug 22 has been marked as a duplicate of this bug. *** ------- 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@frink.w3.org Fri Nov 25 14:16:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efj3L-0004jG-OM for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:16:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05347 for ; Fri, 25 Nov 2005 14:15:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efj2h-0007Zz-U2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:15:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Efj2h-0007ZM-FT for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:15:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Efj2e-000502-E5 for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:15:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJFQ4p017602; Fri, 25 Nov 2005 11:15:26 -0800 Date: Fri, 25 Nov 2005 11:15:26 -0800 Message-Id: <200511251915.jAPJFQ4p017602@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Efj2e-000502-E5 741c26b175e8abe5e863c018c2f6f955 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200511251915.jAPJFQ4p017602@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10652 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:15:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:15 ------- Lisa to make proposed changes in next revision. ------- 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@frink.w3.org Fri Nov 25 14:16:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efj3h-0004sW-Br for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:16:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05370 for ; Fri, 25 Nov 2005 14:15:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efj39-0007hy-P5 for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:15:59 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efj39-0007hQ-4Y for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:15:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efj35-0000HO-SH for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:15:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJFtR2017636; Fri, 25 Nov 2005 11:15:55 -0800 Date: Fri, 25 Nov 2005 11:15:55 -0800 Message-Id: <200511251915.jAPJFtR2017636@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Efj35-0000HO-SH 63ac95ee4e314203439cdc09dd7ef575 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200511251915.jAPJFtR2017636@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10653 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:15:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Fri Nov 25 14:23:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfjAR-0007fB-LQ for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:23:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06090 for ; Fri, 25 Nov 2005 14:22:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efj9m-00017Z-94 for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:22:50 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efj9l-00016v-Kf for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:22:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efj9f-0003Za-SD for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:22:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJMdlX017902; Fri, 25 Nov 2005 11:22:39 -0800 Date: Fri, 25 Nov 2005 11:22:39 -0800 Message-Id: <200511251922.jAPJMdlX017902@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Efj9f-0003Za-SD 4e07d0f6880eb399d919f96b4d38c081 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 41] Paragraph numbering/nesting broken in Section 13 X-Archived-At: http://www.w3.org/mid/200511251922.jAPJMdlX017902@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10655 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:22:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Fri Nov 25 14:23:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfjAR-0007fC-Lr for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:23:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06091 for ; Fri, 25 Nov 2005 14:22:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efj9V-00014v-Vy for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:22:33 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efj9V-00014D-B4 for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:22:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efj9T-0003RT-LT for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:22:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJMR51017876; Fri, 25 Nov 2005 11:22:27 -0800 Date: Fri, 25 Nov 2005 11:22:27 -0800 Message-Id: <200511251922.jAPJMR51017876@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 41] Paragraph numbering/nesting broken in Section 13 X-Archived-At: http://www.w3.org/mid/200511251922.jAPJMR51017876@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10654 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:22:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:22 ------- to be alphabetized in next revision. ------- 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@frink.w3.org Fri Nov 25 14:42:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfjT8-0004fe-MV for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:42:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08251 for ; Fri, 25 Nov 2005 14:42:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfjSP-0005Ql-Bt for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:42:05 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfjSM-0005Q4-Gp for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:42:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfjSJ-00031K-Kc for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:42:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJfvQX018449; Fri, 25 Nov 2005 11:41:57 -0800 Date: Fri, 25 Nov 2005 11:41:57 -0800 Message-Id: <200511251941.jAPJfvQX018449@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EfjSJ-00031K-Kc f84bc214d09c4ef35c45ec946aba3c9f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 49] propfind XML description incorrect X-Archived-At: http://www.w3.org/mid/200511251941.jAPJfvQX018449@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10656 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:42:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=49 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:41 ------- Current proposal has been shown to not work as expected, with the only known implementation being from SAP... Julian to propose new text for related issue, 188. ------- 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@frink.w3.org Fri Nov 25 14:46:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfjWb-0005Fx-3m for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:46:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08514 for ; Fri, 25 Nov 2005 14:45:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfjVy-0007Ip-DY for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:45:46 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfjVx-0007IH-P1 for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:45:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfjVo-0004bJ-0f for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:45:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJjXMA018474; Fri, 25 Nov 2005 11:45:33 -0800 Date: Fri, 25 Nov 2005 11:45:33 -0800 Message-Id: <200511251945.jAPJjXMA018474@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfjVo-0004bJ-0f a3f5de40d0f795739967cc57b2a7d913 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200511251945.jAPJjXMA018474@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10657 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:45:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Fri Nov 25 14:54:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfjeN-0001pS-2K for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:54:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09462 for ; Fri, 25 Nov 2005 14:53:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efjdf-00081X-Kz for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:53:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Efjdf-00080u-3c for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:53:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Efjdb-0006lf-W7 for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:53:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJrMcY018501; Fri, 25 Nov 2005 11:53:22 -0800 Date: Fri, 25 Nov 2005 11:53:22 -0800 Message-Id: <200511251953.jAPJrMcY018501@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Efjdb-0006lf-W7 31d31f01538937c1a3c2701d5b13c27a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200511251953.jAPJrMcY018501@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10658 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:53:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:53 ------- Julian to propose new text after sleeping on 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@frink.w3.org Fri Nov 25 14:57:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfjhJ-0002bU-3z for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:57:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09747 for ; Fri, 25 Nov 2005 14:56:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efjgi-0000eR-HH for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:56:52 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Efjgh-0000dT-TK for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:56:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Efjgb-0000uM-Ea for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:56:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJujbt018524; Fri, 25 Nov 2005 11:56:45 -0800 Date: Fri, 25 Nov 2005 11:56:45 -0800 Message-Id: <200511251956.jAPJujbt018524@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Efjgb-0000uM-Ea dc4f3ed09871250f1eca7e2dd639f309 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 86] DAV header definitions should use RFC3864 templates X-Archived-At: http://www.w3.org/mid/200511251956.jAPJujbt018524@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10659 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:56:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=86 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:56 ------- to be reviewed before submission - if no new headers have been introduced, then this is a no-op, otherwise register them! ------- 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@frink.w3.org Fri Nov 25 14:59:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efjj1-0002sn-EI for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 14:59:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09896 for ; Fri, 25 Nov 2005 14:58:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfjiP-0000vm-OR for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:58:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfjiO-0000vE-W3 for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:58:37 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfjiL-0008Pw-JU for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:58:36 +0000 Received: from [192.168.2.104] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jAPJwC6I018583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Nov 2005 11:58:12 -0800 (PST) Message-ID: <43876CD4.4050109@cse.ucsc.edu> Date: Fri, 25 Nov 2005 11:58:12 -0800 From: Elias Sinderson Reply-To: webdav WG User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG References: <43869077.5090208@cse.ucsc.edu> In-Reply-To: <43869077.5090208@cse.ucsc.edu> Content-Type: multipart/alternative; boundary="------------090805000605010801000603" Received-SPF: none (maggie.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EfjiL-0008Pw-JU 4f0f0ef5fbcbd849f6e455b2d4574b32 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Issues for 11/25 Conference Call (notes) X-Archived-At: http://www.w3.org/mid/43876CD4.4050109@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10660 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:58:37 +0000 This is a multi-part message in MIME format. --------------090805000605010801000603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, We (Julian, Lisa, Jim, Cullen and I) discussed the enclosed list of issues during the 11/25 telecon - issues on which we reached some sort of consensus are marked with a (+), while those that were floored for future discussion are marked with a (_). Best, Elias ___________________ > Critical: > 27 - Copy > vs live properties (+) > 40 - > definition of null resource gone (+) > 44 - > OPTIONS * (_) > 62 - href > format (+) > 73 - > "Changes" section missing (+) > 86 - DAV > header definitions should use RFC3864 templates (+) > > Major: > 13 - New > ETag requirements (_) > 16 - > Trailing slash required in collection names? (+) > 18 - no > record of consensus for force authenticate (+) > 22 - > attributes on properties (+) > 23 - Lock > discovery vs shared locks (+) > 25 - Lock > to unmapped URL (+) > > Normal (but fairly easy to resolve): > 41 - > Paragraph numbering/nesting broken in Section 13 (+) > 49 - > propfind XML description incorrect (+) > 50 - > Property terminology inconsistent with RFC3253 (+) --------------090805000605010801000603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All,

We (Julian, Lisa, Jim, Cullen and I) discussed the enclosed list of issues during the 11/25 telecon - issues on which we reached some sort of consensus are marked with a (+), while those that were floored for future discussion are marked with a (_).


Best,
Elias
___________________

Critical:
27 - Copy vs live properties (+)
40 - definition of null resource gone (+)
44 - OPTIONS * (_)
62 - href format (+)
73 - "Changes" section missing (+)
86 - DAV header definitions should use RFC3864 templates (+)

Major:
13 - New ETag requirements (_)
16 - Trailing slash required in collection names? (+)
18 - no record of consensus for force authenticate (+)
22 - attributes on properties (+)
23 - Lock discovery vs shared locks (+)
25 - Lock to unmapped URL (+)

Normal (but fairly easy to resolve):
41 - Paragraph numbering/nesting broken in Section 13 (+)
49 - propfind XML description incorrect (+)
50 - Property terminology inconsistent with RFC3253 (+)

--------------090805000605010801000603-- From w3c-dist-auth-request@frink.w3.org Fri Nov 25 15:00:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efjjo-0003GD-Sp for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 15:00:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09991 for ; Fri, 25 Nov 2005 14:59:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfjjE-00012b-Gm for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 19:59:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfjjD-000123-T5 for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 19:59:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Efjj6-0000H9-3a for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 19:59:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPJx4Yb018546; Fri, 25 Nov 2005 11:59:04 -0800 Date: Fri, 25 Nov 2005 11:59:04 -0800 Message-Id: <200511251959.jAPJx4Yb018546@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Efjj6-0000H9-3a 1cab5747d6cb8752dc675e9abb985f9b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 13] new ETag requirements X-Archived-At: http://www.w3.org/mid/200511251959.jAPJx4Yb018546@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10661 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 19:59:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 11:59 ------- Jim sent an email to the HTTP guys asking for some input on this issue... to be revisited at a later date. ------- 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@frink.w3.org Fri Nov 25 16:47:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflQ7-00088h-Nt for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 16:47:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21503 for ; Fri, 25 Nov 2005 16:47:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EflOp-00048E-GE for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 21:46:31 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EflOj-000443-Cs for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 21:46:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EflOU-00027h-Gs for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 21:46:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPLk70m018648; Fri, 25 Nov 2005 13:46:07 -0800 Date: Fri, 25 Nov 2005 13:46:07 -0800 Message-Id: <200511252146.jAPLk70m018648@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EflOU-00027h-Gs f0d4b17c4c3d87d42de01f555cca6db6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 40] Definition of "null resource" gone X-Archived-At: http://www.w3.org/mid/200511252146.jAPLk70m018648@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10662 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 21:46:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=40 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Fri Nov 25 16:48:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflQj-0000Lc-Ae for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 16:48:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21535 for ; Fri, 25 Nov 2005 16:47:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EflQ7-0004Vh-0a for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 21:47:51 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EflQ6-0004UV-Eb for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 21:47:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EflQ2-0004c6-1w for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 21:47:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPLkm4H018670; Fri, 25 Nov 2005 13:46:48 -0800 Date: Fri, 25 Nov 2005 13:46:48 -0800 Message-Id: <200511252146.jAPLkm4H018670@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EflQ2-0004c6-1w 8e1d084b340e4a70d899793b726e7be3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] href format X-Archived-At: http://www.w3.org/mid/200511252146.jAPLkm4H018670@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10663 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 21:47:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Fri Nov 25 16:49:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflRT-0000O8-Oz for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 16:49:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21556 for ; Fri, 25 Nov 2005 16:48:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EflQu-0004iq-6v for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 21:48:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EflQt-0004iD-Lr for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 21:48:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EflQp-000502-Pw for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 21:48:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPLldwh018690; Fri, 25 Nov 2005 13:47:39 -0800 Date: Fri, 25 Nov 2005 13:47:39 -0800 Message-Id: <200511252147.jAPLldwh018690@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EflQp-000502-Pw 0f8f7f44c347423d171831e8d4625386 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200511252147.jAPLldwh018690@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10664 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 21:48:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- 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@frink.w3.org Fri Nov 25 16:51:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflTe-0001Fw-UM for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 16:51:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21789 for ; Fri, 25 Nov 2005 16:50:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EflT6-0005eZ-9z for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 21:50:56 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EflT5-0005di-LZ for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 21:50:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EflT2-0004W9-0B for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 21:50:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPLopSV018719; Fri, 25 Nov 2005 13:50:51 -0800 Date: Fri, 25 Nov 2005 13:50:51 -0800 Message-Id: <200511252150.jAPLopSV018719@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EflT2-0004W9-0B 72be4b2f0f0591d38a31ff34cef3937f 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/200511252150.jAPLopSV018719@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10665 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 21:50:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Fri Nov 25 16:52:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflV5-0001hx-SO for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 16:52:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21988 for ; Fri, 25 Nov 2005 16:52:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EflUR-0005u5-CW for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 21:52:19 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EflUO-0005tX-Be for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 21:52:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EflUL-000521-FY for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 21:52:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPLqDQt018745; Fri, 25 Nov 2005 13:52:13 -0800 Date: Fri, 25 Nov 2005 13:52:13 -0800 Message-Id: <200511252152.jAPLqDQt018745@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EflUL-000521-FY 78810173db56d2c59eaaea9f0676554b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200511252152.jAPLqDQt018745@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10666 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 21:52:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Fri Nov 25 16:57:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflZL-0002Yx-MW for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 16:57:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22489 for ; Fri, 25 Nov 2005 16:56:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EflYi-0006yD-3N for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 21:56:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EflYT-0006rq-KM for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 21:56:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EflYP-0000EW-Mn for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 21:56:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPLu2ws018794; Fri, 25 Nov 2005 13:56:02 -0800 Date: Fri, 25 Nov 2005 13:56:02 -0800 Message-Id: <200511252156.jAPLu2ws018794@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EflYP-0000EW-Mn 5faab5c70ddff424663601aa3ddcac5f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 60] If header evaluation when? X-Archived-At: http://www.w3.org/mid/200511252156.jAPLu2ws018794@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10667 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 21:56:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=60 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |18 nThis| | ------- 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@frink.w3.org Fri Nov 25 16:57:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflZL-0002Yy-NO for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 16:57:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22488 for ; Fri, 25 Nov 2005 16:56:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EflYm-0006yf-Fx for w3c-dist-auth-dist@listhub.w3.org; Fri, 25 Nov 2005 21:56:48 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EflYV-0006sw-36 for w3c-dist-auth@listhub.w3.org; Fri, 25 Nov 2005 21:56:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EflY2-0006Sy-LF for w3c-dist-auth@w3.org; Fri, 25 Nov 2005 21:56:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAPLu1QD018780; Fri, 25 Nov 2005 13:56:01 -0800 Date: Fri, 25 Nov 2005 13:56:01 -0800 Message-Id: <200511252156.jAPLu1QD018780@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EflY2-0006Sy-LF f5bc82ff518c3bba66c67d073c7699b4 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/200511252156.jAPLu1QD018780@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10668 X-Loop: w3c-dist-auth@w3.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, 25 Nov 2005 21:56:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |60 ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 13:56 ------- Resolution of this issue is related to that of issue 60... ------- 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@frink.w3.org Fri Nov 25 21:57:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfqFI-0004Gt-Se for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 21:57:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18089 for ; Fri, 25 Nov 2005 21:56:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfqDo-0008En-G3 for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 02:55:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfqDi-0008EF-QP for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 02:55:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfqDg-0007Do-HS for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 02:55:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ2tJrm018970; Fri, 25 Nov 2005 18:55:19 -0800 Date: Fri, 25 Nov 2005 18:55:19 -0800 Message-Id: <200511260255.jAQ2tJrm018970@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfqDg-0007Do-HS 3f77228d7f179e8d18933e47a8d43034 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/200511260255.jAQ2tJrm018970@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10669 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 02:55:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 18:55 ------- verified text made in draft -08 ------- 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@frink.w3.org Fri Nov 25 22:01:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfqJm-00063L-Dr for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 22:01:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18419 for ; Fri, 25 Nov 2005 22:00:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfqJ9-0001wZ-LJ for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 03:00:59 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfqJ8-0001ui-Q7 for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 03:00:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfqJ2-00060t-PZ for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 03:00:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ30oJx018991; Fri, 25 Nov 2005 19:00:50 -0800 Date: Fri, 25 Nov 2005 19:00:50 -0800 Message-Id: <200511260300.jAQ30oJx018991@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfqJ2-00060t-PZ 56d22fd9f74c251be238188adf48a0f7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200511260300.jAQ30oJx018991@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10670 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 03:00:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 19:00 ------- Text from -08 reads: A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. The state token is an example of a state token that will never match an actual valid lock token. ------- 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@frink.w3.org Fri Nov 25 22:04:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfqMe-0006iS-0m for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 22:04:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18920 for ; Fri, 25 Nov 2005 22:03:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfqM1-0002Ht-Ek for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 03:03:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfqLz-0002HF-Tv for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 03:03:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfqLy-0001ci-3c for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 03:03:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ33s7O019025; Fri, 25 Nov 2005 19:03:54 -0800 Date: Fri, 25 Nov 2005 19:03:54 -0800 Message-Id: <200511260303.jAQ33s7O019025@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfqLy-0001ci-3c 7e21183c381fc0c111f330ae01ae035f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 20] lock token example X-Archived-At: http://www.w3.org/mid/200511260303.jAQ33s7O019025@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10671 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 03:03:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- 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@frink.w3.org Fri Nov 25 22:07:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfqPH-0006tX-8w for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 22:07:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19199 for ; Fri, 25 Nov 2005 22:06:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfqOa-00034J-7w for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 03:06:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfqOZ-00033g-NI for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 03:06:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfqOX-0002Qg-Ii for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 03:06:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ36WFC019048; Fri, 25 Nov 2005 19:06:32 -0800 Date: Fri, 25 Nov 2005 19:06:32 -0800 Message-Id: <200511260306.jAQ36WFC019048@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfqOX-0002Qg-Ii bb1d83df8f60a19c41b0c9135fd50532 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 29] refreshing locks X-Archived-At: http://www.w3.org/mid/200511260306.jAQ36WFC019048@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10672 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 03:06:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=29 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 19:06 ------- verified text in -08 ------- 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@frink.w3.org Fri Nov 25 22:13:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfqVR-0001Ue-Fo for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 22:13:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19737 for ; Fri, 25 Nov 2005 22:13:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfqUn-0003tF-RY for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 03:13:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfqUn-0003sh-DX for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 03:13:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfqUl-0004Oz-Pm for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 03:13:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ3CxeZ019072; Fri, 25 Nov 2005 19:12:59 -0800 Date: Fri, 25 Nov 2005 19:12:59 -0800 Message-Id: <200511260312.jAQ3CxeZ019072@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfqUl-0004Oz-Pm 75922cd68faf297fff0390ed582ebce9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 34] property "URI" X-Archived-At: http://www.w3.org/mid/200511260312.jAQ3CxeZ019072@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10673 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 03:13:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=34 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 19:12 ------- verified the phrase does not appear in -08 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@frink.w3.org Fri Nov 25 22:14:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfqWM-0001ho-0b for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 22:14:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19775 for ; Fri, 25 Nov 2005 22:13:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfqVn-000423-Fa for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 03:14:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfqVm-00041M-B7 for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 03:14:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfqVj-00076x-Rk for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 03:14:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ3Dlbh019089; Fri, 25 Nov 2005 19:13:47 -0800 Date: Fri, 25 Nov 2005 19:13:47 -0800 Message-Id: <200511260313.jAQ3Dlbh019089@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EfqVj-00076x-Rk 4bbe81917338322af95808e05b0342ee X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 36] Appendix numbering X-Archived-At: http://www.w3.org/mid/200511260313.jAQ3Dlbh019089@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10674 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 03:14:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=36 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- 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@frink.w3.org Fri Nov 25 22:47:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efr1t-0003lU-PJ for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 22:47:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21843 for ; Fri, 25 Nov 2005 22:46:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efr12-0002a8-4W for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 03:46:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Efr0t-0002YU-Nj for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 03:46:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Efr0l-0000GJ-Ak for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 03:46:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ3k2nq019158; Fri, 25 Nov 2005 19:46:02 -0800 Date: Fri, 25 Nov 2005 19:46:02 -0800 Message-Id: <200511260346.jAQ3k2nq019158@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Efr0l-0000GJ-Ak ff0f9df36180623671e9cf4bbb652623 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 38] RFC2396bis update X-Archived-At: http://www.w3.org/mid/200511260346.jAQ3k2nq019158@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10675 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 03:46:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=38 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Fri Nov 25 22:47:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efr27-0003wn-IA for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 22:47:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21869 for ; Fri, 25 Nov 2005 22:46:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efr1Z-0002hB-Cn for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 03:46:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Efr1Y-0002gd-Ku for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 03:46:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Efr1V-0001hA-W5 for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 03:46:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ3kerG019177; Fri, 25 Nov 2005 19:46:40 -0800 Date: Fri, 25 Nov 2005 19:46:40 -0800 Message-Id: <200511260346.jAQ3kerG019177@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Efr1V-0001hA-W5 f70e10c3f8b6516abf313032401f014d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 38] RFC2396bis update X-Archived-At: http://www.w3.org/mid/200511260346.jAQ3kerG019177@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10676 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 03:46:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=38 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- 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@frink.w3.org Fri Nov 25 23:11:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfrPE-0003ft-0t for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 23:11:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23463 for ; Fri, 25 Nov 2005 23:10:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfrO5-0007Wb-Fb for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 04:10:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfrNz-0007Vx-VU for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 04:10:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfrNv-0004JN-I1 for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 04:10:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ49vG9019241; Fri, 25 Nov 2005 20:09:57 -0800 Date: Fri, 25 Nov 2005 20:09:57 -0800 Message-Id: <200511260409.jAQ49vG9019241@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EfrNv-0004JN-I1 5bd0a1aaf270ce363479977b3138ad56 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 67] non-ASCII characters X-Archived-At: http://www.w3.org/mid/200511260409.jAQ49vG9019241@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10677 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 04:10:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=67 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 20:09 ------- -08 seems good, however it would be prudent to check this again prior to submission. ------- 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@frink.w3.org Fri Nov 25 23:12:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfrPu-0003nn-Ql for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 23:12:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23517 for ; Fri, 25 Nov 2005 23:11:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfrPL-0007pJ-A1 for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 04:11:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfrPK-0007og-Qf for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 04:11:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfrPK-00051J-6f for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 04:11:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ4BOrN019261; Fri, 25 Nov 2005 20:11:24 -0800 Date: Fri, 25 Nov 2005 20:11:24 -0800 Message-Id: <200511260411.jAQ4BOrN019261@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 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200511260411.jAQ4BOrN019261@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10678 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 04:11:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Fri Nov 25 23:13:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfrRY-0003we-9w for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 23:13:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23559 for ; Fri, 25 Nov 2005 23:13:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfrQv-00088a-6C for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 04:13:05 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EfrQu-00087t-Kb for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 04:13:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EfrQh-0001FG-Uo for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 04:13:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ4Cb0T019284; Fri, 25 Nov 2005 20:12:37 -0800 Date: Fri, 25 Nov 2005 20:12:37 -0800 Message-Id: <200511260412.jAQ4Cb0T019284@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EfrQh-0001FG-Uo c88388864a8d49d4fc175a8780a05ea9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200511260412.jAQ4Cb0T019284@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10679 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 04:13:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-11-25 20:12 ------- text in accordance with discussion on 11/23 telecon to be added to next draft. ------- 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@frink.w3.org Fri Nov 25 23:25:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfrdI-0008Vs-0N for webdav-archive@megatron.ietf.org; Fri, 25 Nov 2005 23:25:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24386 for ; Fri, 25 Nov 2005 23:25:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfrcV-00042I-35 for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 04:25:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EfrcU-0003oW-GB for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 04:25:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EfrcT-0004Rb-Tu for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 04:25:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ4OwO7019325; Fri, 25 Nov 2005 20:24:58 -0800 Date: Fri, 25 Nov 2005 20:24:58 -0800 Message-Id: <200511260424.jAQ4OwO7019325@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 93] Write Locks and Collections vs MOVE X-Archived-At: http://www.w3.org/mid/200511260424.jAQ4OwO7019325@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10680 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 04:25:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=93 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major ------- 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@frink.w3.org Sat Nov 26 01:02:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eft8p-0006Ys-JC for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 01:02:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01750 for ; Sat, 26 Nov 2005 01:01:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eft5q-0003pe-Pj for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 05:59:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eft5k-0003oe-OP for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 05:59:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eft5i-0000rX-63 for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 05:59:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQ5xCYx020312; Fri, 25 Nov 2005 21:59:12 -0800 Date: Fri, 25 Nov 2005 21:59:12 -0800 Message-Id: <200511260559.jAQ5xCYx020312@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eft5i-0000rX-63 4be0c156ae6c5a7146dbfb1c61d3dd27 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 51] Property behaviour upon COPY vs "remote COPY" X-Archived-At: http://www.w3.org/mid/200511260559.jAQ5xCYx020312@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10681 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 05:59:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=51 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major ------- 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@frink.w3.org Sat Nov 26 04:08:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efw2x-0003Oc-OT for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 04:08:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17045 for ; Sat, 26 Nov 2005 04:07:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efw0e-0007ZR-3O for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 09:06:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Efw0X-0007Xf-0Y for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 09:06:09 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1Efw0U-0007PN-4s for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 09:06:08 +0000 Received: (qmail invoked by alias); 26 Nov 2005 09:05:50 -0000 Received: from p508F9706.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.151.6] by mail.gmx.net (mp034) with SMTP; 26 Nov 2005 10:05:50 +0100 X-Authenticated: #1915285 Message-ID: <43882537.4000005@gmx.de> Date: Sat, 26 Nov 2005 10:04:55 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Geoffrey M Clemm , WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Efw0U-0007PN-4s d7c1fc9c047b402cd225885eedc29161 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/43882537.4000005@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10682 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 09:06:16 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I have heard that this is wanted for applications other than a file system. > Right now I was sort of looking for examples of applications that did not > want to use this. I think in this case the question needs to be rephrased: what would these clients prefer? 1) keeping the spec as is, meaning that there aren't any guarantees about this behaviour 2) changing the spec to mandate this, leading 2a) to some servers claiming to support this, but failing to do so (non-compliant implementations), or 2b) to some servers stopping to support WebDAV altogether. I'd also like to point out again that there is a class of resources that simply can't support strong ETags (for instance, WebDAV interfaces to XML-Infoset-based databases). Thinking of this, even the SHOULD that we have somewhere else in the spec is a very bad decision, and everybody should understand that this makes it impossible to maintain WebDAV interfaces to certain classes of resources (this is likely to be raised during IETF last call, so we better make sure the problem is understood). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Nov 26 04:16:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfwAx-0005IQ-SF for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 04:16:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17848 for ; Sat, 26 Nov 2005 04:16:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Efw9N-0001Br-Nd for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 09:15:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Efw9M-00018y-Vs for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 09:15:17 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Efw9M-0007Fn-7Z for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 09:15:16 +0000 Received: (qmail invoked by alias); 26 Nov 2005 09:15:11 -0000 Received: from p508F9706.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.151.6] by mail.gmx.net (mp018) with SMTP; 26 Nov 2005 10:15:11 +0100 X-Authenticated: #1915285 Message-ID: <43882769.5010500@gmx.de> Date: Sat, 26 Nov 2005 10:14:17 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: bugzilla@soe.ucsc.edu, WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: [Bug 184] New: Section 19.8 added with no open issue nor WG consensus X-Archived-At: http://www.w3.org/mid/43882769.5010500@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10683 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 09:15:17 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Do you think it is wrong? It's not necessarily wrong, but it definitively needs to be discussed and understood. This is a Security Consideration, and if we add something new *here*, we better make sure it's correct. Quoting: : > HTTP has the ability to host scripts which are executed on client > machines. These scripts can be used to read another user's cookies > and therefore may provide an attacker the ability to use another > user's session, assume their identity temporarily and gain access to > their resources. Other attacks are also possible with client- > executed scripts. 1) How would a script be able to read another user's cookies? If this is about potential bugs in user agents, it should say so. The way it's written now confuses me, because I don't understand the risk yet. 2) And yes, letting people store arbitrary content on a shared server introduces the same security problems when people share a file server, or people download code from the Web. In particular, this includes executables, or file types with security issues (such as the recent JPG-related attacks). RFC2518bis *could* talk about that, but then this really needs to be expanded a lot. > WebDAV may worsen this situation only by making it easier for a Web > server to host content provided by many different authors (making it > harder to trust the content providers) and to host content with > restricted access alongside public pages (see particularly RFC3744). How is the latter a security problem? > HTTP servers may mitigate some of these threats by filtering content > in areas where many authors contribute pages -- the server could, for > example, remove script from HTML pages. It could also run virus scanners on new content. > This vulnerability should provide yet another reason for server > implementors and administrators not to replace authentication > mechanisms with cookie-based session tokens if there's any sensitive > information relying on the authenticated identity. This relates back to the cookie discussion above. I prefer HTTP auth as well, but I don't think this is the right place to evangelize it. > HTTP and WebDAV client implementors might consider locking down the > use of scripts and cookies based on these considerations. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Nov 26 06:29:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfyEu-0005oO-1e for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 06:29:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28457 for ; Sat, 26 Nov 2005 06:28:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EfyDe-0006w1-GF for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 11:27:50 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EfyDY-0006vN-I7 for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 11:27:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EfyDU-00017s-2k for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 11:27:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQBRbgi020516; Sat, 26 Nov 2005 03:27:37 -0800 Date: Sat, 26 Nov 2005 03:27:37 -0800 Message-Id: <200511261127.jAQBRbgi020516@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EfyDU-00017s-2k ff7507f3c7a7ceec073a7e15fd59eed2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 199] New: Front matter editorial nits X-Archived-At: http://www.w3.org/mid/200511261127.jAQBRbgi020516@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10684 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 11:27:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=199 Summary: Front matter editorial nits Product: WebDAV-RFC2518-bis Version: -08 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org 1. There's no reason why the document title shouldn't be the same as in RFC2518 (this also affects the abbreviated name for the pages titles in the ASCII version). 2. The abstract says: "RFC2518 was published in February 1999, and this draft makes minor revisions mostly due to interoperability experience." "this draft" should be replaced by "this specification" (we really should make the RFC Editor's job as simple as possible) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ktaihcul@hotmail.com Sat Nov 26 07:20:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efz30-0002Jw-9k for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 07:20:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03490 for ; Sat, 26 Nov 2005 07:20:11 -0500 (EST) Message-Id: <200511261220.HAA03490@ietf.org> Received: from m93.net85-168-141.noos.fr ([85.168.141.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfzMR-0007Qp-Hi for webdav-archive@ietf.org; Sat, 26 Nov 2005 07:41:01 -0500 FCC: mailbox://ktaihcul@hotmail.com/Sent X-Identity-Key: id1 Date: Sat, 26 Nov 2005 16:14:58 +0400 From: Robert Rocha X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav-archive@ietf.org Subject: re[4] Content-Type: multipart/related; boundary="------------060503050202010201050000" X-Spam-Score: 2.5 (++) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb This is a multi-part message in MIME format. --------------060503050202010201050000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

in 1924 what do you do? Jobs What would you like?

How's your? Cindy Margolis

--------------060503050202010201050000 Content-Type: image/gif; name="monoxide.GIF" Content-ID: Content-Disposition: inline; filename="monoxide.GIF" Content-Transfer-Encoding: base64 R0lGODlhLQJjAvWJAAYEAMDAwMDcwKbK8EAgAABAACBAAKBAAABgACBgACAgQEAgQOAgQABAQCBAQEBAQGBAQOBAQABgQCBgQEBgQGBgQOBgQACAQCCAQECAQGCAQICAQACgQCCgQECgQGCgQCDAQEDAQGDAQGBg gIBggOBggECAgGCAgICAgKCAgOCAgGCggICggKCggMCggOCggEDAgGDAgIDAgKDAgMDAgKDggKCgwMCg wOCgwKDAwP/78KCgpP8AAAAA/////wAAACH5BAQAAAAALAAAAAAsAmICAAb/QJ9wSCwaj8ikcslsOp/Q qHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGS k5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2gwe3YDy8vb69Rb+/Q8LFvMG+SMbIwEfF RsbHQtHU0kkH2Nna2k3b2Efe3ODh5ELkuT7hztXJ68PM1VTP0O9E7PXw7cT619v01kwATlumBJ89fksE DlzXRp9BHwj38ZCocF/BiBb/TRxYESNEgfw8FhFnLpsSkiRHmuy2kkjLdClLoruosNlBaxhD2nTicCfF /43QNAYUWdHlt1wtCdLU+PAmR2ZPE/pEKHKMzpo+7eVTNjTrNHdg4SUBSlHskpgxh7xU+81IWiRv28qU q5anV5AdseItGhZqPrLEhHYtCnicuZIc5ymbqrRvT6BVP+4FHDkMVcZ8C+cs7I6zXs+YOX81e1M0W7pz 3a5NrRJ1P9eHjb6cOZhrWcG3SzfZDFJyTdxS855tOxMdzqqXFQNvdjU45dBskj/P3Dmo3d+kl3sdrTv7 ONdoV5+mDRP2d9rFVdMlT5Ms5NzaP9deDHBjRM3bqwdjsjL95LFURXHVRAO2511lu0DXnTP6BfZEgMBl R1SEvg0H3lpvsTaeEymx1/8aOh4CWF+D8eHHF3wSJkYZhSKuyJ9JIS64X0hSFFhgiwfmZ9VO9+UnGo1Q AFmaafVM6F2FJ63WYYblrSfeeWxZ+CSOC21F33HytUekQz9pdaSBDkppnowODmiahMDceGWOJ4rxGGjU NXjmmtwN2SJkPkZYWXio+QPXkmN+KNOLgdKZVVMqolgZor6912WdiQVp05yyTRmVdWbqiGSkai7GED0N RUMng2tSWuqVW06aJ5ptatikemP66WqS6ogpYGOJogofgowWaaWJpuoW7HiBEpYbNc7d9qZUnyITKpZZ klrdsGL9SNSytg3JKKze/DmlrK+yRFyhc8Wo36HXqor/q5Z3htklsLceQ225Id61YDxUIoktgM0e9Ox0 AI8Fpjw+pgutwGYhyFqG4H6InqWVRkkoufcCm+rBmw52saN2whvvvJV62NGXKs6J67qgpuxsdKG5t+qo Uxi8MYpedrdtxE162HDIOE/sEn85P8gjU+1G2uh1mXHJlMeStvraWoThS2JXSzGrsr8sT+ZynDDXqKPB ZNZ8LIIoxfUtht/2nM5ZxCItNs27qut0xil2xrR1LHIYbpVhslP1bgXP/Yd0WxM5cMxfB144wjLevHfQ gnpLHsMPx+qW2od33TiPvCr+dtgeRS342nWV9zmeyF7ktuaIEB42pHmvni+ZoU+9/yfasJl9oXlOWv4z z/Mlq6eCwdP+N9wfsX7N70mhbLRkzSZ9pqYZrWy9GmayaDL1mffllPa2R8Zn7uTrLF6fT653nrnPB+d9 +0cDDifenn4pPbVygTiTqPneRzPY8gvY68rwJmvVh1IKUx5pAMi3I20rLTvbG+V2FznZGGV97EvgvkCn sA26q1/wg54Cv3OYlaRuVMJwV6dI1jXppOEeGtue81DlOOXcCU7KSWHIwNUtbpXvHOIAYg97SC/YnNA5 6GqMDmNoMa7dI4k2fFrz+NfCJVaPgZICYQN1wcUuPoJ9XgyjGMdIxjKa8YxoTKMa18jGNrrxjXCMoxzn SMc62v/xjnjMox73yMc++vGPgAykIAdJyEIa8pCITKQiF8nIRjrykZCMpCQnSclKWvKSmMykJjfJyU56 8pOgDKUoR0nKUppSkzrAgQ5OycpEqkAYFlCBKltJyz6+IAIMMEYESoCDWvqSjzp4gQoi8AsVrPKXyMwj DlSQS15EoJfJjKYdcVCCXjxTmqYk4p/YqINX8qIEx8RmKPNnLoqFsZu9gKY4P0nOJMFRB8TkwQvWyc7i 2LOdGhrXOavJA3DSk5P41CdMEDPQgpoTFi/ghQX+uUkiCvSh9wQjLXDACxUwNJMCNaj+6HVBM1KUB+q8 KCUDulGNQsmM3gynHajYKCtWCHX/6zrHDseHO+LkTJupASNOeQhBIN4UKd0SouR2p6ShNqxWQnSoT7NA UoJC1KkSrQUxLaoH5uwFa3zDiUQ+eJpBWdCrX+2qWE0nsbIGajbo6xNcxnrP1ri1rCfFHFzfStawwhWt patrVF/U0bJtCKpn/KhKV4ql7/VtRNyZlLfGWtfGNlZJbf0dWElHQro+jrIjYStjHYshWvWufK+xK2fV k9nY6LWUU61qYbcKkcQi1i+0YixaJ9c7cIgVRHaNEe/Q81hCVXaz/TGtbWfj2FnJNq1z9SpuSctKijJA taj73t3e99vZirYl6bttXENbXbDqFLTXtSnQiHu+9NX2q7oV/+9iW8mLwdLBqtNJXuxEGFvOkpM92CUX jELEpMmGVX/q5a5l7QvUbijXv6Qrb2QtWM6jNHivmyRmSOsQRZc+6h8Tg2wE9arfDUPut3SNKGbX67Cd eph54i1qcX9qVCk+mJYWAGke1OWUE/HGt6E174JzzL4JkrhyIwYxcJFLMQAjxb877qqOV2y6sx6UQ7Wa Aj7P+Eqq3oFz0W3tfv7XKkv1B7xMRq9t/zpgzcqVuQPGnXCXl0+1bpasCkYwnOvrhSdvk6BU5oGVCbs1 1joqvrAVcHUp+Oa3pmfN5r3zmsNcaDWLedF5LRttccph/N6XuYcW7RbsbBg8o1TPMz5glv+9JGoMW4jO GtY0ZVVcUDkXl7iqwXGakVvaMXtXfbNO8mNpLdlCM3XSD2u1WUUM2DZzmhJVDvWo6Vsl+FIXzSB2NHDD e1snA7nXyYX2kCetEjZ7Gtbhvfa2qV1mLeDapBoOYkmfatJTJJvPipGafaC4nSgT675APaqshFq6/t7b YZdzcUT36w9+c6vfS+VolLmhjqSa+MRUIGqxO9pudrPbFO8W6STRV3FLS2yI6/bTsSuRcY1H0knFvtDH Pd5uipei5CZ/JMrRrfKUb/TLE385qGN+cmDbU9h4xvcFhe5pUsCc554cuRiPjnRM/ryOTG/6Jf3NxqhL /eqqsDrWt67/8z1z/esY3zkeHG5kEQ+c0j+lqc9PvER8WHge7+AeIzn+BKVHnOplsLsVtC4H69a61fkz c7R3LG1L2Yu1l0K8CkeXSLpDGQ1TtgKEEc4GvsfB75IF94LTOzkEY57RUzGs4pldJ7nP/el1n7zkVc/X KOg9C5aHw+dNC25VYzo2u81tsXpTveuRXsuJt+SUAXXzyhHbr+STXJQ+Gy7kG5nmZYj9G2a/aohB7MC+ zq+46bN4A4q+9Ixv/NPHX/wCd3zlg6p5tzVqfn2qd1ztD7n5xSB9N1Df+HSO7XnRrH35AT/4incoW6ZJ DhY5dGdx5JdzRWdzUBVsf4WACvgF9dcG//cHcELWYtmHb9e3VYBmagDoIgQ4fwOVUTanbujXctkGgQvz cyp4cWEwgWxQgbBygSS0fyHmYBCWRNw3ev/Xg1M3fy54fusnhOrXVyHnVi14hCgIBjC4BjKIWT0lUcGV gZG1gR8oOt/XgyCzSHh1fkl4giQ4bER4hF84hmTQhHkHf5qWaZ5XZAEGdHd1af53NVj1gaNUU8dXUhKE fxFYLmSWUX4FOYAYfwvoBWhIBl+2fbSniIxGhdDWf3MYaMEngDwIdrVwiGMQeZN1bXEma4/Ia40IgIl3 F68lipY4C5iIiDrWWZfFYkbFeXhIdHYjOonTI1t4imHndbi4i5uQiv+8+IuG4IvAiEZoBwWxsm8sV4BG J3bDuEeaGHCKFmsR6H6sJwnC2Ixl9IwuJ42dtoRD2HXYyEfDl4jPp4BNdY7Ft3x8yAjXGI5iFFBgSIYs x35eCGD0GISI0I7u6EUPp4TwZz6B+FRlGIb5yIz7WEe5B1HqlnzSKJD+KH9W+Af6eJC6wJD4qIzbyIAj +JB9qAgTSZG2YJEcuZHcaISApYYoqYSL8JEgSQu7lV9tVnQieZLpiBjM1wgs2ZINNY+WkJM6iVE8SXIG +ZPYVIRCqYtEmZR44JNK2ZRawJROqQp4l0dQGZWnQJB/VJVWSQozJ0hauZWiMHM4KGxLAngR2Qr/XwmW oCCWYwmBUwiHlziUajlGbKmRLjiVaCmXcxlGddlxJmiWcEkLabmXnNCXFzmSXDSYhLkJg2iX5deRqKiX i9lFZdlyZamBXqSYk8lFr7cKmrmZs4B6ZfSZoCkLeBmXSFmaqlkFpLmaSdmarvmTsGmMGVYolGZwGHhv O/N2BuFSLFUycWdhZUEWZ0lGfPJhJSkFxQgGnZkGs5l64nJqsiV4n8ht2UY3dINlsKWDvZc4vVec76iH +Hidj1eIzFmNbvCc0emJ2nZa3kVix9V5dmMnPKidoxd6lTiKtqdGhomexiia7iaZc0B1XsZfANl6JTmF 9cJsBHJA9TOJgGYf/1kYgPuZRihXDkRHjWc2ju10k80Hk4Ggnj4jnTT4arb5ktpVEAxKX9tBY6LHHM8W Qq7Gnw74hSk5jeO3coRomScICCJ6EjM6o0tWbrbXf4UybxLKolgIoX2WF9NTb3PUn+Y4kkSVVlSqhyso CD/KZtZ3jAZqaT2GohyloiKEpPnpogHYFJryEP5ZkTWKmI7ZU9uEgH9pk1jqB1tqa13KefAZpExmpBnE KZfSoquVpg0ao97RprcgpUuogtEYjzgKqSEqoLJXoefzp4QmaP/1hnjzGGdaqKMoDfMTFIuTV3HUmGZY hhlphkLYqhJJqdNnb+2JlXB5fbmXoozjqb1Xh/+M4Rccgy5aGH7E2IWD6KhmM1QTF4h+GJh6kKd/J6Q1 l2rtOas2SKaDWmqBZp/1WZ+HinjgGZtY4KzYFmZoo3tfup5IZk4u833aeq0mYj29WqYA8a3gunew6oSz FYu3uWGymptFxC6jYUO+uS744jdahhD0Wq9UIK4Ky4sM27C4+LAQ6wfN6XoQBnFHObG1ULH/CZ3mCaQr ea8ae5WKKmVRpXccCwcSO7J6IIuPg5GSRltx9ZIJyHAQaVxysLIsO3bLlaqOmpHjOZAqSatvQFELtbOw cJNCW4jReqeO+bSQ6QY6wAPPhbSv0KFl95B1CrQiZz5Qe3HL+QbtZbVSeaX/Dem0l2aUtWq2rZqyXyBh ZJsKS7uRcJpcqEqSNCeP4um0OcsDERC3cpuvxGanfwiQ2udzZIa30EeWCUsGUytjgGtGbusKr/S3kcuX 5IlGj5ual+uSjasLHzVhnbua3iS6o1uaMQa5p1uYQMihk1sLOpC6nLu6kwCzTfWxceRNFuBetFu78he1 d/RResa7vftF6aiMrytG8NQLxlS8vku4yFuya4QD8dRPpuu8iaCh0WtI1NsLDNC82LsI2rujhoROvhAB skS84Uuxm6eNhERNzSQMDBABEaC+61sHcrhrmQtMy0QN83S/fJC/eEhIwVS9vMAAsaQCKvACOHC9ANyM /ziQus6Uvg+slN3rTC9gvxW8j8tbURq8wfvoTcMLwk3ZweBLwkmJA83kwPgaREUkuMX4peWwNC0jagQy nz44sMGpRO0gNS9VoXyJscMhYAWKu6HwUfU7oKAIicf1qIvIhtt5VVglxaHaZ1lYqiqEeHjynclbChXr pb4GvJ/wuP7Udwy5idV6oNCIXSLyotgKfvjBrVYsNhDiWn9Wip97tdLLrDbrZEbsCcubxErMX+b6aIab f23Mq2/8f4cnX1dDiV8xNNQlyX7Kj2Bajoobhn3MtnvYxXkQYwzwwZDnO2jMiZ6FyDuoxTYco2bqGNgR sFo1yfXmyaOgfuRHiCp3ZP9zS7STELr4a05MnH66Ba0ShRn3yZ2J7IGQfLAw+mwescesAHIGeLOxpsts O56VEGOzG4PAjHbLaY99msruSjT5+anLVnrDKc70Oa6Sy5Pby35ea81f27WbIFh2oK/CfKC8E8YbaMym qKvJHMWaQcfyos6Jyka2bLa5/M4/+8ePoM130InKRWiE7IhUY1iUrC9tQqjnzMgks8z8AM2rkNBPu9C4 PLeZMLYRrca3Zp1sOMPT6oENlNFKuj0P+nvuIdNXLIkI7c5/GYQpxoJDC6KY8Lh5IK0tXWZQvGL9vMic g9Ejc4VznMV0yK2GlcdIS1GWy7PWWcrkFmQS/Tf+HBX/Yw0p7aqfn+PIPO1sYYy9FFUCAaxNC0d2rqJU HvabcCejLUVDN7TOXJVD8IPVO6uzKFxKhF3Yo3TYiH0F9EwHtDyp27zYh4C1vwyOkm283ehHin3ZFmsY GQqTHvoqgUe4xibSzSqynA0IoIWqNzqGaoi3GsqsOInaqc2+ncba13yhDF2tyEbbtR3Xt7238/yAumyZ h3sJm/3bCGqSgMmqREZwd0p9kJDcyj3EpI3bw32Pt/vOvR3Z1f0HjU2CATm4eyiGpY3cvv3dW0fd6i1J 7N3ekPTe8O1I8j3fjFTf9i3EyblG+A3f7jtmj52L9o0L1RjgqdDf6k2zutm6LpuY/+k94LKnMz2qqmGE 4N/tpcLNqkv34BBufwZq3A2Ic2Nk4dU9k81NkAaOCSRe4kKdrJxc4Rze4R5+uFhqu/9tCysu44CU4zqu 2THe4+vE40C+R0I+5FT540YeTQxbYSkUb090ymeXtTAtUxhUYmqHjKbtjCeGslneCRJbizwNfE+taKAo XImIXkvMa5o32qHYSP/N5TDu3VlzPDjNrvDZ1abKxHqeqbuWaWxcyW4OoKs6R19uY3oxgGUKO5uo1Jva voL+bbzN1Cl+qi1O2pl83JM+CYX+pO/6Qc38NJoKhQIsh0Pa5zQo2H8kzdedb4sYdF3OCZtO54MKFV1W 6nn+2v8TrWtJ7WrZBZTo97N1munWiORuYuijGqxkE4XQ6Iq6WaQaaG1r5es0qZGw/eioqWyy/hTvKjjH +Xdnc66DxuqhDmkbV7O57epxju2YgoWdPifr+Gr7aeuNTszR7nSoB6Jj2bav3ovEbhlYYYq/l+iKjues Rq7HGI3BDMT2DihiiJnN3UWxvjKBM8mZ/YQGz6eWlfCNJuyGxPGhEPFXJD3vUxFnnvFEymizJ91h3UrW rkZLHg9RBDs+jGI0+1n47GJWXrj6tu+n5/Ef3+9J7ktFHvRQB/RE3wVhu9+87OByfvSjvL8Up5KjafRO b24t706yveFNX/VpqKOYjIM7ipH/igsLQy/ZSiWpdJq3kbn1XJ+JCZjdFP4KZb/Yt3tTcC/1ck/1bb96 E56M5571qDD3iF33u6y3a7/3l4eMPUPZ+g74Acr2iB8JPl8Igh/5IOv4Am75rDv5lK/3ms9Jlf/5ZBT6 hX2WBn72Xu75op96F8vzUc+3Eaelqr/6fHVQp3/1dyf7kE/7WGC76C6LbbmO4dH3+v6PkM37aeD7au+X TdazWLnd4h73fUD6IAz9dw/pz6/4zo330z/7yN+NQvvTwp39wR2nIu6j3v/9Ob/9Zwu134j23M/5UkD9 Fcxx+X7/f0/+7Y9zIr70dwAEKp7KVzQekUnlktl0PqFR6ZRa/7VesVntltv1Kg8HZLhIJpfFZ19YfXaL 0Ww0GD6um+/pvHpd//6RhIgACQsNDxETFRcZGx0X+R4bBSUrLS8xMzU3OSGNIjv/KENJS01PUVNVmdj8 VrNGX2VnaWttb3G9YnN5e31/gYMZd4WLjY+Rk3uJN1ud25zj8J7lqFs/r7Gts4+236ideMTHfcbJi86R eJTM29eP3M2b3tXljdrR48/d7+XllFmBmsPoH52CSwQCE/Li1MFIB9d80iYxTjdX3MpY3JPEoZ+CEOvR yyey3BJxJk+OTJIu3UqS/VLegwdTpsqVEwEiTJiQEB462Jrw9BWBB46GDzl67IYzYsWlGv8vapQ6laJT q+xilsta0uVLm1/BtqSJdatIeizhlaWa02Kfn5D0vIUitJc4HUfh5E2qV6crp3wlOlzrdirgPhf9piWJ lqzXlmIfbx3pWKtZlF4rqxvM1q1AaNAIz/mcWJpBg3lC+9RGmpQOyZ3+sT7c1PTejGCsenzIJ3ZtpmRh nr3sOCvk4q/tac6M7jITxr85d07sBujsN7MJ75SN8br1vKq7pxJiAVW17SA3e0dYmjb23+Z9X+0avKZy scvxj81f8/47e5jvU4yrMaJrayAD2etOwe9Oaw+q6hYcKMJUXCuqvGiCEgq9Z9YrTTfEPtxwN9n2UQlA sCYLsLLkbtr/b0B5AHyNJq9kSwY0O4CacEGMREsjQwazA3JH9EIZLxX4fmRNxLhwm+hDO570bMRwTvKv Snb0m1FGclQ8SzKzrgRuHhlrRAYcHIOUUEggdZIvKTXhTDM0VXAQx6gLDePIPdv4JA3EJ9fqjU/o5rNy HcqyXC7AfZATcCbFYsQs0aqi201OHRmMjU0IQbkR0zjDK0UHBngg70jqbnuKyCVTVQrKwaakbSMExwQz UnwcdZGlL+NRLteQqJS0wAN7PBDD8FQ7zE8koQqR0ziVRUUHoiK461S/onJTW5BcRfMqiLh9j66wGgVW v/5igmy++tJqrtb4hj1k3Hit0MECu1YB/xe19FildTpA95TvM0LdRZE5c8ld7DjLEB6wXTGde41IerfY l+IuprVTFW/2+OYjDqU5U1lsQ+ZxZJC3oeKllSPTZ9cq+UmxZX1ahHTRmAm+uOKJdaaiTh4YuLPnoYku 2uhTdChBnGqPbtrpp6E2RAchxCnB2qixzlrrrZGYepwIhOZa7LHJpliHF4haOuyy2W7b7V90wEGFtKte ++278c6bk7NV6LuECEg1J4IXrtbb8MMRH0afCFTAofDEIY9cci5esKBvFV7Awe7JOe/c889BD1300Ukv 3fTTUU9d9dVZb93112GPXfbZaa/d9ttxz1333Xnv3fffgQ9e+OGJL//e+OORT1755Zlv3vnnoY9e+ump r97667HPXvvtue/e++/BD1/88ckv3/zz0U9f/fXZb9/9929PiVebg8M5JIVdklnFFe9ncUV+5vc//wlw YfbDFQFfVkBcbelWC+xV/+CHDPmxrH4TpFn/XlYP/SHngQjEIIwoiECWddBlFTTUA0l4QQYOx4EdJGAE jTHB/GnlVzSM2MP41498ROE4OuQh/jRoQyoFUYgzRFFZbLVDlCwRKzd01MJgKAwZBhGJRDSiD1k0xSFS UVhWLKISZeTFdEmqijhUIhbJGCMmNpGLRAxjFF+hRTS+MYwBhBkaoWDHLprxizZ8ow8BWcf9fXH/gH0E pBcPKUYLqhGOuJDjGe2XSD760UpgvOAkFzlIJKrwkia0Fc4iecYK2uw/jOxKzEo4ykYC45GEHKAgZzjF TL4yhC68oghPeEBPesmWuhQl/TZYSTaesoWF/N8qf9FKBgJxmHjcYSubaUkplPFhf/wlo6ZJTXfBMpqS DCQdrYlMUvSwj4/UJiLlWMo81nKPidTjOmOZRkXO05C/9GY9i7grRIozFYwy1BPHyMxmjhFS9lyjEMN5 TXbCs40FMw7CsHnQSRpUoedKKD85YUAX2hKfHlRoLgt5yYuek5IcTaUITXjLFwZzgy1FqSt5mcV2YhQT tLQpB5/gPz1ylD4T/5XoTkPZyZMeU6VEZalHOYnCEdZvnzR16lOhGlWpTpWqVbXqVbGaVa1ulatd9epX wRpWsR5NAAJ43FjRWgkdWEsHNKCBAIxg1rTOlRECcGtc31oEu9LgrFgwWSKsARspmSEgZbrCvOh6jL0e gQZ45SsXeGPYP9yoGdiymFwmK9nEFkMHZTVCW48gV8jqxgqalQtiq2Da6vgrQ5vFm2eL0NnPPrYIjdVr XktrWSqg9rSqjQJvV8uU87j2bW3FLWhjS1vk+sCtcM3tm66hqWl4rCKd2lc2zAOyBIHjY5QN1DRCVt1N YXe6emDSds9LXGk1N7nWsqt7neuD9x5Wt6mRkP+x1uQjKGlKTT76VGrWBK1XPetS4MWUf7/DpB05SL2m 6Gx8cWtX58KWuX39bX2rIS4C88S6Av6vpzCsJBCDKsBoiiyJBdxgVSzXrrd1boTj+1xvEVa4HQuVt1YT qiEhi03HItlfSvzfkRHrwPxVsSwi/FgJ+6CtL46xjIls3R7XF7PEinKKAYziOaWqwFr+MGm7jOMjp2K+ SzZzXttqYSmcmLVpOu+mxGzfOU2oKYT98pu8HGQ9XznMdfbtmNWa1zM39sxd+Gtk2RwtRTfrT+wZ8moQ hLKULYU70TCvh8B7MvJySLoJ/jOgH+HWtYrarY1tbpMV8Wm4gDp5Ejaucd//Kur5GoLGpgAuq29n3L3u Nda9VvNoVZ1qnuG6d80t9bGP/WRiL1u+yHY2e5kdbSY/29m/lvaRqY3sa0t712v19q63HW1UJ0HU4Y62 hM26VnCbW9xlRbdo2R3vWYzgAfW29wMUoAAABCAAZeX3vwUAcHf3GwUoIEHBEY5weV91Bw13+MMr8G+J T5ziAkDBwzG+g4Vbtd8Bn7jHKR7yjwfc3SVXthdmuvHp/VrkLef3I0KZQ4Z+0Jq+BKbKC9FZGeQA3pzt eMkB7nKhm7zkf+BSfjpZMFIOUlG8+ifOlSAACUyd6lWXAAZkEHUTWF0CKyjc1rmeBKlznesZ0CvZJeAD /7J7QQdCd3gAGg73uE98B3AXutH9A8mhnpKYxrQoFCcDdbGbAOxXJ3wGqp71I8iA6hhgwQowMHUMxJcF hZdABkwweMRLnvCEp3rm5WuCyDc+84XHAOHZ7vaMv331dXe5tadQooMh1O8y32Wtkhj4SQm+CGBXvHwb f4QcUD0Hn928BGLMgqmbvQmb/z2TEQ96Iwxf8me/POyp0HaXt577c2/5ya8ge65sMo39qYJMF1lQ3iPB 90co/GdHv4KuUZ35RWC8BKS/hPb7wAQsAH7+i2AFqG4FBCDyMAD7ss/uJM715K77Vk/oAgDlji6nusT2 HCabCkj3NHD9em/qfk8HRv+v/pRv6pRNAEnQCO4PAJOg/XQA/4rABVfQ6iaPEATAAW3wATFOAV+uC2KO 71pEp2rvftQP/VKO3cDOBGRABlhg9GawA6furO5PAn4vBZ3gCGUg+oogB4ovCXTg+JoQEBrwBsUwDFfv C3qwhvjDOM6wp3SPCDnQ/dDO646g6pQgCqdw6lSQ/bguD5Fg7K4O/LaADMVwEFsP74JwS9gQlygwoGIq ETnQCpdw+Qrn+OqQ6u4QBj9LBq4G7E4v8kCPwo6gC6vuAAmBEE2x+wDhDBdF/YLpj5LjFRPoDY1g/wpw 6rbQCZEvCUxQAm6RCkMrF50w66QO9E5PCUxwFzMAAaf/4OK6z9ucEegkjuQcMAIJweYMSmHAKQg9aumK 0Ag9cBa/URN9gPokwP+QYPQk4Gp8EQWBkf++Ue0yrwVV0ASLbwS7DhCYsfUCIOH4sR8TbhoLIagaiKcc cRGDRRbBUQqNwARZoAXhCgQlr3DIUf7YERMDsB33b/os0gcYciEt8Q+msd4q4AFG8t5M8t4E8eGoMRUt UC1a0RUvygKFECF9YPMo0gfuDwMEcMLo7yHJMRmPwASlTweoz7kgUiGnzxODcvlCsepukQumsQJGAAVG oCqt8iqvciRT8uFQ7lHUxVdchuk6aiaHAyH9sOoyjxxPUK/Q0epMYBPRrurKKi7R/9L6rE7t1q4Luo/f 8nEH/JEfW+AGuzINP8kaN/Bm7slgGoYDBaDzHNMcI7EcuyYHVgDxTo8FnqzyHHMzCa+sOPMzzbExOZP/ PtMLbJDfXO8Uc7DhJDANuVFY3BAsbyYbu5Emh8XiCu40tzLjFhAH/bLftqBEEmgNiTBdWHEDfdA2n0b1 chACQ8776A4FJE4LNiosca/vQgg5yVI5n2YHTK4kS/IknTPkUKACwvPeFIABdzA4uXN54M4Zta/iBm48 JQ4+vw0a/609y0c6C4c+/dPfQq6s4pPflFE/qScAHsc/IdDdBjTkOisaDTR8Gg4+fWBBie5CBVRAha7t AHQlI/+0e+ruwdKN6H6OQe3zROETQxmU6Ar0Q5uHQ0s03VDU25jM2+yu7upuRK9mRu/CPgHRRadHOitO zdrO+3wgR4vU20IUQRG0Cc6qRYE0edSzPrkQ5Owu3eAuBXLzBiKwRyu0Sy3srDw0SqlHQ4fURgmU3wJu BBSgANJNvpgsCzvAAzBgAh4ABY4AOJ0RTruGTK8nMN/u4/pt4lDAAQrgAi5AAhJ1rXgu4NZqTj0gUjsA BDxAA0ZgJdXNrE7uR/1UebQPOlFT7lCzTRNVAiZg6iYgUeFNByJVUue0A2C1A2JAA1rgLuQq4JRA4zpV eggUR1USRwMgBQCgVGUQUS/gBOL/SwdgVVI9AFKbtVk5oAZGwL2eFEp3FXh8dTVRswDIDlEb7wIQ4FZ3 wANyoFlZQAaadVJbNQTYFQbw9MFiq0bb7lqf51Obk98AgC5T9QImAAP8VQLg7gE6YAVmoFkFIF2VFVJD oFk7KwbwtAgQ9Nt0lV6ZJ0cfzt8E4AEK4AS4Fe1K1ViNVQDmdAXQ1QMStgN84FUFAARCQPHMFUxHtEkp 1j3DUOLyte1aMC4TFQEMgAJOoC/9sgIooF9hVVkX9mA7wFYX1gNioALiVN3gbmY9NeACFe6mDgEcgN8o gOsSdWNvYK36zS+rEgVSgEAhFgUmgANE4GBbtgjmlF2btQLu/2LipFZKq1YHHqDqEMA7daBjp25jERQF ACA39RE1UeAh0bYDQkCv2NVZPWAGgBPk6vZ4UHMHHkwBuA4BtG/qDMByUUABpBMF7G0q+XEHprLhNLXf 2i4D5M8DQiBpIRVWY0Dj5nZiJ1d4BhVJMTdzJ6AGO1cHRNd0HSDfTvLeTlclM/VIJwAEQCBlW3VZHRZi x/R2f4cZX04BEAAB9PZqATcAHmAH8I149Q0AyHd8H4B8z5d8K0A9H+wuUKADAoBSO+BgWxUGLBdsqTd4 2netsDcuDQBB09MvwxcA0rcCypd8ERiBx1cBHuBBmZRJEyBSdWAFYnVORYBJOTV/a2dQzf+qArQX7UZg AA6u4egNAEaAfE8YgSvAHxN4fAkY5MwKQSuABcqVAypYViPWWjV4dVyvBuOyAA43PaWy3tA3gRM4h9cq hY1YcAFAAWpwUCPwBJaVAF+1AyZAvqZ3h23Hgfv2g62uABpOAVpgcM8334x4iZ8xfc+YfAXAhBswcDnA 6yrYXx2ARrU4d+7XBwwA7cDYdNnUhdGXTddYAZxxB9aYgEVXgeFOSC0OA6oYVm24gXX4jksnAL52BOKS BcB3JM2XjdXtkCPWBwz4jCO2BgeXfBvu4uC4Ay7ABzCAAxD0AvCXkjf45RAgAFqAW7NXAhDg4iigAhTA AUYZleU1ANb/+AGYzJjPWAFqNOASeGxVWZQ9wJVlmWAFoABwlpZpx1EBwABYYAJ0gAU6lgIy9gTMmIAR OIcrFJR1wJCXWV7b2IgrYIQt1wEwAEEPcAV2IAPyWJtlB2x7twCylwJ0YAIMwOJ2gHiX2RkB+Zl9oKHT WUmXuSrX93ARgAX67QLqVAc0t+f8mXXeUwEm4AR0gAK4lQUqwAZqkIHV94y/F3wPmXyZGJT3MabLc333 8QAx4AIaMlUP16M/OnX+LR0LoAAI2gB0QG7vdKZjuqlb2qmdegfWNwV04KDBeQcQFQOweT2DOnXm1QEo AAXCVQBYwKQN94SVGKrVeq1VGABWeAfK/xZgLyADQPZw27mrV2etsHkHHOAEEIAC9rGdpZqtY1oBRsCd CbuFH+CwLZcCkjEAdhpRsZlq8fp02lkHRgABCiBrJwCMC0DuqHJ8L26Y11qADTuxpzJ9qfLipFN7szpk zaruKrt0HNUBrlazA46kC06NZVSN1fpSWZqwoVgqCfh0M1ajQfYCGngfuXq2PydEr5aXedlN9/Fz0dcZ lZmtvY2wG9h06w6BLxV8AyBR8Xlni9RyM9i5DcfbKiBzHUAAwFPfptVGE1sAglutEe6wnRkAwLfeLPd/ TzXyELVG7W6S1XtsIrZ/qU57cZSIEfghfcC3XXqeTbgk3bo8G86Ej/95BOBbv4E3gf1bqo119JR7rXDU wA+ca16O7Kh7JI04PcvTiIfXiEmyiQeXgdcXAshXByb6fqU6lWl8hSPug0+Vc7E4RCs0xSWHQMkOnEmS BMwTqmGccBXAmBNadA07BUBXcJl6KsHWutf4cyHgTq9Z3aiulUNVr5QccjpLB1KA7E4A7qJcu6d1Wmva dO9US/2ybPXNL8HX26pykBN4JOtuaxX1zB/MV1F8zZ8m3fKW63BZqiG6qZEZs9dKcEmy3kCXgfFtjMsz Ygturektlfm1yKfuBooAfKUTqBn9bQh0j78YeP1SAUjbqRuYJAMXqlf4y/tcJBlbZumNJFdYOnn/mQI0 gOqQ2eJ8tNXzJkRhveqwGacT+07BdirTOsjTLZEJmNPrbQTWNzXLmCTL9rNZ4NinDgDaLuKgk9nxhkD9 lurq+LCzm63505iZbKYX+FIvnak/l4GJlyQJV5nrrQUCoABM/dzLagQA9e0Wnd11xt3IjpxVuYQT24WZ jLgN2LC/fIm900olzuCiPN/qrgAagOSLuqjvPUWB0+HbZlAjvp1ret+0FOFaAAXGGKrxre0w3NsxG6JV N6nzLd809aYxHaeRuuQKWnp7FGxZneW1xpIDgOw0QAcCM30n1kvtW631LdO9PcbXOIcrPbZMHOAJeIUD oI7bfK2uGL7j099k/8vpyWaoHVsDTuAEyr1I1zc9TzTr17rebrqp7xdvrR3dTdw8TRfDc8ABslegtfex CZn1IBzuEbztbjka5bbqZfo5J/2QF3uFN5981RnQfRzX3drsHeDgJYACjvQBkHheG17yo+PfNBc+Cbrg rj2xz5i4nTqHFQACYNrbRPd7Cfh7A8AADn4CVP9LQw72x4bkPtiLe1d0UQACPh/31bqBBfQ+y2okgdmw iV+gTd1Oi6A88ZP5xUZN3/1vI/y+rX+Z17oGHY4qzxN0m9i/r9lUUXUC6jgAAjgHzR8IfMIhsWg8IpPK JbPpNAoCAoCkai3oFI8HoOv9gsNirjj88Ol8gv8dClXZKnZd7WgXQEgmE+tDIIgHBN4E2D0ZHiImKi4y Njo+QkZKTlJWWl4SBRJYcQY8oGyRlY2KVZCCAe6o7qSQgHZ9VqjmcFqR+BCirKoGYPr+AgcLDxMXGx9b BkLUVrGgBCicSoONTFt3gaqiMEsICHnuoPmEI5ebn6Onq6+zKwYGcFMIoChEX39VVCjo2O2MCLTghWJE ChT3vox4YIeCBAQTEEDEoINQgInv2mHMqHEjx44ehwQSwA1LPTgHAdDTNULfmwf5KLhMeDLmiBY6CjDL gOudgIkffwINKnQo0SRSAuDkBNETPTA7dECd9qDaCC1d8qGchsLPny8D2dz/qYXAwU5C3oqiTat2Ldtf Fhdw2iNBwxqr0UZAFSKH1CcID0hU8KSghZvBe8vsgzrRq64AFRpWwSPh1riQbS9jzqx5s5CJO7gh8KFF FArF/E7O1NFTtZc2bW7GdZiGXyBynG/jzq07XRQBSWvZCPRmjuJxYnZ80hV4BIRon9i4TlgvgBjT1Luw 2SHLAAs8kifw43V2N/ny5s9DsviAG/gKbrI+I3Qvjil710ovbpFPFwofBgKw8JBkEHjWC3oHIpiggkUI coFYEuSQi0HXKFDBAg8QVpEOAHzimEvv3UMIWP9NsAMCOjDkTU8Lstiii7dB5ZtcEpwAFXiEmIIaNqfp /4iQLk8ZQEECBQiAAJEGFPeikksyOVQg20iAhYksUPAUGxVUo6MoPXKBAgurIImUABQEUGIhTaKZpprr hISABjpM4OBWCAAUAAoU9DhQHaTYV4Z7yPl2E3h3IjXReGsimqiimFi0DTzgnbCDABr4cIIbD1jlVIx+ CjFhGHhBtSV2ALzxWgVEFgARBTpIIKmBi8Iaq6yLSKEDnZIWIIUDra4xQlVhVGDaYV+coUMLZVgnBijP 7ZBqrjkY4MAUUaQxq7XXYnvEO3no9JAPVbwzwoSe4gfVsF4Ue+4caCj2hRwPOKDQA0h5Z2RPuRKSrb77 zqqKDtx9JoFNO1wQmh1t9P+ZGFSeeqEFGup2oSGPrTkQhwK+NZRAQxAVcLEU/IIcspqq9QQeVBlcgIHK N87DRlYAvMNww+mW8QBU13HIYT07XGxAHmLh+6rIQxPNoh86pICBBBikfEHKGGRgES8N80XzKVkCoIUC oAjggENKaWxHRUWTXTZ6NwvwwNMqs91B1BZJscUp8S4sjSnuTcW11xAxE1ggZgMeeG52lMy24Rh0AB4u FomWsxha1C2NY3VUwEIOONXLNwIE1Ca4559fZmhPTbetcgcXeNOLHxV5cRgXdLiCLtVZf6hLHywUoIdk kSEAsx3Vgh688EIR3pMHHRiOfAfLn4CG6uF6oQ+muqD/JF2m9WghiypRUFAvZHkY+Y7Qw5NffkYh9RKA 8suzv7wHGKio+i6/On4dGZhWXE8dCs1TAAsP8E0pQbON+QpoQHRI7WbI88Dx3MdAD6wgA96YiGp2QJg2 iCs6bXAP9hRikK3swAAICEmqEJCACWgsaH87IAtbaAyx4aInGXBfBxi4vAsIwQMTMBBFajOCKmmjJXWw EwAcIAUU/IZIdvpe+HjxFBdCMYq+EF8MfUCBGh7vgSty3wVOMLY1EIYNARnIQEqlGhtQ4DcNmYAXAyDC KsDsHWyQIh3rGAl+RIEQ1dLAAxkYNR+woIZYRN4EUBCc1ZhmdTY4gQPUaAU8YCEQ/z6DgA36wQs7YjKT iZAUVww1kUAycDZY7CP7mJYHPaCyAKniRmSqsIcGCOAEBUjBLrIDPE3iMpfa6iS1DJSCD3gAKiuw4QPb xzSn5UAILCBZwFgpwAX00IL80SU1q9mZp5hGB/3pjAsk0sdiLg9xTruArejEqgmwwJm8k4DvahmQFIzP mvK0IzazSUHVteCbgyyl02wlAahQQA/MmBEeAMCL2tSyNPNcKCaPZk9zgWQDMthnAw1XpH8G4AQzehA7 dyGiWqqCoSKlo7Hywi5zhUMKE0SBBj6wT+Sl7KKqkc1IAkM4J4L0TCPdaQvj+Y2Q+EQNUPmhS5XHNHKs QZgSuP/AHgzgt36I76O1vCVPq1o+P2grmz7YynjSkAJ47WGcTosSABbA1RuIzTMk84Mld2HVtxpFcAQc wgQ7U61eeDIN9RRdHuW4hmc8lDZR9SlcCxu4sRXhUEbISzj8VUFXhbQ2tVKC2MRHVcNi1mzUMs1JA2vS k66hIu8wqWc5q1IqZja1geOkQ1XKldd2srSBhS1tewNb1eK2bGLLo2AH28PaAve1vh1sIi+b2+Pqy7cB yalHh+tcqTIXkcZFLnWxFU3o5nS4lRVbZbFby1pxtrrizZaIonpQ3zI3vcwd7NGONt73Wiu0u3ANBn1l X++qVxs/ym5U4evfWX3UtVwxb37/0yu+7/b1Y/9d8KJUg9ACQxjC6FsRgysMq/AYOMAQ3m92p2vhD6MJ w+mlL4lL7BrtpdfDIF7xi0ScU1Jhyb4y1hN9/6ReFbM4xwvKb3B7XGAdA5lJ+Q2MbGOkGh0oRL1BXrKL 8ktfGUPZvtFRL2GZbGXy5Pe5An5tlq/sZfREOMzZMfCXy4xl/Ip5vgZWrJnbnJm2ppm5HAYpjt1sZ6LA Oc5htsyd+8wW7uo5p8vNLpv9bOigdHcVD9YzdEd76Ec76bmMliNxIW3pn2h50s6t86U7bY4ey1fMUc1j bzxt6oyoWKoaXq9d7XnqV8M61rKeNa1rbetb4zrXut41r3vt/+tfAzvYwh42sYtt7GMjO9nKXjazm+3s Z0M72tKeNrWrbe1rYzvb2t42t7vt7W+DO9ziHje5y21uQ/cg3ekWQg98oG51H+Hd6y6CvNnt7nqz+91M wHe+501vfRtB3gIf+BAEfm+A99ve8eY3EQYO74A73N8Mb3jE/d1viy8c4Rc/+MMT7u6C17viGId4xy9u cZGXfAkPbzfHJT7xlzsciid3ucpZ/m+K23zkI4f4zUFuc3ongeb5HjrPKd7zlPc86D9HusKJbnSlgzzq Tp96xhf+dKmnXOj3lrrVr071gnt950Uv+c4xbvafb53rBkS708Wu9qZf3exNKPvSyx70sP9/Pe1qn7kS 3E51ptcd6CrHu9693nXB7z3wcSd80ZNe+IYb3u+F53vjHz/1sx+Q7m+vvOX1fnInaN7nbGc7EkLv+Mmj nfSbP73G4f75Q5je8JyHO+oRn/fOz7728Y686t+ueMfHHvMFdHvOe3/53hcf7HNHfs4Pbvu+kz72qF86 9GsO9KwvHhE6Z/7gnz99yMv+9uFvu+p/L36Puz76yS/9+lcfPMmfX/fW/zjoua9wuS//8Lz/t/HH7/u/ P13/Qd3p+R8Ash7xlZ8AIqD7mR/8OZ/+cd0C/p0ABo4DSh7l1RzTsd8A0t/k1V/GxZzstR4Ecl77dWDL KcL2ceAGgp//CAJeAu6b/eFe3U0c9G1fxLmf55lf+Vhg/2Fg9Wlg7rVd9sUgCT6e2AVh/OHfEEZdEq6g +MGfxBnhA45fFMogEgYgBfIfAeogBxJc5lHgBe4gCzohFDZfAH5g7glf1T1hCR5dFmqhC7Zh46mf0qUe DM7f4WEh1jngFq6e1tFhHIJOD+Yh7iVdGUrgCQ6dFkrfBLYg+gnh/93c75UhASYiELIg7ZEdHlZfJu4h +c2dH3YeIB6iIA5i+f2h76Hi8SlgHSofzjGiKx7gI5rh7hkgLIZdH+ZdI24gJyqi/HGhGo5h+hUg7XVh 5QWfKX6O3W0eKTLjBPqgLP4iFRbiH97h//5lYgSmHhtC4xPwYh+umy+u4QyGoTRa3jX6XDWS4vHpny4K D9nNYjO+njxGI+tlYydy4Th2nN/p4za24+iBoy8a4hR+nyMSZDziHDamox0mHgSO40CC4SbiYMsBpETu Yw3y39kBXgwinMGZXLt5JMuNoOh9ocFhpEjym0ey30iiIOypH8Ch5MxpnEpmID+2Hk2yZEwWX0fCXNZh 5LkBZVAKJYugXFEa5VEiZVIq5VIyZVM65VNCZVRK5VRSZVVaZVEOZVZq5VZyZVd65VeCZViK5ViSZVma 5VmiZVqq5VqyZVu65VvCZVzK5VzSZV3a5V3iZV7q5V7yZV/65V8CZv9gCuZgEmZhGuZhImZiKuZiMmZj OuZjQibZaNlkUmZlWuZlYmZmauZmcmZneuZngmZoiuZokmZpmuZpoiZqRuZqsmZruuZrwmZsyqZqXYRH 1OYkvEr6oNZPCU1/RUJtrpAjBCdIDCcS3GY77GZZFGclVBkTxFNymsdyno90BgN1YoR09iYi5GZwrpBv cmdzaicPgecTcCdxNoF1psN3micmjGdcZYJuPkJ7ZgI6oCc71Cd7yid9Pud2HkJu7oR58ud//pQk3Ccj qKdz5ucxHKiAJgOtGEGBOgGEDiisSCit+CaD7mZyZuhx8mZZEOd3Yid8Kudkruc3gASGjk+AMmj/h3Yn cF7o39wmaskojNLoRfQXjb5ni6Joi+qmjfYoi/ami/7ogi5ojm4nj/4nh1LRjf7oiRopb4qniD4pkyKp b+WogM4ofB5nlvaoj0rpiAZplmLplsYomXqph/oolBqCjo7pgLJpd07ocr4pD8XpfoookYrnhJqoieKp isopjLZpoM5pkuYplu4pm6JpnlbpnUYpLiRqnTJqnR7qe5bonwpqoyIqpj4qhj5ooVYpg9DppbLoin6o o85ppIrqoWKqp+4npJoqq6bqoI5p+gTqecJqrXporkoqqLrqelpqrR4odjppkW4qqa6orCKrT7komu5q qvpqmOpprN6qjkIn/552Kq9K654e67Rqy7QSFpmCaqFGa4lmq7MC6q7KKqXiarqiq7dGK6IiaLvO6I5+ KIcCK4jaa7oGq7IOq4o+q71u67yWK4Aq6rlm6q0+q5uKa7kmK7NWqr+Oa8Ma6rty67U6a6f6KaqOK8UK rMQmacJebLuqK7yCqciu64XGa8jC67IaxcKyrHEi7L5qS7+Sa8Qqa5BarMfeq54ebLNKKrtKrL4uLIrW LKkGbahuK7p2q8nCrLsmrcVu7NGWKsji69KerM8aq9QWra0yLarGbM6GaqaCrZt+LLI6KdGW59T6bNpq rcb2bNlWLLUiLMPG7NBaq6CaLLWqq8h+q9M+6LnPAi2t7i2n0u3gmq0SBK7SEq7W8ix5cqmaQmmNhmnf LqmZ2mmT7muZauvkRimIXquGlqmQeie+Jqvc1miHKmeiDpeaemnldu7IHqnoZuzksq7k1mvtdmm38ujr YizOginohivtpu6Zpu7erm7r/qnoPqnaFm/kdu5gLW+EJuhaVCgyVK9QWungssX1pgX3FoP3nluKYmtb QOdtlK99AmxYomzzzmb7uu/7wm/8yu/80m/92u/9slAQAAAh/nBocWdodW1lYXlsbmxmZHhmaXJjdnNj c2dxc3hkanBsd3pmbWpvb3B5eWlmdmttd3dwZ3BsamVhd3B2YXBpaG94dXVmZmJydwA7 --------------060503050202010201050000-- From w3c-dist-auth-request@frink.w3.org Sat Nov 26 11:53:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg3JH-0005Sh-Om for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 11:53:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01966 for ; Sat, 26 Nov 2005 11:53:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg3He-0001Ix-T5 for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 16:52:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eg3HV-0001HK-Oi for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 16:52:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eg3HQ-0000O6-OK for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 16:52:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQGq1dT020918; Sat, 26 Nov 2005 08:52:01 -0800 Date: Sat, 26 Nov 2005 08:52:01 -0800 Message-Id: <200511261652.jAQGq1dT020918@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Eg3HQ-0000O6-OK 029e4d67dc08a49fa1931de321b6a11f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] New: remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200511261652.jAQGq1dT020918@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10685 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 16:52:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 Summary: remove "bis" compliance class Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.17.3 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 17. DAV Compliance Classes AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Should "force-authenticate" and the changes to the "if" header syntax be backed out, there doesn't seem to be a compelling reason anymore for the introduction of a new compliance class, thus Section 17.3 and text that refers to it can be removed. ------- 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@frink.w3.org Sat Nov 26 11:55:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg3KO-0005aD-8e for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 11:55:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02030 for ; Sat, 26 Nov 2005 11:54:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg3Jq-0001Ym-Ib for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 16:54:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eg3Jq-0001Xp-0Z for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 16:54:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eg3Jm-0001SU-T6 for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 16:54:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQGs5tY020939; Sat, 26 Nov 2005 08:54:05 -0800 Date: Sat, 26 Nov 2005 08:54:05 -0800 Message-Id: <200511261654.jAQGs5tY020939@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eg3Jm-0001SU-T6 2e65a10dce71a2b349b6678b39751d70 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200511261654.jAQGs5tY020939@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10687 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 16:54:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |18 ------- 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@frink.w3.org Sat Nov 26 11:55:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg3KO-0005aS-Br for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 11:55:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02031 for ; Sat, 26 Nov 2005 11:54:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg3Jo-0001XY-It for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 16:54:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eg3Jo-0001X0-3x for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 16:54:32 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1Eg3Jn-0001Oo-Q8 for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 16:54:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eg3JP-0004C6-Ut for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 16:54:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQGs5T6020949; Sat, 26 Nov 2005 08:54:05 -0800 Date: Sat, 26 Nov 2005 08:54:05 -0800 Message-Id: <200511261654.jAQGs5T6020949@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eg3JP-0004C6-Ut 242bb4aa945007465e5246fe623a6be2 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/200511261654.jAQGs5T6020949@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10686 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 16:54:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |200 nThis| | ------- 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@frink.w3.org Sat Nov 26 11:55:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg3Ke-0005dv-2y for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 11:55:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02081 for ; Sat, 26 Nov 2005 11:54:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg3K6-0001jk-53 for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 16:54:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eg3K5-0001iy-G5 for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 16:54:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eg3K0-0001Uf-Rk for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 16:54:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQGsiTF020967; Sat, 26 Nov 2005 08:54:44 -0800 Date: Sat, 26 Nov 2005 08:54:44 -0800 Message-Id: <200511261654.jAQGsiTF020967@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Eg3K0-0001Uf-Rk e047b87f8ca413d3752458819a7090f1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200511261654.jAQGsiTF020967@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10688 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 16:54:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |171 ------- 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@frink.w3.org Sat Nov 26 11:55:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg3Ku-0005wb-GX for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 11:55:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02152 for ; Sat, 26 Nov 2005 11:54:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg3KM-0002Ax-JN for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 16:55:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eg3KL-0002AO-VQ for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 16:55:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eg3KJ-0001i3-2N for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 16:55:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQGsjpF020979; Sat, 26 Nov 2005 08:54:45 -0800 Date: Sat, 26 Nov 2005 08:54:45 -0800 Message-Id: <200511261654.jAQGsjpF020979@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eg3KJ-0001i3-2N e618c0259ff22155edf92d173f9849bd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/200511261654.jAQGsjpF020979@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10689 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 16:55:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |200 nThis| | ------- 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@frink.w3.org Sat Nov 26 11:56:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg3M5-00064s-S0 for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 11:56:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02321 for ; Sat, 26 Nov 2005 11:56:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg3LX-0002eO-HH for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 16:56:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eg3LX-0002dn-3R for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 16:56:19 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1Eg3LW-0002Al-O6 for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 16:56:18 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Eg3LJ-0005Ey-EX for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 16:56:10 +0000 Received: (qmail invoked by alias); 26 Nov 2005 16:55:56 -0000 Received: from p508F9706.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.151.6] by mail.gmx.net (mp033) with SMTP; 26 Nov 2005 17:55:56 +0100 X-Authenticated: #1915285 Message-ID: <4388934A.3040207@gmx.de> Date: Sat, 26 Nov 2005 17:54:34 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings , WebDAV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eg3LJ-0005Ey-EX 12f4e2c8e2b78c614b4cbaedea3ce62d Received-SPF: fail (lisa.w3.org: domain of julian.reschke@gmx.de does not designate 133.27.228.225 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Proposed changes X-Archived-At: http://www.w3.org/mid/4388934A.3040207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10690 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 16:56:19 +0000 Content-Transfer-Encoding: 7bit I've set up a sandbox where I will be making proposed changes, see . In particular: : HTML version with change tracking : XML version with change tracking : diff of ASCII version compared to latest ASCII version of WG draft : diffs between the two XML versions I'll try to merge in changes made on the WG draft whenever they come out (the smaller the increments are, the easier it will be to do that). Right now I've put in proposed resolutions for Bugzilla issues 18, 186 and 199 for testing. And yes, I'll be working on more important changes (BZ 10, 11 and 188) now. In case there's consensus for a particular part of these changes (WG members, please review and give feedback), I'll be happy to provide a per-issue diff if this accelerates inclusion into the WG draft. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Nov 26 13:05:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg4Qx-00011u-7d for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 13:05:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10980 for ; Sat, 26 Nov 2005 13:05:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg4PV-00030T-FB for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 18:04:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eg4PS-0002zQ-CT for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 18:04:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eg4PN-0004K0-Qo for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 18:04:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQI4JwJ021052; Sat, 26 Nov 2005 10:04:19 -0800 Date: Sat, 26 Nov 2005 10:04:19 -0800 Message-Id: <200511261804.jAQI4JwJ021052@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Eg4PN-0004K0-Qo fe7c71cae0e04f01a44f21893cce64fe X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200511261804.jAQI4JwJ021052@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10691 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 18:04:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-26 10:04 ------- Note that the Changes section still says (): "A more complete list of changes has been published in a separate document." ...which of course will cause every reader to ask: "where is this document, and if it's interesting enough to be mentioned here, why isn't its contents included here?" ------- 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@frink.w3.org Sat Nov 26 13:17:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg4bq-0004Mh-8l for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 13:17:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11751 for ; Sat, 26 Nov 2005 13:16:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg4bC-0006WC-1l for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 18:16:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eg4bB-0006Ug-GS for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 18:16:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eg4b4-0000ho-IN for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 18:16:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQIGNfH021074; Sat, 26 Nov 2005 10:16:23 -0800 Date: Sat, 26 Nov 2005 10:16:23 -0800 Message-Id: <200511261816.jAQIGNfH021074@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Eg4b4-0000ho-IN 46e360716ada31c20cc681668975c4ba X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200511261816.jAQIGNfH021074@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10692 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 18:16:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-26 10:16 ------- I'd also like to point out that splitting between server and client considerations may be a bad idea; many changes (such as allprop behaviour) affect both. ------- 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@frink.w3.org Sat Nov 26 14:08:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg5Pe-0008Vh-96 for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 14:08:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16483 for ; Sat, 26 Nov 2005 14:07:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg5OR-0000bu-8T for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 19:07:27 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eg5ON-0000aN-Re for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 19:07:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eg5O6-0001PB-Li for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 19:07:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQJ73R3021118; Sat, 26 Nov 2005 11:07:03 -0800 Date: Sat, 26 Nov 2005 11:07:03 -0800 Message-Id: <200511261907.jAQJ73R3021118@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eg5O6-0001PB-Li 205ffcc60aa07f6fd3bdedca6aefd42b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/200511261907.jAQJ73R3021118@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10693 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 19:07:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-26 11:06 ------- Proposed resolutions: follow the links from . ------- 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@frink.w3.org Sat Nov 26 14:31:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg5lQ-0006gS-Ia for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 14:31:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18318 for ; Sat, 26 Nov 2005 14:30:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg5kg-0005s0-IE for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 19:30:26 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eg5kf-0005rN-QV for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 19:30:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eg5kZ-0002JZ-VF for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 19:30:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAQJUJLH021143; Sat, 26 Nov 2005 11:30:19 -0800 Date: Sat, 26 Nov 2005 11:30:19 -0800 Message-Id: <200511261930.jAQJUJLH021143@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eg5kZ-0002JZ-VF f72e91a7bd2b3057d990b4fb6008deca X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200511261930.jAQJUJLH021143@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10694 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 19:30:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-26 11:30 ------- More questionable stuff in Changes section: "...use of Date header, ETag and Location header." (no, there is no change regaring Date or Location) "Several changes for "If:" header, including requirement to accept commas and "DAV:no-lock" state token." (the latter is no new requirement) "Required to handle empty multistatus responses in PROPFIND responses" (not true) ------- 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@frink.w3.org Sat Nov 26 14:31:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg5lU-0006iw-Bi for webdav-archive@megatron.ietf.org; Sat, 26 Nov 2005 14:31:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18324 for ; Sat, 26 Nov 2005 14:30:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eg5ku-0005t6-86 for w3c-dist-auth-dist@listhub.w3.org; Sat, 26 Nov 2005 19:30:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eg5kt-0005sS-DC for w3c-dist-auth@listhub.w3.org; Sat, 26 Nov 2005 19:30:39 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eg5ko-0002Q1-Dr for w3c-dist-auth@w3.org; Sat, 26 Nov 2005 19:30:38 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C4EBD1422BB; Sat, 26 Nov 2005 11:30:31 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27630-03; Sat, 26 Nov 2005 11:30:31 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F2D191422BE; Sat, 26 Nov 2005 11:30:30 -0800 (PST) In-Reply-To: <200511261804.jAQI4JwJ021052@ietf.cse.ucsc.edu> References: <200511261804.jAQI4JwJ021052@ietf.cse.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <144518ef20578e2385d5b82a7b48007e@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Sat, 26 Nov 2005 11:30:28 -0800 To: bugzilla@soe.ucsc.edu X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eg5ko-0002Q1-Dr 04f2ced41c10ea6879dd4f55bbf87024 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/144518ef20578e2385d5b82a7b48007e@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10695 X-Loop: w3c-dist-auth@w3.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, 26 Nov 2005 19:30:40 +0000 Content-Transfer-Encoding: 7bit I intended that to be temporary -- part of the section that the RFC editor is going to remove. Since I put it in the wrong place by accident I might as well just remove it now. The document I refer to is "http://ietf.webdav.org/webdav/rfc2518bis/RFC2518%20Changes.doc". It's got changes from -01 to -07. By now I don't think anybody besides you is interested in it, because I'm not updating it anymore now that we've got bugzilla tracking. Lisa On Nov 26, 2005, at 10:04 AM, bugzilla@soe.ucsc.edu wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > 2005-11-26 10:04 ------- > Note that the Changes section still says > ( -08.html#rfc.section.D.1>): > > "A more complete list of changes has been published in a separate > document." > > ...which of course will cause every reader to ask: "where is this > document, and > if it's interesting enough to be mentioned here, why isn't its > contents included > here?" > > > > > > > > ------- 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@frink.w3.org Sun Nov 27 07:23:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgLZB-0002ge-AZ for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 07:23:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06714 for ; Sun, 27 Nov 2005 07:22:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgLXN-00010C-Jg for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Nov 2005 12:21:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EgLXI-0000yv-1s for w3c-dist-auth@listhub.w3.org; Sun, 27 Nov 2005 12:21:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EgLXF-0004nV-Ad for w3c-dist-auth@w3.org; Sun, 27 Nov 2005 12:21:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jARCLUAI021993; Sun, 27 Nov 2005 04:21:30 -0800 Date: Sun, 27 Nov 2005 04:21:30 -0800 Message-Id: <200511271221.jARCLUAI021993@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EgLXF-0004nV-Ad 4a44d4736046e1911ae8a83a719691d3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 201] New: LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/200511271221.jARCLUAI021993@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10696 X-Loop: w3c-dist-auth@w3.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: Sun, 27 Nov 2005 12:21:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201 Summary: LWS allowed in Coded-URL Product: WebDAV-RFC2518-bis Version: -08 Platform: Other 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 QAContact: w3c-dist-auth@w3.org Is LWS (linear white space) allowed in Coded-URLs? The grammar seems to allow it, but I'd be surprised if all servers get this right. ------- 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@frink.w3.org Sun Nov 27 07:26:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgLbo-0003fR-Mv for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 07:26:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07054 for ; Sun, 27 Nov 2005 07:25:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgLbD-0001ep-Go for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Nov 2005 12:25:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EgLbD-0001eH-15 for w3c-dist-auth@listhub.w3.org; Sun, 27 Nov 2005 12:25:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EgLbC-0007CE-Lk for w3c-dist-auth@w3.org; Sun, 27 Nov 2005 12:25:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jARCPfoN032531; Sun, 27 Nov 2005 04:25:41 -0800 Date: Sun, 27 Nov 2005 04:25:41 -0800 Message-Id: <200511271225.jARCPfoN032531@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 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200511271225.jARCPfoN032531@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10697 X-Loop: w3c-dist-auth@w3.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: Sun, 27 Nov 2005 12:25:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-27 04:25 ------- Nit: RFC2518 required "1" to appear as compliance class, while RFC2518bis doesn't anymore (that is, something like DAV: has become a legal header. I'll assume this is a bug, and I'll fix it in my change proposal. ------- 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@frink.w3.org Sun Nov 27 07:43:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgLrz-0007La-K5 for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 07:43:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08767 for ; Sun, 27 Nov 2005 07:42:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgLrG-0005VX-Ct for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Nov 2005 12:42:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EgLrD-0005Uu-VC for w3c-dist-auth@listhub.w3.org; Sun, 27 Nov 2005 12:42:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EgLrA-00082r-Im for w3c-dist-auth@w3.org; Sun, 27 Nov 2005 12:42:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jARCg1s1032555; Sun, 27 Nov 2005 04:42:01 -0800 Date: Sun, 27 Nov 2005 04:42:01 -0800 Message-Id: <200511271242.jARCg1s1032555@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EgLrA-00082r-Im 07a085c56acac74c432759badd766532 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200511271242.jARCg1s1032555@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10698 X-Loop: w3c-dist-auth@w3.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: Sun, 27 Nov 2005 12:42:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-27 04:42 ------- Proposed changes: follow links from http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz008> ------- 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@frink.w3.org Sun Nov 27 08:13:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgMLo-0005Xo-H2 for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 08:13:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12204 for ; Sun, 27 Nov 2005 08:13:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgML2-0002tx-DB for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Nov 2005 13:13:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EgMKz-0002tM-E3 for w3c-dist-auth@listhub.w3.org; Sun, 27 Nov 2005 13:13:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EgMKv-0001KS-TF for w3c-dist-auth@w3.org; Sun, 27 Nov 2005 13:13:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jARDCu4x032590; Sun, 27 Nov 2005 05:12:56 -0800 Date: Sun, 27 Nov 2005 05:12:56 -0800 Message-Id: <200511271312.jARDCu4x032590@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EgMKv-0001KS-TF 942171385f53cee101d9dbe12912d8b9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 99] Risks Connected with Lock Tokens X-Archived-At: http://www.w3.org/mid/200511271312.jARDCu4x032590@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10699 X-Loop: w3c-dist-auth@w3.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: Sun, 27 Nov 2005 13:13:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=99 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-27 05:12 ------- Suggested replacement text (see also ): 19.7 Risks Connected with Lock Tokens This specification, in Section 6.3, encourages the use of Universal Unique Identifiers (UUIDs) in lock tokens, in order to guarantee their uniqueness across space and time. Version 1 UUIDs, as defined in Section 4 of [RFC4122], may contain a "node" field which "consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE 802 addresses, any available one can be used". Since a WebDAV server will issue many locks over its lifetime, the implication is that it may also be publicly exposing its IEEE 802 address. There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address: o It is possible to track the movement of hardware from subnet to subnet. o It may be possible to identify the manufacturer of the hardware running a WebDAV server. o It may be possible to determine the number of each type of computer running WebDAV. This risk only applies to host address based UUID versions. Section 4 of [RFC4122] describes several other mechanisms for generating UUIDs that do involve the host address and therefore do not suffer from this risk. ------- 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@frink.w3.org Sun Nov 27 08:34:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgMfK-0001P4-VS for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 08:34:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14630 for ; Sun, 27 Nov 2005 08:33:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgMeJ-0007Zj-St for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Nov 2005 13:32:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EgMeJ-0007ZB-AP for w3c-dist-auth@listhub.w3.org; Sun, 27 Nov 2005 13:32:59 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EgMeG-0001CB-IP for w3c-dist-auth@w3.org; Sun, 27 Nov 2005 13:32:58 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 27 Nov 2005 05:32:33 -0800 X-IronPort-AV: i="3.97,380,1125903600"; d="scan'208"; a="234657350:sNHT24006264" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jARDWU6a000740; Sun, 27 Nov 2005 05:32:30 -0800 (PST) Received: from 10.21.88.113 ([10.21.88.113]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 27 Nov 2005 13:33:28 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 27 Nov 2005 05:32:34 -0800 From: Cullen Jennings To: Julian Reschke , WebDav CC: Geoffrey M Clemm Message-ID: Thread-Topic: ETags, next call, was: Notes on call from today ... Thread-Index: AcXzVwYaRG8cZV9KEdqEGQARJEEJ/A== In-Reply-To: <43882537.4000005@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EgMeG-0001CB-IP 9116ec0927d5cdc419243c6f409eb6a5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/BFAEF572.627D9%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10700 X-Loop: w3c-dist-auth@w3.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: Sun, 27 Nov 2005 13:32:59 +0000 Content-Transfer-Encoding: 7bit Some people have been advocating a profile approach. I am simply trying to figure out if there are a large contingent of applications for both profiles. I have heard many applications (much more than just file system) that would not be impacted by no strong ETags so I am convinced that group is large, what I am looking for is what are the applications in the other group that don't care if they get back a weak or strong ETag? Let me a related questions to client implementers? On the phone call the other day, knowledgeable server implementers seemed to imply that the right solution for clients that got bag a weak ETag but needed a strong one was to poll the server until they got back a strong one. Does any client do that? On 11/26/05 1:04 AM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> >> I have heard that this is wanted for applications other than a file system. >> Right now I was sort of looking for examples of applications that did not >> want to use this. > > I think in this case the question needs to be rephrased: what would > these clients prefer? > > 1) keeping the spec as is, meaning that there aren't any guarantees > about this behaviour > > 2) changing the spec to mandate this, leading > > 2a) to some servers claiming to support this, but failing to do so > (non-compliant implementations), or > > 2b) to some servers stopping to support WebDAV altogether. > > I'd also like to point out again that there is a class of resources that > simply can't support strong ETags (for instance, WebDAV interfaces to > XML-Infoset-based databases). Thinking of this, even the SHOULD that we > have somewhere else in the spec is a very bad decision, and everybody > should understand that this makes it impossible to maintain WebDAV > interfaces to certain classes of resources (this is likely to be raised > during IETF last call, so we better make sure the problem is understood). > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Nov 27 11:02:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgOzB-0002Bt-O8 for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 11:02:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29896 for ; Sun, 27 Nov 2005 11:01:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgOxy-0007Dy-Om for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Nov 2005 16:01:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EgOxs-0007Cp-RB for w3c-dist-auth@listhub.w3.org; Sun, 27 Nov 2005 16:01:20 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EgOxn-0003FO-TQ for w3c-dist-auth@w3.org; Sun, 27 Nov 2005 16:01:20 +0000 Received: (qmail invoked by alias); 27 Nov 2005 16:01:12 -0000 Received: from p508F99D4.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.153.212] by mail.gmx.net (mp025) with SMTP; 27 Nov 2005 17:01:12 +0100 X-Authenticated: #1915285 Message-ID: <4389D7FA.5070506@gmx.de> Date: Sun, 27 Nov 2005 16:59:54 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav , Geoffrey M Clemm References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EgOxn-0003FO-TQ 9fba1c6cfc1b2bd2e51b57024ef838ea X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/4389D7FA.5070506@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10701 X-Loop: w3c-dist-auth@w3.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: Sun, 27 Nov 2005 16:01:26 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Some people have been advocating a profile approach. I am simply trying to > figure out if there are a large contingent of applications for both > profiles. I have heard many applications (much more than just file system) > that would not be impacted by no strong ETags so I am convinced that group > is large, what I am looking for is what are the applications in the other > group that don't care if they get back a weak or strong ETag? First of all, I'm not aware of any widely deployed WebDAV clients that currently *require* strong ETags, because they wouldn't work with many servers. If somebody disagrees here, please provide details. Furthermore, it seems to me that many still underestimate what requiring strong ETags means. Let's see what RFC2616 says...: 'A "strong entity tag" MAY be shared by two entities of a resource only if they are equivalent by octet equality.' () That means that requiring strong ETags rules out *any* kind of server that actually doesn't store content binary. Some examples are: - XML based databases with WebDAV interfaces (Tamino, Oracle?) - Severs specializing in / optimizing for specific content types (Atom, ICS) In particular I'm surprised to hear that implementors of CalDAV clients expect the servers to provide strong ETags for calendar entries. A calendar server that has a ICS store has basically the following options: - store the binary representation sent with PUT for every entry (expensive), or - do not return an ETag at all after PUT, because the ETag returnen upon GET will depend on what the server's default binary representation of the calendar object will be (and that's unlikely the same as sent by arbitrary clients) On the other hand, a server that implements RFC2616/RFC2518 would just use weak ETags, allowing to reformat the content as long the semantics stay the same. > Let me a related questions to client implementers? On the phone call the > other day, knowledgeable server implementers seemed to imply that the right > solution for clients that got bag a weak ETag but needed a strong one was to > poll the server until they got back a strong one. Does any client do that? I would be surprised, because there's no guarantee that this will actually work (a server may decide to use weak ETags all the time). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Nov 27 14:35:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgSJS-0003Jy-6N for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 14:35:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19851 for ; Sun, 27 Nov 2005 14:35:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgSHx-0002kG-Kk for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Nov 2005 19:34:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EgSHr-0002hZ-FF for w3c-dist-auth@listhub.w3.org; Sun, 27 Nov 2005 19:34:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EgSHn-0004GY-W9 for w3c-dist-auth@w3.org; Sun, 27 Nov 2005 19:34:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jARJY6Ke000363; Sun, 27 Nov 2005 11:34:06 -0800 Date: Sun, 27 Nov 2005 11:34:06 -0800 Message-Id: <200511271934.jARJY6Ke000363@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/200511271934.jARJY6Ke000363@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10702 X-Loop: w3c-dist-auth@w3.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: Sun, 27 Nov 2005 19:34:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-27 11:34 ------- Proposed replacement text for section 4.4 (also see ). Note that due to the fact that this may be the issue that has been the source of lots of discussion, I also added a real-world example. Feedback appreciated. 4.4 Property Values The value of a property is always a (well-formed) XML fragment. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. A property is always presented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist: The value of the property appears inside the property name element. It may be any kind of well-formed XML content, including both text- only and mixed content. In the latter case, servers MUST preserve certain aspects of the content. Using the terminology from [REC-XML- INFOSET], the following rules apply: For the property name element itself: (1) [namespace name], (2) [local name], (3) [attributes] named "xml:space" (present on the property name element itself or it's closest ancestor), (4) [children] of type element or character. For all children of the property name element additionally: (5) [attributes]. Future revisions of this specification may also require to preserve namespace prefixes for child elements of the property elements, thus servers SHOULD preserve the (6) [prefix]. XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. Note that a property only has one single value in one language (when specified). Also note that whitespace inside values is always significant, and that servers MUST NOT support overriding this using the xml:space attribute. 4.4.1 Example - Property with mixed content Consider a dead property such as: Jane Doe mailto:jane.doe@example.com http://www.example.com too long on the long-awaited revision of RFC2518. ]]> (where an xml:lang attribute with value 'en' appeared on a parent element when setting the property) When retrieving the property, a server may return: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has working way too long on the long-awaited revision of RFC2518. Note: o The [prefix] for the property name itself was not preserved, being non-significant, o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and that attribute order has not been preserved, o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope), o the [prefix] has been preserved on the child element "notes", o whitespace between tags has been preserved everywhere (but the fact that CDATA escaping was used is irrelevant), and o the comment item was stripped (as would have been a processing instruction item). ------- 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@frink.w3.org Sun Nov 27 14:46:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgSTz-0004zw-Kg for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 14:46:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21109 for ; Sun, 27 Nov 2005 14:46:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgSTH-0005h5-V5 for w3c-dist-auth-dist@listhub.w3.org; Sun, 27 Nov 2005 19:45:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EgSTH-0005gX-Gi for w3c-dist-auth@listhub.w3.org; Sun, 27 Nov 2005 19:45:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EgSTE-0000fD-Be for w3c-dist-auth@w3.org; Sun, 27 Nov 2005 19:45:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jARJjulM000383; Sun, 27 Nov 2005 11:45:56 -0800 Date: Sun, 27 Nov 2005 11:45:56 -0800 Message-Id: <200511271945.jARJjulM000383@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EgSTE-0000fD-Be 018e952076e337ea013b4e1a4bb13a92 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/200511271945.jARJjulM000383@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10703 X-Loop: w3c-dist-auth@w3.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: Sun, 27 Nov 2005 19:45:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-27 11:45 ------- Oh my, shouldn't have put XHTML markup inside CDATA :-). Example fixed: 4.4.1 Example - Property with mixed content Consider a dead property such as: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has working way too long on the long-awaited revision of ]]>. (where an xml:lang attribute with value 'en' appeared on a parent element when setting the property) When retrieving the property, a server may return: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has working way too long on the long-awaited revision of <RFC2518>. Note: o The [prefix] for the property name itself was not preserved, being non-significant, o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and that attribute order has not been preserved, o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope), o the [prefix] has been preserved on the child element "notes", o whitespace between tags has been preserved everywhere (but the fact that CDATA escaping was used is irrelevant), and o the comment item was stripped (as would have been a processing instruction item). ------- 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@frink.w3.org Sun Nov 27 21:00:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgYJs-0001uR-Sc for webdav-archive@megatron.ietf.org; Sun, 27 Nov 2005 21:00:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21309 for ; Sun, 27 Nov 2005 20:59:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgYI3-0002aN-KL for w3c-dist-auth-dist@listhub.w3.org; Mon, 28 Nov 2005 01:58:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EgYHx-0002XY-UL for w3c-dist-auth@listhub.w3.org; Mon, 28 Nov 2005 01:58:41 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EgYHt-0003UP-Lz for w3c-dist-auth@w3.org; Mon, 28 Nov 2005 01:58:40 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 27 Nov 2005 17:58:36 -0800 X-IronPort-AV: i="3.97,383,1125903600"; d="scan'208"; a="234727304:sNHT25489524" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAS1wY6a020208; Sun, 27 Nov 2005 17:58:34 -0800 (PST) Received: from 10.21.83.141 ([10.21.83.141]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 28 Nov 2005 01:59:32 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 27 Nov 2005 14:17:27 -0800 From: Cullen Jennings To: Julian Reschke CC: WebDav , Geoffrey M Clemm Message-ID: Thread-Topic: ETags, next call, was: Notes on call from today ... Thread-Index: AcXzoFlkmAx2Zl+TEdq3NgARJEEJ/A== In-Reply-To: <4389D7FA.5070506@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EgYHt-0003UP-Lz 1e869e481542e244fda1f4e652f284b1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/BFAF7077.6285E%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10704 X-Loop: w3c-dist-auth@w3.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, 28 Nov 2005 01:58:47 +0000 Content-Transfer-Encoding: 7bit This is all fine but I think I am still far behind you. You keep pointing out it is impossible to implement but I'm actually interested in who might not need it? How can I make my question any more clear that I am not asking about if current servers implement it or not? I'm just trying to figure out the practicalities of number of types of application in each camp. On 11/27/05 7:59 AM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> >> Some people have been advocating a profile approach. I am simply trying to >> figure out if there are a large contingent of applications for both >> profiles. I have heard many applications (much more than just file system) >> that would not be impacted by no strong ETags so I am convinced that group >> is large, what I am looking for is what are the applications in the other >> group that don't care if they get back a weak or strong ETag? > > First of all, I'm not aware of any widely deployed WebDAV clients that > currently *require* strong ETags, because they wouldn't work with many > servers. If somebody disagrees here, please provide details. > > Furthermore, it seems to me that many still underestimate what requiring > strong ETags means. Let's see what RFC2616 says...: > > 'A "strong entity tag" MAY be shared by two entities of a resource only > if they are equivalent by octet equality.' > > () > > That means that requiring strong ETags rules out *any* kind of server > that actually doesn't store content binary. Some examples are: > > - XML based databases with WebDAV interfaces (Tamino, Oracle?) > > - Severs specializing in / optimizing for specific content types (Atom, ICS) > > In particular I'm surprised to hear that implementors of CalDAV clients > expect the servers to provide strong ETags for calendar entries. A > calendar server that has a ICS store has basically the following options: > > - store the binary representation sent with PUT for every entry > (expensive), or > > - do not return an ETag at all after PUT, because the ETag returnen upon > GET will depend on what the server's default binary representation of > the calendar object will be (and that's unlikely the same as sent by > arbitrary clients) > > On the other hand, a server that implements RFC2616/RFC2518 would just > use weak ETags, allowing to reformat the content as long the semantics > stay the same. > >> Let me a related questions to client implementers? On the phone call the >> other day, knowledgeable server implementers seemed to imply that the right >> solution for clients that got bag a weak ETag but needed a strong one was to >> poll the server until they got back a strong one. Does any client do that? > > I would be surprised, because there's no guarantee that this will > actually work (a server may decide to use weak ETags all the time). > > Best regards, Julian From mpzavtfvklnj@macdonald.cc Mon Nov 28 01:52:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egcrq-0007bO-VT for webdav-archive@megatron.ietf.org; Mon, 28 Nov 2005 01:52:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18977 for ; Mon, 28 Nov 2005 01:51:19 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgdBe-0000Ud-Ir for webdav-archive@ietf.org; Mon, 28 Nov 2005 02:12:32 -0500 Received: from c-67-184-13-128.hsd1.il.comcast.net ([67.184.13.128]) by mx2.foretec.com with smtp (Exim 4.24) id 1Egcrk-00052S-6k for webdav-archive@ietf.org; Mon, 28 Nov 2005 01:51:56 -0500 Received: from . ...es ([1] helo=.mail.desty.org) by smtp3.desty.org with esmtp id 7A565j-0051FN-00; Mon, 28 Nov 2005 09:48:49 +0300 Message-Id: Sender: mpzavtfvklnj@macdonald.cc Date: Mon, 28 Nov 2005 09:46:49 +0300 In-Reply-To: Your message of "Mon, 28 Nov 2005 09:43:49 +0300." <20031002150239.GG32185@asuka.tech.sitadelle.com> From: "Cecile Kirby" To: webdav-archive@ietf.org Subject: Welcome to matrix X-Spam-Score: 3.7 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d -Icrease Your Sexual Desire and Sperm volume by 500% -Longer orgasms - The longest most intense orgasms of your life -Rock hard erections - Erections like steel -Ejaculate like a porn star - Stronger ejaculation -Multiple orgasms - Cum again and again -SPUR-M is The Newest and The Safest Way of Pharmacy -100% Natural and No Side Effects - in contrast to well-known brands. -Experience three times longer orgasms -World Wide shipping within 24 hours Click here http://davidsellsmt.info From w3c-dist-auth-request@frink.w3.org Mon Nov 28 02:29:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgdSV-0005x1-Hx for webdav-archive@megatron.ietf.org; Mon, 28 Nov 2005 02:29:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22713 for ; Mon, 28 Nov 2005 02:29:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EgdR0-0000nQ-NC for w3c-dist-auth-dist@listhub.w3.org; Mon, 28 Nov 2005 07:28:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EgdQu-0000mD-91 for w3c-dist-auth@listhub.w3.org; Mon, 28 Nov 2005 07:28:16 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EgdQp-0005tA-Im for w3c-dist-auth@w3.org; Mon, 28 Nov 2005 07:28:15 +0000 Received: (qmail invoked by alias); 28 Nov 2005 07:28:07 -0000 Received: from p508FB63C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.182.60] by mail.gmx.net (mp027) with SMTP; 28 Nov 2005 08:28:07 +0100 X-Authenticated: #1915285 Message-ID: <438AB151.8090001@gmx.de> Date: Mon, 28 Nov 2005 08:27:13 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EgdQp-0005tA-Im 6990b1815eb87f62641ff90503a1f38e X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/438AB151.8090001@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10705 X-Loop: w3c-dist-auth@w3.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, 28 Nov 2005 07:28:22 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > This is all fine but I think I am still far behind you. You keep pointing > out it is impossible to implement but I'm actually interested in who might > not need it? How can I make my question any more clear that I am not asking > about if current servers implement it or not? I'm just trying to figure out > the practicalities of number of types of application in each camp. Well. I thought that was clear from the fact that today you can't rely on it. Thus, none of the general purpose WebDAV clients I know of (Webfolders, Xythos, MacOSX) seems to need it (implementors, please speak up if I'm incorrect here). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Nov 28 18:12:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgsAy-00022y-B0 for webdav-archive@megatron.ietf.org; Mon, 28 Nov 2005 18:12:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06651 for ; Mon, 28 Nov 2005 18:12:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Egs95-0006rs-SX for w3c-dist-auth-dist@listhub.w3.org; Mon, 28 Nov 2005 23:10:51 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Egs8z-0006qJ-2V for w3c-dist-auth@listhub.w3.org; Mon, 28 Nov 2005 23:10:45 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Egs8p-0006ee-95 for w3c-dist-auth@w3.org; Mon, 28 Nov 2005 23:10:44 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DCC9214228C; Mon, 28 Nov 2005 15:10:31 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13865-03; Mon, 28 Nov 2005 15:10:31 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E0536142288; Mon, 28 Nov 2005 15:10:30 -0800 (PST) In-Reply-To: <4389D7FA.5070506@gmx.de> References: <4389D7FA.5070506@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , WebDav , Cullen Jennings From: Lisa Dusseault Date: Mon, 28 Nov 2005 15:10:29 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Egs8p-0006ee-95 ec7f92b2645400be50e7ba507a3fa494 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10706 X-Loop: w3c-dist-auth@w3.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, 28 Nov 2005 23:10:51 +0000 Content-Transfer-Encoding: 7bit On Nov 27, 2005, at 7:59 AM, Julian Reschke wrote: > > In particular I'm surprised to hear that implementors of CalDAV > clients expect the servers to provide strong ETags for calendar > entries. A calendar server that has a ICS store has basically the > following options: > > - store the binary representation sent with PUT for every entry > (expensive), or > > - do not return an ETag at all after PUT, because the ETag returnen > upon GET will depend on what the server's default binary > representation of the calendar object will be (and that's unlikely the > same as sent by arbitrary clients) Another option is for the server to store the calendar data in some internal format (e.g. nodes) and have a consistent way of constructing the entity from that. As long as the server has an algorithm that generates the same bytes each time from the underlying data, it can use the same ETag. It also doesn't matter what format the client sends the event in: the ETag refers to the octets the server sends, not to the octets the client sends. It also doesn't matter if the client can request variants: for example, a server can keep one ETag around for the iCalendar version of the event, and a separate ETag for the xCalendar version of the event if it can generate two formats (both consistently). Both ETags would have to change if the event data actually changed, of course. > > On the other hand, a server that implements RFC2616/RFC2518 would just > use weak ETags, allowing to reformat the content as long the semantics > stay the same. How do weak ETags solve this? What can a client really rely on if the weak ETag is the same, or different? Do you believe a client could rely on weak ETags to do synchronization? Wouldn't we need restrictions on what changes could be allowed before the weak ETag had to change in order to use weak ETags? I haven't seen weak ETags be useful to clients except in two cases: - possibly for a client doing GET only (not an authoring client, and so it doesn't care about obtaining exact copy to author from) - a client that has inside information about what a server does -- e.g. a client with a coding dependency on the behavior of Apache which is to switch from a weak ETag to a strong one. Lisa From miyoshi@gloverelectrical.com Mon Nov 28 19:50:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgthE-0000xl-2t for webdav-archive@megatron.ietf.org; Mon, 28 Nov 2005 19:50:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17299 for ; Mon, 28 Nov 2005 19:49:28 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egu1B-00042l-87 for webdav-archive@ietf.org; Mon, 28 Nov 2005 20:10:50 -0500 Received: from 196.red-83-35-16.dynamicip.rima-tde.net ([83.35.16.196] helo=-193059528) by mx2.foretec.com with smtp (Exim 4.24) id 1Egth4-0008GA-LC for webdav-archive@ietf.org; Mon, 28 Nov 2005 19:50:06 -0500 Received: from gloverelectrical.com (-195715680 [-195952232]) by 196.Red-83-35-16.dynamicIP.rima-tde.net (Qmailv1) with ESMTP id B2B9A6B680 for ; Tue, 29 Nov 2005 08:53:56 -0600 Date: Tue, 29 Nov 2005 08:53:56 -0600 From: Doctor X-Mailer: The Bat! (v2.00.7) Personal X-Priority: 3 Message-ID: <0266191792.20051129085356@gloverelectrical.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------1D017BDF138762E" X-AntiVirus: OK! AntiVir MailGate Version 2.0.1; AVE: 6.15.0.0; VDF: 6.15.0.6 X-Spam-Score: 3.1 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------1D017BDF138762E Content-Type: text/plain Content-Transfer-Encoding: 7bit Vllagra $3.3 Lervitra $3.3 Cimalis $3.7 Imijtrex $16.4 Flormax $2.2 Ultxram $0.78 Vitoxx $4.75 Ambbien $2.2 Valiqum $0.97 Xarnax $1.09 Somya $3 Mercidia $2.2 visit our website http://obeegativ.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals qwefgfgjs RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------1D017BDF138762E Content-Type: text/html Content-Transfer-Encoding: 7bit Vllagra - $3.3
Lemvitra - $3.3
Cifalis - $3.7
Imiitrex - $16.4
Floxmax - $2.2
Ultgram - $0.78
Viroxx - $4.75
Ammbien - $2.2
Valibum - $0.97
Xamnax - $1.09
Somoa - $3
Mernidia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

qwefgfgjs RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------1D017BDF138762E-- From w3c-dist-auth-request@frink.w3.org Tue Nov 29 04:27:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh1lj-0000zH-Sq for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 04:27:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07695 for ; Tue, 29 Nov 2005 04:26:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eh1kP-0002Zu-D2 for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 09:26:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eh1kH-0002ZL-E1 for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 09:25:53 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Eh1k5-00085s-Vh for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 09:25:52 +0000 Received: (qmail invoked by alias); 29 Nov 2005 09:25:27 -0000 Received: from p508FB4D4.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.212] by mail.gmx.net (mp031) with SMTP; 29 Nov 2005 10:25:27 +0100 X-Authenticated: #1915285 Message-ID: <438C1E4B.5090002@gmx.de> Date: Tue, 29 Nov 2005 10:24:27 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , WebDav , Cullen Jennings References: <4389D7FA.5070506@gmx.de> <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> In-Reply-To: <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eh1k5-00085s-Vh 1bbcc8bf9461f26597572b5bd41a7056 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/438C1E4B.5090002@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10707 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 09:26:01 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > On Nov 27, 2005, at 7:59 AM, Julian Reschke wrote: >> >> In particular I'm surprised to hear that implementors of CalDAV >> clients expect the servers to provide strong ETags for calendar >> entries. A calendar server that has a ICS store has basically the >> following options: >> >> - store the binary representation sent with PUT for every entry >> (expensive), or >> >> - do not return an ETag at all after PUT, because the ETag returnen >> upon GET will depend on what the server's default binary >> representation of the calendar object will be (and that's unlikely the >> same as sent by arbitrary clients) > > Another option is for the server to store the calendar data in some > internal format (e.g. nodes) and have a consistent way of constructing > the entity from that. As long as the server has an algorithm that > generates the same bytes each time from the underlying data, it can use > the same ETag. That's exactly what I just said. But the problem here is that if the server does that, it can't return an ETag upon PUT. As far as I can tell, returning a strong ETag in the response to PUT signals that the server has stored the message body binary, and that the ETag applies to that content (not the internally rewritten content the client may see on the next GET request). > It also doesn't matter what format the client sends the event in: the > ETag refers to the octets the server sends, not to the octets the client > sends. How do you know that? RFC2616 in fact doesn't define at all what an ETag in a response to PUT means (): "The ETag response-header field provides the current value of the entity tag for the requested variant." Note that PUT doesn't request any representation/variant, thus the text doesn't even apply. I guess that's another reason why RFC2518bis MUST NOT make any statements about ETags in PUT responses. This really needs to be coordinated with the base spec. > It also doesn't matter if the client can request variants: for example, > a server can keep one ETag around for the iCalendar version of the > event, and a separate ETag for the xCalendar version of the event if it > can generate two formats (both consistently). Both ETags would have to > change if the event data actually changed, of course. That may be true, although "common wisdom" (i.e. afair Roy's) is that resources that are content-negotiated better not be authorable. >> On the other hand, a server that implements RFC2616/RFC2518 would just >> use weak ETags, allowing to reformat the content as long the semantics >> stay the same. > > How do weak ETags solve this? What can a client really rely on if the > weak ETag is the same, or different? Do you believe a client could rely > on weak ETags to do synchronization? Wouldn't we need restrictions on Yes, I would think so. > what changes could be allowed before the weak ETag had to change in > order to use weak ETags? : "A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics. A weak entity tag can only be used for weak comparison." > I haven't seen weak ETags be useful to clients except in two cases: > - possibly for a client doing GET only (not an authoring client, and so > it doesn't care about obtaining exact copy to author from) > - a client that has inside information about what a server does -- e.g. > a client with a coding dependency on the behavior of Apache which is to > switch from a weak ETag to a strong one. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Nov 29 05:09:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh2Qn-0005HF-MT for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 05:09:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11962 for ; Tue, 29 Nov 2005 05:09:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eh2Py-0005z5-Gp for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 10:08:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eh2Pt-0005xP-66 for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 10:08:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eh2Pl-0004VH-4c for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 10:08:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jATA8fCZ003709; Tue, 29 Nov 2005 02:08:41 -0800 Date: Tue, 29 Nov 2005 02:08:41 -0800 Message-Id: <200511291008.jATA8fCZ003709@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eh2Pl-0004VH-4c c31120040a0cc4383cbf799a2ffe1817 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 13] new ETag requirements X-Archived-At: http://www.w3.org/mid/200511291008.jATA8fCZ003709@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10708 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 10:08:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-29 02:08 ------- Also note the new requirements in : "The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Refer to RFC2616 for a complete definition of the semantics of an ETag. Note that changes in properties or lock state MUST not cause a resource's ETag to change." ------- 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@frink.w3.org Tue Nov 29 13:28:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhADp-0005KR-Jj for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 13:28:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16393 for ; Tue, 29 Nov 2005 13:28:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhABs-0001QV-9c for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 18:26:56 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhABm-0001Mz-BK for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 18:26:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhABd-0005v0-2z for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 18:26:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jATIQHEL006234; Tue, 29 Nov 2005 10:26:17 -0800 Date: Tue, 29 Nov 2005 10:26:17 -0800 Message-Id: <200511291826.jATIQHEL006234@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhABd-0005v0-2z e3f8f7fe2d55ba44dff3f0f248dbc70d 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/200511291826.jATIQHEL006234@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10709 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 18:26:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-29 10:26 ------- Proposed resolution: follow pointers from , summary: Removed section explaining why 503 is a candidate status code for detected DOS attacks (this doesn't make any sense at all, because if a server indeed detects a DOS attack, it will signal a client error, not a "not now, but maybe later" condition). Rename Section Section 19.6 to "Implications of XML entities", and also expain the so-called one-billion-laughs-attack over there. Expand Section 8.1.1 to point to the various risks described in Section 19, and give advice on how to reject those requests. ------- 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@frink.w3.org Tue Nov 29 13:40:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAOl-0006QK-MY for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 13:40:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17551 for ; Tue, 29 Nov 2005 13:39:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhAO5-0006gK-4Q for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 18:39:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhAO4-0006fi-Lv for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 18:39:32 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by lisa.w3.org with esmtp (Exim 4.50) id 1EhAO3-0006pM-5P for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 18:39:31 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhANq-00023Z-BW for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 18:39:23 +0000 Received: from [192.168.2.104] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jATIdFvs025405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Nov 2005 10:39:16 -0800 (PST) Message-ID: <438CA053.3000108@cse.ucsc.edu> Date: Tue, 29 Nov 2005 10:39:15 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG Content-Type: multipart/alternative; boundary="------------070004050107010500050404" Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhANq-00023Z-BW 60b5aaccf6616b27a807d1aa14003e72 Received-SPF: none (lisa.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Agenda for 11/30 telecon X-Archived-At: http://www.w3.org/mid/438CA053.3000108@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10710 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 18:39:33 +0000 This is a multi-part message in MIME format. --------------070004050107010500050404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello all, Enclosed please find the agenda for tomorrows' telecon. Although there are a few more issues than previous weeks, better than a handful of them have already been discussed and should go quickly. I've also attempted to gather together various issues dealing with namespace operations in the hope that maintaining some context through the discussion will also help things move along. Of course, anything that we don't get to will be bumped to the next telecon. Cheers, Elias _______________ (1) Brief (5 min) status update from Lisa on the -09 draft; set date if not already posted. (2) Quickly (10 - 15 minutes?) address the following issues 9 - XML namespace discussion (terminology issue) 47 - 3xx in multistatus (missing section in -08) 102 - lock tokens in examples (XML formatting issue) 172 - Whether to obsolete 'opaquelocktoken', keep it, or remove it (consensus issue) 12 - Destination header "consistent" (nits) (3) Bug bashing Critical: 173 - Info about inside multistatus lost Major: 7 - Example for PROPFIND/allprop missing (Important but easy to address.) 51 - Property behaviour upon COPY vs "remote COPY" (Is this covered by the discussion of issue 27, COPY with live properties?) 28 - MOVE vs live properties (Also related to the discussion of issue 27 in the 11/25 telecon.) 85 - clarification of live property behaviour vs namespace ops needed (This seems to follow logically from issue 28, above; perhaps a non-issue now.) 93 - Write Locks and Collections vs MOVE (More on namespace operations.) 94 - COPY and the Overwrite Header vs (Yet another issue related to namespace operations.) 48 - XML extensibility description (Should be relatively easy to reach consensus on this one) 95 - possible LOCK response codes 171 - If header grammar (Check production rules.) Normal: 10 - Round-tripping namespace decls in properties (Need to hammer out text, as none has been proposed) Minor: 186 - opaquelocktoken appendix (Perhaps resolved in earlier discussion of issue 172.) Trivial: 174 - Terminology in 4.4: "namespace name in scope" (Should be easy to reach consensus.) --------------070004050107010500050404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all,

Enclosed please find the agenda for tomorrows' telecon. Although there are a few more issues than previous weeks, better than a handful of them have already been discussed and should go quickly. I've also attempted to gather together various issues dealing with namespace operations in the hope that maintaining some context through the discussion will also help things move along. Of course, anything that we don't get to will be bumped to the next telecon.


Cheers,
Elias
_______________

(1) Brief (5 min) status update from Lisa on the -09 draft; set date if not already posted.

(2) Quickly (10 - 15 minutes?) address the following issues
9 - XML namespace discussion (terminology issue)
47 - 3xx in multistatus (missing section in  -08)
102 - lock tokens in examples (XML formatting issue)
172 - Whether to obsolete 'opaquelocktoken', keep it, or remove it (consensus issue)
12 - Destination header "consistent" (nits)

(3) Bug bashing
Critical:
173 - Info about <location> inside multistatus lost
Major:
7 - Example for PROPFIND/allprop missing
     (Important but easy to address.)
51 - Property behaviour upon COPY vs "remote COPY"
       (Is this covered by the discussion of issue 27, COPY with live properties?)
28 - MOVE vs live properties
       (Also related to the discussion of issue 27 in the 11/25 telecon.)
85 - clarification of live property behaviour vs namespace ops needed
       (This seems to follow logically from issue 28, above; perhaps a non-issue now.)
93 - Write Locks and Collections vs MOVE
       (More on namespace operations.)
94 - COPY and the Overwrite Header vs
       (Yet another issue related to namespace operations.)
48 - XML extensibility description
       (Should be relatively easy to reach consensus on this one)
95 - possible LOCK response codes
171 - If header grammar
         (Check production rules.)
Normal:
10 - Round-tripping namespace decls in properties
       (Need to hammer out text, as none has been proposed)
Minor:
186 - opaquelocktoken appendix
         (Perhaps resolved in earlier discussion of issue 172.)
Trivial:
174 - Terminology in 4.4: "namespace name in scope"
         (Should be easy to reach consensus.)

--------------070004050107010500050404-- From w3c-dist-auth-request@frink.w3.org Tue Nov 29 13:51:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAZ9-0001EK-QM for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 13:51:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19319 for ; Tue, 29 Nov 2005 13:50:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhAYS-0003Va-5n for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 18:50:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhAYP-0003UZ-6a for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 18:50:13 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EhAYE-0005RQ-T0 for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 18:50:12 +0000 Received: (qmail invoked by alias); 29 Nov 2005 18:49:21 -0000 Received: from p508FB4D4.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.212] by mail.gmx.net (mp017) with SMTP; 29 Nov 2005 19:49:21 +0100 X-Authenticated: #1915285 Message-ID: <438CA24A.8010301@gmx.de> Date: Tue, 29 Nov 2005 19:47:38 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Elias Sinderson CC: webdav WG References: <438CA053.3000108@cse.ucsc.edu> In-Reply-To: <438CA053.3000108@cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhAYE-0005RQ-T0 f73cf32c18b8c9a8129f27f0e91f68b4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Agenda for 11/30 telecon X-Archived-At: http://www.w3.org/mid/438CA24A.8010301@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10711 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 18:50:16 +0000 Content-Transfer-Encoding: 7bit Elias, thanks for the agenda. I've worked on some of the issues, attendees of the conference call (and of course everybody else) may want to check the following proposed changes (maybe having spec-ready text will help resolving these issues quickly). In particular: > 172 - > Whether to obsolete 'opaquelocktoken', keep it, or remove it (consensus > issue) > 10 - > Round-tripping namespace decls in properties > (Need to hammer out text, as none has been proposed) > Minor: > 186 - > opaquelocktoken appendix > (Perhaps resolved in earlier discussion of issue 172.) (again) > Trivial: > 174 - > Terminology in 4.4: "namespace name in scope" > (Should be easy to reach consensus.) gone with the proposed rewrite () Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Nov 29 14:00:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAhs-0002Qw-NG for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 14:00:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20581 for ; Tue, 29 Nov 2005 13:59:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhAh5-0005Rh-Bm for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 18:59:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhAh4-0005R1-Q6 for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 18:59:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhAh1-0000Ho-JS for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 18:59:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jATIwk5U006280; Tue, 29 Nov 2005 10:58:46 -0800 Date: Tue, 29 Nov 2005 10:58:46 -0800 Message-Id: <200511291858.jATIwk5U006280@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhAh1-0000Ho-JS 6647c213619d6107f4b1e38c08b7b91f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200511291858.jATIwk5U006280@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10712 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 18:59:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-29 10:58 ------- See also discussion . ------- 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@frink.w3.org Tue Nov 29 15:11:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBod-0008F4-54 for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 15:11:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29006 for ; Tue, 29 Nov 2005 15:10:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhBnV-0005qm-OA for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 20:09:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhBnO-0005Z5-Fp for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 20:09:46 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EhBnL-0003d5-Jk for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 20:09:45 +0000 Received: (qmail invoked by alias); 29 Nov 2005 20:09:22 -0000 Received: from p508FB4D4.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.212] by mail.gmx.net (mp007) with SMTP; 29 Nov 2005 21:09:22 +0100 X-Authenticated: #1915285 Message-ID: <438CB501.9070001@gmx.de> Date: Tue, 29 Nov 2005 21:07:29 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Geoffrey M Clemm , WebDav , Cullen Jennings References: <4389D7FA.5070506@gmx.de> <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> <438C1E4B.5090002@gmx.de> <58CC0E40-16C8-4440-8BFC-3A8569F77198@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/438CB501.9070001@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10713 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 20:09:53 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I hadn't thought that a client could use weak etags at all for > authoring. I had started from considering the cases of a JPG or a > Photoshop file or a Word document. What does a weak ETag mean for those > documents? If I edit a Word document on a WebDAV server and all I do is > fix a couple inconsistent fonts and a space or two, one might think that > the weak ETag need not change -- but I would not find the system very > usable if these changes were lost on a subsequent update. Of course it's not always simple to define what "semantically equivalent" means. For instance, if a server would take the Word document and remove all implementation artefacts (for which there are cleanup tools nowadays), I'd call that "semantically equivalent", and a useful feature. Servers like these exist, and making the revision of WebDAV inherently incompatible with them IMHO is an extremely bad idea. Fortunately, I'm pretty confident that the community wouldn't let us get away with that. It seems that you have a very specific authoring scenario in mind, which you'd like to be simpler to support in a client. How about summarizing the *precise* requirements first, then think about the right technical approach, and only then discuss a way what to do in the spec? Yes, that's more work to do then simply stating "Strong ETags are now required", but it's the better approach nevertheless. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Nov 29 15:47:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCOI-0007Yn-9J for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 15:47:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03206 for ; Tue, 29 Nov 2005 15:47:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhCNU-0004ik-UJ for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 20:47:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhBdP-0005IM-6O for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 19:59:27 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhBUT-0001KV-Am for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 19:50:20 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F194C1422B4; Tue, 29 Nov 2005 11:49:56 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18031-08; Tue, 29 Nov 2005 11:49:56 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 960A91422B1; Tue, 29 Nov 2005 11:49:56 -0800 (PST) In-Reply-To: <58CC0E40-16C8-4440-8BFC-3A8569F77198@apple.com> References: <4389D7FA.5070506@gmx.de> <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> <438C1E4B.5090002@gmx.de> <58CC0E40-16C8-4440-8BFC-3A8569F77198@apple.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , Geoffrey M Clemm , WebDav , Cullen Jennings From: Lisa Dusseault Date: Tue, 29 Nov 2005 11:49:55 -0800 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhBUT-0001KV-Am 1df7236d8a1ef828c3b622700d0a8b4c X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/d798963775414caa9ac27ac98c41ee4a@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10714 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 20:47:04 +0000 Content-Transfer-Encoding: quoted-printable I hadn't thought that a client could use weak etags at all for=20 authoring. I had started from considering the cases of a JPG or a=20 Photoshop file or a Word document. What does a weak ETag mean for=20 those documents? If I edit a Word document on a WebDAV server and all=20= I do is fix a couple inconsistent fonts and a space or two, one might=20 think that the weak ETag need not change -- but I would not find the=20 system very usable if these changes were lost on a subsequent update. Lisa On Nov 29, 2005, at 11:09 AM, Wilfredo S=E1nchez Vega wrote: > Agreed. If you can only guarantee semantic equivalence and not=20 > byte-for-byte equivalence between GETs, you have to must weak etags=20 > according to HTTP/1.1. > > A weak etag, as per rfc2616, should sufficient for CalDAV and=20 > accurately reflects what's going on in the server if it is generating=20= > the iCalendar dynamically. I don't see why a client can't use that to=20= > do sync just fine. All you care about is whether the etag changes,=20 > not whether it's strong or weak, unless you actually need=20 > byte-for-byte replication, but I don't know why you would. > > -wsv > > > On Nov 29, 2005, at 1:24 AM, Julian Reschke wrote: > >>>> On the other hand, a server that implements RFC2616/RFC2518 would=20= >>>> just use weak ETags, allowing to reformat the content as long the=20= >>>> semantics stay the same. >>> How do weak ETags solve this? What can a client really rely on if=20= >>> the weak ETag is the same, or different? Do you believe a client=20 >>> could rely on weak ETags to do synchronization? Wouldn't we need=20 >>> restrictions on >> >> Yes, I would think so. >> >>> what changes could be allowed before the weak ETag had to change in=20= >>> order to use weak ETags? >> >> : >> >> "A "weak entity tag," indicated by the "W/" prefix, MAY be shared by=20= >> two entities of a resource only if the entities are equivalent and=20 >> could be substituted for each other with no significant change in=20 >> semantics. A weak entity tag can only be used for weak comparison." > From w3c-dist-auth-request@frink.w3.org Tue Nov 29 16:14:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCoA-0001at-6V for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 16:14:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09173 for ; Tue, 29 Nov 2005 16:13:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhCnb-0006CW-Up for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 21:14:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhCna-0006AM-BZ for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 21:14:02 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EhCnX-0004X2-4o for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 21:14:01 +0000 Received: (qmail invoked by alias); 29 Nov 2005 21:13:47 -0000 Received: from p508FB4D4.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.212] by mail.gmx.net (mp031) with SMTP; 29 Nov 2005 22:13:47 +0100 X-Authenticated: #1915285 Message-ID: <438CC421.3020600@gmx.de> Date: Tue, 29 Nov 2005 22:12:01 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhCnX-0004X2-4o a49558b4eec15c2ab7f2c5fa36f6c5de X-Original-To: w3c-dist-auth@w3.org Subject: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/438CC421.3020600@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10716 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 21:14:03 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA09173 (fyi) -------- Original Message -------- Wilfredo S=E1nchez Vega wrote: > Question for you. >=20 > Apache HTTPD emits a weak etag for a file resource if the timestamp o= n=20 > the file is the same as the current time (one second accuracy) and a=20 > strong etag otherwise. >=20 > The reason for that logic, as I understand it, is that because the=20 > etag generation depends on the timestamp and that the file may change=20 > multiple times within a one-second period, an etag generated from a=20 > timestamp matching the current time isn't reliable. Finally a good explanation. > But your post caused me to re-read the spec, and this logic doesn't=20 > seem consistent with the spec. The weak etag would be the same for all= =20 > changes in a one-second period but the documents may not be semanticall= y=20 > similar. So that seems like a bug. Perhaps HTTPD should instead omit=20 > the etag in that case, since the etag isn't weak; it's simply not=20 > correctly calculable using the timestamp. >=20 > That sound right? I think this is correct, and getting this question answered is essential on how the working group tackles the various (new) ETag issues in RFC2518bis. May I forward this mail to the WebDAV mailing list? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Nov 29 16:14:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCo4-0001aV-5w for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 16:14:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09139 for ; Tue, 29 Nov 2005 16:13:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhCn3-00064e-DA for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 21:13:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhCmv-00062r-QB for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 21:13:22 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhCmm-00045g-JA for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 21:13:21 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jATLC5tZ026880; Tue, 29 Nov 2005 13:12:08 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 9BB6F4A8; Tue, 29 Nov 2005 13:12:05 -0800 (PST) In-Reply-To: References: <4389D7FA.5070506@gmx.de> <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> <438C1E4B.5090002@gmx.de> <58CC0E40-16C8-4440-8BFC-3A8569F77198@apple.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54EAAEC6-A208-4A66-BAD2-4894B3100F80@wsanchez.net> Cc: Julian Reschke , Geoffrey M Clemm , WebDav , Cullen Jennings Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Tue, 29 Nov 2005 13:12:04 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (maggie.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhCmm-00045g-JA 22d3ac05d179477a65a892940e7b333e X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/54EAAEC6-A208-4A66-BAD2-4894B3100F80@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10715 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 21:13:29 +0000 Content-Transfer-Encoding: 7bit On Nov 29, 2005, at 11:49 AM, Lisa Dusseault wrote: > I hadn't thought that a client could use weak etags at all for > authoring. I had started from considering the cases of a JPG or a > Photoshop file or a Word document. What does a weak ETag mean for > those documents? If I edit a Word document on a WebDAV server and > all I do is fix a couple inconsistent fonts and a space or two, one > might think that the weak ETag need not change -- but I would not > find the system very usable if these changes were lost on a > subsequent update. As Julian said, the meaning of semantically equivalent is important. The XML rewriting debate with respect to properties we've been having is an example of why it's important to define, and presumably a similar debate could be had as to whether such rewriting of a XML resource body would lend itself to a weak etag match. In the case of CalDAV, the iCalendar spec would be the authority on semantic equivalence. If iCalendar says that the order of iCalendar properties and subcomponents is semantically meaningful, then they need to be preserved. (Presumably the iCalendar parsers, storage, and generators you use would know this and preserve the order.) If not, then for the purposes of iCalendar, changes in order are semantically equivalent, and we could probably agree that for CalDAV such changed in a element are equivalent by extension. It should be noted that we've already agreed that normalizing out newlines in iCalendar data within XML is OK, and that variation would be semantically equivalent as well as any variations considered equivalent in iCalendar. CalDAV should probably be explicit about both of these equivalence measures as they related to etags. -wsv From w3c-dist-auth-request@frink.w3.org Tue Nov 29 16:30:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhD2z-0007mD-Df for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 16:30:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11165 for ; Tue, 29 Nov 2005 16:29:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhD2D-0003Dk-VX for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 21:29:09 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhD2B-0003Cw-UZ for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 21:29:08 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhD23-0006fx-RA for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 21:29:07 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BFB431422B6; Tue, 29 Nov 2005 13:28:58 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07114-01; Tue, 29 Nov 2005 13:28:58 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C91F01422B5; Tue, 29 Nov 2005 13:28:56 -0800 (PST) In-Reply-To: <438CB501.9070001@gmx.de> References: <4389D7FA.5070506@gmx.de> <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> <438C1E4B.5090002@gmx.de> <58CC0E40-16C8-4440-8BFC-3A8569F77198@apple.com> <438CB501.9070001@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <04f55c87171bb6b6ec923fa355813e62@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Geoffrey M Clemm , WebDav , Cullen Jennings From: Lisa Dusseault Date: Tue, 29 Nov 2005 13:28:53 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhD23-0006fx-RA 728e684d704d6dddb65a2bf5ac187e82 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/04f55c87171bb6b6ec923fa355813e62@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10717 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 21:29:09 +0000 Content-Transfer-Encoding: 7bit On Nov 29, 2005, at 12:07 PM, Julian Reschke wrote: > > It seems that you have a very specific authoring scenario in mind, > which you'd like to be simpler to support in a client. How about > summarizing the *precise* requirements first, then think about the > right technical approach, and only then discuss a way what to do in > the spec? Yes, that's more work to do then simply stating "Strong > ETags are now required", but it's the better approach nevertheless. > > First, before discussing the precise requirements I have in mind, I'd like to remind you that the "Strong ETags" proposal didn't come from me alone, I'm not the only one with requirements. After the 2002 interop where this was first discussed, we had a bunch of list discussion about this in late 2002, e.g. Dan Brotsky's email of Oct 16 and yours of Nov 28. You were the one who pointed out that solving the problem we were discussing required strong ETags, not weak ETags. The requirements: - Clients must be able to interoperate against different server implementations with great consistency. That means that there should be very few cases where clients need to determine what the server implementation is or what features it supports, or how, before choosing between alternative code paths. - Clients must be able to be confident, when doing a PUT, that they are not overwriting another client's change -- that means that there must be some way to compare the state of the resource to the state when it was last retrieved. - Specifically, this must work for images, HTML pages, office documents, etc -- without requiring any different behavior on the part of a client. It would be nice if the server didn't have to care what kind of resource it had, as well. - It must be possible to write a generic library or remote file system, such as WebDAV FS, Xythos WFC or Adobe's library -- one which communicates with the WebDAV server on behalf of an application such as Word or Photoshop, without requiring overly heavy integration between the application and the library. - Clients must be able to keep an offline store with content that's fairly reliably consistent with what's on the server. (One problem to solve here is for the client to know whether it needs to download a resource after a PUT) I generated these rather off-the-cuff, but I believe that's a good start at least. Lisa From w3c-dist-auth-request@frink.w3.org Tue Nov 29 16:44:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhDGz-0008Vl-DR for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 16:44:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12756 for ; Tue, 29 Nov 2005 16:43:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhDGJ-0001ub-ON for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 21:43:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhDG9-0001tA-VE for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 21:43:33 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhDG9-0003RZ-7i for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 21:43:33 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 022E81422B6; Tue, 29 Nov 2005 13:43:21 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08878-01; Tue, 29 Nov 2005 13:43:20 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C36114227B; Tue, 29 Nov 2005 13:43:20 -0800 (PST) In-Reply-To: <438CC421.3020600@gmx.de> References: <438CC421.3020600@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <44f343732127f2b6a16a63e407637eae@osafoundation.org> Content-Transfer-Encoding: quoted-printable Cc: WebDAV From: Lisa Dusseault Date: Tue, 29 Nov 2005 13:43:15 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/44f343732127f2b6a16a63e407637eae@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10718 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 21:43:43 +0000 Content-Transfer-Encoding: quoted-printable On Nov 29, 2005, at 1:12 PM, Julian Reschke wrote: > > Wilfredo S=E1nchez Vega wrote: >> Question for you. >> Apache HTTPD emits a weak etag for a file resource if the timestamp=20= >> on the file is the same as the current time (one second accuracy) and=20= >> a strong etag otherwise. >> The reason for that logic, as I understand it, is that because the=20= >> etag generation depends on the timestamp and that the file may change=20= >> multiple times within a one-second period, an etag generated from a=20= >> timestamp matching the current time isn't reliable. > > Finally a good explanation. Do other people consider this behavior to be incorrect according to the=20= spec? (I'm assuming the explanation is correct and it aligns with what=20= I've seen). But it seems that within-second changes do not guarantee=20 "semantic equivalence" as required by HTTP. Lisa From w3c-dist-auth-request@frink.w3.org Tue Nov 29 17:18:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhDoG-0002J0-NP for webdav-archive@megatron.ietf.org; Tue, 29 Nov 2005 17:18:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17440 for ; Tue, 29 Nov 2005 17:18:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhDnK-0001eX-1w for w3c-dist-auth-dist@listhub.w3.org; Tue, 29 Nov 2005 22:17:50 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhDnA-0001dG-F8 for w3c-dist-auth@listhub.w3.org; Tue, 29 Nov 2005 22:17:40 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhDn5-000421-Et for w3c-dist-auth@w3.org; Tue, 29 Nov 2005 22:17:39 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jATMHMw8008118; Tue, 29 Nov 2005 14:17:22 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id CAEB74A8; Tue, 29 Nov 2005 14:17:22 -0800 (PST) In-Reply-To: <04f55c87171bb6b6ec923fa355813e62@osafoundation.org> References: <4389D7FA.5070506@gmx.de> <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> <438C1E4B.5090002@gmx.de> <58CC0E40-16C8-4440-8BFC-3A8569F77198@apple.com> <438CB501.9070001@gmx.de> <04f55c87171bb6b6ec923fa355813e62@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <695EF07B-A22F-435C-874E-7B3BDCE71E56@wsanchez.net> Cc: Julian Reschke , WebDav WG Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Tue, 29 Nov 2005 14:17:22 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhDn5-000421-Et 1ccacbd963545d5730544b1df950f10b X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/695EF07B-A22F-435C-874E-7B3BDCE71E56@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10719 X-Loop: w3c-dist-auth@w3.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, 29 Nov 2005 22:17:50 +0000 Content-Transfer-Encoding: 7bit OK, this is a good list. On Nov 29, 2005, at 1:28 PM, Lisa Dusseault wrote: > - Clients must be able to interoperate against different server > implementations with great consistency. That means that there > should be very few cases where clients need to determine what the > server implementation is or what features it supports, or how, > before choosing between alternative code paths. Semantic equivalence requires an agreement on the meaningful features of a resource's content, and presumably not any knowledge of the server. It is of come concern, though, that the former is difficult (all servers and clients need to agree on equivalence) and that difficultly may cause the latter. > - Clients must be able to be confident, when doing a PUT, that > they are not overwriting another client's change -- that means that > there must be some way to compare the state of the resource to the > state when it was last retrieved. Weak ETags should be sufficient here, though the behavior might be different. Weak ETags imply that the server knows something about semantic equivalence, and the server is telling you that the document hasn't meaningfully changed. If overwriting the other client's change is bad, that's presumably because the other client's change was meaningful. So the problem remains in defining what's a meaningful change in the context of that resource. > - Specifically, this must work for images, HTML pages, office > documents, etc -- without requiring any different behavior on the > part of a client. It would be nice if the server didn't have to > care what kind of resource it had, as well. Right, and we're OK with how it works with strong etags. With weak etags, if the server knows nothing about the semantics of the resource, it shouldn't be issuing a weak etag to you (because that would imply that it does know). If the server does send you a weak etag, you know that the server thinks they are equivalent. Again, this means you have to trust the server to actually know. Clients don't generate etags, so the reverse isn't required. > - It must be possible to write a generic library or remote file > system, such as WebDAV FS, Xythos WFC or Adobe's library -- one > which communicates with the WebDAV server on behalf of an > application such as Word or Photoshop, without requiring overly > heavy integration between the application and the library. In filesystems, the last writer simply wins, and stomping another client's change is OK. Some apps do check if a file changed before saving, and they typically use last-modified timestamps for that; I don't know any filesystems with an equivalent to ETag. Perhaps that's a bad example. But the prior counterpoint stands. The server is the arbitrator here. If the server says the document didn't meaningfully change, then the client should be able to rely on that. What I think we need is an example scenario where I GET a document, the weak etag didn't change, so I PUT it back on save, but in the mean time the document change in a manner that the server deemed semantically equivalent, and that's somehow a problem for me. > - Clients must be able to keep an offline store with content > that's fairly reliably consistent with what's on the server. (One > problem to solve here is for the client to know whether it needs to > download a resource after a PUT) Same argument. Server tells you it hasn't changed in a way that you care about. It may have changed in a way that you don't care about. Assuming it did, why do you need to update your local copy, given that you don't care? That is, what's a scenario in which the semantics did not change, but the client needs to reload the document anyway or should refuse/ hesitate to do a PUT? -wsv From w3c-dist-auth-request@frink.w3.org Wed Nov 30 05:56:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhPdk-0000cW-2e for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 05:56:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28355 for ; Wed, 30 Nov 2005 05:55:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhPbr-0006j3-JF for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 10:54:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhPbg-0006iK-Py for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 10:54:37 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EhPbd-0006Pm-8Z for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 10:54:35 +0000 Received: (qmail invoked by alias); 30 Nov 2005 10:54:13 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 30 Nov 2005 11:54:13 +0100 X-Authenticated: #1915285 Message-ID: <438D8498.4000609@gmx.de> Date: Wed, 30 Nov 2005 11:53:12 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Geoffrey M Clemm , WebDav , Cullen Jennings References: <4389D7FA.5070506@gmx.de> <1c7c19e8aad74fd022666b72ce6a39eb@osafoundation.org> <438C1E4B.5090002@gmx.de> <58CC0E40-16C8-4440-8BFC-3A8569F77198@apple.com> <438CB501.9070001@gmx.de> <04f55c87171bb6b6ec923fa355813e62@osafoundation.org> In-Reply-To: <04f55c87171bb6b6ec923fa355813e62@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhPbd-0006Pm-8Z 6cc4cee8bcfaeb17d939cc627d917c5c X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/438D8498.4000609@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10720 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 10:54:47 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > On Nov 29, 2005, at 12:07 PM, Julian Reschke wrote: > >> >> It seems that you have a very specific authoring scenario in mind, >> which you'd like to be simpler to support in a client. How about >> summarizing the *precise* requirements first, then think about the >> right technical approach, and only then discuss a way what to do in >> the spec? Yes, that's more work to do then simply stating "Strong >> ETags are now required", but it's the better approach nevertheless. >> >> > > First, before discussing the precise requirements I have in mind, I'd > like to remind you that the "Strong ETags" proposal didn't come from me > alone, I'm not the only one with requirements. After the 2002 interop > where this was first discussed, we had a bunch of list discussion about > this in late 2002, e.g. Dan Brotsky's email of Oct 16 and yours of Nov I guess it would be good if people would just re-read what was discussed back then (Dan: , myself replying: ). If there was consensus back then, it was for: 1) ETags are good. Strong ETags are better. Optimally, PUT returns a strong Etag. 2) Server support for ETags must be consistent (that is, DAV:getetag and ETag response header should agree) Re 1) I don't think there's any disagreement here. The question is how to achieve it. Putting SHOULD- or MUST-level requirements into the spec without understanding why servers may not be doing it already is IMHO the wrong approach. Re 2) Of course. If that needs clarification in the spec, let's do it. > 28. You were the one who pointed out that solving the problem we were > discussing required strong ETags, not weak ETags. What I pointed out was that the requirement you want to make makes Apache/mod_dav non-compliant, as it returns weak ETags upon PUT. > The requirements: > - Clients must be able to interoperate against different server > implementations with great consistency. That means that there should be > very few cases where clients need to determine what the server > implementation is or what features it supports, or how, before choosing > between alternative code paths. Yes. It's good when this is the case. On the other hand, it's also good when servers can support WebDAV for a wide range of resource types, not just filesystem-like stores. > - Clients must be able to be confident, when doing a PUT, that they are > not overwriting another client's change -- that means that there must be > some way to compare the state of the resource to the state when it was > last retrieved. ETags do that. If a server doesn't support ETags, the client always can refuse to update. On the other hand, as Wilfredo just pointed out, filesystems do not have ETags either, and people just live with that (last update wins). So yes, it's nice if you can avoid it, but it's unclear why it needs to be a WebDAV requirement. > - Specifically, this must work for images, HTML pages, office > documents, etc -- without requiring any different behavior on the part > of a client. It would be nice if the server didn't have to care what > kind of resource it had, as well. So are you now requiring that a WebDAV server can store any type of binary content? What if it's a WebDAV connector on top of an XML database? > - It must be possible to write a generic library or remote file system, > such as WebDAV FS, Xythos WFC or Adobe's library -- one which > communicates with the WebDAV server on behalf of an application such as > Word or Photoshop, without requiring overly heavy integration between > the application and the library. It's hard to judge what that actually means protocol-wise. > - Clients must be able to keep an offline store with content that's > fairly reliably consistent with what's on the server. (One problem to > solve here is for the client to know whether it needs to download a > resource after a PUT) As far as I can tell, the recent discussion on the HTTP mailing list shows that ETags do not help with that. > I generated these rather off-the-cuff, but I believe that's a good start > at least. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Nov 30 12:37:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVth-0005E5-AE for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 12:37:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15315 for ; Wed, 30 Nov 2005 12:36:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhVsW-0000wl-6x for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 17:36:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhVsP-0000vR-4o for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 17:36:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhVsO-00022g-EK for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 17:36:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUHa6Gx015852; Wed, 30 Nov 2005 09:36:06 -0800 Date: Wed, 30 Nov 2005 09:36:06 -0800 Message-Id: <200511301736.jAUHa6Gx015852@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/200511301736.jAUHa6Gx015852@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10721 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 17:36:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 ------- Additional Comments From lisa@osafoundation.org 2005-11-30 09:36 ------- Sure, I can add the word URI. ------- 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@frink.w3.org Wed Nov 30 12:46:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhW2R-00019B-Oc for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 12:46:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16506 for ; Wed, 30 Nov 2005 12:45:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhW1n-0006Su-5B for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 17:45:59 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhW1l-0006Rl-Cx for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 17:45:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhW1b-0008Je-Af for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 17:45:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUHjjcn015906; Wed, 30 Nov 2005 09:45:45 -0800 Date: Wed, 30 Nov 2005 09:45:45 -0800 Message-Id: <200511301745.jAUHjjcn015906@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhW1b-0008Je-Af 86fd5c1c33899fe517110a11334e048c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200511301745.jAUHjjcn015906@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10722 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 17:45:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From julian.reschke@greenbytes.de 2005-11-30 09:45 ------- Julian to suggest text to be added based on what whas in draft 07. ------- 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@frink.w3.org Wed Nov 30 12:56:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWCF-00004s-3a for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 12:56:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17912 for ; Wed, 30 Nov 2005 12:56:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhWBX-00030G-Io for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 17:56:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhWBU-0002z4-6s for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 17:56:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhWBT-0001EK-Mi for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 17:55:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUHtiuG015947; Wed, 30 Nov 2005 09:55:44 -0800 Date: Wed, 30 Nov 2005 09:55:44 -0800 Message-Id: <200511301755.jAUHtiuG015947@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] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200511301755.jAUHtiuG015947@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10723 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 17:56:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-30 09:55 ------- I goofed in my understanding of a related topic we'd come to consensus on -- I removed more than was necessary. I'll put this back in, and the language should be carefully reviewed in light of other recent changes, because I myself find this language confusing. ------- 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@frink.w3.org Wed Nov 30 13:08:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWO3-0005tE-7o for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 13:08:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20313 for ; Wed, 30 Nov 2005 13:08:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhWNE-0001EK-Ai for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 18:08:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhWNA-0001Cf-1y for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 18:08:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhWN9-0001ux-5B for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 18:08:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUI7xEu015992; Wed, 30 Nov 2005 10:07:59 -0800 Date: Wed, 30 Nov 2005 10:07:59 -0800 Message-Id: <200511301807.jAUI7xEu015992@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 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/200511301807.jAUI7xEu015992@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10724 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 18:08:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-30 10:07 ------- Teleconference consensus is to use the following text for Appendix C: C. The opaquelocktoken scheme and URIs The 'opaquelocktoken' URI scheme was defined in I RFC2518[RFC2518] (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time. A server MAY generate one ore more UUIDs to use with the 'opaquelocktoken' scheme as lock tokens. A server MAY reuse a UUID with extension characters added. If the server does this then the algorithm generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID. OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; UUID is defined in Section 3 of [RFC4122]. Note that linear white ; space (LWS) is not allowed between elements of this production. Extension = path ; path is defined in Section 3.3 of [RFC3986] ------- 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@frink.w3.org Wed Nov 30 13:12:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWRm-0000b0-A0 for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 13:12:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21122 for ; Wed, 30 Nov 2005 13:12:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhWRC-0002rm-KT for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 18:12:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhWRB-0002qz-1v for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 18:12:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhWQv-00062i-QZ for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 18:12:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUIBfPV016021; Wed, 30 Nov 2005 10:11:41 -0800 Date: Wed, 30 Nov 2005 10:11:41 -0800 Message-Id: <200511301811.jAUIBfPV016021@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhWQv-00062i-QZ 2ec93312f34cf1b322be5fce2bfb129b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200511301811.jAUIBfPV016021@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10725 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 18:12:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-30 10:11 ------- Teleconference consensus is this issue has been resolved. ------- 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@frink.w3.org Wed Nov 30 13:14:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWTJ-0001MZ-Tr for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 13:14:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21191 for ; Wed, 30 Nov 2005 13:13:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhWSi-00039d-FC for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 18:13:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhWSg-00038s-VR for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 18:13:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhWSg-0006Gf-C9 for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 18:13:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUIDbjD016043; Wed, 30 Nov 2005 10:13:37 -0800 Date: Wed, 30 Nov 2005 10:13:37 -0800 Message-Id: <200511301813.jAUIDbjD016043@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 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/200511301813.jAUIDbjD016043@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10726 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 18:13:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-30 10:13 ------- I've replaced the "obsoleted" verbiage with a simple reference to RFC4122. The 'opaquelocktoken' URI scheme was defined in RFC2518 (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time. Servers MAY use [RFC4122] instead. ------- 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@frink.w3.org Wed Nov 30 13:15:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWUj-00028u-Dh for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 13:15:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21251 for ; Wed, 30 Nov 2005 13:15:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhWUA-0005Sh-TM for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 18:15:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhWU8-0005H5-PD for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 18:15:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhWU4-00077B-Rt for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 18:15:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUIEkoH016073; Wed, 30 Nov 2005 10:14:46 -0800 Date: Wed, 30 Nov 2005 10:14:46 -0800 Message-Id: <200511301814.jAUIEkoH016073@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhWU4-00077B-Rt 84900205c23125868c7effd3677a980b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200511301814.jAUIEkoH016073@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10727 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 18:15:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 10:14 ------- *** Bug 173 has been marked as a duplicate of this bug. *** ------- 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@frink.w3.org Wed Nov 30 13:16:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWUt-0002DY-Dc for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 13:16:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21285 for ; Wed, 30 Nov 2005 13:15:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhWUL-0005i6-Vj for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 18:15:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhWUK-0005gO-3Q for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 18:15:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhWTh-0005li-55 for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 18:15:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUIEkiG016063; Wed, 30 Nov 2005 10:14:46 -0800 Date: Wed, 30 Nov 2005 10:14:46 -0800 Message-Id: <200511301814.jAUIEkiG016063@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhWTh-0005li-55 a757ff6d5421cf92b5d1aff61bbfdd51 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 173] Info about inside multistatus lost X-Archived-At: http://www.w3.org/mid/200511301814.jAUIEkiG016063@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10728 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 18:15:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=173 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 10:14 ------- *** This bug has been marked as a duplicate of 47 *** ------- 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@frink.w3.org Wed Nov 30 13:23:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWcP-00065y-0D for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 13:23:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22172 for ; Wed, 30 Nov 2005 13:23:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhWbh-0000En-Dx for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 18:23:05 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhWbf-0000Dc-Mf for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 18:23:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhWba-0001F9-IL for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 18:23:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUIMq95016110; Wed, 30 Nov 2005 10:22:52 -0800 Date: Wed, 30 Nov 2005 10:22:52 -0800 Message-Id: <200511301822.jAUIMq95016110@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhWba-0001F9-IL a231c0ee0f477e063f3c738851889f57 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 7] Example for PROPFIND/allprop missing X-Archived-At: http://www.w3.org/mid/200511301822.jAUIMq95016110@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10729 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 18:23:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=7 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-30 10:22 ------- Teleconference consensus is to re-insert the example, and modify it slightly to use the relative URL syntax within the href elements, so as to also demonstrate this protocol feature. ------- 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@frink.w3.org Wed Nov 30 13:24:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWdG-0006bA-GE for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 13:24:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22263 for ; Wed, 30 Nov 2005 13:23:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhWci-0000aQ-Pj for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 18:24:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhWch-0000Yd-6h for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 18:24:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhWcZ-0001oo-Nk for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 18:24:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUINjhX016132; Wed, 30 Nov 2005 10:23:45 -0800 Date: Wed, 30 Nov 2005 10:23:45 -0800 Message-Id: <200511301823.jAUINjhX016132@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhWcZ-0001oo-Nk 999b8ff84412aa54877ff0aef0ef31d7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 7] Example for PROPFIND/allprop missing X-Archived-At: http://www.w3.org/mid/200511301823.jAUINjhX016132@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10730 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 18:24:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=7 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Wed Nov 30 13:55:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhX7E-0002AO-Oi for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 13:55:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26363 for ; Wed, 30 Nov 2005 13:54:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhX6A-0004sZ-EX for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 18:54:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhX64-0004rQ-3s for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 18:54:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhX5z-0007Sh-67 for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 18:54:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUIsEQl016182; Wed, 30 Nov 2005 10:54:14 -0800 Date: Wed, 30 Nov 2005 10:54:14 -0800 Message-Id: <200511301854.jAUIsEQl016182@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EhX5z-0007Sh-67 740e0c9cbe4f74e7a635b754f13e105d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 51] Property behaviour upon COPY vs "remote COPY" X-Archived-At: http://www.w3.org/mid/200511301854.jAUIsEQl016182@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10731 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 18:54:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=51 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-30 10:54 ------- Two issues here. 1) Should 2518bis have information about cross-server COPY/MOVE behavior at all? The specification has been silent on this issue so far, as there are many issues with cross-server behavior. This should ideally be covered in a separate draft. 2) Should the specification have a section describing COPY/MOVE behavior for each live property at all? Pro: can potentially clarify property-specific semantics as they apply to each property. Con: can potentially lead to confusion, and possible ambiguity if there are conflicts between this text and more general statements in the rest of the speficiation. Julian agreed to look through the current specification's COPY/MOVE behavior subsections within Section 14, and will determine if they are (a) correct, and (b) conflict with other places in the specification. There was agreement that discussion of cross-server COPY/MOVE should be removed from the specification. ------- 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@frink.w3.org Wed Nov 30 14:02:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXEH-0006Jb-4O for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:02:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27408 for ; Wed, 30 Nov 2005 14:02:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXDe-0002Dl-GH for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:02:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhXDX-0002CD-Nh for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:02:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhXDU-0002Ql-0m for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:02:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJ22PR016221; Wed, 30 Nov 2005 11:02:02 -0800 Date: Wed, 30 Nov 2005 11:02:02 -0800 Message-Id: <200511301902.jAUJ22PR016221@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EhXDU-0002Ql-0m 97da12365137b8022d57aca1b988c46e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200511301902.jAUJ22PR016221@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10732 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:02:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 ------- Additional Comments From lisa@osafoundation.org 2005-11-30 11:02 ------- I agree that the first MUST is too stringent, so I'll make some changes to this in the next version of the draft, but since we didn't come to consensus in the call it's not certain that these changes will resolve the issues. ------- 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@frink.w3.org Wed Nov 30 14:12:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXNk-0002GY-Jc for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:12:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28614 for ; Wed, 30 Nov 2005 14:11:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXMz-000688-R8 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:11:57 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhXMw-00066v-GC for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:11:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhXMd-0006je-Ie for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:11:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJBWxT016254; Wed, 30 Nov 2005 11:11:32 -0800 Date: Wed, 30 Nov 2005 11:11:32 -0800 Message-Id: <200511301911.jAUJBWxT016254@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhXMd-0006je-Ie 9259e82da965e1b58b4c6b5b7d161f5b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200511301911.jAUJBWxT016254@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10733 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:11:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- 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@frink.w3.org Wed Nov 30 14:17:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXSC-0003h6-UY for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:17:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29271 for ; Wed, 30 Nov 2005 14:16:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXRc-0000gi-PF for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:16:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhXRY-0000fG-GL for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:16:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhXOP-0001gQ-Ng for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:16:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJD0rk016275; Wed, 30 Nov 2005 11:13:00 -0800 Date: Wed, 30 Nov 2005 11:13:00 -0800 Message-Id: <200511301913.jAUJD0rk016275@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhXOP-0001gQ-Ng 2e597471f19dbeb37eb2677aca6f3e7a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200511301913.jAUJD0rk016275@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10734 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:16:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 11:13 ------- Consensus on 11/30 telecon was that: * the current MUST language seems too strong * use cases exist which indicate that it is desireable for per property behaviour to be defined * we need to actively solicit input from client and server implementers via the mailing list and otherwise Lisa will propose text to address the first two points above. ------- 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@frink.w3.org Wed Nov 30 14:20:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXVT-0006Zp-ON for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:20:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29595 for ; Wed, 30 Nov 2005 14:19:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXUp-0001pf-D2 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:20:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhXU1-00013R-Pn for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:19:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhXRv-0004NG-IB for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:17:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJGmM5016299; Wed, 30 Nov 2005 11:16:48 -0800 Date: Wed, 30 Nov 2005 11:16:48 -0800 Message-Id: <200511301916.jAUJGmM5016299@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 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200511301916.jAUJGmM5016299@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10735 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:20:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From ejw@cs.ucsc.edu 2005-11-30 11:16 ------- We agreed in the teleconference to have Julian take a look at how property definitions/semantics might change in the face of multiple BINDings (also replacement of a binding as well, as in a MOVE to an existing mapped URL) . We suspect that getlastmodified and getetag are definitely affected by this issue, but others might be as well. It's hard to get the semantics right during a teleconference, since thinking about bindings and their implications is tricky. ------- 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@frink.w3.org Wed Nov 30 14:21:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXWP-00073P-6x for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:21:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29677 for ; Wed, 30 Nov 2005 14:20:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXVq-0002Qa-K4 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:21:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhXVp-0002Pj-2c for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:21:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhXUp-0003mC-HH for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:21:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJJZHO016320; Wed, 30 Nov 2005 11:19:35 -0800 Date: Wed, 30 Nov 2005 11:19:35 -0800 Message-Id: <200511301919.jAUJJZHO016320@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhXUp-0003mC-HH fa16784c159b4520b08c5cc3e8b4c065 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200511301919.jAUJJZHO016320@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10736 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:21:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Wed Nov 30 14:29:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXe2-0001LB-TO for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:29:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00660 for ; Wed, 30 Nov 2005 14:28:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXdH-0004nE-NG for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:28:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhXdG-0004mg-8W for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:28:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhXdF-0004nk-Gu for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:28:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJSgIB016360; Wed, 30 Nov 2005 11:28:42 -0800 Date: Wed, 30 Nov 2005 11:28:42 -0800 Message-Id: <200511301928.jAUJSgIB016360@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 93] Write Locks and Collections vs MOVE X-Archived-At: http://www.w3.org/mid/200511301928.jAUJSgIB016360@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10737 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:28:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=93 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From lisa@osafoundation.org 2005-11-30 11:28 ------- We agreed that the BIND model, where the resource that a collection's member URL points to is part of the collection's state, is a reasonable model from which to derive this list. That implies that even when MOVE/COPY overwrites a pre-existing member, the lock token of the locked parent collection is still required. This has the side benefits of: - consistent with existing implementations (greenbytes) which do require lock in these two cases - simpler handling where server always requires the lock token if the destination parent is locked ------- 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@frink.w3.org Wed Nov 30 14:30:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXeo-0001o4-Kh for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:30:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00921 for ; Wed, 30 Nov 2005 14:29:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXeG-0005Cf-Jw for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:29:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhXeF-0005C1-1u for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:29:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhXeB-00075X-BQ for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:29:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJTNtX016378; Wed, 30 Nov 2005 11:29:23 -0800 Date: Wed, 30 Nov 2005 11:29:23 -0800 Message-Id: <200511301929.jAUJTNtX016378@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhXeB-00075X-BQ 2d788602da68a0d3703e75e7b47a6605 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 93] Write Locks and Collections vs MOVE X-Archived-At: http://www.w3.org/mid/200511301929.jAUJTNtX016378@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10738 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:29:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=93 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-30 11:29 ------- Will be fixed in -09. ------- 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@frink.w3.org Wed Nov 30 14:45:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXte-0001nV-SR for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:45:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03246 for ; Wed, 30 Nov 2005 14:44:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXss-00038j-L3 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:44:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhXso-00036B-87 for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:44:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhXre-0004Ja-Oo for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:44:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJhai3016423; Wed, 30 Nov 2005 11:43:36 -0800 Date: Wed, 30 Nov 2005 11:43:36 -0800 Message-Id: <200511301943.jAUJhai3016423@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhXre-0004Ja-Oo 05e540bea39bedca36887aba4cdd8b6d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 94] COPY and the Overwrite Header vs X-Archived-At: http://www.w3.org/mid/200511301943.jAUJhai3016423@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10739 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:44:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=94 ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 11:43 ------- Agreement on 11/30 telecon that the existing language needs work -- IIS is suspected of implementing merge behavior, and Delta-V may rely upon the same. Julian will do some research on the issue, while Lisa will make an interim 'straw-man' proposal for new text. To be revisited... Jim notes that deprecating this feature may not have large repercussions. ------- 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@frink.w3.org Wed Nov 30 14:45:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXtr-0001xG-8z for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 14:45:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03263 for ; Wed, 30 Nov 2005 14:45:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhXtG-00050r-Vi for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 19:45:19 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhXtE-0004tF-05 for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 19:45:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhXsI-0004eO-0B for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 19:45:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUJiDmt016441; Wed, 30 Nov 2005 11:44:13 -0800 Date: Wed, 30 Nov 2005 11:44:13 -0800 Message-Id: <200511301944.jAUJiDmt016441@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhXsI-0004eO-0B a672a98f93ba11bd38d10ab81793dd58 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 94] COPY and the Overwrite Header vs X-Archived-At: http://www.w3.org/mid/200511301944.jAUJiDmt016441@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10740 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 19:45:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=94 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Wed Nov 30 15:03:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYB6-0004PW-9E for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:03:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05411 for ; Wed, 30 Nov 2005 15:02:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYA7-0005vq-H1 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:02:43 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhYA1-0005u8-75 for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:02:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhY9m-0004NY-IA for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:02:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUK2M1u016496; Wed, 30 Nov 2005 12:02:22 -0800 Date: Wed, 30 Nov 2005 12:02:22 -0800 Message-Id: <200511302002.jAUK2M1u016496@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhY9m-0004NY-IA 595d00f841e410b61f2ecc5ceac98464 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200511302002.jAUK2M1u016496@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10741 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:02:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 12:02 ------- 11/30 telecon reached deadlock wrt the specific form of the text (references vs. repeated text and readability of the same) -- Julian to propose text which explicitly defines the three extensibility classes for XML elements as part of the introduction to the section. Whether to refer to these classes within the definition of each element is tbd. ------- 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@frink.w3.org Wed Nov 30 15:13:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYKl-000801-E6 for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:13:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07075 for ; Wed, 30 Nov 2005 15:12:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYK6-0001Bf-Sw for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:13:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhYK5-0001AX-7b for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:13:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhYK1-0004yI-TB for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:13:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKBsKJ016519; Wed, 30 Nov 2005 12:11:54 -0800 Date: Wed, 30 Nov 2005 12:11:54 -0800 Message-Id: <200511302011.jAUKBsKJ016519@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhYK1-0004yI-TB 694c5a0c98d44159b406785a741bf483 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200511302011.jAUKBsKJ016519@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10742 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:13:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- 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@frink.w3.org Wed Nov 30 15:26:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYXM-0006r8-2E for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:26:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08988 for ; Wed, 30 Nov 2005 15:25:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYWf-0007qY-KO for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:26:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhYWc-0007po-Tj for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:25:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhYWc-0008Jp-Ed for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:25:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKPupg016580; Wed, 30 Nov 2005 12:25:56 -0800 Date: Wed, 30 Nov 2005 12:25:56 -0800 Message-Id: <200511302025.jAUKPupg016580@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 95] possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200511302025.jAUKPupg016580@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10743 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:26:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- 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@frink.w3.org Wed Nov 30 15:46:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYqR-0007p3-Eu for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:46:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10885 for ; Wed, 30 Nov 2005 15:45:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYpn-0007zv-4p for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:45:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhYkd-0004Yy-V1 for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:40:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhYV5-0000js-58 for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:24:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKNuHk016558; Wed, 30 Nov 2005 12:23:56 -0800 Date: Wed, 30 Nov 2005 12:23:56 -0800 Message-Id: <200511302023.jAUKNuHk016558@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhYV5-0000js-58 64839774f15dd5b58777e86679e81d60 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 95] possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200511302023.jAUKNuHk016558@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10745 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:45:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 12:23 ------- Julian to write test cases to determine what is actually implemented currently -- do servers return 424 within a multistatus (207) when child resources are already locked? ------- 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@frink.w3.org Wed Nov 30 15:46:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYqR-0007p4-GS for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:46:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10884 for ; Wed, 30 Nov 2005 15:45:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYpY-0007xi-5G for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:45:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhYpR-0007pC-UN for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:45:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhYpR-00073y-Jp for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:45:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKjIlZ016621; Wed, 30 Nov 2005 12:45:18 -0800 Date: Wed, 30 Nov 2005 12:45:18 -0800 Message-Id: <200511302045.jAUKjIlZ016621@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 171] If header grammar X-Archived-At: http://www.w3.org/mid/200511302045.jAUKjIlZ016621@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10744 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:45:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 12:45 ------- Additional testing has shown that breaking long header lines into multiple lines does not correctly address the issue -- existing servers limit the length of all headers combined (perhaps as protection against DOS attacks), although this is configurable in both Apache and IIS. New grammer merely clarifies the grammer of 2518, without reflecting change in the associated prose (section 9.5). Need to find out if the fix stated in the prose is really a fix (for the issue outlined by Joel Soderberg), in which case we need to modify the production grammer, or if the change to the prose should be backed out. Consensus reached in 11/30 telecon to: * remove the newly introduced text * leave the current expression of the BNF (which will be consistent after the above change) ------- 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@frink.w3.org Wed Nov 30 15:50:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYuE-0001OQ-4E for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:50:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11444 for ; Wed, 30 Nov 2005 15:49:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYte-0000eL-JL for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:49:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhYtb-0000bg-OX for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:49:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhYtY-0000jg-6o for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:49:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKmrnD016643; Wed, 30 Nov 2005 12:48:53 -0800 Date: Wed, 30 Nov 2005 12:48:53 -0800 Message-Id: <200511302048.jAUKmrnD016643@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhYtY-0000jg-6o 1d80d0891a6e2e04053ba9c9c0511653 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/200511302048.jAUKmrnD016643@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10746 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:49:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 12:48 ------- Consensus of 11/30 telecon if for WG to review Julians proposal before next telecon. ------- 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@frink.w3.org Wed Nov 30 15:50:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYuW-0001bI-SA for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:50:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11474 for ; Wed, 30 Nov 2005 15:49:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYty-0001QV-NU for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:50:06 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhYtx-0001PV-1X for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:50:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhYtl-0008HJ-6F for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:50:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKno3g016662; Wed, 30 Nov 2005 12:49:50 -0800 Date: Wed, 30 Nov 2005 12:49:50 -0800 Message-Id: <200511302049.jAUKno3g016662@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhYtl-0008HJ-6F abe0ce76a34ff0249d1bdc1e638b024e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 174] Terminology in 4.4: "namespace name in scope" X-Archived-At: http://www.w3.org/mid/200511302049.jAUKno3g016662@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10747 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:50:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=174 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |10 ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 12:49 ------- Perhaps resolved by Julians proposed resolution to issue 10. ------- 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@frink.w3.org Wed Nov 30 15:50:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYub-0001d5-C4 for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:50:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11504 for ; Wed, 30 Nov 2005 15:49:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYu3-0001WL-V4 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:50:11 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhYu2-0001Tc-2y for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:50:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhYtl-0008Ho-67 for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:50:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKnpMm016676; Wed, 30 Nov 2005 12:49:51 -0800 Date: Wed, 30 Nov 2005 12:49:51 -0800 Message-Id: <200511302049.jAUKnpMm016676@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhYtl-0008Ho-67 e54a2f70f2905e41db60ef6152f2cd80 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/200511302049.jAUKnpMm016676@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10748 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:50:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |174 nThis| | ------- 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@frink.w3.org Wed Nov 30 15:51:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYvL-0002BN-O8 for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:51:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11666 for ; Wed, 30 Nov 2005 15:50:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYuj-0001pt-T9 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:50:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhYui-0001p4-DQ for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:50:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhYuh-00037A-Ud for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:50:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKopMq016702; Wed, 30 Nov 2005 12:50:51 -0800 Date: Wed, 30 Nov 2005 12:50:51 -0800 Message-Id: <200511302050.jAUKopMq016702@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 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/200511302050.jAUKopMq016702@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10749 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:50:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |186 nThis| | ------- 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@frink.w3.org Wed Nov 30 15:51:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYvM-0002Bb-1l for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:51:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11665 for ; Wed, 30 Nov 2005 15:50:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYum-0001rb-CB for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:50:56 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhYuk-0001qM-JK for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:50:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhYug-0000Dh-Lk for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:50:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKooWg016692; Wed, 30 Nov 2005 12:50:50 -0800 Date: Wed, 30 Nov 2005 12:50:50 -0800 Message-Id: <200511302050.jAUKooWg016692@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhYug-0000Dh-Lk 3c80f855424602911953819a684e0e7e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 186] opaquelocktoken appendix X-Archived-At: http://www.w3.org/mid/200511302050.jAUKooWg016692@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10750 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:50:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=186 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |172 Bug 186 depends on bug 172, which changed state. Bug 172 Summary: Whether to obsolete 'opaquelocktoken', keep it, or remove it http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 What |Old Value |New Value ---------------------------------------------------------------------------- Status|REOPENED |NEW Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 12:50 ------- addressed by resolution to 172? ------- 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@frink.w3.org Wed Nov 30 15:53:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYwv-0002sg-Fl for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:53:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12422 for ; Wed, 30 Nov 2005 15:52:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhYwN-0002MV-04 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 20:52:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhYwL-0002Lh-E1 for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 20:52:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhYwD-0001nP-6J for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 20:52:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUKq8JC016722; Wed, 30 Nov 2005 12:52:08 -0800 Date: Wed, 30 Nov 2005 12:52:08 -0800 Message-Id: <200511302052.jAUKq8JC016722@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhYwD-0001nP-6J dcab9e397b6e51618737c392994a384e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/200511302052.jAUKq8JC016722@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10751 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 20:52:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-11-30 12:52 ------- assigned ------- 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@frink.w3.org Wed Nov 30 17:10:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eha9m-0003Jr-Vd for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:10:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06399 for ; Wed, 30 Nov 2005 17:09:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eha8X-0007Ll-GD for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:09:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eha8P-0007JV-5W for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:09:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eha8L-00055y-1D for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:09:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUM8wc6016821; Wed, 30 Nov 2005 14:08:58 -0800 Date: Wed, 30 Nov 2005 14:08:58 -0800 Message-Id: <200511302208.jAUM8wc6016821@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Eha8L-00055y-1D dedb212d2d76176505338502a6e148dd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 7] Example for PROPFIND/allprop missing X-Archived-At: http://www.w3.org/mid/200511302208.jAUM8wc6016821@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10752 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:09:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=7 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Wed Nov 30 17:11:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhaAg-0003ao-W1 for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:11:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06519 for ; Wed, 30 Nov 2005 17:10:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhaA8-0008J0-3y for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:10:52 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhaA6-0008IG-6R for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:10:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhaA2-0002xw-WE for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:10:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMAEY5016849; Wed, 30 Nov 2005 14:10:14 -0800 Date: Wed, 30 Nov 2005 14:10:14 -0800 Message-Id: <200511302210.jAUMAEY5016849@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhaA2-0002xw-WE e27f4c1481c6a42d8718d8e8519a0672 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/200511302210.jAUMAEY5016849@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10753 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:10:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Wed Nov 30 17:11:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhaB0-0003lv-GY for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:11:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06557 for ; Wed, 30 Nov 2005 17:11:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhaAQ-0008RD-Ek for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:11:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhaAO-0008QK-RV for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:11:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhaA7-00030A-JA for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:11:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMAJit016863; Wed, 30 Nov 2005 14:10:19 -0800 Date: Wed, 30 Nov 2005 14:10:19 -0800 Message-Id: <200511302210.jAUMAJit016863@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhaA7-00030A-JA 7d6f2cbf72c0c21d62c70391cb08b544 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200511302210.jAUMAJit016863@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10754 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:11:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 Bug 200 depends on bug 171, which changed state. Bug 171 Summary: If header grammar http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Wed Nov 30 17:18:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhaH8-0008CT-Kd for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:18:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07267 for ; Wed, 30 Nov 2005 17:17:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhaGV-0003nG-Rk for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:17:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhaGU-0003mZ-BP for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:17:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EhaGR-0000Mt-6U for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:17:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMHJFP016888; Wed, 30 Nov 2005 14:17:19 -0800 Date: Wed, 30 Nov 2005 14:17:19 -0800 Message-Id: <200511302217.jAUMHJFP016888@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-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EhaGR-0000Mt-6U 608e6c12f0c065d34ff8f923b52a749d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200511302217.jAUMHJFP016888@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10755 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:17:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-11-30 14:17 ------- Note that the change in ABNF syntax also makes ordering now unimportant, whereas before, ordering was unimportant. That is, DAV: 2, 1 was not legal with the original syntax but legal with the ABNF syntax in draft -08. ------- 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@frink.w3.org Wed Nov 30 17:21:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhaJz-00008Y-MA for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:21:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07610 for ; Wed, 30 Nov 2005 17:20:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhaJP-0004um-HL for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:20:27 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhaJL-0004tx-9C for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:20:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhaIy-0003xB-Lc for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:20:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMJwQl016907; Wed, 30 Nov 2005 14:19:58 -0800 Date: Wed, 30 Nov 2005 14:19:58 -0800 Message-Id: <200511302219.jAUMJwQl016907@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhaIy-0003xB-Lc 6a683bb635333035033a111c3b785364 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200511302219.jAUMJwQl016907@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10756 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:20:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-11-30 14:19 ------- Assuming that the ordering change is OK, this will be fixed in the next draft. ------- 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@frink.w3.org Wed Nov 30 17:45:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhahJ-0005BM-CP for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:45:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10228 for ; Wed, 30 Nov 2005 17:42:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhaeP-0003bk-Kk for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:42:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhaeJ-0003Zn-RO for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:42:04 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EhaeG-0005FJ-Nj for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:42:03 +0000 Received: (qmail invoked by alias); 30 Nov 2005 22:41:57 -0000 Received: from p508FB8DF.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.223] by mail.gmx.net (mp021) with SMTP; 30 Nov 2005 23:41:57 +0100 X-Authenticated: #1915285 Message-ID: <438E2A77.5060900@gmx.de> Date: Wed, 30 Nov 2005 23:40:55 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDAV Content-Type: multipart/mixed; boundary="------------000208040900080005030002" X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhaeG-0005FJ-Nj ab9573f7040207eb42d2dc55b94fc76e X-Original-To: w3c-dist-auth@w3.org Subject: [Fwd: I-D ACTION:draft-reschke-webdav-mount-03.txt] X-Archived-At: http://www.w3.org/mid/438E2A77.5060900@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10757 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:42:09 +0000 This is a multi-part message in MIME format. --------------000208040900080005030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi. This is an update to draft-reschke-webdav-mount-02, based on early feedback from the RFC Editor's review. Changes are only editorial (nothing normative changed), with the biggest change being made to the mount example (). Best regards, Julian -------- Original Message -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mounting WebDAV (Web Distributed Authoring and Versioning) servers Author(s) : J. Reschke Filename : draft-reschke-webdav-mount-03.txt Pages : 17 Date : 2005-11-30 In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of a WebDAV server. For example, it is frequently desirable to be able to click on a link, and have this link open a window that can handle drag and drop interaction with the resources of a WebDAV server. This document specifies a mechanism and a document format that enables Web Distributed Authoring and Versioning (WebDAV) servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reschke-webdav-mount-03.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-reschke-webdav-mount-03.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-reschke-webdav-mount-03.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. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 --------------000208040900080005030002 Content-Type: Message/External-body; name="draft-reschke-webdav-mount-03.txt" Content-Disposition: inline; filename="draft-reschke-webdav-mount-03.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-11-30135053.I-D@ietf.org> --------------000208040900080005030002 Content-Type: text/plain; name="file:///C|/DOKUME%7E1/JR/LOKALE%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOKUME%7E1/JR/LOKALE%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------000208040900080005030002-- From w3c-dist-auth-request@frink.w3.org Wed Nov 30 17:46:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhaiC-0005II-0b for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:46:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10821 for ; Wed, 30 Nov 2005 17:45:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ehahd-0006Bw-9s for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:45:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ehahb-00062g-FN for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:45:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhahY-0004rZ-3p for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:45:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMjNKE017131; Wed, 30 Nov 2005 14:45:23 -0800 Date: Wed, 30 Nov 2005 14:45:23 -0800 Message-Id: <200511302245.jAUMjNKE017131@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhahY-0004rZ-3p 9f026cf1d2a8e39d88f596726f6f3f07 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200511302245.jAUMjNKE017131@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10759 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:45:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX ------- Additional Comments From lisa@osafoundation.org 2005-11-30 14:45 ------- I don't see anything wrong with the spec. Certainly servers must use any other valid *URI*, because to use another *URI scheme* alone might make an incomplete URI and thus an invalid lock token. I don't recall agreeing to make these changes in the con call, perhaps this bug was edited by mistake? ------- 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@frink.w3.org Wed Nov 30 17:46:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehaj1-0005Lu-0N for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:46:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10835 for ; Wed, 30 Nov 2005 17:46:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhaiS-0006Uq-H9 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:46:20 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhaiP-0006UE-VK for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:46:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhaiH-00054U-SV for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:46:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMk9Z3017154; Wed, 30 Nov 2005 14:46:09 -0800 Date: Wed, 30 Nov 2005 14:46:09 -0800 Message-Id: <200511302246.jAUMk9Z3017154@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhaiH-00054U-SV e8f57a55ec5b2b07165445b605cc2fb7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200511302246.jAUMk9Z3017154@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10760 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:46:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Wed Nov 30 17:47:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehak2-0005bk-Pt for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:47:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10868 for ; Wed, 30 Nov 2005 17:47:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhajS-0006fD-5T for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:47:22 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EhajQ-0006ec-IC for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:47:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EhajN-0006ta-Fz for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:47:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMlEcP017284; Wed, 30 Nov 2005 14:47:14 -0800 Date: Wed, 30 Nov 2005 14:47:14 -0800 Message-Id: <200511302247.jAUMlEcP017284@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EhajN-0006ta-Fz 8b556c6efc79a4ac0e706f80e5525c40 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200511302247.jAUMlEcP017284@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10761 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:47:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|lisa@osafoundation.org |elias@cse.ucsc.edu ------- Additional Comments From lisa@osafoundation.org 2005-11-30 14:47 ------- I've dealt with the first two; assigning to Elias for the list follow-up (apologies if you're not actually the one following up) ------- 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@frink.w3.org Wed Nov 30 17:48:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhakX-0005ki-Bg for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:48:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10927 for ; Wed, 30 Nov 2005 17:47:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ehajx-0006v5-SJ for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:47:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ehajw-0006tx-4f for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:47:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ehajt-00073w-8O for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:47:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMljfk017302; Wed, 30 Nov 2005 14:47:45 -0800 Date: Wed, 30 Nov 2005 14:47:45 -0800 Message-Id: <200511302247.jAUMljfk017302@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ehajt-00073w-8O 1698a0030141b266d7a3cc85a85dc7e2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 40] Definition of "null resource" gone X-Archived-At: http://www.w3.org/mid/200511302247.jAUMljfk017302@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10762 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:47:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=40 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Wed Nov 30 17:48:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehakr-0005li-Kr for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 17:48:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10970 for ; Wed, 30 Nov 2005 17:48:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhakI-000764-20 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:48:14 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhakG-00074i-9v for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:48:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ehak2-0005lW-7d for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:48:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMluGF017320; Wed, 30 Nov 2005 14:47:56 -0800 Date: Wed, 30 Nov 2005 14:47:56 -0800 Message-Id: <200511302247.jAUMluGF017320@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ehak2-0005lW-7d ffad35a00cbec844a446e9cfb711707e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 41] Paragraph numbering/nesting broken in Section 13 X-Archived-At: http://www.w3.org/mid/200511302247.jAUMluGF017320@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10763 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:48:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- 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@frink.w3.org Wed Nov 30 18:14:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehb9H-0005Rz-JC for webdav-archive@megatron.ietf.org; Wed, 30 Nov 2005 18:14:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13705 for ; Wed, 30 Nov 2005 18:13:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhafP-0003ub-U5 for w3c-dist-auth-dist@listhub.w3.org; Wed, 30 Nov 2005 22:43:11 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhafN-0003ty-Vc for w3c-dist-auth@listhub.w3.org; Wed, 30 Nov 2005 22:43:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ehaee-0003kd-8Y for w3c-dist-auth@w3.org; Wed, 30 Nov 2005 22:43:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jAUMgNWH017058; Wed, 30 Nov 2005 14:42:23 -0800 Date: Wed, 30 Nov 2005 14:42:23 -0800 Message-Id: <200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ehaee-0003kd-8Y 1abc6767ceed919fa3d22fb4995f9aaf 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/200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10758 X-Loop: w3c-dist-auth@w3.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, 30 Nov 2005 22:43:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|lisa@osafoundation.org |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- Additional Comments From lisa@osafoundation.org 2005-11-30 14:42 ------- I didn't understand the part about removing the section on 503 -- what's wrong with it? The part about XML entities I've fixed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.