From w3c-dist-auth-request@frink.w3.org Sat Oct 01 07: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 1ELfdl-0006Lh-4Q for webdav-archive@megatron.ietf.org; Sat, 01 Oct 2005 07:34:53 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27244 for ; Sat, 1 Oct 2005 07:34:49 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ELfbJ-00070F-Jq for w3c-dist-auth-dist@listhub.w3.org; Sat, 01 Oct 2005 11:32:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ELfbJ-0006za-5u for w3c-dist-auth@listhub.w3.org; Sat, 01 Oct 2005 11:32:21 +0000 Received: from natnoddy.rzone.de ([81.169.145.166]) by lisa.w3.org with esmtp (Exim 4.50) id 1ELfbB-0007J3-TQ for w3c-dist-auth@w3.org; Sat, 01 Oct 2005 11:32:18 +0000 Received: from x.oberon.ethz.ch (Kb74a.k.pppool.de [85.75.183.74]) by post.webmailer.de (8.13.1/8.13.1) with SMTP id j91BW9re005867; Sat, 1 Oct 2005 13:32:10 +0200 (MEST) Date: Sat, 1 Oct 2005 13:32:09 +0200 (MEST) Message-Id: <200510011132.j91BW9re005867@post.webmailer.de> From: edgar@edgarschwarz.de X-Mailer: Oberon Mail (ejz) on Aos 16.09.05 X-Content-Type: application/compressed/oberon Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit To: w3c-dist-auth@w3.org Cc: edgar@edgarschwarz.de Received-SPF: none (lisa.w3.org: domain of edgar@edgarschwarz.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Scan-Sig: lisa.w3.org 1ELfbB-0007J3-TQ 973fd29036e77c8aba904dc6ad1563df X-Original-To: w3c-dist-auth@w3.org Subject: Re (2): last calling WebDAV mounting spec X-Archived-At: http://www.w3.org/mid/200510011132.j91BW9re005867@post.webmailer.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9849 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 01 Oct 2005 11:32:21 +0000 Content-Transfer-Encoding: 8bit Hi, after havin a look at the spec here my naive thoughts. If I'm overlooking something just flame me :-) As I understand it the idea is to tell a webbrowser that an URL it got is WebDAV or even DeltaV capable. But this is just meta information. Do why not something simple like: GET /documents/user42/inbox HTTP/1.1 Host: www.example.com Response: HTTP/1.1 200 OK Content-Type: what/ever; dav/deltav Content-Length: xxx The normal document for the browser .... .... I hope you get the idea to give a hint in the header. If what I'm proposing above would confuse a plain vanilla browser perhaps there is another way. This would tell the browser that it makes sense to open this URL with a WebDAV client. Because I think that much of the information in the dm: is redundant. Chees, Edgar --- start of oberon mail --- :O@h=:<]T]\Q5TYM^PT^_5Td]\\U]P<\Pl^UE\RE^_ m^c]\b5Td5]QU^P<\^5TEEZ<5TYU>?kKY;8CkLKhE;[H9J@]:8O[L1II]KIM;89JII;M3[E1iH3; L3[HIKIMI35JMY;8Ycd>G@Vfi2BeF7ffbBg`2bdjFcnFiff`BgdnFgjB@Bdg2bkRfl2BgnFj2bin ff0L^Y]]`U]U5T\=][]\j\Q=lX5UZPlUTm]S]^]]\^U^cmUeM^UE^dDV_<]^E\_5?19BY:EQj;SY ;SI3AjKW;Me98_kM_[;;;N3KKQ;Kjbanfff`6:eb>GhnFg>gbZc6RDZBEXPPDV`4VPlY;]Q3m]^U ^Ue]d]UD=_`]\j4Tg5]QU^_\\f]\bMWPT\Qe^_T\UU]dYMKh@O[KP<]\^m\d5]j4Th5_h]Q=TZX] \Pd]_E^]9K19IOkH[32BcnFi2BjRfbD\bm]g1MY;MY;KX;MY;Ma6VD@Rfg2gb2blnfj2bcFFj22; cdPdm]Pl\Ye^U5TQ5TX=]^U^P<]^5Td5=Rfb6FbFFijb6VDcl^XA@VdCfV`E^_5^_M^Ye]WIH5kK ]KI1iMOKMI;I1iHO[K=KMWKI1IH19LIKHC[K1YM3[KC;KIKH1YHU38L;[LAKHQkLK8MAKIUSYM>3 [KO;MAKIU;8_KHc[;K8EAKJWcknfj@jFFf8MASR18M66CS]=\[]\c5Tc]\^M^U5Tdm=O;L;[K19M V6[ZDIbkVFjRF@6f6Neb:6L\\=]Ue]deU=DXUM\Q]^c]\PFd2bgJF@B GdFVYe=@j@@VFg22T\]EWP<]c5Tb]\T]^^U\Qe]de51I37:J;KIW;;1IA9kI3[Lg^@CJAUj[7P8O 06PmM02@0b2180X2ZPoooDP14Pooo3eYQ]]UY0U[I7[;7;J3[K?KIMII9KJY[;cQ18E;;NYkA3;I ?KIYkLMYC;kM7jKM;MUkKIS020$ From w3c-dist-auth-request@frink.w3.org Sat Oct 01 08:08:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELgAg-00058n-0b for webdav-archive@megatron.ietf.org; Sat, 01 Oct 2005 08:08:54 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28832 for ; Sat, 1 Oct 2005 08:08:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ELg9g-0004TT-U3 for w3c-dist-auth-dist@listhub.w3.org; Sat, 01 Oct 2005 12:07:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ELg9g-0004Sv-GP for w3c-dist-auth@listhub.w3.org; Sat, 01 Oct 2005 12:07:52 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ELg9d-0000lK-Ar for w3c-dist-auth@w3.org; Sat, 01 Oct 2005 12:07:52 +0000 Received: (qmail invoked by alias); 01 Oct 2005 12:07:46 -0000 Received: from p508F87AC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.135.172] by mail.gmx.net (mp028) with SMTP; 01 Oct 2005 14:07:46 +0200 X-Authenticated: #1915285 Message-ID: <433E7C0F.80102@gmx.de> Date: Sat, 01 Oct 2005 14:07:43 +0200 From: Julian Reschke User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: edgar@edgarschwarz.de CC: w3c-dist-auth@w3.org References: <200510011132.j91BW9re005867@post.webmailer.de> In-Reply-To: <200510011132.j91BW9re005867@post.webmailer.de> 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 1ELg9d-0000lK-Ar 750761b7b1f797a41f8dc9570c712dae X-Original-To: w3c-dist-auth@w3.org Subject: Re: Re (2): last calling WebDAV mounting spec X-Archived-At: http://www.w3.org/mid/433E7C0F.80102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9850 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 01 Oct 2005 12:07:52 +0000 Content-Transfer-Encoding: 7bit edgar@edgarschwarz.de wrote: > Hi, > after havin a look at the spec here my naive thoughts. > If I'm overlooking something just flame me :-) > As I understand it the idea is to tell a webbrowser that an URL it got is > WebDAV or even DeltaV capable. Not just that. For instance, you may also want to initiate an "mount" request for a different URL. For instance, many document management systems use separate URL namespaces for HTML-based navigation, and HTTP/WebDAV access. Thus one level of indirection is needed anyway. > But this is just meta information. Do why not something simple like: > > GET /documents/user42/inbox HTTP/1.1 > Host: www.example.com > > Response: > HTTP/1.1 200 OK > Content-Type: what/ever; dav/deltav > Content-Length: xxx > > The normal document for the browser .... > .... > > I hope you get the idea to give a hint in the header. > If what I'm proposing above would confuse a plain vanilla browser perhaps > there is another way. Independant of the question whether it confuses browsers, how will it have any effect in existing browsers? > This would tell the browser that it makes sense to open this URL with a > WebDAV client. > Because I think that much of the information in the dm: is redundant. Such as? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 01 15:42:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELnG1-0008MA-At for webdav-archive@megatron.ietf.org; Sat, 01 Oct 2005 15:42:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16455 for ; Sat, 1 Oct 2005 15:42:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ELnEX-0008My-2n for w3c-dist-auth-dist@listhub.w3.org; Sat, 01 Oct 2005 19:41:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ELnEW-0008MQ-AT for w3c-dist-auth@listhub.w3.org; Sat, 01 Oct 2005 19:41:20 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ELnER-0002n3-37 for w3c-dist-auth@w3.org; Sat, 01 Oct 2005 19:41:19 +0000 Received: (qmail invoked by alias); 01 Oct 2005 19:41:12 -0000 Received: from p508F87AC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.135.172] by mail.gmx.net (mp003) with SMTP; 01 Oct 2005 21:41:12 +0200 X-Authenticated: #1915285 Message-ID: <433EE635.5040708@gmx.de> Date: Sat, 01 Oct 2005 21:40:37 +0200 From: Julian Reschke User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: webdav CC: Geoffrey M Clemm , John Baumgarten 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=-1.8 X-W3C-Scan-Sig: maggie.w3.org 1ELnER-0002n3-37 d6043b5a58cfd3ba9b038e0ba07f4f54 X-Original-To: w3c-dist-auth@w3.org Subject: REDIRECTREF issue "8.1_deep_lock_complexity", was: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/433EE635.5040708@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9851 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 01 Oct 2005 19:41:21 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > I agree with Julian that the Depth infinity section of redirectref should > be redefined based on this implementation experience. > > Cheers, > Geoff OK, I finally got around reviewing the issue. I have changed the spec based on the principle of "least client astonishment", letting the behaviour default to "the right thing". That is, non redirect-aware clients will see no difference when applying LOCK, COPY, MOVE or DELETE to a collection that may contain redirects. (Our server currently obeys the Apply-To-Redirect-Ref header for COPY and MOVE, but I'm not aware of any use case depending on that, so I'll simply change the behaviour). Not surprisingly, the spec has gotten quiet a bit shorter because of that. Feedback appreciated -- I'd like to submit this as a revised draft addressing all WGLC comments before the cutoff date for the upcoming IETF. Best regards, Julian -- Link to issue for tracking: Link to latest edits (includes change tracking): Revised spec text (Section 8): 8. Operations on Collections That Contain Redirect Reference Resources According to [RFC2518], Section 9.2, methods that have defined interactions with the "Depth" request header should apply all other request headers to each resource in scope. However, applying this principle to the "Apply-To-Redirect-Ref" header uniformly would make it impractical to implement this specification on top of existing servers and also would result in unexpected server behaviour for clients that do not take the existence of redirect references into account. On the other hand, the definition of the "Depth" header allows to explicitly define alternate behaviours. For this reason, this specification defines the interaction between "Depth" and "Apply-To-Redirect-Ref" request headers on a case-by-case basis, and also provides a default for methods not mentioned here that do not specify the behaviour themselves. +-------------+-----------------+------------------+-----------+ | method name | defined in | supported depths | behaviour | +-------------+-----------------+------------------+-----------+ | COPY | [RFC2518], 8.9 | 0, infinity | "T" | | DELETE | [RFC2518], 8.7 | infinity | "T" | | LOCK | [RFC2518], 8.11 | 0, infinity | "T" | | MOVE | [RFC2518], 8.10 | 0, infinity | "T" | | PROPFIND | [RFC2518], 8.2 | 0, 1, infinity | inherit | | REPORT | [RFC3253], 3.6 | 0, 1, infinity | inherit | | default | | | "T" | +-------------+-----------------+------------------+-----------+ When the behaviour is defined to be "inherit", the method should follow RFC2518's default behaviour for "Depth" operations, which means applying the value given for "Apply-To-Redirect-Ref" to each resource in scope. On the other hand, when it is defined to be "T", the method should behave as if a "Apply-To-Redirect-Ref: T" header was specified for each operation on child resources. The latter ensures that "Depth: infinity" operations will not fail unexpectedly just because there was a redirect reference resource in scope. 8.1 Example: PROPFIND on a Collection with Redirect Reference Resources Suppose a PROPFIND request with Depth: infinity is submitted to the following collection, with the members shown here: /MyCollection/ (non-reference resource) diary.html (redirect reference resource) nunavut >> Request: PROPFIND /MyCollection/ HTTP/1.1 Host: example.com Depth: infinity Apply-To-Redirect-Ref: F Content-Type: text/xml Content-Length: xxxx >> Response: HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx /MyCollection/ diary, interests, hobbies HTTP/1.1 200 OK /MyCollection/diary.html diary, travel, family, history HTTP/1.1 200 OK /MyCollection/nunavut HTTP/1.1 302 Found http://example.ca/art/inuit/ In this example the Depth header is set to infinity, and the Apply- To-Redirect-Ref header is set to "F". The collection contains one URI that identifies a redirect reference resource. The response element for the redirect reference resource has a status of 302 (Found), and includes a DAV:location extension element to allow clients to retrieve the properties of its target resource. (The response element for the redirect reference resource does not include the requested properties. The client can submit another PROPFIND request to the URI in the DAV:location pseudo-property to retrieve those properties.) 8.2 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with Redirect Reference Resources Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: infinity is submitted to the following collection, with the members shown here: /MyCollection/ (non-reference resource) diary.html (redirect reference resource) nunavut >> Request: PROPFIND /MyCollection/ HTTP/1.1 Host: example.com Depth: infinity Apply-To-Redirect-Ref: T Content-Type: text/xml Content-Length: xxxx >> Response: HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx /MyCollection/ HTTP/1.1 200 OK HTTP/1.1 404 Not Found /MyCollection/diary.html HTTP/1.1 200 OK HTTP/1.1 404 Not Found /MyCollection/nunavut http://example.ca/art/inuit/ HTTP/1.1 200 OK Since the "Apply-To-Redirect-Ref: T" header is present, the response shows the properties of the redirect reference resource in the collection rather than reporting a 302 status. From porter@lissamail.com Sun Oct 02 06:55:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM1VG-0006BE-Cr for webdav-archive@megatron.ietf.org; Sun, 02 Oct 2005 06:55:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07308 for ; Sun, 2 Oct 2005 06:55:31 -0400 (EDT) Received: from [59.150.129.92] (helo=-1212267048) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EM1dU-0004xW-8p for webdav-archive@ietf.org; Sun, 02 Oct 2005 07:04:06 -0400 Received: from lissamail.com (-1212637000 [-1213268376]) by dbzmail.com (Qmailv1) with ESMTP id 9D5BEBF988 for ; Sun, 02 Oct 2005 06:56:24 -0400 Date: Sun, 02 Oct 2005 06:56:24 -0400 From: Doctor X-Mailer: The Bat! (v2.00.2) Personal X-Priority: 3 Message-ID: <8228581713.20051002065624@lissamail.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------E7521A6F4CBA1C9" X-AntiVirus: OK! AntiVir MailGate Version 2.0.1; AVE: 6.15.0.0; VDF: 6.15.0.6 X-Spam-Score: 2.9 (++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------------E7521A6F4CBA1C9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlazgra $3.3 Levirtra $3.3 Ciajlis $3.7 Imitrrex $16.4 Flommax $2.2 Ultrnam $0.78 Vioaxx $4.75 Ambrien $2.2 Valpium $0.97 Xanamx $1.09 Soqma $3 Meriodia $2.2 our site http://decinopla.com/?GFSMKDRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals ------------E7521A6F4CBA1C9 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlabgra - $3.3
Leviwtra - $3.3
Ciamlis - $3.7
Imitcrex - $16.4
Flomxax - $2.2
Ultrqam - $0.78
Vioyxx - $4.75
Ambaien - $2.2
Valpium - $0.97
Xanagx - $1.09
Sozma - $3
Meriwdia - $2.2

our website

___
Best regards,
Online Pharmaceuticals ------------E7521A6F4CBA1C9-- From w3c-dist-auth-request@frink.w3.org Mon Oct 03 05:34:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMiF-0007Yy-Q4 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 05:34:24 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16276 for ; Mon, 3 Oct 2005 05:34:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMMg3-0005Gl-Qv for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 09:32:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMMg3-0005G4-Am for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 09:32:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMMfz-0004nh-Ee for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 09:32:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j939W1ot006966; Mon, 3 Oct 2005 02:32:01 -0700 Date: Mon, 3 Oct 2005 02:32:01 -0700 Message-Id: <200510030932.j939W1ot006966@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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1EMMfz-0004nh-Ee 2524261023746f826d826315451b18e6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200510030932.j939W1ot006966@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9852 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 09:32:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 02:32 ------- Secion 6.7 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 Mon Oct 03 05:40:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMoI-0000bb-Fo for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 05:40:38 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16691 for ; Mon, 3 Oct 2005 05:40:34 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMMnX-0007hK-4d for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 09:39:51 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMMnW-0007gk-NI for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 09:39:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMMnR-0006Rs-Cr for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 09:39:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j939di81007002; Mon, 3 Oct 2005 02:39:44 -0700 Date: Mon, 3 Oct 2005 02:39:44 -0700 Message-Id: <200510030939.j939di81007002@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=-1.2 X-W3C-Scan-Sig: maggie.w3.org 1EMMnR-0006Rs-Cr e752b2c99434534f6e303b91c71ab7b7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 64] Incorrect IETF boilerplate X-Archived-At: http://www.w3.org/mid/200510030939.j939di81007002@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9853 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 09:39:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=64 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 02:39 ------- Fixed in 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 Mon Oct 03 05:45:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMsv-0001bs-M2 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 05:45:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16942 for ; Mon, 3 Oct 2005 05:45:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMMsF-0008OO-Aj for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 09:44:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMMsF-0008Nk-2d for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 09:44:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMMs7-0001Ey-1g for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 09:44:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j939iXvh007019; Mon, 3 Oct 2005 02:44:33 -0700 Date: Mon, 3 Oct 2005 02:44:33 -0700 Message-Id: <200510030944.j939iXvh007019@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMMs7-0001Ey-1g 49e706c855bbf097e1cf17a928a13587 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 55] Multistatus format (empty) X-Archived-At: http://www.w3.org/mid/200510030944.j939iXvh007019@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9854 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 09:44:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=55 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 05:48:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMva-000244-1K for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 05:48:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17079 for ; Mon, 3 Oct 2005 05:48:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMMun-0001l8-Ng for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 09:47:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMMun-0001kQ-B5 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 09:47:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMMua-0001tp-UI for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 09:47:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j939l8Ot007042; Mon, 3 Oct 2005 02:47:08 -0700 Date: Mon, 3 Oct 2005 02:47:08 -0700 Message-Id: <200510030947.j939l8Ot007042@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=-0.5 X-W3C-Scan-Sig: lisa.w3.org 1EMMua-0001tp-UI bf28e67f17dcfbea5f57bc44a9b500a2 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/200510030947.j939l8Ot007042@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9855 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 09:47:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=56 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 05:50:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMy4-0002Qa-0F for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 05:50:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17197 for ; Mon, 3 Oct 2005 05:50:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMMxL-0001wt-EK for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 09:49:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMMxL-0001wL-3L for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 09:49:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMMxI-0000Ib-0l for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 09:49:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j939nrsX007058; Mon, 3 Oct 2005 02:49:53 -0700 Date: Mon, 3 Oct 2005 02:49:53 -0700 Message-Id: <200510030949.j939nrsX007058@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMMxI-0000Ib-0l 26841a8442332e2b22d0086bdb4c66c8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 57] incorrect section reference X-Archived-At: http://www.w3.org/mid/200510030949.j939nrsX007058@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9856 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 09:49:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=57 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 05:52:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMzo-0002ct-4M for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 05:52:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17349 for ; Mon, 3 Oct 2005 05:52:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMMzB-0002Rz-TA for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 09:51:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMMzB-0002RQ-Hv for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 09:51:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMMz8-0000lO-TM for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 09:51:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j939poUj007079; Mon, 3 Oct 2005 02:51:50 -0700 Date: Mon, 3 Oct 2005 02:51:50 -0700 Message-Id: <200510030951.j939poUj007079@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=-0.6 X-W3C-Scan-Sig: maggie.w3.org 1EMMz8-0000lO-TM 9f7ed0a5a98e0c799799147626390551 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 58] MOVE status 403 description X-Archived-At: http://www.w3.org/mid/200510030951.j939poUj007079@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9857 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 09:51:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=58 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 05:59:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMN6V-0003lH-GR for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 05:59:27 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17635 for ; Mon, 3 Oct 2005 05:59:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMN5m-0003D8-LB for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 09:58:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMN5m-0003CV-6p for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 09:58:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMN5b-0004kM-N8 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 09:58:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j939wUqo007100; Mon, 3 Oct 2005 02:58:30 -0700 Date: Mon, 3 Oct 2005 02:58:30 -0700 Message-Id: <200510030958.j939wUqo007100@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=-1.2 X-W3C-Scan-Sig: lisa.w3.org 1EMN5b-0004kM-N8 70897520c14db9bad2b2ef750d4a57db X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 59] failed LOCK response body X-Archived-At: http://www.w3.org/mid/200510030958.j939wUqo007100@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9858 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 09:58:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=59 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 02:58 ------- Now in section 8.11.5 () ------- 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 Oct 03 06: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 1EMN84-00043L-MD for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:01:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17722 for ; Mon, 3 Oct 2005 06:01:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMN7P-0004kl-RU for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:00:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMN7P-0004kD-Jc for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:00:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMN7H-0005D4-DA for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:00:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93A0FYt007119; Mon, 3 Oct 2005 03:00:15 -0700 Date: Mon, 3 Oct 2005 03:00:15 -0700 Message-Id: <200510031000.j93A0FYt007119@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=-1.0 X-W3C-Scan-Sig: lisa.w3.org 1EMN7H-0005D4-DA c4f5074225de74f59b90e3e97febc544 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 60] If header evaluation when? X-Archived-At: http://www.w3.org/mid/200510031000.j93A0FYt007119@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9859 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:00:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=60 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:02:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMN9i-0004WK-LD for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:02:46 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17773 for ; Mon, 3 Oct 2005 06:02:44 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMN93-0004yf-Sb for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:02:05 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMN93-0004y7-HX for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:02:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMN8w-0002xx-Nn for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:02:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93A1J8a007150; Mon, 3 Oct 2005 03:01:19 -0700 Date: Mon, 3 Oct 2005 03:01:19 -0700 Message-Id: <200510031001.j93A1J8a007150@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMN8w-0002xx-Nn 8714b6069e9e14ace610bdcdb58bad95 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 61] invalid lock token in example X-Archived-At: http://www.w3.org/mid/200510031001.j93A1J8a007150@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9860 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:02:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=61 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:04:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNBj-0004il-6h for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:04:51 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17853 for ; Mon, 3 Oct 2005 06:04:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNAs-00059h-H6 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:03:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNAs-000599-9F for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:03:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNAj-0006Jv-9p for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:03:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93A3n3S007168; Mon, 3 Oct 2005 03:03:49 -0700 Date: Mon, 3 Oct 2005 03:03:49 -0700 Message-Id: <200510031003.j93A3n3S007168@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMNAj-0006Jv-9p 8252eb00cf74af3f03123814ba4ca1bc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] href format X-Archived-At: http://www.w3.org/mid/200510031003.j93A3n3S007168@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9861 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:03:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 03:03 ------- (RFC2396bis has been published as RFC3986) ------- 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 Oct 03 06:06:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNCy-00051Q-G7 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:06:08 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17915 for ; Mon, 3 Oct 2005 06:06:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNCH-0005dB-My for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:05:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNCH-0005cY-FH for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:05:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNC6-0006gA-MG for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:05:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93A5Ega007187; Mon, 3 Oct 2005 03:05:14 -0700 Date: Mon, 3 Oct 2005 03:05:14 -0700 Message-Id: <200510031005.j93A5Ega007187@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=-0.5 X-W3C-Scan-Sig: lisa.w3.org 1EMNC6-0006gA-MG eb97a23912b4fc1e1ece8c742039ec8b 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/200510031005.j93A5Ega007187@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9862 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:05:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=63 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:07:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNDq-00053y-LE for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:07:02 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17959 for ; Mon, 3 Oct 2005 06:07:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNDG-0005mF-R3 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:06:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNDG-0005lf-J3 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:06:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMND9-000728-C8 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:06:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93A6I5s007209; Mon, 3 Oct 2005 03:06:18 -0700 Date: Mon, 3 Oct 2005 03:06:18 -0700 Message-Id: <200510031006.j93A6I5s007209@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=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1EMND9-000728-C8 207b18b18067552895a1bd91ba999084 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 65] Table of Contents missing X-Archived-At: http://www.w3.org/mid/200510031006.j93A6I5s007209@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9863 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:06:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=65 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 03:06 ------- Fixed in 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 Mon Oct 03 06:08:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNEu-00059W-30 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:08:08 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18016 for ; Mon, 3 Oct 2005 06:08:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNEG-0005x4-G7 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:07:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNEG-0005wR-1K for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:07:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNE6-0007HZ-UL for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:07:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93A7H8N007225; Mon, 3 Oct 2005 03:07:17 -0700 Date: Mon, 3 Oct 2005 03:07:17 -0700 Message-Id: <200510031007.j93A7H8N007225@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMNE6-0007HZ-UL 142effb6bd22eb5590f7e6e1e67e7ace X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 66] references style X-Archived-At: http://www.w3.org/mid/200510031007.j93A7H8N007225@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9864 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:07:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=66 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:12:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNIh-00061l-M6 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:12:03 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18167 for ; Mon, 3 Oct 2005 06:12:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNI6-0006oW-CS for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:11:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNI6-0006ny-4h for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:11:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNI0-0008RY-QZ for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:11:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93ABJwN007262; Mon, 3 Oct 2005 03:11:19 -0700 Date: Mon, 3 Oct 2005 03:11:19 -0700 Message-Id: <200510031011.j93ABJwN007262@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMNI0-0008RY-QZ d42a83b52fbb80f9abc3ccf02dcf0ae7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 68] Reference to XML spec X-Archived-At: http://www.w3.org/mid/200510031011.j93ABJwN007262@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9866 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:11:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=68 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06: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 1EMNKa-0006II-In for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:14:00 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18247 for ; Mon, 3 Oct 2005 06:13:57 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNJz-0007Gp-Vc for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:13:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNJz-0007GH-Kb for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:13:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNJv-0005ro-FO for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:13:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93ADHcU007281; Mon, 3 Oct 2005 03:13:17 -0700 Date: Mon, 3 Oct 2005 03:13:17 -0700 Message-Id: <200510031013.j93ADHcU007281@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=-1.4 X-W3C-Scan-Sig: maggie.w3.org 1EMNJv-0005ro-FO 45e2e43459d58783ceecab5be7b9db0c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 69] Formatting lost in appendix B.2 X-Archived-At: http://www.w3.org/mid/200510031013.j93ADHcU007281@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9867 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:13:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=69 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 03:13 ------- (appendix was removed in 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 Mon Oct 03 06: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 1EMNIQ-00060B-8l for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:11:46 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18159 for ; Mon, 3 Oct 2005 06:11:43 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNHe-0006ht-Ie for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:10:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNHe-0006hL-AT for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:10:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNH9-0008By-0Q for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:10:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AAOIj007244; Mon, 3 Oct 2005 03:10:24 -0700 Date: Mon, 3 Oct 2005 03:10:24 -0700 Message-Id: <200510031010.j93AAOIj007244@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMNH9-0008By-0Q efaa41c475193d8a9392ca2e483db0df X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 67] non-ASCII characters X-Archived-At: http://www.w3.org/mid/200510031010.j93AAOIj007244@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9865 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:10:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=67 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:16:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNNJ-0006lF-04 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:16:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18373 for ; Mon, 3 Oct 2005 06:16:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNMf-0000dZ-MW for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:16:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNMf-0000cs-B4 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:16:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNMT-0006Qt-DA for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:16:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AFtuN007307; Mon, 3 Oct 2005 03:15:55 -0700 Date: Mon, 3 Oct 2005 03:15:55 -0700 Message-Id: <200510031015.j93AFtuN007307@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMNMT-0006Qt-DA 89b86eaa3e8ffc910c4253b0c874d8a9 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/200510031015.j93AFtuN007307@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9868 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:16:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=42 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06: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 1EMNOR-0006xC-JE for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:17:59 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18410 for ; Mon, 3 Oct 2005 06:17:57 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNNr-0000lc-Aj for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:17:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNNq-0000l4-Sn for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:17:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNNk-0001Yd-7i for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:17:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AHFjI007325; Mon, 3 Oct 2005 03:17:15 -0700 Date: Mon, 3 Oct 2005 03:17:15 -0700 Message-Id: <200510031017.j93AHFjI007325@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMNNk-0001Yd-7i 6dd9ad943ca521790e9328e6d4ee7786 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 43] "ill-formed" XML X-Archived-At: http://www.w3.org/mid/200510031017.j93AHFjI007325@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9869 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:17:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=43 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:19:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNQ9-0007O6-SZ for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:19:46 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18466 for ; Mon, 3 Oct 2005 06:19:43 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNPV-0000tm-OT for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:19:05 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNPV-0000tE-D9 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:19:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNPQ-00076J-Pl for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:19:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AIx7s007341; Mon, 3 Oct 2005 03:18:59 -0700 Date: Mon, 3 Oct 2005 03:18:59 -0700 Message-Id: <200510031018.j93AIx7s007341@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=-0.5 X-W3C-Scan-Sig: maggie.w3.org 1EMNPQ-00076J-Pl b52b724611f31de2e19a678c8d558b96 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] OPTIONS * X-Archived-At: http://www.w3.org/mid/200510031018.j93AIx7s007341@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9870 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:19:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06: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 1EMNSM-0007ju-Mm for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:22:02 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18522 for ; Mon, 3 Oct 2005 06:22:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNRe-0001R8-D1 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:21:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNRe-0001Qa-1Z for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:21:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNRX-0007bC-N4 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:21:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93ALAC8007362; Mon, 3 Oct 2005 03:21:10 -0700 Date: Mon, 3 Oct 2005 03:21:10 -0700 Message-Id: <200510031021.j93ALAC8007362@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMNRX-0007bC-N4 44e8e1e37f80a050feba96724a465178 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 45] DAV request header X-Archived-At: http://www.w3.org/mid/200510031021.j93ALAC8007362@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9871 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:21:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=45 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:24:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNV7-0008Cj-Iy for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:24:53 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18659 for ; Mon, 3 Oct 2005 06:24:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNUT-0001Za-1D for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:24:13 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNUS-0001Yv-MG for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:24:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNUJ-0008Bo-KN for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:24:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AO1XF007380; Mon, 3 Oct 2005 03:24:01 -0700 Date: Mon, 3 Oct 2005 03:24:01 -0700 Message-Id: <200510031024.j93AO1XF007380@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMNUJ-0008Bo-KN a0503cf002538d801eac98f7f35ff0d3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200510031024.j93AO1XF007380@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9872 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:24:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:27:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNXi-0008WF-6X for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:27:34 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18738 for ; Mon, 3 Oct 2005 06:27:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNX5-0002Ce-1c for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:26:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNX4-0002C6-GK for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:26:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNWx-0000HP-E6 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:26:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AQkIc007401; Mon, 3 Oct 2005 03:26:46 -0700 Date: Mon, 3 Oct 2005 03:26:46 -0700 Message-Id: <200510031026.j93AQkIc007401@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=-0.5 X-W3C-Scan-Sig: maggie.w3.org 1EMNWx-0000HP-E6 c020fa9e253251b5b25876838361f20c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200510031026.j93AQkIc007401@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9873 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:26:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:29:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNZu-0000dr-GA for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:29:50 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18847 for ; Mon, 3 Oct 2005 06:29:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNZH-0002P1-Ht for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:29:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNZH-0002OO-3u for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:29:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNZ9-0004Og-Af for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:29:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AT2sq007419; Mon, 3 Oct 2005 03:29:02 -0700 Date: Mon, 3 Oct 2005 03:29:02 -0700 Message-Id: <200510031029.j93AT2sq007419@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMNZ9-0004Og-Af b44bbc0571fb561dc72922940ca097a1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200510031029.j93AT2sq007419@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9874 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:29:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:31:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNbj-0000zu-Ha for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:31:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18897 for ; Mon, 3 Oct 2005 06:31:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNb5-0003yk-Jx for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:31:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNb5-0003yC-C3 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:31:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNar-0004pi-VW for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:31:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AUnEh007438; Mon, 3 Oct 2005 03:30:49 -0700 Date: Mon, 3 Oct 2005 03:30:49 -0700 Message-Id: <200510031030.j93AUnEh007438@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMNar-0004pi-VW ace5e7c79ba223edcb9857a24eb1adc7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 49] propfind XML description incorrect X-Archived-At: http://www.w3.org/mid/200510031030.j93AUnEh007438@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9875 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:31:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=49 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:33:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNdD-0001IB-Op for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:33:15 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18991 for ; Mon, 3 Oct 2005 06:33:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNcP-00046K-DZ for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:32:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNcO-00045k-Si for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:32:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNcK-0001Nr-Vq for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:32:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AWKrf007458; Mon, 3 Oct 2005 03:32:20 -0700 Date: Mon, 3 Oct 2005 03:32:20 -0700 Message-Id: <200510031032.j93AWKrf007458@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMNcK-0001Nr-Vq 7e2e402c4aef9dc862d5c898d7e454e1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200510031032.j93AWKrf007458@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9876 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:32:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:35:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNfe-0001fF-OR for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:35:46 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19174 for ; Mon, 3 Oct 2005 06:35:44 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNeo-0004QH-HZ for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:34:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNeo-0004Pi-9b for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:34:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNdh-0005Vo-HL for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:34:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AXj4G007474; Mon, 3 Oct 2005 03:33:45 -0700 Date: Mon, 3 Oct 2005 03:33:45 -0700 Message-Id: <200510031033.j93AXj4G007474@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=-0.5 X-W3C-Scan-Sig: lisa.w3.org 1EMNdh-0005Vo-HL 0afdffe969a0c840d0c473434a811f04 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/200510031033.j93AXj4G007474@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9877 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:34:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=51 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:36:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNfw-0001gO-IJ for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:36:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19179 for ; Mon, 3 Oct 2005 06:36:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNfF-0004rw-DT for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:35:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNfF-0004rG-55 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:35:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNet-0005o2-U9 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:35:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AYxW4007490; Mon, 3 Oct 2005 03:34:59 -0700 Date: Mon, 3 Oct 2005 03:34:59 -0700 Message-Id: <200510031034.j93AYxW4007490@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=-1.0 X-W3C-Scan-Sig: lisa.w3.org 1EMNet-0005o2-U9 c1b0498f2acea077a0e4078e314a3d77 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 52] "mandatory" properties X-Archived-At: http://www.w3.org/mid/200510031034.j93AYxW4007490@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9878 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:35:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=52 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:36:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNgo-0001wU-Aj for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:36:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19237 for ; Mon, 3 Oct 2005 06:36:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNgB-00058j-UQ for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:36:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNgB-00058B-JK for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:36:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNg4-00027C-55 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:36:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AaB6U007507; Mon, 3 Oct 2005 03:36:11 -0700 Date: Mon, 3 Oct 2005 03:36:11 -0700 Message-Id: <200510031036.j93AaB6U007507@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMNg4-00027C-55 3edfecb71ceeff3b765fce10be433abb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200510031036.j93AaB6U007507@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9879 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:36:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 06:38:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNhu-000238-1O for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:38:06 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19268 for ; Mon, 3 Oct 2005 06:38:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNhE-0005Jb-0S for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:37:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNhD-0005J3-La for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:37:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNh5-0002J2-Lc for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:37:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AbE2t007525; Mon, 3 Oct 2005 03:37:14 -0700 Date: Mon, 3 Oct 2005 03:37:14 -0700 Message-Id: <200510031037.j93AbE2t007525@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=-1.4 X-W3C-Scan-Sig: maggie.w3.org 1EMNh5-0002J2-Lc a90ba8db8a81843837de0a048dc42b89 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 74] Remove UUID generation instructions X-Archived-At: http://www.w3.org/mid/200510031037.j93AbE2t007525@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9880 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:37:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=74 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 03:37 ------- Done in 07. ------- 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 Oct 03 06: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 1EMNma-0002so-6o for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:42:56 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19560 for ; Mon, 3 Oct 2005 06:42:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNlv-0005z1-NT for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:42:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNlv-0005yT-Fg for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:42:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNlj-0007Px-Ut for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:42:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93Ag3f5007543; Mon, 3 Oct 2005 03:42:03 -0700 Date: Mon, 3 Oct 2005 03:42:03 -0700 Message-Id: <200510031042.j93Ag3f5007543@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=-0.5 X-W3C-Scan-Sig: lisa.w3.org 1EMNlj-0007Px-Ut cfdefc429bb62e5e19c81c9ad7f6b85d 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/200510031042.j93Ag3f5007543@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9881 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:42:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=6 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 06: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 1EMNo8-00034k-GD for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:44:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19664 for ; Mon, 3 Oct 2005 06:44:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNnJ-00065z-Nj for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:43:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNnJ-00065M-Fo for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:43:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNmw-0007id-TH for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:43:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AhHD2007563; Mon, 3 Oct 2005 03:43:17 -0700 Date: Mon, 3 Oct 2005 03:43:17 -0700 Message-Id: <200510031043.j93AhHD2007563@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=-1.0 X-W3C-Scan-Sig: lisa.w3.org 1EMNmw-0007id-TH 24308b293a813da9e952ab446931201f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 7] Example for PROPFIND/allprop missing X-Archived-At: http://www.w3.org/mid/200510031043.j93AhHD2007563@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9882 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:43:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=7 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 06:45:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNot-0003Du-Gi for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:45:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19713 for ; Mon, 3 Oct 2005 06:45:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNoE-0006DR-4K for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:44:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNoD-0006Ct-Io for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:44:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNo5-0003nK-Tw for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:44:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AiSrf007581; Mon, 3 Oct 2005 03:44:28 -0700 Date: Mon, 3 Oct 2005 03:44:28 -0700 Message-Id: <200510031044.j93AiSrf007581@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMNo5-0003nK-Tw 11bd48f9c91af1f88514f00311b0a27f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200510031044.j93AiSrf007581@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9883 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:44:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 06:49:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNsc-0003xy-OS for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:49:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19864 for ; Mon, 3 Oct 2005 06:49:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNrw-0008DH-8U for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:48:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNrv-0008CY-Qj for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:48:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNrb-0000OJ-Ew for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:48:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93Am6q8007598; Mon, 3 Oct 2005 03:48:06 -0700 Date: Mon, 3 Oct 2005 03:48:06 -0700 Message-Id: <200510031048.j93Am6q8007598@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=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1EMNrb-0000OJ-Ew 77318e3a23b651bea31036f33f802fbc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/200510031048.j93Am6q8007598@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9884 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:48:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 03:48 ------- Now in 4.3 () ------- 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 Oct 03 06:51:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNv4-0004Si-6n for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:51:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19951 for ; Mon, 3 Oct 2005 06:51:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNuR-0000QI-8m for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:51:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNuR-0000Pk-0s for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:51:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMNuD-0000xp-Nn for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:51:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93Aonja007617; Mon, 3 Oct 2005 03:50:49 -0700 Date: Mon, 3 Oct 2005 03:50:49 -0700 Message-Id: <200510031050.j93Aonja007617@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=-1.5 X-W3C-Scan-Sig: lisa.w3.org 1EMNuD-0000xp-Nn 79d558f12f4926a39a831223bda0e2b1 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/200510031050.j93Aonja007617@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9885 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:51:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 03:50 ------- Now in 4.4 () ------- 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 Oct 03 06: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 1EMNxN-0004uL-V9 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:54:06 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20009 for ; Mon, 3 Oct 2005 06:54:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNwh-0000jZ-TM for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:53:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNwh-0000j1-Hm for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 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 1EMNwe-0005eG-Mo for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:53:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93ArKN1007637; Mon, 3 Oct 2005 03:53:20 -0700 Date: Mon, 3 Oct 2005 03:53:20 -0700 Message-Id: <200510031053.j93ArKN1007637@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=-0.5 X-W3C-Scan-Sig: maggie.w3.org 1EMNwe-0005eG-Mo 51af637900d627d38c6af7d786550456 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/200510031053.j93ArKN1007637@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9886 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:53:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 06:56:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNzS-0005JZ-6c for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:56:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20094 for ; Mon, 3 Oct 2005 06:56:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMNyk-0001LT-3m for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:55:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMNyj-0001KS-OH for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:55:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMNyg-000682-9a for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:55:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AtPAi007658; Mon, 3 Oct 2005 03:55:25 -0700 Date: Mon, 3 Oct 2005 03:55:25 -0700 Message-Id: <200510031055.j93AtPAi007658@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMNyg-000682-9a c8b25bffe0093d70ec18a5fd92a84c36 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200510031055.j93AtPAi007658@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9887 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:55:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 03:55 ------- (I honestly still don't understand what this section is trying to define) ------- 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 Oct 03 06:57:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMO0x-0005ZB-Co for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:57:47 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20177 for ; Mon, 3 Oct 2005 06:57:44 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMO0N-0001VB-25 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:57:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMO0M-0001UY-QK for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:57:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMO0J-0002Zv-WE for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:57:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93Av7ZD007676; Mon, 3 Oct 2005 03:57:07 -0700 Date: Mon, 3 Oct 2005 03:57:07 -0700 Message-Id: <200510031057.j93Av7ZD007676@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMO0J-0002Zv-WE 75ac4c30d0848106beafac45d4ca7240 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 13] new ETag requirements X-Archived-At: http://www.w3.org/mid/200510031057.j93Av7ZD007676@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9888 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:57:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 06: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 1EMO29-0005ia-AL for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 06:59:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20237 for ; Mon, 3 Oct 2005 06:58:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMO1Z-0001iy-7C for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:58:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMO1Y-0001iQ-Od for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:58:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMO1W-0002x4-98 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:58:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AwMqP007692; Mon, 3 Oct 2005 03:58:22 -0700 Date: Mon, 3 Oct 2005 03:58:22 -0700 Message-Id: <200510031058.j93AwMqP007692@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMO1W-0002x4-98 06abe7f1ffeaaf8d3d64cf47a6809261 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/200510031058.j93AwMqP007692@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9889 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:58:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 07:00:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMO3J-000619-9l for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:00:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20284 for ; Mon, 3 Oct 2005 07:00:10 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMO2i-0001qO-7o for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 10:59:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMO2h-0001pp-Sb for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 10:59:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMO2e-0006xL-3l for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 10:59:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93AxVSA007708; Mon, 3 Oct 2005 03:59:31 -0700 Date: Mon, 3 Oct 2005 03:59:31 -0700 Message-Id: <200510031059.j93AxVSA007708@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMO2e-0006xL-3l e0fbc4f78d39beeea27ccbdee0137308 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/200510031059.j93AxVSA007708@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9890 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 10:59:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 07:02:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMO5Y-0006IF-VT for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:02:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20425 for ; Mon, 3 Oct 2005 07:02:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMO4t-0003hB-PJ for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:01:51 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMO4t-0003gd-DS for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:01:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMO4k-0007Nq-69 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:01:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93B1fbN007737; Mon, 3 Oct 2005 04:01:41 -0700 Date: Mon, 3 Oct 2005 04:01:41 -0700 Message-Id: <200510031101.j93B1fbN007737@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMO4k-0007Nq-69 083efd465aa8f47e0c6013068297d930 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/200510031101.j93B1fbN007737@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9891 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:01:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 07:06:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMO9T-0006zh-Tj for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:06:35 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20606 for ; Mon, 3 Oct 2005 07:06:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMO8p-0004oa-AD for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:05:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMO8p-0004nu-23 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:05:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMO7c-0004nL-Mt for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:05:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93B4Ope007954; Mon, 3 Oct 2005 04:04:24 -0700 Date: Mon, 3 Oct 2005 04:04:24 -0700 Message-Id: <200510031104.j93B4Ope007954@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=-1.5 X-W3C-Scan-Sig: lisa.w3.org 1EMO7c-0004nL-Mt b96631695eccd10de5a65a485f8712e7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/200510031104.j93B4Ope007954@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9892 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:05:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=17 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 04:04 ------- Now in 8.2.3 () ------- 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 Oct 03 07:07:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOAZ-0007LE-MD for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:07:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20697 for ; Mon, 3 Oct 2005 07:07:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMO9x-00050k-7K for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:07:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMO9w-00050C-VR for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:07:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMO9o-0005dk-4g for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:07:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93B6twR007973; Mon, 3 Oct 2005 04:06:55 -0700 Date: Mon, 3 Oct 2005 04:06:55 -0700 Message-Id: <200510031106.j93B6twR007973@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMO9o-0005dk-4g a4d9a5cc8dceaccc617b0b80d47c75f3 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/200510031106.j93B6twR007973@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9893 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:07:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 07:09:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOBt-0007RX-DN for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:09:05 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20742 for ; Mon, 3 Oct 2005 07:09:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOBE-0005At-8w for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:08:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOBE-0005AG-0n for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:08:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMOBA-00061C-Gh for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:08:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93B8JEc007991; Mon, 3 Oct 2005 04:08:19 -0700 Date: Mon, 3 Oct 2005 04:08:19 -0700 Message-Id: <200510031108.j93B8JEc007991@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=-0.5 X-W3C-Scan-Sig: lisa.w3.org 1EMOBA-00061C-Gh 7617def331167a838f402f304d3bd93d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200510031108.j93B8JEc007991@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9894 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:08:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 07:12:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOF9-00086I-UH for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:12:28 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20876 for ; Mon, 3 Oct 2005 07:12:25 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOEQ-0005nS-BH for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:11:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOEQ-0005ms-0E for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:11:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMOEM-0001Oj-JP for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:11:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93BBarW008016; Mon, 3 Oct 2005 04:11:36 -0700 Date: Mon, 3 Oct 2005 04:11:36 -0700 Message-Id: <200510031111.j93BBarW008016@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=-1.5 X-W3C-Scan-Sig: maggie.w3.org 1EMOEM-0001Oj-JP 576685a8ead567222bd740487bd0d4f6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 20] lock token example X-Archived-At: http://www.w3.org/mid/200510031111.j93BBarW008016@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9895 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:11:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 04:11 ------- Section 9.5.1 uses the right scheme, but an syntactically invalid token. Section 9.5.2 still uses an undefined scheme. ------- 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 Oct 03 07:14:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOHY-00007G-T3 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:14:56 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21083 for ; Mon, 3 Oct 2005 07:14:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOGv-000653-D9 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:14:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOGv-00064S-1x for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:14:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMOGs-0001wm-5i for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:14:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93BEBkQ008043; Mon, 3 Oct 2005 04:14:11 -0700 Date: Mon, 3 Oct 2005 04:14:11 -0700 Message-Id: <200510031114.j93BEBkQ008043@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=-0.7 X-W3C-Scan-Sig: maggie.w3.org 1EMOGs-0001wm-5i f8906d1c772b21d6d0d127d74ab2f93a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 21] XML element definitions X-Archived-At: http://www.w3.org/mid/200510031114.j93BEBkQ008043@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9896 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:14:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=21 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 04:14 ------- *** This bug has been marked as a duplicate of 48 *** ------- 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 Oct 03 07:14:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOHb-00007S-K6 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:14:59 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21085 for ; Mon, 3 Oct 2005 07:14:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOH2-00065h-59 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:14:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOH1-000659-Jc for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:14:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMOGy-0001x1-Fk for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:14:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93BECVr008053; Mon, 3 Oct 2005 04:14:12 -0700 Date: Mon, 3 Oct 2005 04:14:12 -0700 Message-Id: <200510031114.j93BECVr008053@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMOGy-0001x1-Fk 8b62e014e995857d183f1f7b38850332 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200510031114.j93BECVr008053@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9897 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:14:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 04:14 ------- *** Bug 21 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 Mon Oct 03 07:17:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOJf-0000QD-Jp for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:17:07 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21187 for ; Mon, 3 Oct 2005 07:17:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOIy-00083W-RL for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:16:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOIy-00082r-I1 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:16:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMOIv-0007vn-N6 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:16:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93BGLlZ008073; Mon, 3 Oct 2005 04:16:21 -0700 Date: Mon, 3 Oct 2005 04:16:21 -0700 Message-Id: <200510031116.j93BGLlZ008073@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMOIv-0007vn-N6 f9d7fd161eea48ed425f77712b7c038f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 22] attributes on properties X-Archived-At: http://www.w3.org/mid/200510031116.j93BGLlZ008073@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9898 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:16:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=22 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 07:19:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOML-00015b-0v for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:19:53 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21321 for ; Mon, 3 Oct 2005 07:19:52 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOLi-0008IX-CQ for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:19:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOLi-0008Hy-0r for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:19:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMOLe-0003Av-0F for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:19:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93BJ1lH008089; Mon, 3 Oct 2005 04:19:01 -0700 Date: Mon, 3 Oct 2005 04:19:01 -0700 Message-Id: <200510031119.j93BJ1lH008089@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=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1EMOLe-0003Av-0F 2054a32a54b6990fb7cbbafe29272e5d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200510031119.j93BJ1lH008089@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9899 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:19:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 07:22:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOOP-0001UW-OQ for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:22:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21430 for ; Mon, 3 Oct 2005 07:22:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMONi-0000Ms-Rh for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:21:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMONi-0000MK-AN for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:21:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMONa-0003k6-0n for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:21:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93BL7D5008106; Mon, 3 Oct 2005 04:21:07 -0700 Date: Mon, 3 Oct 2005 04:21:07 -0700 Message-Id: <200510031121.j93BL7D5008106@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=-1.5 X-W3C-Scan-Sig: maggie.w3.org 1EMONa-0003k6-0n 5e9bcd1b874e3c13e863326c892cb57a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/200510031121.j93BL7D5008106@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9900 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:21:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=24 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 04:21 ------- Now in 7.6 () ------- 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 Oct 03 07:23:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOPp-0001g7-Me for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:23:29 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21501 for ; Mon, 3 Oct 2005 07:23:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOPG-0000Tt-5z for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:22:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOPF-0000TL-NX for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:22:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMOP7-000122-J7 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:22:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93BMjWN008122; Mon, 3 Oct 2005 04:22:45 -0700 Date: Mon, 3 Oct 2005 04:22:45 -0700 Message-Id: <200510031122.j93BMjWN008122@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=-1.5 X-W3C-Scan-Sig: lisa.w3.org 1EMOP7-000122-J7 d85ec44b13be0a6e5a57ccef126f97d8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200510031122.j93BMjWN008122@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9901 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:22:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 04:22 ------- Now in 7.6 () ------- 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 Oct 03 07:47:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOmx-0005a9-JZ for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:47:23 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22398 for ; Mon, 3 Oct 2005 07:47:22 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOlo-0005VY-7n for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:46:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOln-0005Uv-J0 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:46:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMOlf-0000yo-NO for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:46:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93Bk2Qo008169; Mon, 3 Oct 2005 04:46:02 -0700 Date: Mon, 3 Oct 2005 04:46:02 -0700 Message-Id: <200510031146.j93Bk2Qo008169@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=-1.8 X-W3C-Scan-Sig: maggie.w3.org 1EMOlf-0000yo-NO ce6397f1cc8345720501579c3e5681b1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/200510031146.j93Bk2Qo008169@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9902 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:46:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 04:46 ------- Update 07 (). Now says: "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." I don't understand what this means, and what problem it is supposed to address. As far as I can tell, clients will not be able to cope with the collection URL (after normalization and resolution) being different from what the request URI was (maybe except normalization of trailing "/"). ------- 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 Oct 03 07:48:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOnr-0005uQ-M4 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:48:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22466 for ; Mon, 3 Oct 2005 07:48:18 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOnF-0005du-Dv for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:47:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOnF-0005dM-2F for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:47:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMOnB-0001Hv-Ib for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:47:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93BlRre008185; Mon, 3 Oct 2005 04:47:27 -0700 Date: Mon, 3 Oct 2005 04:47:27 -0700 Message-Id: <200510031147.j93BlRre008185@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=-0.5 X-W3C-Scan-Sig: maggie.w3.org 1EMOnB-0001Hv-Ib 9d118b8fb4a2481082311ba48ead6cb1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 27] COPY vs live properties X-Archived-At: http://www.w3.org/mid/200510031147.j93BlRre008185@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9903 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:47:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=27 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 07:52:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOs7-0006wg-Pk for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:52:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22730 for ; Mon, 3 Oct 2005 07:52:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMOrT-0006GC-Oh for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 11:52:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMOrT-0006FW-9x for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 11:52:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMOrQ-0008VD-JD for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 11:52:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93Bq05h008208; Mon, 3 Oct 2005 04:52:00 -0700 Date: Mon, 3 Oct 2005 04:52:00 -0700 Message-Id: <200510031152.j93Bq05h008208@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=-0.5 X-W3C-Scan-Sig: lisa.w3.org 1EMOrQ-0008VD-JD 59cf99064df9b8287f98e66855a187bc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200510031152.j93Bq05h008208@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9904 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 11:52:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:03:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMP2C-0000K0-UK for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:03:09 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23349 for ; Mon, 3 Oct 2005 08:03:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMP1X-0000xS-1h for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:02:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMP1W-0000wu-OO for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:02:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMP1P-0002W8-7y for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:02:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93C2Ihf008254; Mon, 3 Oct 2005 05:02:18 -0700 Date: Mon, 3 Oct 2005 05:02:18 -0700 Message-Id: <200510031202.j93C2Ihf008254@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=-1.8 X-W3C-Scan-Sig: lisa.w3.org 1EMP1P-0002W8-7y 7088bec7e5d7dfde7f9c3d279f4f149b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 29] refreshing locks X-Archived-At: http://www.w3.org/mid/200510031202.j93C2Ihf008254@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9905 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:02:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=29 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 05:02 ------- Update -07, spec now says (): "A lock is refreshed by sending a LOCK request without a body to a resource within the scope of the lock. A LOCK request to refresh a lock must specify which lock to refresh by using the Lock-Token header with a single lock token (only one lock may be refreshed at a time). This request MUST NOT contain a body, but it may contain a Timeout header. A server MAY accept the Timeout header to change the duration remaining on the lock to the new value. A server MUST ignore the Depth header on a LOCK refresh, and the client SHOULD NOT send the Depth header on a LOCK refresh as the server will not convert the lock or confirm the depth." This can be stated much simpler; also the new client requirement on the Depth header is new and unnecessary. Just state: "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." ------- 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 Oct 03 08:04:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMP3A-0000Xt-Mc for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:04:08 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23530 for ; Mon, 3 Oct 2005 08:04:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMP2W-00018e-5T for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:03:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMP2V-000186-TM for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:03:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMP2P-0002pU-Cn for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:03:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93C3KgU008270; Mon, 3 Oct 2005 05:03:20 -0700 Date: Mon, 3 Oct 2005 05:03:20 -0700 Message-Id: <200510031203.j93C3KgU008270@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMP2P-0002pU-Cn bd1ca6f688041c24945a98902cef30c9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 30] incorrect XML in example X-Archived-At: http://www.w3.org/mid/200510031203.j93C3KgU008270@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9906 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:03:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=30 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:06:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMP5M-0001W3-1X for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:06:24 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23961 for ; Mon, 3 Oct 2005 08:06:22 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMP4V-0001q8-R4 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:05:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMP4S-0001pY-RS for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:05:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMP4L-0003RE-Ru for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:05:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93C5Kfn008300; Mon, 3 Oct 2005 05:05:20 -0700 Date: Mon, 3 Oct 2005 05:05:20 -0700 Message-Id: <200510031205.j93C5Kfn008300@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=-0.5 X-W3C-Scan-Sig: lisa.w3.org 1EMP4L-0003RE-Ru 6062933e723e182a680f79a930c3e5ed X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 32] DAV:displayname handling X-Archived-At: http://www.w3.org/mid/200510031205.j93C5Kfn008300@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9907 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:05:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=32 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:07:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMP6F-00023U-Vg for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:07:20 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24046 for ; Mon, 3 Oct 2005 08:07:18 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMP5a-0001zJ-BS for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:06:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMP5a-0001yf-23 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:06:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMP5Q-0003kN-I5 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:06:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93C6R1A008331; Mon, 3 Oct 2005 05:06:27 -0700 Date: Mon, 3 Oct 2005 05:06:27 -0700 Message-Id: <200510031206.j93C6R1A008331@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMP5Q-0003kN-I5 e8635e47cf0c96a8abddc2df817c2536 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/200510031206.j93C6R1A008331@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9908 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:06:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=51 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 05:06 ------- *** Bug 33 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 Mon Oct 03 08:08:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMP76-0002Tq-Vd for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:08:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24100 for ; Mon, 3 Oct 2005 08:08:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMP6O-00028h-3Q for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:07:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMP6M-000289-ED for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:07:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMP5Q-0005NT-T7 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:07:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93C6Rv2008321; Mon, 3 Oct 2005 05:06:27 -0700 Date: Mon, 3 Oct 2005 05:06:27 -0700 Message-Id: <200510031206.j93C6Rv2008321@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=-0.7 X-W3C-Scan-Sig: maggie.w3.org 1EMP5Q-0005NT-T7 bebb5e2ca6ee5557af19413de09b2d58 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 33] Terminology in properties section X-Archived-At: http://www.w3.org/mid/200510031206.j93C6Rv2008321@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9909 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:07:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=33 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 05:06 ------- *** This bug has been marked as a duplicate of 51 *** ------- 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 Oct 03 08: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 1EMPAV-0003OO-7Y for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:11:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24266 for ; Mon, 3 Oct 2005 08:11:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMP9j-0003B3-9v for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:10:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMP9i-0003AP-O5 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:10:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMP9W-0006It-1i for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:10:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CAe8D008384; Mon, 3 Oct 2005 05:10:40 -0700 Date: Mon, 3 Oct 2005 05:10:40 -0700 Message-Id: <200510031210.j93CAe8D008384@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMP9W-0006It-1i 1341647bbb50bf089313013fd45c0068 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 36] Appendix numbering X-Archived-At: http://www.w3.org/mid/200510031210.j93CAe8D008384@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9912 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:10:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=36 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:11:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMP9w-0003HN-LJ for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:11:08 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24240 for ; Mon, 3 Oct 2005 08:11:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMP98-00032V-WA for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:10:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMP98-00031x-K7 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:10:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMP95-00069o-BX for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:10:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CA4ri008365; Mon, 3 Oct 2005 05:10:04 -0700 Date: Mon, 3 Oct 2005 05:10:04 -0700 Message-Id: <200510031210.j93CA4ri008365@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMP95-00069o-BX b738326fde3d770144e36cf79473b8a5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 35] RFC2606 compliance X-Archived-At: http://www.w3.org/mid/200510031210.j93CA4ri008365@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9911 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:10:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=35 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:10:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMP8u-00035X-0F for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:10:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24171 for ; Mon, 3 Oct 2005 08:10:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMP8C-0002V3-G0 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:09:20 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMP8C-0002UT-4d for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:09:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMP84-0005xE-KA for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:09:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93C9941008347; Mon, 3 Oct 2005 05:09:09 -0700 Date: Mon, 3 Oct 2005 05:09:09 -0700 Message-Id: <200510031209.j93C9941008347@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMP84-0005xE-KA eab0c8cad693e4c1ab60a18c80bb0091 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 34] property "URI" X-Archived-At: http://www.w3.org/mid/200510031209.j93C9941008347@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9910 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:09:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=34 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:14:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPDP-0004Ch-G7 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:14:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24421 for ; Mon, 3 Oct 2005 08:14:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPCd-0003RF-E6 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:13:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPCd-0003Qh-1O for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:13:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMPCZ-0006wY-Fm for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:13:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CDn1S008404; Mon, 3 Oct 2005 05:13:49 -0700 Date: Mon, 3 Oct 2005 05:13:49 -0700 Message-Id: <200510031213.j93CDn1S008404@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMPCZ-0006wY-Fm acfd64df1a7a13a0547462835db1784c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200510031213.j93CDn1S008404@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9913 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:13:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:15:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPEN-0004KA-SW for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:15:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24453 for ; Mon, 3 Oct 2005 08:15:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPDn-0004qF-39 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:15:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPDm-0004od-MB for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:15:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPDj-0005nC-Rj for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:15:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CF23D008420; Mon, 3 Oct 2005 05:15:02 -0700 Date: Mon, 3 Oct 2005 05:15:02 -0700 Message-Id: <200510031215.j93CF23D008420@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=-1.5 X-W3C-Scan-Sig: lisa.w3.org 1EMPDj-0005nC-Rj bfc57246e18dc2431ec849a36a68e46c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 38] RFC2396bis update X-Archived-At: http://www.w3.org/mid/200510031215.j93CF23D008420@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9914 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:15:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=38 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |major Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 05:15 ------- RFC3986 has since been published. ------- 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 Oct 03 08:16:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPFF-0004RE-5k for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:16:37 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24497 for ; Mon, 3 Oct 2005 08:16:36 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPEa-0005Rg-N7 for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:15:56 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPEa-0005R6-5J for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:15:56 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMPEW-0007MO-Mu for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:15:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CFp7O008439; Mon, 3 Oct 2005 05:15:51 -0700 Date: Mon, 3 Oct 2005 05:15:51 -0700 Message-Id: <200510031215.j93CFp7O008439@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMPEW-0007MO-Mu 0f0b71434d05d4c0d82014f16d850a79 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/200510031215.j93CFp7O008439@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9915 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:15:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=39 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:19:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPHc-0004xK-DO for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:19:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24558 for ; Mon, 3 Oct 2005 08:19:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPGz-00066S-EA for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:18:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPGy-00065u-Vm for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:18:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPGv-0006fV-Be for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:18:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CIKeG008456; Mon, 3 Oct 2005 05:18:20 -0700 Date: Mon, 3 Oct 2005 05:18:20 -0700 Message-Id: <200510031218.j93CIKeG008456@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=-1.5 X-W3C-Scan-Sig: lisa.w3.org 1EMPGv-0006fV-Be 826a31ca1476b7a0c70a6011543d846f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 40] Definition of "null resource" gone X-Archived-At: http://www.w3.org/mid/200510031218.j93CIKeG008456@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9916 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:18:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=40 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-03 05:18 ------- (for instance ). ------- 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 Oct 03 08:21:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPJY-0005By-1t for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:21:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24602 for ; Mon, 3 Oct 2005 08:20:18 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPIB-0006GJ-Vp for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:19:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPIB-0006Fh-NV for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:19:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPI7-0006zG-Oh for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:19:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CJYEC008474; Mon, 3 Oct 2005 05:19:34 -0700 Date: Mon, 3 Oct 2005 05:19:34 -0700 Message-Id: <200510031219.j93CJYEC008474@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMPI7-0006zG-Oh a654dc524527bd0e2be196341bea1125 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/200510031219.j93CJYEC008474@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9917 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:19:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=41 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-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 Mon Oct 03 08:28:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPQJ-0006kf-Q3 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:28:03 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24957 for ; Mon, 3 Oct 2005 08:28:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPPa-0007up-8t for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:27:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPPa-0007uC-0N for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:27:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPPX-0000Rx-8u for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:27:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CREdg008502; Mon, 3 Oct 2005 05:27:14 -0700 Date: Mon, 3 Oct 2005 05:27:14 -0700 Message-Id: <200510031227.j93CREdg008502@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMPPX-0000Rx-8u 44066fdd06c3f71b010e6651b2ea3726 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 72] Review references section X-Archived-At: http://www.w3.org/mid/200510031227.j93CREdg008502@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9918 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:27:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=72 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 08: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 1EMPQv-0006pR-Vu for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:28:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24981 for ; Mon, 3 Oct 2005 08:28:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPQL-00083n-Pf for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:28:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPQL-00083F-Hf for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:28:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPQJ-0000fW-Iy for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:28:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CS3gF008516; Mon, 3 Oct 2005 05:28:03 -0700 Date: Mon, 3 Oct 2005 05:28:03 -0700 Message-Id: <200510031228.j93CS3gF008516@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMPQJ-0000fW-Iy cd11abb14f1284155bed7ec8e7ac75d6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200510031228.j93CS3gF008516@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9919 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:28:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 08: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 1EMPRm-0006ty-Ae for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:29:34 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25015 for ; Mon, 3 Oct 2005 08:29:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPR9-0008HQ-Fy for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:28:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPR9-0008Gs-6b for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:28:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPR6-0000tu-Jg for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:28:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CSqnp008540; Mon, 3 Oct 2005 05:28:52 -0700 Date: Mon, 3 Oct 2005 05:28:52 -0700 Message-Id: <200510031228.j93CSqnp008540@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=-1.1 X-W3C-Scan-Sig: lisa.w3.org 1EMPR6-0000tu-Jg ed8940b480f98840ab5660748265e40a 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/200510031228.j93CSqnp008540@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9921 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:28:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 08:29:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPRp-0006uH-9H for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:29:37 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25020 for ; Mon, 3 Oct 2005 08:29:36 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPR5-0008Gi-Ud for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:28:51 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPR5-0008GA-J7 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:28:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMPQz-0001vU-V8 for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:28:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CSgjc008528; Mon, 3 Oct 2005 05:28:42 -0700 Date: Mon, 3 Oct 2005 05:28:42 -0700 Message-Id: <200510031228.j93CSgjc008528@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMPQz-0001vU-V8 7af01ae7425d8225b3d1677079c6bb6f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 79] PUT for collections rationale X-Archived-At: http://www.w3.org/mid/200510031228.j93CSgjc008528@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9920 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:28:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=79 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 08:29:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPS2-0006v5-5j for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:29:50 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25049 for ; Mon, 3 Oct 2005 08:29:49 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPRQ-0008RZ-9c for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:29:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPRP-0008Qw-Tw for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:29:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMPRH-00020w-1I for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:29:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CT2JW008552; Mon, 3 Oct 2005 05:29:02 -0700 Date: Mon, 3 Oct 2005 05:29:02 -0700 Message-Id: <200510031229.j93CT2JW008552@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=-1.1 X-W3C-Scan-Sig: maggie.w3.org 1EMPRH-00020w-1I b1eb313880af929909c703a719924622 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/200510031229.j93CT2JW008552@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9922 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:29:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-06 |-07 ------- 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 Oct 03 08:41:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPcv-0000Nn-GC for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:41:05 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25661 for ; Mon, 3 Oct 2005 08:41:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPbr-0005Bx-7x for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:39:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPbq-0005BP-E5 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:39:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMPbj-0004Ro-Lm for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:39:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CdjRJ008613; Mon, 3 Oct 2005 05:39:45 -0700 Date: Mon, 3 Oct 2005 05:39:45 -0700 Message-Id: <200510031239.j93CdjRJ008613@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=-1.8 X-W3C-Scan-Sig: maggie.w3.org 1EMPbj-0004Ro-Lm 52c454b7da0d8c7f1ecc6e72c62001c0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 88] New: typo in list X-Archived-At: http://www.w3.org/mid/200510031239.j93CdjRJ008613@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9923 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:39:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=88 Summary: typo in list Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.11.5 OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Typo: "h 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." ------- 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 Oct 03 08:43:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPfO-0000zV-H3 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:43:41 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26007 for ; Mon, 3 Oct 2005 08:43:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPek-00061I-Ai for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:42:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPek-00060f-1T for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:42:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPeA-0004sg-JT for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:42:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CgMRM008632; Mon, 3 Oct 2005 05:42:22 -0700 Date: Mon, 3 Oct 2005 05:42:22 -0700 Message-Id: <200510031242.j93CgMRM008632@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=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1EMPeA-0004sg-JT aaf0aa4b562313287a66f167ef96aa82 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 89] New: whitespace introduced into hyphenated words X-Archived-At: http://www.w3.org/mid/200510031242.j93CgMRM008632@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9924 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:42:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=89 Summary: whitespace introduced into hyphenated words Product: WebDAV-RFC2518-bis Version: -07 Platform: Other 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 There seem to be places in the XML source where whitespace was introduced inside hyphenated terms, such as in "Coded- URLs". ------- 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 Oct 03 08:44:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPfn-00011w-63 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:44:03 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26033 for ; Mon, 3 Oct 2005 08:44:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPfC-0006BI-Qj for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:43:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPcH-0005dy-36 for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:40:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPal-0003k7-9C for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:40:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93Ccn6J008595; Mon, 3 Oct 2005 05:38:49 -0700 Date: Mon, 3 Oct 2005 05:38:49 -0700 Message-Id: <200510031238.j93Ccn6J008595@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=-1.8 X-W3C-Scan-Sig: lisa.w3.org 1EMPal-0003k7-9C 1eb6a2686c15fd7915ce61b453078f56 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 87] New: broken XML source of spec X-Archived-At: http://www.w3.org/mid/200510031238.j93Ccn6J008595@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9925 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:43:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=87 Summary: broken XML source of spec Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 4 OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Broken XML source (invalid list style "symbol") ------- 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 Oct 03 08:46:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPhl-0001lJ-37 for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:46:06 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26174 for ; Mon, 3 Oct 2005 08:46:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMPh1-0007rU-QW for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 12:45:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMPh1-0007pP-8F for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 12:45:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMPgy-00062B-Ae for w3c-dist-auth@w3.org; Mon, 03 Oct 2005 12:45:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j93CjAc7008650; Mon, 3 Oct 2005 05:45:10 -0700 Date: Mon, 3 Oct 2005 05:45:10 -0700 Message-Id: <200510031245.j93CjAc7008650@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=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1EMPgy-00062B-Ae cb3f1a41428566bafae03b098ee6c382 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 90] New: broken RFC2277 reference X-Archived-At: http://www.w3.org/mid/200510031245.j93CjAc7008650@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9926 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 12:45:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=90 Summary: broken RFC2277 reference Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.18 OS/Version: other Status: NEW Severity: minor Priority: P2 Component: 18. Internationalization Considerations AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Broken reference to RFC2277 () "RFC2277". ------- 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 Oct 03 11:34:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSL9-00080Z-JN for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 11:34:57 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12999 for ; Mon, 3 Oct 2005 11:34:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMSJo-0001CC-LA for w3c-dist-auth-dist@listhub.w3.org; Mon, 03 Oct 2005 15:33:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMSJo-0001Be-2D for w3c-dist-auth@listhub.w3.org; Mon, 03 Oct 2005 15:33:32 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EMSIZ-0005Y5-Mv for w3c-dist-auth@w3c.org; Mon, 03 Oct 2005 15:33:31 +0000 Received: (qmail invoked by alias); 03 Oct 2005 15:32:10 -0000 Received: from p508FAEE9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.174.233] by mail.gmx.net (mp030) with SMTP; 03 Oct 2005 17:32:10 +0200 X-Authenticated: #1915285 Message-ID: <43414ED0.8070608@gmx.de> Date: Mon, 03 Oct 2005 17:31:28 +0200 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-15; format=flowed 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 1EMSIZ-0005Y5-Mv c604e7d4491c65cb6140c874902b6a73 X-Original-To: w3c-dist-auth@w3.org Subject: Re: New draft of RFC2518bis X-Archived-At: http://www.w3.org/mid/43414ED0.8070608@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9927 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 03 Oct 2005 15:33:32 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA12999 OK. I just went through my existing issues list, and reviewed the diffs to=20 the previous drafts: - none of the issues that I have reported for draft 06 (and earlier=20 drafts) have been addressed (I have updated BugZilla accordingly) - draft 07 contains lots of changes that do not seem to be related to=20 any open issue, nor have been discussed over here If we want to make RFC2518bis a success, changing the spec without=20 notice and prior discussion really should be avoided. That being said, here are the new issues that I found (most but not all=20 related to changes between 06 and 07). As soon as we agree on a single=20 issue tracking, I'll resubmit them in whatever format needed. Best regards, Julian -- 07-E01, Section 8.11 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D87 Broken XML source (invalid list style) Draft: 07-E02, Section 8.11.5 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D88 Typo: "h 400 (Bad Request), with 'request-uri-must-match-lock-token'=20 precondition - The LOCK request was made with a Lock-Token header,=20 indicating that the client wishes to refresh the given lock. However,=20 the Request-URI did not fall within the scope of the lock identified by=20 the token. The lock may have a scope that does not include the=20 Request-URI, or the lock could have disappeared, or the token may be=20 invalid." Draft: 07-E04, hyphenated words http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D89 There seem to be places in the XML source where whitespace was=20 introduced inside hyphenated terms, such as in "Coded- URLs". 07-E05, RFC2277 ref is broken http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D90 Broken reference to RFC2277=20 () "RFC2277". 07-E06, lock tokens in examples 8.11.6: "Note that the locktoken and lockroot href elements would not contain=20 any whitespace. The line return appearing in this document is only for=20 formatting." I'd prefer to have the XML examples be valid. Such as: opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 Draft:=20 07-E07, 8.7 DELETE vs LOCKs The first sentence of the description of DELETE now says: "Locks rooted on a resource MUST be destroyed in a successful DELETE of=20 that resource." This is correct, but it's certainly not the right way to start the=20 description of DELETE. 07-E08, 8.9 COPY Newly states: "The state of the resource to be copied is fixed at the point the server=20 begins processing the COPY request." Why this change, and what problem does it solve? Draft:=20 07-E09, 8.9.3 COPY for Collection Resources Now says: "A COPY of depth infinity instructs that the collection resource=20 identified by the Request-URI is to be copied to the location identified=20 by the URI in the Destination header, and all its internal member=20 resources are to be copied to a location relative to it, recursively=20 through all levels of the collection hierarchy. Servers should of course=20 avoid infinite recursion, and can do so by copying the source resource=20 as it existed at the point where processing started." The last sentence was added. I'm not sure why. Of course servers never=20 should run in an infinite loop, but that applies to all Depth-related=20 operations. I'm not sure why it's stated here, and furthermore I don't=20 understand what the suggested workaround is. Draft:=20 07-E10, 8.9.4, COPY and the Overwrite Header Interoperability testing has shown that some clients expect a=09 collection COPY to actually do a merge if a destination collection=09 exists. That behavior is appropriate for file system folders but not=09 necessarily for other data objects modelled as collections. Thus,=09 implementors are urged to comply with the standard language above,=09 and leave clients to perform a manual merge if that's the expected=09 behavior when copying a collection over another collection. May be a useful remark, but I think it should either clearly marked as a=20 comment, or moved into an appendix (away from normative text) Draft:=20 07-E11, 10.1 102 Processing I note that =EEn draft 05, the "status-uri" response header was removed=20 (see ),=20 but the "102 Processing" status was left in. Either we have implementations and interoperability - then we need both=20 - or we should remove both. Draft:=20 =20 From w3c-dist-auth-request@frink.w3.org Mon Oct 03 21:37:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMbke-0001Tv-Sy for webdav-archive@megatron.ietf.org; Mon, 03 Oct 2005 21:37:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03468 for ; Mon, 3 Oct 2005 21:37:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMbiP-0000nZ-Qr for w3c-dist-auth-dist@listhub.w3.org; Tue, 04 Oct 2005 01:35:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMbiO-0000mw-ST for w3c-dist-auth@listhub.w3.org; Tue, 04 Oct 2005 01:35:32 +0000 Received: from agminet01.oracle.com ([141.146.126.228]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMbi9-0002uU-Fs for w3c-dist-auth@w3.org; Tue, 04 Oct 2005 01:35:32 +0000 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j941cm4v032161; Mon, 3 Oct 2005 20:38:49 -0500 Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j941ZDVN009483; Mon, 3 Oct 2005 19:35:13 -0600 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw5-141-144-104-205.vpn.oracle.com [141.144.104.205]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j941ZAi1009418; Mon, 3 Oct 2005 19:35:12 -0600 Message-ID: <4341DC51.4050401@oracle.com> Date: Mon, 03 Oct 2005 21:35:13 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList CC: Calsify WG , WebDAV WG , Lisa Dusseault , Cyrus Daboo Content-Type: multipart/mixed; boundary="------------030201060504080201040300" X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Received-SPF: none (lisa.w3.org: 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: lisa.w3.org 1EMbi9-0002uU-Fs 39a6a4e3efa45272216ea9426d4e2f95 X-Original-To: w3c-dist-auth@w3.org Subject: [Fwd: I-D ACTION:draft-dusseault-caldav-08.txt] X-Archived-At: http://www.w3.org/mid/4341DC51.4050401@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9928 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 04 Oct 2005 01:35:33 +0000 This is a multi-part message in MIME format. --------------030201060504080201040300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit We submitted CalDAV draft -08 to the IETF last Friday. It is now available at the following URL: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-08.txt We are planning to submit a new revision in a few weeks for an informal Last-Call on the ietf-caldav, ietf-calsify and w3c-dist-auth (WebDAV) mailing lists before we actually submit it to the IESG. Please review the draft and send us feedback/questions/comments. Thanks, Bernard B.1. Changes in -08 a. Removed statement that said that client SHOULD always request DAV:getetag in calendar REPORTs. b. Removed redefiniton of DAV:response. c. Removed XML elements CALDAV:calendar-data-only. d. Removed resource type CALDAV:calendar-home. e. Moved the CALDAV:calendar-data element in the DAV:prop element in requests, and in the DAV:propstat element in responses. f. Further defined the request body of MKCALENDAR to allow clients to set properties at calendar collection creation time. g. Renamed CALDAV:calendar-home-URL to CALDAV:calendar-home-set h. Clarified the fact that calendar collections may only contain calendar object resources and ordinary collections. i. Clarified that calendar REPORTs should only be applied to calendar object resources contained in calendar collections. j. Changed the CALDAV:calendar-component-restriction-set and CALDAV: calendar-restriction properties to always be protected. k. Changed to use existing postcondition DAV:needs-privileges instead of a new CALDAV:insufficient-privilege postcondition. l. Added example for limit-recurrence-set. m. Added example for expand-recurrence-set. n. Moved CALDAV:calendar-address-set in the calendar-schedule draft and renamed it to CALDAV:calendar-user-address-set. o. Added guidelines on attachments and alarms. -------- Original Message -------- Subject: I-D ACTION:draft-dusseault-caldav-08.txt Date: Mon, 03 Oct 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Calendaring Extensions to WebDAV (CalDAV) Author(s) : L. Dusseault, et al. Filename : draft-dusseault-caldav-08.txt Pages : 75 Date : 2005-10-3 This document specifies a set of methods, headers, message bodies, properties, and reports that define calendar access extensions to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring and scheduling an interoperable standard that supports calendar access, calendar management, calendar sharing, and calendar publishing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-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-dusseault-caldav-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-dusseault-caldav-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. --------------030201060504080201040300 Content-Type: Message/External-body; name="draft-dusseault-caldav-08.txt" Content-Disposition: inline; filename="draft-dusseault-caldav-08.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-3121841.I-D@ietf.org> nt-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------030201060504080201040300-- From w3c-dist-auth-request@frink.w3.org Tue Oct 04 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 1EMqfr-0004ER-L0 for webdav-archive@megatron.ietf.org; Tue, 04 Oct 2005 13:33:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12499 for ; Tue, 4 Oct 2005 13:33:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMqdG-0000li-O5 for w3c-dist-auth-dist@listhub.w3.org; Tue, 04 Oct 2005 17:31:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMqdF-0000lA-UG for w3c-dist-auth@listhub.w3.org; Tue, 04 Oct 2005 17:31:13 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMqdC-00007M-9r for w3c-dist-auth@w3.org; Tue, 04 Oct 2005 17:31:13 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 Oct 2005 10:31:09 -0700 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 j94HV7uk007212 for ; Tue, 4 Oct 2005 10:31:07 -0700 (PDT) Received: from 10.21.113.215 ([10.21.113.215]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Oct 2005 17:31:10 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Tue, 04 Oct 2005 10:31:08 -0700 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Plan to resolve issues in 2518bis Thread-Index: AcXJCWeaplRydjT8EdqkrQARJEEJ/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.68.10.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.1 X-W3C-Scan-Sig: lisa.w3.org 1EMqdC-00007M-9r 390bdea3badf2924a0ca0dee691db588 X-Original-To: w3c-dist-auth@w3.org Subject: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/BF680A6C.532D6%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9929 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 04 Oct 2005 17:31:14 +0000 Content-Transfer-Encoding: 7bit I had a phone call with Elias, Julian, Geoffrey, Lisa, and Jim today to see what we could all do to get things moving on 2518bis. Elias kindly volunteered to collect all the know issues and put them in bugzilla. He is going to tell us how he will mark in bugzilla two different states. One state is when the WG agrees on general way to resolved the issue but has not updated drafts yet or figured out exact text, and other state is when the actual text has been put into the draft. If people can send text to the list proposing the text they want put into 2518bis-07 to fix a given issue that would be great. We are then going to have some conference calls to run through all the issues - we know some will be easy and some will be hard. Initially we are going to try and knock of the easy one quickly and figure out which ones are hard and start an email thread on the list for the hard ones. If we come up with a proposed text on the call, it will still be approved on the list. The calls will help set a regular event to move the draft forward and will also help us quickly figure out where we all agree and disagree. Hard issues that need discussion will still be discussed on the list. Julian is going to start a thread on one hard issue some time soon. In general we are going to try and have the conference calls every Wednesday at 10 AM pacific time. For next week, we need to have it at 10 am Thursday (not Wednesday). These times seems as good as any but if there is huge list feedback that we need to pick a different time, I will move them. Thank you Julian for staying up late for us west coast guys. I will send out conference bridge information for these calls. Elias will send out a list of the bugs we hope to cover in a given meeting. Cullen From w3c-dist-auth-request@frink.w3.org Tue Oct 04 14: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 1EMrFZ-0000sE-Lp for webdav-archive@megatron.ietf.org; Tue, 04 Oct 2005 14:10:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14563 for ; Tue, 4 Oct 2005 14:10:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMrEe-0000J3-A9 for w3c-dist-auth-dist@listhub.w3.org; Tue, 04 Oct 2005 18:09:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EMrEd-0000IC-Lb for w3c-dist-auth@listhub.w3.org; Tue, 04 Oct 2005 18:09:51 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lisa.w3.org with esmtp (Exim 4.50) id 1EMrES-0000Ju-Ct for w3c-dist-auth@w3.org; Tue, 04 Oct 2005 18:09:51 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 Oct 2005 11:09:39 -0700 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 j94I9Zuk020544 for ; Tue, 4 Oct 2005 11:09:38 -0700 (PDT) Received: from 10.21.113.215 ([10.21.113.215]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Oct 2005 18:09:39 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Tue, 04 Oct 2005 11:09:37 -0700 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Conf call next Wednesday Thread-Index: AcXJCuY46IWaDS0vRvmHw7/fJBgtnAAA+Grx In-Reply-To: <941DA488B5230344A21F26008BEC0F7901D32411@mail1> 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.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1EMrES-0000Ju-Ct 38fe60407f10d9b07e197c7391ed1503 X-Original-To: w3c-dist-auth@w3.org Subject: Conf call next Wednesday X-Archived-At: http://www.w3.org/mid/BF681371.53300%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9930 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 04 Oct 2005 18:09:52 +0000 Content-Transfer-Encoding: 7bit The goal of the call is to do triage on the 2518bis-07 issues. If you plan to join the conference call next Thursday, please drop me an email so I make sure there are enough ports reserved. Date/Time: October 13, 2005 at 10:00 AM America/Los_Angeles Length: 60 minutes Frequency: once Meeting ID: 251807 Description: 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 Tue Oct 04 14:10:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrFd-0000sc-Vn for webdav-archive@megatron.ietf.org; Tue, 04 Oct 2005 14:10:54 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14565 for ; Tue, 4 Oct 2005 14:10:52 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMrF5-0000o6-6E for w3c-dist-auth-dist@listhub.w3.org; Tue, 04 Oct 2005 18:10:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMrF4-0000m3-Hb for w3c-dist-auth@listhub.w3.org; Tue, 04 Oct 2005 18:10:18 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EMrEz-0000fZ-Vm for w3c-dist-auth@w3.org; Tue, 04 Oct 2005 18:10:17 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2005 11:09:41 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="216955053:sNHT45549425996" 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 j94I9Zum020544 for ; Tue, 4 Oct 2005 11:09:39 -0700 (PDT) Received: from 10.21.113.215 ([10.21.113.215]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Oct 2005 18:09:41 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Tue, 04 Oct 2005 11:09:40 -0700 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Recurring Thursday Conf call Thread-Index: AcXJC34rF6I9S2UJTymzigwLAEk2aAAA0t+M In-Reply-To: <941DA488B5230344A21F26008BEC0F7901D32413@mail1> 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.8 X-W3C-Scan-Sig: maggie.w3.org 1EMrEz-0000fZ-Vm 9d5ce9f9d67737835a2ee1cdbfb7f490 X-Original-To: w3c-dist-auth@w3.org Subject: Recurring Thursday Conf call X-Archived-At: http://www.w3.org/mid/BF681374.53300%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9931 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 04 Oct 2005 18:10:19 +0000 Content-Transfer-Encoding: 7bit I have scheduled a weekly conference call to help get 2519bis done. It is primarily for people contributing text to that but anyone is welcome. The goal of the call is to do triage and resolve 2518bis-07 issues. If you plan to regularly join the conference call next, please drop me an email so I make sure there are enough ports reserved. Note the first call is Oct 19, then weekly after that. Date/Time: October 19, 2005 at 10:00 AM America/Los_Angeles Length: 60 minutes Frequency: This meeting is scheduled to occur every Wednesday for 10 weeks. Meeting ID: 251807 Meeting Password: Description: 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 Tue Oct 04 14:19:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrNe-0004Pi-7T for webdav-archive@megatron.ietf.org; Tue, 04 Oct 2005 14:19:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15307 for ; Tue, 4 Oct 2005 14:19:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EMrMy-0003Ev-9V for w3c-dist-auth-dist@listhub.w3.org; Tue, 04 Oct 2005 18:18:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EMrMx-0003EI-Th for w3c-dist-auth@listhub.w3.org; Tue, 04 Oct 2005 18:18:28 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EMrMm-0002VG-Lu for w3c-dist-auth@w3.org; Tue, 04 Oct 2005 18:18:27 +0000 Received: (qmail invoked by alias); 04 Oct 2005 18:18:13 -0000 Received: from pd95b7d02.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.125.2] by mail.gmx.net (mp023) with SMTP; 04 Oct 2005 20:18:13 +0200 X-Authenticated: #1915285 Message-ID: <4342C764.6090204@gmx.de> Date: Tue, 04 Oct 2005 20:18:12 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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 (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.4 X-W3C-Scan-Sig: maggie.w3.org 1EMrMm-0002VG-Lu ec3b97d6c9f295e1208bd4cee5934c4e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/4342C764.6090204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9932 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 04 Oct 2005 18:18:28 +0000 Content-Transfer-Encoding: 7bit Thanks, Cullen. For those who can use ics-over-http (such as with iCal or Mozilla Calendar), here's a calendar file: Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 05 09:07:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN8zk-0001ko-Fk for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 09:07:40 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21856 for ; Wed, 5 Oct 2005 09:07:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EN8wr-0000aX-GN for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 13:04:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EN8wq-0000Zy-Oj for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 13:04:40 +0000 Received: from web25101.mail.ukl.yahoo.com ([217.12.10.49]) by lisa.w3.org with smtp (Exim 4.50) id 1EN8wo-0005sp-1a for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 13:04:40 +0000 Received: (qmail 97027 invoked by uid 60001); 5 Oct 2005 13:04:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i79i24eZN3zlDQmOZrBvKVKxT473B7RWeRn7Q8Tn8kPndGrDH/dW+S3rmKRad3dlXwBIalA4yLWfpBPE8bxLyiZt8h3RLyZ7V14fRm4AwVdCyX30iydZpElkM7n/YPL35D/3om9P8RKgPselRUBjmmLsFsYF+LRMvIKtNCpWmU0= ; Message-ID: <20051005130436.97025.qmail@web25101.mail.ukl.yahoo.com> Received: from [134.83.1.225] by web25101.mail.ukl.yahoo.com via HTTP; Wed, 05 Oct 2005 14:04:36 BST Date: Wed, 5 Oct 2005 14:04:36 +0100 (BST) From: david muller To: w3c-dist-auth@w3.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received-SPF: none (lisa.w3.org: domain of david_muller_8888@yahoo.co.uk does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: lisa.w3.org 1EN8wo-0005sp-1a 1c5fccc276994cd0e00c9ee9f29ccd5b X-Original-To: w3c-dist-auth@w3.org Subject: ideas for research on wbedav required X-Archived-At: http://www.w3.org/mid/20051005130436.97025.qmail@web25101.mail.ukl.yahoo.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9933 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 13:04:41 +0000 Content-Transfer-Encoding: 8bit hi all, I am new to this group. Can some help me with some ideas for research on wbedav. David. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From w3c-dist-auth-request@frink.w3.org Wed Oct 05 13:02:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENCeh-0003kS-Et for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 13:02:11 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05024 for ; Wed, 5 Oct 2005 13:02:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENCck-0000mx-UG for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 17:00:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENCck-0000ke-21 for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 17:00:10 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1ENCcc-0007HZ-O1 for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 17:00:07 +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 j95GxvLl027135 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Oct 2005 09:59:57 -0700 (PDT) In-Reply-To: <20051005130436.97025.qmail@web25101.mail.ukl.yahoo.com> References: <20051005130436.97025.qmail@web25101.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-1--99459953 Message-Id: Cc: w3c-dist-auth@w3.org From: Jim Whitehead Date: Wed, 5 Oct 2005 09:59:55 -0700 To: david muller X-Mailer: Apple Mail (2.734) 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=-1.6 X-W3C-Scan-Sig: maggie.w3.org 1ENCcc-0007HZ-O1 4b8200839d067b9ae97e7685af527d30 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ideas for research on wbedav required X-Archived-At: http://www.w3.org/mid/F4E14A6F-6059-4854-868B-58BE313F498B@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9934 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 17:00:10 +0000 --Apple-Mail-1--99459953 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Yes. What did you have in mind? - Jim On Oct 5, 2005, at 6:04 AM, david muller wrote: > > hi all, > > I am new to this group. > > Can some help me with some ideas for research on > wbedav. > > > David. --Apple-Mail-1--99459953 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Yes.

What did you have in = mind?

- = Jim

On Oct 5, 2005, at 6:04 AM, david muller = wrote:


hi all,

I am new to this = group.

Can some help me with some ideas for research = on
wbedav.


David.

= --Apple-Mail-1--99459953-- From w3c-dist-auth-request@frink.w3.org Wed Oct 05 14: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 1ENEFd-0005q8-Ek for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 14:44:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09343 for ; Wed, 5 Oct 2005 14:44:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENEDv-0003E8-Jb for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 18:42:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENEDu-0003DX-Ox for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 18:42: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 1ENEDo-0004gz-NN for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 18:42:38 +0000 Received: (qmail invoked by alias); 05 Oct 2005 18:42:30 -0000 Received: from p508FAFE3.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.175.227] by mail.gmx.net (mp007) with SMTP; 05 Oct 2005 20:42:30 +0200 X-Authenticated: #1915285 Message-ID: <43441E92.8070504@gmx.de> Date: Wed, 05 Oct 2005 20:42:26 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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 1ENEDo-0004gz-NN 073f503c826d7b71f2a1ffcc3e735478 X-Original-To: w3c-dist-auth@w3.org Subject: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/43441E92.8070504@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9935 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 18:42:39 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA09343 Cullen Jennings wrote: > ... > Julian is going to start a thread on one hard issue some time soon. > ... OK, here we go. I'd like to discuss the following issue...: which reads..: -- start -- 4.5: =93The value of a property appears inside the property name element. The value may be any text, including valid XML. When the value is structured as 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.=94 1) I think this needs to rephrased to use proper XML terminology, also 2) I think that namespace prefixes within the property value do need to be roundtripped. Proposal: =93The value of a property appears inside the property name element and 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 and namespace prefixes 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.=94 Update draft -05/06: Issue 2 still needs to be resolved, the current text says: "Namespace prefixes need not be preserved due to the rules of prefix declaration in XML. This is incorrect because namespace prefixes *are* significant for certain XML vocabularies, such as XSLT and XML Schema. So independantly of what we decide for WebDAV, we should add an accurate statement about what that means for arbitrary XML content in properties. (Now in 4.4 ()) -- end -- Proposed solutions: (i) stick with the stated behaviour, but fix the explanation that=20 misleadingly states that namespace prefixes are irrelevant, or (ii) state that namespace prefixes need to be preserved (such as in the=20 text proposed by myself). Further thought: depending on what standards status we aim for, we=20 either need to think about what the protocol *should* be doing, or what=20 current implementations actually do today. As far as I can tell, IIS=20 doesn't preserve mixed content at all, while Apache/mod_dav does that=20 (however it doesn't preserve prefixes; but maybe this can easily be=20 fixed). I know that SAP Netweaver is preserving prefixes, and I=20 *suspect* that Xythos does this as well (to be tested). Feedback appreciated, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 05 15:19:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENEnR-0008B2-Dl for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 15:19:21 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12259 for ; Wed, 5 Oct 2005 15:19:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENEm0-0002IG-Vx for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 19:17:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENEm0-0002Hh-19 for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 19:17:52 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1ENElr-0002sL-11 for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 19:17:51 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2005 12:17:41 -0700 X-IronPort-AV: i="3.97,178,1125903600"; d="scan'208"; a="217290010:sNHT26560128" 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 j95JHUVv017809; Wed, 5 Oct 2005 12:17:32 -0700 (PDT) Received: from 10.21.120.59 ([10.21.120.59]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Oct 2005 19:17:41 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Wed, 05 Oct 2005 12:17:38 -0700 From: Cullen Jennings To: Julian Reschke CC: WebDav Message-ID: Thread-Topic: Bugzilla issue 10, was: Plan to resolve issues in 2518bis Thread-Index: AcXJ4XLAsU5KjjXUEdqL1QARJEEJ/A== In-Reply-To: <43441E92.8070504@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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.0 X-W3C-Scan-Sig: maggie.w3.org 1ENElr-0002sL-11 bbbee585a205c37efa98be98a1ee3e10 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/BF6974E2.54079%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9936 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 19:17:52 +0000 Content-Transfer-Encoding: quoted-printable I'm not sure I understand what you mean by namespace preservation. Take the example portion of some XML: Book Review XML: A Primer Is it the "http://www.xml.com/books" that gets preserved or the "xdc". What I'm trying to ask is if would be OK if the above XML got transformed to Book Review XML: A Primer I suspect you are saying this is not OK and the namespace prefix (ie the xdc) needs to be preserved and not changed to foo-xdc. If this is what you mean, then I am not sure what you mean by this is important for XSLT and XM= L Schema, can you provide a bit more of an example. Thanks for educating me on this - I'm not really going to end up with much of an opinion on any of this but I am making sure I know enough to at least understand the argument. Also, I suspect I might not be the only one of the list that does not understand as much about XML as I wish I did :-) Cullen On 10/5/05 11:42 AM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> ... >> Julian is going to start a thread on one hard issue some time soon. >> ... >=20 >=20 > OK, here we go. I'd like to discuss the following issue...: >=20 > >=20 > which reads..: >=20 > -- start -- >=20 > 4.5: =B3The value of a property appears inside the property name element. > The value may be any text, including valid XML. When the value is > structured as 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.=B2 >=20 > 1) I think this needs to rephrased to use proper XML terminology, also > 2) I think that namespace prefixes within the property value do need to > be roundtripped. >=20 > Proposal: >=20 > =B3The value of a property appears inside the property name element and > 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 and namespace prefixes 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.=B2 >=20 > Update draft -05/06: >=20 > Issue 2 still needs to be resolved, the current text says: "Namespace > prefixes need not be preserved due to the rules of prefix declaration in > XML. This is incorrect because namespace prefixes *are* significant for > certain XML vocabularies, such as XSLT and XML Schema. So independantly > of what we decide for WebDAV, we should add an accurate statement about > what that means for arbitrary XML content in properties. >=20 >=20 > (Now in 4.4 > ( ction.4.4.p.5>)) >=20 > -- end -- >=20 > Proposed solutions: >=20 > (i) stick with the stated behaviour, but fix the explanation that > misleadingly states that namespace prefixes are irrelevant, >=20 > or >=20 > (ii) state that namespace prefixes need to be preserved (such as in the > text proposed by myself). >=20 > Further thought: depending on what standards status we aim for, we > either need to think about what the protocol *should* be doing, or what > current implementations actually do today. As far as I can tell, IIS > doesn't preserve mixed content at all, while Apache/mod_dav does that > (however it doesn't preserve prefixes; but maybe this can easily be > fixed). I know that SAP Netweaver is preserving prefixes, and I > *suspect* that Xythos does this as well (to be tested). >=20 > Feedback appreciated, >=20 > Julian >=20 >=20 >=20 >=20 >=20 >=20 From w3c-dist-auth-request@frink.w3.org Wed Oct 05 15:43:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFB2-0001jA-22 for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 15:43:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13425 for ; Wed, 5 Oct 2005 15:43:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENF9o-0008U4-6V for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 19:42:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENF9n-0008TW-Dw for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 19:42:27 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ENF6I-00033W-Ej for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 19:42:27 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 06D8B1422AA; Wed, 5 Oct 2005 12:38:49 -0700 (PDT) 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 32749-10; Wed, 5 Oct 2005 12:38:48 -0700 (PDT) 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 DA8881422A4; Wed, 5 Oct 2005 12:38:47 -0700 (PDT) In-Reply-To: <43441E92.8070504@gmx.de> References: <43441E92.8070504@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <8cca60fc101d781c975da35774ac02fa@osafoundation.org> Content-Transfer-Encoding: quoted-printable Cc: WebDav , Cullen Jennings From: Lisa Dusseault Date: Wed, 5 Oct 2005 12:38:44 -0700 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 1ENF6I-00033W-Ej 2a67a14c70719a930f0dca7eefe08457 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/8cca60fc101d781c975da35774ac02fa@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9937 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 19:42:28 +0000 Content-Transfer-Encoding: quoted-printable IMPLEMENTORS -- can we get some sense of what existing server =20 implementations do to preserve prefixes/namespaces in property values? =20= If I recall correctly, Xythos WFS preserves the namespaces but =20 generates its own prefixes, and will frequently declare prefixes in =20 another place. so if a PROPPATCH contains text in =20= here a subsequent PROPFIND might return text in here Lisa On Oct 5, 2005, at 11:42 AM, Julian Reschke wrote: > > OK, here we go. I'd like to discuss the following issue...: > > > > which reads..: > > -- start -- > > 4.5: =93The value of a property appears inside the property name = element. > The value may be any text, including valid XML. When the value is > structured as 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 =20 > prefixes > need not be preserved due to the rules of prefix declaration in XML.=94 > > 1) I think this needs to rephrased to use proper XML terminology, also > 2) I think that namespace prefixes within the property value do need = to > be roundtripped. > > Proposal: > > =93The value of a property appears inside the property name element = and > may be any kind of well-formed XML content, including both text-only =20= > and > mixed content. When the property value contains further XML elements, > namespaces and namespace prefixes that are in scope for that part of =20= > the > XML document apply within the property value as well, and MUST be > preserved in server storage for retransmission later.=94 > > Update draft -05/06: > > Issue 2 still needs to be resolved, the current text says: "Namespace > prefixes need not be preserved due to the rules of prefix declaration =20= > in > XML. This is incorrect because namespace prefixes *are* significant = for > certain XML vocabularies, such as XSLT and XML Schema. So = independantly > of what we decide for WebDAV, we should add an accurate statement = about > what that means for arbitrary XML content in properties. > > > (Now in 4.4 > ( -07.html#rfc.section.4.4.p.5>)) > > -- end -- > > Proposed solutions: > > (i) stick with the stated behaviour, but fix the explanation that =20 > misleadingly states that namespace prefixes are irrelevant, > > or > > (ii) state that namespace prefixes need to be preserved (such as in =20= > the text proposed by myself). > > Further thought: depending on what standards status we aim for, we =20 > either need to think about what the protocol *should* be doing, or =20 > what current implementations actually do today. As far as I can tell, =20= > IIS doesn't preserve mixed content at all, while Apache/mod_dav does =20= > that (however it doesn't preserve prefixes; but maybe this can easily =20= > be fixed). I know that SAP Netweaver is preserving prefixes, and I =20 > *suspect* that Xythos does this as well (to be tested). > > Feedback appreciated, > > Julian > > > > > > > > > > From w3c-dist-auth-request@frink.w3.org Wed Oct 05 15:58:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFPN-0007hd-Pc for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 15:58:34 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14034 for ; Wed, 5 Oct 2005 15:58:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENFNo-0003SQ-1H for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 19:56:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENFNn-0003Rm-GL for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 19:56:55 +0000 Received: from web25108.mail.ukl.yahoo.com ([217.12.10.56]) by lisa.w3.org with smtp (Exim 4.50) id 1ENFNE-0007Wh-MP for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 19:56:55 +0000 Received: (qmail 27468 invoked by uid 60001); 5 Oct 2005 19:56:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GGvRiru66cWlFuKCFoBcQcEGd19t2NZmkGo51Fmu2T6wlSi73DBncWfefOSKaR/I0aiQtu7vBm7Z221RRUQEiJ75iTMrDk4EBnHaIoWG9lBXLTfDajyxT80TFdEmToCX+TEh4lavQ5EeY/wq2q7XYPxJApJV3K8mFyaASNMxZJA= ; Message-ID: <20051005195619.27466.qmail@web25108.mail.ukl.yahoo.com> Received: from [134.83.1.225] by web25108.mail.ukl.yahoo.com via HTTP; Wed, 05 Oct 2005 20:56:18 BST Date: Wed, 5 Oct 2005 20:56:18 +0100 (BST) From: david muller To: Jim Whitehead Cc: w3c-dist-auth@w3.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1011044054-1128542178=:27240" Content-Transfer-Encoding: 8bit Received-SPF: none (lisa.w3.org: domain of david_muller_8888@yahoo.co.uk does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1ENFNE-0007Wh-MP a73bb6148e7948e7deb438d85c946114 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ideas for research on wbedav required X-Archived-At: http://www.w3.org/mid/20051005195619.27466.qmail@web25108.mail.ukl.yahoo.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9938 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 19:56:56 +0000 --0-1011044054-1128542178=:27240 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi, what I have in mind is this. I want to basically research upon some idea which exploits the advantages of webdav protocol over HTTP1.1 to the advantage of some existing problem or for efficiency. Like say some idea which makes use of the extra methods provided by webdav namely ( e.g profind, propatch, copy, move, delete, lock, unlock) and then aims to solve some existing problem in the computer world today or intends to make some existing process or methodology being curently followed much more efficient. Also I want it to be a real great researchable idea which would require considerable effor on my part to materilaise it. I would like to do a PHD in this. One small idea which I have in mind right now is to develop a Framework For Sending RDF Documents using the WebDAV protocol as transport protocol. But I am not sure if its a real great idea and also its its big enough to do phd upon. Thanks in anticipation, Regards. Jim Whitehead wrote: Yes. What did you have in mind? - Jim On Oct 5, 2005, at 6:04 AM, david muller wrote: hi all, I am new to this group. Can some help me with some ideas for research on wbedav. David. --------------------------------- How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos --0-1011044054-1128542178=:27240 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
hi,
 
what I have in mind is this.
 
I want to basically research upon some idea which exploits the advantages of webdav protocol  over HTTP1.1 to the advantage of some existing problem or for efficiency.
 
Like say some idea which makes use of the extra methods provided by webdav namely ( e.g profind, propatch, copy, move, delete, lock, unlock) and then aims to solve some existing problem in the computer world today or intends to make some existing process or methodology being curently followed much more efficient.
 
Also I want it to be a real great researchable idea which would require considerable effor on my part to materilaise it. I would like to do a PHD in this.
 
One small idea which I have in mind right now is to develop a Framework For Sending RDF Documents using the WebDAV protocol as transport protocol. But I am not sure if its a real great idea and also its its big enough to do phd upon.

Thanks in anticipation,
 
Regards.
 


Jim Whitehead <ejw@soe.ucsc.edu> wrote:
Yes.

What did you have in mind?

- Jim

On Oct 5, 2005, at 6:04 AM, david muller wrote:


hi all,

I am new to this group.

Can some help me with some ideas for research on
wbedav.


David.

How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos --0-1011044054-1128542178=:27240-- From w3c-dist-auth-request@frink.w3.org Wed Oct 05 16:24:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFoi-0000QS-RE for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 16:24:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15135 for ; Wed, 5 Oct 2005 16:22:20 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENFl6-0000jQ-3L for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 20:21:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENFl5-0000is-Cu for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 20:20:59 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by maggie.w3.org with esmtp (Exim 4.50) id 1ENFkz-0006SZ-GE for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 20:20:57 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j95KKebj024586 for ; Wed, 5 Oct 2005 13:20:40 -0700 (PDT) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id A93E34C9 for ; Wed, 5 Oct 2005 13:20:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <8cca60fc101d781c975da35774ac02fa@osafoundation.org> References: <43441E92.8070504@gmx.de> <8cca60fc101d781c975da35774ac02fa@osafoundation.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--87415740; protocol="application/pkcs7-signature" Message-Id: <132DE691-8C17-4149-9A15-0E74CEF22B9B@wsanchez.net> From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Wed, 5 Oct 2005 13:20:39 -0700 To: WebDav X-Mailer: Apple Mail (2.734) 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=-1.8 X-W3C-Scan-Sig: maggie.w3.org 1ENFkz-0006SZ-GE 39c473881d3a8a71b6e1a869f560888b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/132DE691-8C17-4149-9A15-0E74CEF22B9B@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9939 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 20:21:00 +0000 --Apple-Mail-11--87415740 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit My DAV implementation (http://svn.red-bean.com/wsanchez/trunk/ TwistedDAV/) removes the property value element from the DOM in the request and creates a new XML document with that element as the new document's root element. I let the PyXML engine render the new document and store the result in the property store for the resource. My intention is that when a client requests a property value, that the value sent back is semantically equal to the original. It is not character-for-character equal. If you want that, don't send me XML, but escape your XML on the way in, and undo that on the way out. For example: May come back as: /foo/ HTTP/1.1 200 OK I just jiggered that by hand, so the XML may be error-prone, but I think the idea should get across. Personally, I found the whole notion of preserving XML semantics to be quite annoying; it basically means that all of my (dead) property storage has to be XML, or I have to tag them as to whether they are or aren't XML, but that's even more complexity. I'd prefer that XML not be allowed in property values at all. If the values were always CDATA, then the server wouldn't ever have to do anything with them at all, which is far more appropriate, I think. And you could always put XML in there escaped as CDATA and parse it when you get it back if you need to. That would require you to do what Julian is expecting, which is to make XML in property values self-contained and eliminates any ambiguity about who is responsible for ensuring that (which I agree should be the client, but don't agree that the current spec says so). -wsv On Oct 5, 2005, at 12:38 PM, Lisa Dusseault wrote: > IMPLEMENTORS -- can we get some sense of what existing server > implementations do to preserve prefixes/namespaces in property > values? If I recall correctly, Xythos WFS preserves the > namespaces but generates its own prefixes, and will frequently > declare prefixes in another place. --Apple-Mail-11--87415740 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIzDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggWFMIIE7qADAgECAgMNZZAwDQYJKoZI hvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MTExMDAyMjkyN1oXDTA1MTExMDAyMjkyN1owggH/MRUwEwYDVQQEEwxTYW5jaGV6IFZlZ2ExETAP BgNVBCoTCFdpbGZyZWRvMR4wHAYDVQQDExVXaWxmcmVkbyBTYW5jaGV6IFZlZ2ExJDAiBgkqhkiG 9w0BCQEWFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldDEhMB8GCSqGSIb3DQEJARYSd3NhbmNoZXpAYXBw bGUuY29tMSIwIAYJKoZIhvcNAQkBFhN3c2FuY2hlekBhcGFjaGUub3JnMR8wHQYJKoZIhvcNAQkB FhB3c2FuY2hlekBtaXQuZWR1MSQwIgYJKoZIhvcNAQkBFhV3c2FuY2hlekBhbHVtLm1pdC5lZHUx IzAhBgkqhkiG9w0BCQEWFHdzYW5jaGV6QGZyZWVic2Qub3JnMSIwIAYJKoZIhvcNAQkBFhN3c2Fu Y2hlekBuZXRic2Qub3JnMR0wGwYJKoZIhvcNAQkBFg50cml0YW5AbWl0LmVkdTEsMCoGCSqGSIb3 DQEJARYdd3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb20xJzAlBgkqhkiG9w0BCQEWGHdzYW5j aGV6QGZyZWVtZXRob2RzLm9yZzEfMB0GCSqGSIb3DQEJARYQdG9vbEByYW5nZXJzLm9yZzEfMB0G CSqGSIb3DQEJARYQd3NhbmNoZXpAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMdR8Xdk0klE2zVpa5NJPNI1rz1kTWtpPqCz0/h9oI5cdpw8OiJpfD/7npvxTKQk564YwikW wIZ9zkE1Nu9twStukxQb6D8QdAKk+4SVgkDZm62rHBJBoLoBpW9O5qTkHtvuWMVCRuCZW4lAJYdp vZ9FkGrLssn+rBV99LYZPc2D7Y0y4XoAoqvGu1rjkRNXftm49PXXHth/wlgzSiaC7f27M8s7IhuC fcvp04iMok3id03+blIKwmcH7Nb1L7X3wok+5JMhTa1txGds1m9AqN9nb3zav30GEO0LXU2Y7PMV 8De6TYU3cJD95BfATGEx7JhxrPXwKBCbiJDc5dsMPhcCAwEAAaOCASQwggEgMIIBDgYDVR0RBIIB BTCCAQGBFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldIESd3NhbmNoZXpAYXBwbGUuY29tgRN3c2FuY2hl ekBhcGFjaGUub3JngRB3c2FuY2hlekBtaXQuZWR1gRV3c2FuY2hlekBhbHVtLm1pdC5lZHWBFHdz YW5jaGV6QGZyZWVic2Qub3JngRN3c2FuY2hlekBuZXRic2Qub3JngQ50cml0YW5AbWl0LmVkdYEd d3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb22BGHdzYW5jaGV6QGZyZWVtZXRob2RzLm9yZ4EQ dG9vbEByYW5nZXJzLm9yZ4EQd3NhbmNoZXpAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAGtqmsTpUyTIYFCMtTwEM0wg/l0Ul/EOTzfSx9CUni9i32m2DF8h5801L+64LOl8 XawvtrVmE7HCFF3d33/lNd9nmLrGAdEvG7yr++FJ1059puTTgqUChZBL+xkHZp8Yu9d5yPtGxeHZ E3Ke+6t+UuSS9OV8pt2VmzjKwTGjJtJLMYIC5zCCAuMCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMDUyMDIwMzlaMCMGCSqGSIb3DQEJBDEW BBTMA2IdSNv5Zpv72wsx5oIW3YDjVjB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDWWQMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDANBgkqhkiG9w0BAQEFAASC AQCuFV3Zfc4eoBkKMh98B9favcT49AD0rpuI6ckdVZrf491U1aqGgjo6cSIRyjmT0Uik23Tt/7C9 3Ilm6XL+NJJj+L/MA0MGHAInyYDladQye0eubisIf/jgpciSjDPxFNlgsim+gR1X+9oXYeNlW3Bn /9HAFaBGzicdarPNmqzHQJFVTedyPSgFuHS/0ZSE4nNFuvJbYWKi0OZxPssZnEw2TcFwuLmVZ3bu 8ngMJAv/I9dNc+Jav+ZzvVlKv5fpFoms4MyO9Zf6dM6EthEC9RyM+bwqz5i+zQIRP46es5dcKsZ1 ehsKNjfs3ERVZBSKyc6oIzyatpaXDHY451/TW0mUAAAAAAAA --Apple-Mail-11--87415740-- From w3c-dist-auth-request@frink.w3.org Wed Oct 05 17:17:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGdi-0007BN-K4 for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 17:17:26 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29707 for ; Wed, 5 Oct 2005 17:17:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENGc2-00009H-Ig for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 21:15:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENGc1-00008i-It for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 21:15:41 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1ENGbp-0000pG-DQ for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 21:15:40 +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 j95LFQ4a018966 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Oct 2005 14:15:26 -0700 (PDT) In-Reply-To: <20051005195619.27466.qmail@web25108.mail.ukl.yahoo.com> References: <20051005195619.27466.qmail@web25108.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95C4A0DE-0347-4C59-9BA0-73F7DCB5AB78@cs.ucsc.edu> Cc: WebDav Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Wed, 5 Oct 2005 14:15:24 -0700 To: david muller X-Mailer: Apple Mail (2.734) 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=-1.7 X-W3C-Scan-Sig: maggie.w3.org 1ENGbp-0000pG-DQ 017dba7a75fab8ebbd4819f59c61444d X-Original-To: w3c-dist-auth@w3.org Subject: Re: ideas for research on wbedav required X-Archived-At: http://www.w3.org/mid/95C4A0DE-0347-4C59-9BA0-73F7DCB5AB78@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9940 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 21:15:42 +0000 Content-Transfer-Encoding: 7bit Here are some thoughts on substantial research projects involving WebDAV. * Photo transport protocol. The cost of 802.11x hardware is dropping rapidly, while the number of deployed 802.11x access points is increasing. Especially with VOIP gaining traction, it seems likely that widespread wireless networking access based on TCP/IP will soon be a reality. Given this background, it would be very useful for digital cameras to be able to automatically transfer their pictures from the camera to a remote server. WebDAV seems like a useful protocol to build upon for such a service, since it's well suited for synchronization, and has strong metadata facilities. The existing standard in this space, CPXe (http://www.i3a.org/) is focused on getting photos to photo finishing services for hardcopy. Many consumers want auto-download without being required to upload to a photo finishing service. Project: develop a standard for automatic photo upload from a camera via wireless networking. * Identity management protocol. Many web sites require users to create an identify for that site, usually by creating a username/ password pair. Users interacting with multiple sites need to maintain multiple username/password pairs (or compromise security by using the same pair). It would be much more convenient to have a single signon capability. There are many existing efforts in this space (Passport, Liberty Alliance), with each effort having some concern over its degree of capture by one or more organizations or communities. Since identity management involves a fair amount of metadata management, WebDAV might be a good protocol to use as a starting point in crafting an identity management protocol, due to its strong support for metadata, and DeltaV versioning capabilities.. This issue can have significant impact on the cross-organization calendar scheduling problem (see CalDAV). * Email transport protocol. Spam is killing SMTP. It would be nice to have a mail transport protocol that was point-to-point, and involved authentication or some form of expensive computation for people to write email to a remote inbox. An email message is a blog of content plus metadata, just like a WebDAV resource. WebDAV + ACLs might be an interesting starting point for creating an alternate to SMTP for mail transport. WebDAV is already the third most popular email transport between mail server and mail client (MUA), since Hotmail and Outlook Express use WebDAV for mail transport. Note that this project might very well also involve a solution for identity management. For extra credit (and a shred of hope for adoption), ensure some form of interoperability with the existing SMTP-based email system (perhaps by putting all of this email into an "untrusted" or "unverified" folder). RDF may very well be a useful technology in addressing the metadata aspects of these projects. Or it might not. Let the requirements drive your choice of technology, not vice-versa. - Jim Whitehead Assistant Professor Computer Science UC Santa Cruz From w3c-dist-auth-request@frink.w3.org Wed Oct 05 17: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 1ENHAd-00005s-4f for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 17:51:27 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03453 for ; Wed, 5 Oct 2005 17:51:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENH9m-0000Uy-84 for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 21:50:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENH9k-0000TM-Rv for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 21:50:32 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ENH9X-0000N7-8t for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 21:50:32 +0000 Received: (qmail invoked by alias); 05 Oct 2005 21:50:16 -0000 Received: from brmn-d9b8f26a.pool.mediaWays.net (EHLO [217.184.242.106]) [217.184.242.106] by mail.gmx.net (mp023) with SMTP; 05 Oct 2005 23:50:16 +0200 X-Authenticated: #1915285 Message-ID: <43444A95.5000106@gmx.de> Date: Wed, 05 Oct 2005 23:50:13 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: WebDav References: <43441E92.8070504@gmx.de> <8cca60fc101d781c975da35774ac02fa@osafoundation.org> <132DE691-8C17-4149-9A15-0E74CEF22B9B@wsanchez.net> In-Reply-To: <132DE691-8C17-4149-9A15-0E74CEF22B9B@wsanchez.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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.6 X-W3C-Scan-Sig: lisa.w3.org 1ENH9X-0000N7-8t 8003035fac4796eafb8a75a8be8b2040 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/43444A95.5000106@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9941 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 21:50:34 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA03453 Wilfredo S=E1nchez Vega wrote: > My DAV implementation (http://svn.red-bean.com/wsanchez/trunk/=20 > TwistedDAV/) removes the property value element from the DOM in the =20 > request and creates a new XML document with that element as the new =20 > document's root element. I let the PyXML engine render the new =20 > document and store the result in the property store for the resource. >=20 > My intention is that when a client requests a property value, that =20 > the value sent back is semantically equal to the original. It is not =20 > character-for-character equal. If you want that, don't send me XML, =20 > but escape your XML on the way in, and undo that on the way out. So who decides what "semantically equal" means? Is it semantically equal=20 if it does a differing XML Infoset=20 ()? I doubt so. > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 05 17:53:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENHCa-0001EJ-PQ for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 17:53:28 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03540 for ; Wed, 5 Oct 2005 17:53:25 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENHC0-0001Dm-VN for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 21:52:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENHBz-0001Cy-T4 for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 21:52:51 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ENHBj-0000zG-OU for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 21:52:51 +0000 Received: (qmail invoked by alias); 05 Oct 2005 21:52:33 -0000 Received: from brmn-d9b8f26a.pool.mediaWays.net (EHLO [217.184.242.106]) [217.184.242.106] by mail.gmx.net (mp016) with SMTP; 05 Oct 2005 23:52:33 +0200 X-Authenticated: #1915285 Message-ID: <434449EF.8000202@gmx.de> Date: Wed, 05 Oct 2005 23:47:27 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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.6 X-W3C-Scan-Sig: lisa.w3.org 1ENHBj-0000zG-OU f0fdab8971a2af89cc0240c402c52f01 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/434449EF.8000202@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9942 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 21:52:52 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I'm not sure I understand what you mean by namespace preservation. Take the > example portion of some XML: > > xmlns:h="http://www.w3.org/HTML/1998/html4"> > Book Review > > > XML: A Primer > > Is it the "http://www.xml.com/books" that gets preserved or the "xdc". What > I'm trying to ask is if would be OK if the above XML got transformed to > > xmlns:h="http://www.w3.org/HTML/1998/html4"> > Book Review > > > XML: A Primer > > I suspect you are saying this is not OK and the namespace prefix (ie the > xdc) needs to be preserved and not changed to foo-xdc. If this is what you > mean, then I am not sure what you mean by this is important for XSLT and XML > Schema, can you provide a bit more of an example. > The namespace URI definitively needs to preserved, I don't think there's any question about that. What this issue is about is whether if it's a problem to get XML: A Primer or XML: A Primer instead. *Usually* that doesn't make a difference, and in a perfect world, it never would. Unfortunately, this isn't a perfect world and a long time ago, XML vocabularies have started to leak prefixes into text content and attribute values. Consider: In this case, loosing the "D" prefix actually breaks the semantics of the document, such as in: This is an example from XSLT/XPath, similar cases can be constructed with documents that use XML Schema, such as in 123 For the record, the XML Infoset spec includes prefixes. So no, rewriting namespace prefixes is *not* without problems, and *will* break semantics of XML content. Thus, we should either require prefixes to be preserved, or at least state that this part of the XML Infoset may not round-trip through WebDAV properties. > Thanks for educating me on this - I'm not really going to end up with much > of an opinion on any of this but I am making sure I know enough to at least > understand the argument. Also, I suspect I might not be the only one of the > list that does not understand as much about XML as I wish I did :-) Sure :-) Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 05 18:13:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENHWQ-0000vZ-Qf for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 18:13:59 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05286 for ; Wed, 5 Oct 2005 18:13:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENHVg-0004z4-VO for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 22:13:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENHVg-0004yW-0s for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 22:13:12 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ENHVS-0004te-8I for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 22:13:11 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0B21C1422B0; Wed, 5 Oct 2005 15:12:57 -0700 (PDT) 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 01463-05; Wed, 5 Oct 2005 15:12:56 -0700 (PDT) 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 BCAE61422AF; Wed, 5 Oct 2005 15:12:55 -0700 (PDT) In-Reply-To: <434449EF.8000202@gmx.de> References: <434449EF.8000202@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: Lisa Dusseault Date: Wed, 5 Oct 2005 15:12:52 -0700 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 1ENHVS-0004te-8I 3eab9b91ce9dfc50f81cee21d7229f07 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/e019ca0908a0431f0776e7688e2dd991@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9943 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 22:13:12 +0000 Content-Transfer-Encoding: 7bit This is a great argument for a from-scratch design, and I understand it and would agree with it were we starting from a clean slate. However, we're not starting from a clean slate. * Existing clients have to handle servers that do prefix replacement. An existing client would not benefit from more stringent rules in RFC2518bis until most servers are upgraded and satisfy the new requirements. (Yes I'm aware this is a general concern with spec changes but it should still factor into this trade-off calculation) * Existing servers probably don't preserve prefixes, by and large. Requiring so many existing implementations to change is quite a burden. For some of them this will involve performance considerations. * I'm unaware of any actual interoperability problems that have arisen in ordinary usage that require prefix preservation. The template example is certainly a theoretical problem I agree. We might consider WSanchez's idea of recommending that clients create self-contained XML fragments and escape with CDATA, if the client is concerned about prefix preservation. Otherwise, unprotected XML fragments are subject to server rewriting (whitespace as well as prefix selection). This seems like a more practical approach starting from where we are now, and I think it handles all the cases with less spec changes. Lisa On Oct 5, 2005, at 2:47 PM, Julian Reschke wrote: > > Cullen Jennings wrote: >> I'm not sure I understand what you mean by namespace preservation. >> Take the >> example portion of some XML: >> > xmlns:h="http://www.w3.org/HTML/1998/html4"> >> Book Review >> >> >> XML: A Primer >> Is it the "http://www.xml.com/books" that gets preserved or the >> "xdc". What >> I'm trying to ask is if would be OK if the above XML got transformed >> to >> > xmlns:h="http://www.w3.org/HTML/1998/html4"> >> Book Review >> >> >> XML: A Primer > > > > I suspect you are saying this is not OK and the namespace prefix (ie > the > > xdc) needs to be preserved and not changed to foo-xdc. If this is > what you > > mean, then I am not sure what you mean by this is important for XSLT > and XML > > Schema, can you provide a bit more of an example. > > > > The namespace URI definitively needs to preserved, I don't think > there's any question about that. > > What this issue is about is whether if it's a problem to get > > XML: A > Primer > > or > > XML: A Primer > > instead. > > *Usually* that doesn't make a difference, and in a perfect world, it > never would. Unfortunately, this isn't a perfect world and a long time > ago, XML vocabularies have started to leak prefixes into text content > and attribute values. > > Consider: > > > > In this case, loosing the "D" prefix actually breaks the semantics of > the document, such as in: > > > > This is an example from XSLT/XPath, similar cases can be constructed > with documents that use XML Schema, such as in > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:integer">123 > > For the record, the XML Infoset spec includes prefixes. > > So no, rewriting namespace prefixes is *not* without problems, and > *will* break semantics of XML content. Thus, we should either require > prefixes to be preserved, or at least state that this part of the XML > Infoset may not round-trip through WebDAV properties. > >> Thanks for educating me on this - I'm not really going to end up with >> much >> of an opinion on any of this but I am making sure I know enough to at >> least >> understand the argument. Also, I suspect I might not be the only one >> of the >> list that does not understand as much about XML as I wish I did :-) > > Sure :-) > > Best regards, Julian > > From w3c-dist-auth-request@frink.w3.org Wed Oct 05 18:38:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENHu4-0002SJ-7c for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 18:38:24 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07197 for ; Wed, 5 Oct 2005 18:38:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENHt9-0001EF-OG for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Oct 2005 22:37:27 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENHt8-0001Dc-Kv for w3c-dist-auth@listhub.w3.org; Wed, 05 Oct 2005 22:37:26 +0000 Received: from web25107.mail.ukl.yahoo.com ([217.12.10.55]) by maggie.w3.org with smtp (Exim 4.50) id 1ENHt5-0005Kl-Mb for w3c-dist-auth@w3.org; Wed, 05 Oct 2005 22:37:26 +0000 Received: (qmail 89205 invoked by uid 60001); 5 Oct 2005 22:37:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XnOsK18K3+Ne/RHNDVL/yIuQ2QFVufJj0JuqUC9D/9Oa10qFleUFAM+fc6vAr1wWywB2RZIwyr3l4HraVcUFPTJfL2Ws/hHKL34t81JP9JS7Eo2pNMwXTAul2gbl7r+nhYvTSye9o7jYUoNxa5IJeXrrSUsNj8XDC8SGf4EhPHE= ; Message-ID: <20051005223721.89203.qmail@web25107.mail.ukl.yahoo.com> Received: from [134.83.1.225] by web25107.mail.ukl.yahoo.com via HTTP; Wed, 05 Oct 2005 23:37:20 BST Date: Wed, 5 Oct 2005 23:37:20 +0100 (BST) From: david muller To: Jim Whitehead Cc: WebDav In-Reply-To: <95C4A0DE-0347-4C59-9BA0-73F7DCB5AB78@cs.ucsc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Received-SPF: none (maggie.w3.org: domain of david_muller_8888@yahoo.co.uk does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-0.7 X-W3C-Scan-Sig: maggie.w3.org 1ENHt5-0005Kl-Mb e2b0d9ed10dd4d9bfd7e366ea86e53f2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ideas for research on wbedav required X-Archived-At: http://www.w3.org/mid/20051005223721.89203.qmail@web25107.mail.ukl.yahoo.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9944 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Oct 2005 22:37:27 +0000 Content-Transfer-Encoding: 8bit Dear Sir, thanks for your ideas. I had myself once vaguely thought of the webdav email transport protocol long back but could not get the clear thought that time. I found it quite interesting and innovative. I will concentrate on this idea for now and will look into other ideas later. Few poins: 1. What I could understand of the idea is "To Develop a Mail Transport Protocol Based on WEBDAV (i.e which uses the extra methods like copy, move, delete, profind, propatch, lock, unlock provided by webdav). ". The protocol should be point to point, have authentication, some sort of identity management. 2. You have said that WebDAV is already the third most popular email transport between mail server and mail client (MUA ?), since Hotmail and Outlook Express use WebDAV for mail transport. So does it mean that hotmail and outlook have already developed a transport protocol based on WEBDAV and are using it? 3. Would one of the major intention behind this new transport protocol be to stop SPAM (you have said that SPAM is killing SMTP)? If yes then I really did not understand that why you think that point to point transport protocol would not have spam problem. Thanks for your time, Regards. > * Email transport protocol. Spam is killing SMTP. It > would be nice to have a mail transport protocol that was > point-to-point, and involved > authentication or some form of expensive computation > for people to > write email to a remote inbox. An email message is a > blog of content > plus metadata, just like a WebDAV resource. WebDAV + > ACLs might be an > interesting starting point for creating an alternate > to SMTP for mail > transport. WebDAV is already the third most popular > email transport > between mail server and mail client (MUA), since > Hotmail and Outlook > Express use WebDAV for mail transport. Note that > this project might > very well also involve a solution for identity > management. For extra > credit (and a shred of hope for adoption), ensure > some form of > interoperability with the existing SMTP-based email > system (perhaps > by putting all of this email into an "untrusted" or > "unverified" > folder) ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From w3c-dist-auth-request@frink.w3.org Wed Oct 05 20: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 1ENJXP-0007js-FQ for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 20:23:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10960 for ; Wed, 5 Oct 2005 20:23:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENJVs-0005mz-0f for w3c-dist-auth-dist@listhub.w3.org; Thu, 06 Oct 2005 00:21:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENJVq-0005m3-Mp; Thu, 06 Oct 2005 00:21:30 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.50) id 1ENJVl-0003TG-24; Thu, 06 Oct 2005 00:21:30 +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 j960LNSF013268; Wed, 5 Oct 2005 20:21:23 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j960LN08104240; Wed, 5 Oct 2005 20:21:23 -0400 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 j960LNJq008886; Wed, 5 Oct 2005 20:21:23 -0400 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 j960LN0I008883; Wed, 5 Oct 2005 20:21:23 -0400 In-Reply-To: To: Lisa Dusseault Cc: Cullen Jennings , Julian Reschke , 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: Wed, 5 Oct 2005 20:21:22 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/05/2005 20:21:22, Serialize complete at 10/05/2005 20:21:22 Content-Type: multipart/alternative; boundary="=_alternative 0001F4C885257092_=" 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 1ENJVl-0003TG-24 936339bfd380e67d3a74227df567150e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/OFA16D6C25.FEE47A7E-ON85257092.00012936-85257092.0001F502@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9945 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 06 Oct 2005 00:21:32 +0000 This is a multipart message in MIME format. --=_alternative 0001F4C885257092_= Content-Type: text/plain; charset="US-ASCII" Julian's argument was: > Thus, we should either require > prefixes to be preserved, or at least state that this part of the XML > Infoset may not round-trip through WebDAV properties. It appears that Lisa and Wilfredo do not like the first alternative, so let's explore the second alternative. I believe Julian is just saying here that the specification should warn clients and servers about the negative consequences of not round-tripping namespace prefixes (so that clients are prepared to handle the negative consequences). Does anyone object to this being added? If not, Julian, could you write up what you'd like to be said here (I assume it would be something like what you say below)? Also, one could add guidance to a client that they escape the XML if they are concerned about the non-round-tripping of namespace prefixes. Cheers, Geoff Lisa wrote on 10/05/2005 06:12:52 PM: > > This is a great argument for a from-scratch design, and I understand it > and would agree with it were we starting from a clean slate. However, > we're not starting from a clean slate. > > * Existing clients have to handle servers that do prefix replacement. > An existing client would not benefit from more stringent rules in > RFC2518bis until most servers are upgraded and satisfy the new > requirements. (Yes I'm aware this is a general concern with spec > changes but it should still factor into this trade-off calculation) > * Existing servers probably don't preserve prefixes, by and large. > Requiring so many existing implementations to change is quite a burden. > For some of them this will involve performance considerations. > * I'm unaware of any actual interoperability problems that have arisen > in ordinary usage that require prefix preservation. The template > example is certainly a theoretical problem I agree. > > We might consider WSanchez's idea of recommending that clients create > self-contained XML fragments and escape with CDATA, if the client is > concerned about prefix preservation. Otherwise, unprotected XML > fragments are subject to server rewriting (whitespace as well as prefix > selection). This seems like a more practical approach starting from > where we are now, and I think it handles all the cases with less spec > changes. > > On Oct 5, 2005, at 2:47 PM, Julian Reschke wrote: > > > > > Cullen Jennings wrote: > >> I'm not sure I understand what you mean by namespace preservation. > >> Take the > >> example portion of some XML: > >> >> xmlns:h="http://www.w3.org/HTML/1998/html4"> > >> Book Review > >> > >> > >> XML: A Primer > >> Is it the "http://www.xml.com/books" that gets preserved or the > >> "xdc". What > >> I'm trying to ask is if would be OK if the above XML got transformed > >> to > >> >> xmlns:h="http://www.w3.org/HTML/1998/html4"> > >> Book Review > >> > >> > >> XML: A Primer > > > > > > I suspect you are saying this is not OK and the namespace prefix (ie > > the > > > xdc) needs to be preserved and not changed to foo-xdc. If this is > > what you > > > mean, then I am not sure what you mean by this is important for XSLT > > and XML > > > Schema, can you provide a bit more of an example. > > > > > > > The namespace URI definitively needs to preserved, I don't think > > there's any question about that. > > > > What this issue is about is whether if it's a problem to get > > > > XML: A > > Primer > > > > or > > > > XML: A Primer > > > > instead. > > > > *Usually* that doesn't make a difference, and in a perfect world, it > > never would. Unfortunately, this isn't a perfect world and a long time > > ago, XML vocabularies have started to leak prefixes into text content > > and attribute values. > > > > Consider: > > > > > > > > In this case, loosing the "D" prefix actually breaks the semantics of > > the document, such as in: > > > > > > > > This is an example from XSLT/XPath, similar cases can be constructed > > with documents that use XML Schema, such as in > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > > xsi:type="xs:integer">123 > > > > For the record, the XML Infoset spec includes prefixes. > > > > So no, rewriting namespace prefixes is *not* without problems, and > > *will* break semantics of XML content. Thus, we should either require > > prefixes to be preserved, or at least state that this part of the XML > > Infoset may not round-trip through WebDAV properties. > > > >> Thanks for educating me on this - I'm not really going to end up with > >> much > >> of an opinion on any of this but I am making sure I know enough to at > >> least > >> understand the argument. Also, I suspect I might not be the only one > >> of the > >> list that does not understand as much about XML as I wish I did :-) > > > > Sure :-) > > > > Best regards, Julian > > > > > > --=_alternative 0001F4C885257092_= Content-Type: text/html; charset="US-ASCII"
Julian's argument was:
> Thus, we should either require
> prefixes to be preserved, or at least state that this part of the XML
> Infoset may not round-trip through WebDAV properties.

It appears that Lisa and Wilfredo do not like the first alternative, so
let's explore the second alternative.  I believe Julian is just saying here
that the specification should warn clients and servers about the negative
consequences of not round-tripping namespace prefixes (so that clients are
prepared to handle the negative consequences).  Does anyone object to this
being added?  If not, Julian, could you write up what you'd like to be said
here (I assume it would be something like what you say below)?  Also, one
could add guidance to a client that they escape the XML if they are concerned
about the non-round-tripping of namespace prefixes.

Cheers,
Geoff

Lisa wrote on 10/05/2005 06:12:52 PM:
>
> This is a great argument for a from-scratch design, and I understand it
> and would agree with it were we starting from a clean slate.  However,
> we're not starting from a clean slate.
>
>   * Existing clients have to handle servers that do prefix replacement.  
> An existing client would not benefit from more stringent rules in
> RFC2518bis until most servers are upgraded and satisfy the new
> requirements.  (Yes I'm aware this is a general concern with spec
> changes but it should still factor into this trade-off calculation)
>   * Existing servers probably don't preserve prefixes, by and large.  
> Requiring so many existing implementations to change is quite a burden.
>   For some of them this will involve performance considerations.
>   * I'm unaware of any actual interoperability problems that have arisen
> in ordinary usage that require prefix preservation.  The template
> example is certainly a theoretical problem I agree.
>
> We might consider WSanchez's idea of recommending that clients create
> self-contained XML fragments  and escape with CDATA, if the client is
> concerned about prefix preservation.  Otherwise, unprotected XML
> fragments are subject to server rewriting (whitespace as well as prefix
> selection).  This seems like a more practical approach starting from
> where we are now, and I think it handles all the cases with less spec
> changes.
>
> On Oct 5, 2005, at 2:47 PM, Julian Reschke wrote:
>
> >
> > Cullen Jennings wrote:
> >> I'm not sure I understand what you mean by namespace preservation.
> >> Take the
> >> example portion of some XML:
> >> <h:html xmlns:xdc="http://www.xml.com/books"
> >>         xmlns:h="http://www.w3.org/HTML/1998/html4">
> >>  <h:head><h:title>Book Review</h:title></h:head>
> >>  <h:body>
> >>   <xdc:bookreview>
> >>    <xdc:title>XML: A Primer</xdc:title>
> >> Is it the "http://www.xml.com/books" that gets preserved or the
> >> "xdc". What
> >> I'm trying to ask is if would be OK if the above XML got transformed
> >> to
> >> <h:html xmlns:foo-xdc="http://www.xml.com/books"
> >>         xmlns:h="http://www.w3.org/HTML/1998/html4">
> >>  <h:head><h:title>Book Review</h:title></h:head>
> >>  <h:body>
> >>   <foo-xdc:bookreview>
> >>    <foo-xdc:title>XML: A Primer</xdc:title>
> > >
> > > I suspect you are saying this is not OK and the namespace prefix (ie
> > the
> > > xdc) needs to be preserved and not changed to foo-xdc. If this is
> > what you
> > > mean, then I am not sure what you mean by this is important for XSLT
> > and XML
> > > Schema, can you provide a bit more of an example.
> > >
> >
> > The namespace URI definitively needs to preserved, I don't think
> > there's any question about that.
> >
> > What this issue is about is whether if it's a problem to get
> >
> >    <xyz:title xmlns:xyz="http://www.xml.com/books">XML: A
> > Primer</xyz:title>
> >
> > or
> >
> >    <title xmlns="http://www.xml.com/books">XML: A Primer</title>
> >
> > instead.
> >
> > *Usually* that doesn't make a difference, and in a perfect world, it
> > never would. Unfortunately, this isn't a perfect world and a long time
> > ago, XML vocabularies have started to leak prefixes into text content
> > and attribute values.
> >
> > Consider:
> >
> >    <xsl:template match="D:propfind" xmlns:D="DAV:">
> >
> > In this case, loosing the "D" prefix actually breaks the semantics of
> > the document, such as in:
> >
> >    <xsl:template match="D:propfind" xmlns:ns0="DAV:">
> >
> > This is an example from XSLT/XPath, similar cases can be constructed
> > with documents that use XML Schema, such as in
> >
> >    <count xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >    xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xsi:type="xs:integer">123</count>
> >
> > For the record, the XML Infoset spec includes prefixes.
> >
> > So no, rewriting namespace prefixes is *not* without problems, and
> > *will* break semantics of XML content. Thus, we should either require
> > prefixes to be preserved, or at least state that this part of the XML
> > Infoset may not round-trip through WebDAV properties.
> >
> >> Thanks for educating me on this - I'm not really going to end up with
> >> much
> >> of an opinion on any of this but I am making sure I know enough to at
> >> least
> >> understand the argument. Also, I suspect I might not be the only one
> >> of the
> >> list that does not understand as much about XML as I wish I did :-)
> >
> > Sure :-)
> >
> > Best regards, Julian
> >
> >
>
>
--=_alternative 0001F4C885257092_=-- From w3c-dist-auth-request@frink.w3.org Wed Oct 05 21:05:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENKC4-0005K5-SM for webdav-archive@megatron.ietf.org; Wed, 05 Oct 2005 21:05:09 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13259 for ; Wed, 5 Oct 2005 21:05:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENKBO-0007T2-1o for w3c-dist-auth-dist@listhub.w3.org; Thu, 06 Oct 2005 01:04:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENKBN-0007S9-4Z for w3c-dist-auth@listhub.w3.org; Thu, 06 Oct 2005 01:04:25 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by maggie.w3.org with esmtp (Exim 4.50) id 1ENKBH-0002RC-KN for w3c-dist-auth@w3.org; Thu, 06 Oct 2005 01:04:24 +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 j961432n019575; Wed, 5 Oct 2005 18:04:03 -0700 (PDT) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 46546324002; Wed, 5 Oct 2005 18:04:03 -0700 (PDT) In-Reply-To: <43444A95.5000106@gmx.de> References: <43441E92.8070504@gmx.de> <8cca60fc101d781c975da35774ac02fa@osafoundation.org> <132DE691-8C17-4149-9A15-0E74CEF22B9B@wsanchez.net> <43444A95.5000106@gmx.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12--70412539; protocol="application/pkcs7-signature" Message-Id: Cc: WebDav From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Wed, 5 Oct 2005 18:04:02 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.734) 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.2 X-W3C-Scan-Sig: maggie.w3.org 1ENKBH-0002RC-KN 32b3f74677c8ae5c880e0b123164334a X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/BEA74459-17BA-41FD-9786-9DA74DD9B4BB@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9946 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 06 Oct 2005 01:04:26 +0000 --Apple-Mail-12--70412539 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Honestly, I don't really know, 'cuz I'm not an XML guy. But this is exactly why: A) XML isn't nearly as easy as it's hyped up to be B) We shouldn't allow XML elements in property values -wsv On Oct 5, 2005, at 2:50 PM, Julian Reschke wrote: > So who decides what "semantically equal" means? Is it semantically > equal if it does a differing XML Infoset ( infoset/>)? I doubt so. > --Apple-Mail-12--70412539 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIzDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggWFMIIE7qADAgECAgMNZZAwDQYJKoZI hvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MTExMDAyMjkyN1oXDTA1MTExMDAyMjkyN1owggH/MRUwEwYDVQQEEwxTYW5jaGV6IFZlZ2ExETAP BgNVBCoTCFdpbGZyZWRvMR4wHAYDVQQDExVXaWxmcmVkbyBTYW5jaGV6IFZlZ2ExJDAiBgkqhkiG 9w0BCQEWFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldDEhMB8GCSqGSIb3DQEJARYSd3NhbmNoZXpAYXBw bGUuY29tMSIwIAYJKoZIhvcNAQkBFhN3c2FuY2hlekBhcGFjaGUub3JnMR8wHQYJKoZIhvcNAQkB FhB3c2FuY2hlekBtaXQuZWR1MSQwIgYJKoZIhvcNAQkBFhV3c2FuY2hlekBhbHVtLm1pdC5lZHUx IzAhBgkqhkiG9w0BCQEWFHdzYW5jaGV6QGZyZWVic2Qub3JnMSIwIAYJKoZIhvcNAQkBFhN3c2Fu Y2hlekBuZXRic2Qub3JnMR0wGwYJKoZIhvcNAQkBFg50cml0YW5AbWl0LmVkdTEsMCoGCSqGSIb3 DQEJARYdd3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb20xJzAlBgkqhkiG9w0BCQEWGHdzYW5j aGV6QGZyZWVtZXRob2RzLm9yZzEfMB0GCSqGSIb3DQEJARYQdG9vbEByYW5nZXJzLm9yZzEfMB0G CSqGSIb3DQEJARYQd3NhbmNoZXpAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMdR8Xdk0klE2zVpa5NJPNI1rz1kTWtpPqCz0/h9oI5cdpw8OiJpfD/7npvxTKQk564YwikW wIZ9zkE1Nu9twStukxQb6D8QdAKk+4SVgkDZm62rHBJBoLoBpW9O5qTkHtvuWMVCRuCZW4lAJYdp vZ9FkGrLssn+rBV99LYZPc2D7Y0y4XoAoqvGu1rjkRNXftm49PXXHth/wlgzSiaC7f27M8s7IhuC fcvp04iMok3id03+blIKwmcH7Nb1L7X3wok+5JMhTa1txGds1m9AqN9nb3zav30GEO0LXU2Y7PMV 8De6TYU3cJD95BfATGEx7JhxrPXwKBCbiJDc5dsMPhcCAwEAAaOCASQwggEgMIIBDgYDVR0RBIIB BTCCAQGBFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldIESd3NhbmNoZXpAYXBwbGUuY29tgRN3c2FuY2hl ekBhcGFjaGUub3JngRB3c2FuY2hlekBtaXQuZWR1gRV3c2FuY2hlekBhbHVtLm1pdC5lZHWBFHdz YW5jaGV6QGZyZWVic2Qub3JngRN3c2FuY2hlekBuZXRic2Qub3JngQ50cml0YW5AbWl0LmVkdYEd d3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb22BGHdzYW5jaGV6QGZyZWVtZXRob2RzLm9yZ4EQ dG9vbEByYW5nZXJzLm9yZ4EQd3NhbmNoZXpAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAGtqmsTpUyTIYFCMtTwEM0wg/l0Ul/EOTzfSx9CUni9i32m2DF8h5801L+64LOl8 XawvtrVmE7HCFF3d33/lNd9nmLrGAdEvG7yr++FJ1059puTTgqUChZBL+xkHZp8Yu9d5yPtGxeHZ E3Ke+6t+UuSS9OV8pt2VmzjKwTGjJtJLMYIC5zCCAuMCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMDYwMTA0MDNaMCMGCSqGSIb3DQEJBDEW BBSWnkMb/8Oawj4Vahk0GGYOBTOQZzB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDWWQMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDANBgkqhkiG9w0BAQEFAASC AQB3J5uitLDTlvM5h+Jf3IXT9tluziluI8f9Bg8XIirVEkKnR+Tne0UkH5XkVMz9/mCFLxDoMOVe ddZivPO/P5W4gHWzJO9SPmjIWNW9uQwed13Nye5WrqKMpawtrZJ0UMb+lhy5b/7ii4dwK/KAFqU/ fGq/T22L4X1ucpd5ktiIsqH2gOk6OBoWU9hWRwSY+1a/eYYX0+PGGCOp9QprMUj1nNWgd5z3AFSp PIKq04/dAfj1rqwhlDpZSKo620d0Brh++0/NObFwyJ2qEpkSRY8Q0f3Sa9xsSWu7ewUejyKrvnPf AK4qbzU3mcMuTugBvi4iSRAmp6Wx71VJdSXftmmDAAAAAAAA --Apple-Mail-12--70412539-- From w3c-dist-auth-request@frink.w3.org Thu Oct 06 01:05:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENNwJ-0007E7-EZ for webdav-archive@megatron.ietf.org; Thu, 06 Oct 2005 01:05:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23583 for ; Thu, 6 Oct 2005 01:05:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENNuB-00086J-50 for w3c-dist-auth-dist@listhub.w3.org; Thu, 06 Oct 2005 05:02:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENNuA-00085l-7g; Thu, 06 Oct 2005 05:02:54 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ENNu3-00005F-1Y; Thu, 06 Oct 2005 05:02:53 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D01741422AA; Wed, 5 Oct 2005 22:02:44 -0700 (PDT) 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 16261-10; Wed, 5 Oct 2005 22:02:44 -0700 (PDT) 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 E3BCA1422A7; Wed, 5 Oct 2005 22:02:37 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-37--56100977 Message-Id: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> Cc: Julian Reschke , Cullen Jennings , WebDav , w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Wed, 5 Oct 2005 22:02:34 -0700 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: none (lisa.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1ENNu3-00005F-1Y a145c740a6a7efff19ae5c742f3b8d98 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/91df83c7d462717c7fa70fe05411113b@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9947 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 06 Oct 2005 05:02:55 +0000 --Apple-Mail-37--56100977 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable That works for me, unless more feedback from implementors comes up=20 quite different. Based on Julian's rewriting plus the discussion so far, here's some=20 proposed wording: The value of a property appears inside the property name element. The=20 value can be any kind of well-formed XML content: element content, text or=20 mixed content. When the property value contains element or mixed content, namespaces that are in scope for that part of the XML document apply=20 within the property value as well, and servers MUST preserve namespaces in=20 server storage for retransmission later. The server MAY preserve namespace=20 prefixes and non-significant whitespace. For any values where specific prefix choices or whitespace matter (e.g.=20= property values containing XPath with prefixes), clients might need to force the=20= server to store the exact property value by encapsulating the value in a CDATA=20 section. Lisa On Oct 5, 2005, at 5:21 PM, Geoffrey M Clemm wrote: > > Julian's argument was: > > Thus, we should either require > > prefixes to be preserved, or at least state that this part of the=20= > XML > > Infoset may not round-trip through WebDAV properties. > > It appears that Lisa and Wilfredo do not like the first alternative, = so > let's explore the second alternative. =A0I believe Julian is just = saying=20 > here > that the specification should warn clients and servers about the=20 > negative > consequences of not round-tripping namespace prefixes (so that clients=20= > are > prepared to handle the negative consequences). =A0Does anyone object = to=20 > this > being added? =A0If not, Julian, could you write up what you'd like to = be=20 > said > here (I assume it would be something like what you say below)? =A0Also,=20= > one > could add guidance to a client that they escape the XML if they are=20 > concerned > about the non-round-tripping of namespace prefixes. > > Cheers, > Geoff > > Lisa wrote on 10/05/2005 06:12:52 PM: > > > > This is a great argument for a from-scratch design, and I=20 > understand it > > and would agree with it were we starting from a clean slate.=20 > =A0However, > > we're not starting from a clean slate. > > > > =A0 * Existing clients have to handle servers that do prefix=20 > replacement. =A0 > > An existing client would not benefit from more stringent rules in > > RFC2518bis until most servers are upgraded and satisfy the new > > requirements. =A0(Yes I'm aware this is a general concern with spec > > changes but it should still factor into this trade-off calculation) > > =A0 * Existing servers probably don't preserve prefixes, by and=20 > large. =A0 > > Requiring so many existing implementations to change is quite a=20 > burden. > > =A0 For some of them this will involve performance considerations. > > =A0 * I'm unaware of any actual interoperability problems that have=20= > arisen > > in ordinary usage that require prefix preservation. =A0The template > > example is certainly a theoretical problem I agree. > > > > We might consider WSanchez's idea of recommending that clients=20 > create > > self-contained XML fragments =A0and escape with CDATA, if the = client=20 > is > > concerned about prefix preservation. =A0Otherwise, unprotected XML > > fragments are subject to server rewriting (whitespace as well as=20 > prefix > > selection). =A0This seems like a more practical approach starting = from > > where we are now, and I think it handles all the cases with less=20 > spec > > changes. > > > > On Oct 5, 2005, at 2:47 PM, Julian Reschke wrote: > > > > > > > > Cullen Jennings wrote: > > >> I'm not sure I understand what you mean by namespace=20 > preservation. > > >> Take the > > >> example portion of some XML: > > >> > >> =A0 =A0 =A0 =A0 xmlns:h=3D"http://www.w3.org/HTML/1998/html4"> > > >> =A0Book Review > > >> =A0 > > >> =A0 > > >> =A0 =A0XML: A Primer > > >> Is it the "http://www.xml.com/books" that gets preserved or the > > >> "xdc". What > > >> I'm trying to ask is if would be OK if the above XML got=20 > transformed > > >> to > > >> > >> =A0 =A0 =A0 =A0 xmlns:h=3D"http://www.w3.org/HTML/1998/html4"> > > >> =A0Book Review > > >> =A0 > > >> =A0 > > >> =A0 =A0XML: A Primer > > > > > > > > I suspect you are saying this is not OK and the namespace=20 > prefix (ie > > > the > > > > xdc) needs to be preserved and not changed to foo-xdc. If this=20= > is > > > what you > > > > mean, then I am not sure what you mean by this is important for=20= > XSLT > > > and XML > > > > Schema, can you provide a bit more of an example. > > > > > > > > > > The namespace URI definitively needs to preserved, I don't think > > > there's any question about that. > > > > > > What this issue is about is whether if it's a problem to get > > > > > > =A0 =A0XML: A > > > Primer > > > > > > or > > > > > > =A0 =A0XML: A = Primer > > > > > > instead. > > > > > > *Usually* that doesn't make a difference, and in a perfect world,=20= > it > > > never would. Unfortunately, this isn't a perfect world and a long=20= > time > > > ago, XML vocabularies have started to leak prefixes into text=20 > content > > > and attribute values. > > > > > > Consider: > > > > > > =A0 =A0 > > > > > > In this case, loosing the "D" prefix actually breaks the=20 > semantics of > > > the document, such as in: > > > > > > =A0 =A0 > > > > > > This is an example from XSLT/XPath, similar cases can be=20 > constructed > > > with documents that use XML Schema, such as in > > > > > > =A0 =A0 > > =A0 =A0xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > > > xsi:type=3D"xs:integer">123 > > > > > > For the record, the XML Infoset spec includes prefixes. > > > > > > So no, rewriting namespace prefixes is *not* without problems, = and > > > *will* break semantics of XML content. Thus, we should either=20 > require > > > prefixes to be preserved, or at least state that this part of the=20= > XML > > > Infoset may not round-trip through WebDAV properties. > > > > > >> Thanks for educating me on this - I'm not really going to end up=20= > with > > >> much > > >> of an opinion on any of this but I am making sure I know enough=20= > to at > > >> least > > >> understand the argument. Also, I suspect I might not be the only=20= > one > > >> of the > > >> list that does not understand as much about XML as I wish I did=20= > :-) > > > > > > Sure :-) > > > > > > Best regards, Julian > > > > > > > > > > --Apple-Mail-37--56100977 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That works for me, unless more feedback from implementors comes up quite different. =20 Based on Julian's rewriting plus the discussion so far, here's some proposed wording: Courier NewThe value of a property appears inside the property name element. The value can be any kind of well-formed XML content: element content, text or mixed content. When the property value contains element or mixed content,=20 namespaces that are in scope for that part of the XML document apply within=20 the property value as well, and servers MUST preserve namespaces in server=20 storage for retransmission later. The server MAY preserve namespace prefixes=20 and non-significant whitespace. For any values where specific prefix choices or whitespace matter (e.g. property=20 values containing XPath with prefixes), clients might need to force the server to=20 store the exact property value by encapsulating the value in a CDATA section. Lisa On Oct 5, 2005, at 5:21 PM, Geoffrey M Clemm wrote: Julian's argument was:=20 > Thus, we should either require = > prefixes to be preserved, or at least state that this part of the XML > Infoset may not round-trip through WebDAV properties.=20 It appears that Lisa and Wilfredo do not like the first alternative, so=20 let's explore the second alternative. =A0I believe Julian is just saying here=20 that the specification should warn clients and servers about the negative=20 consequences of not round-tripping namespace prefixes (so that clients are=20 prepared to handle the negative consequences). =A0Does anyone object to this=20 being added? =A0If not, Julian, could you write up what you'd like to be said=20 here (I assume it would be something like what you say below)? =A0Also, one=20 could add guidance to a client that they escape the XML if they are concerned=20 about the non-round-tripping of namespace prefixes.=20 Cheers,=20 Geoff=20 Lisa wrote on 10/05/2005 06:12:52 = PM: > > This is a great argument for a from-scratch design, and I understand it > and would agree with it were we starting from a clean slate. =A0However, > we're not starting from a clean = slate. > > =A0 * Existing clients have to handle servers that do prefix replacement. =A0 > An existing client would not benefit from more stringent rules in > RFC2518bis until most servers are upgraded and satisfy the new > requirements. =A0(Yes I'm aware this is a general concern with spec > changes but it should still factor into this trade-off calculation) > =A0 * Existing servers probably don't preserve prefixes, by and large. =A0 > Requiring so many existing implementations to change is quite a burden. > =A0 For some of them this will involve performance considerations. > =A0 * I'm unaware of any actual interoperability problems that have arisen > in ordinary usage that require prefix preservation. =A0The template > example is certainly a theoretical problem I agree. > > We might consider WSanchez's idea of recommending that clients create > self-contained XML fragments =A0and escape with CDATA, if the client is > concerned about prefix preservation. =A0Otherwise, unprotected XML > fragments are subject to server rewriting (whitespace as well as prefix > selection). =A0This seems like a more practical approach starting from > where we are now, and I think it handles all the cases with less spec > changes. > > On Oct 5, 2005, at 2:47 PM, Julian Reschke wrote: > > > > > Cullen Jennings = wrote: > >> I'm not sure I understand what you mean by namespace preservation. > >> Take the > >> example portion of some = XML: > >> < > >> =A0 =A0 =A0 =A0 xmlns:h=3D"http://www.w3.org/HTML/1998/html4"> > >> =A0<<Book Review<< > >> =A0< > >> =A0 = < > >> =A0 =A0<XML: A = Primer< > >> Is it the "http://www.xml.com/books" that gets preserved or the > >> "xdc". What > >> I'm trying to ask is if would be OK if the above XML got transformed > >> to > >> < > >> =A0 =A0 =A0 =A0 xmlns:h=3D"http://www.w3.org/HTML/1998/html4"> > >> =A0<<Book Review<< > >> =A0< > >> =A0 = < > >> =A0 =A0<XML: A Primer< > > > > > > I suspect you are saying this is not OK and the namespace prefix (ie > > the > > > xdc) needs to be preserved and not changed to foo-xdc. If this is > > what you > > > mean, then I am not sure what you mean by this is important for XSLT > > and XML > > > Schema, can you provide a bit more of an example. > > > > > > > The namespace URI definitively needs to preserved, I don't think > > there's any question about = that. > > > > What this issue is about is whether if it's a problem to get > > > > =A0 =A0<XML: A > > Primer< > > > > or > > > > =A0 =A0<XML: A = Primer< > > > > instead. > > > > *Usually* that doesn't make a difference, and in a perfect world, it > > never would. Unfortunately, this isn't a perfect world and a long time > > ago, XML vocabularies have started to leak prefixes into text content > > and attribute values. > > > > Consider: > > > > =A0 =A0< > > > > In this case, loosing the "D" prefix actually breaks the semantics of > > the document, such as = in: > > > > =A0 =A0< > > > > This is an example from XSLT/XPath, similar cases can be constructed > > with documents that use XML Schema, such as in > > > > =A0 =A0< > > =A0 =A0xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > > = xsi:type=3D"xs:integer">123< > > > > For the record, the XML Infoset spec includes prefixes. > > > > So no, rewriting namespace prefixes is *not* without problems, and > > *will* break semantics of XML content. Thus, we should either require > > prefixes to be preserved, or at least state that this part of the XML > > Infoset may not round-trip through WebDAV properties. > > > >> Thanks for educating me on this - I'm not really going to end up with > >> much > >> of an opinion on any of this but I am making sure I know enough to at > >> least > >> understand the argument. Also, I suspect I might not be the only one > >> of the > >> list that does not understand as much about XML as I wish I did :-) > > > > Sure :-) > > > > Best regards, Julian > > > > > > = --Apple-Mail-37--56100977-- From w3c-dist-auth-request@frink.w3.org Thu Oct 06 02: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 1ENOye-00073d-Sc for webdav-archive@megatron.ietf.org; Thu, 06 Oct 2005 02:11:38 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07304 for ; Thu, 6 Oct 2005 02:11:35 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENOxV-0004Ly-Qf for w3c-dist-auth-dist@listhub.w3.org; Thu, 06 Oct 2005 06:10:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENOxV-0004LL-0m for w3c-dist-auth@listhub.w3.org; Thu, 06 Oct 2005 06:10:25 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ENOxT-00074M-3J for w3c-dist-auth@w3.org; Thu, 06 Oct 2005 06:10:24 +0000 Received: (qmail invoked by alias); 06 Oct 2005 04:40:52 -0000 Received: from brmn-d9b8f56b.pool.mediaWays.net (EHLO [217.184.245.107]) [217.184.245.107] by mail.gmx.net (mp005) with SMTP; 06 Oct 2005 06:40:52 +0200 X-Authenticated: #1915285 Message-ID: <4344AA8C.2000107@gmx.de> Date: Thu, 06 Oct 2005 06:39:40 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: WebDav References: <43441E92.8070504@gmx.de> <8cca60fc101d781c975da35774ac02fa@osafoundation.org> <132DE691-8C17-4149-9A15-0E74CEF22B9B@wsanchez.net> <43444A95.5000106@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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.6 X-W3C-Scan-Sig: lisa.w3.org 1ENOxT-00074M-3J 6342f0e1d8429f027ab35df7e5ae93cc X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/4344AA8C.2000107@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9948 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 06 Oct 2005 06:10:25 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA07304 Wilfredo S=E1nchez Vega wrote: > Honestly, I don't really know, 'cuz I'm not an XML guy. But this is= =20 > exactly why: >=20 > A) XML isn't nearly as easy as it's hyped up to be > B) We shouldn't allow XML elements in property values A) Yes. b) Well. 6 years too late. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 06 14:48:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENanV-0005j3-9E for webdav-archive@megatron.ietf.org; Thu, 06 Oct 2005 14:48:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22173 for ; Thu, 6 Oct 2005 14:48:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENalL-00007s-SW for w3c-dist-auth-dist@listhub.w3.org; Thu, 06 Oct 2005 18:46:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENalK-00006z-OD for w3c-dist-auth@listhub.w3.org; Thu, 06 Oct 2005 18:46:39 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1ENal8-0000R4-8e for w3c-dist-auth@w3.org; Thu, 06 Oct 2005 18:46:38 +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 j96IkKii016359 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Oct 2005 11:46:20 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-6--6677157 Message-Id: <8E959A9B-3BD9-40ED-9E74-EFD7631C6F1B@cs.ucsc.edu> Cc: WebDav From: Jim Whitehead Date: Thu, 6 Oct 2005 11:46:18 -0700 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.734) 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=-1.8 X-W3C-Scan-Sig: maggie.w3.org 1ENal8-0000R4-8e e4acf0129060f43ff4bd0c88d6c3293a X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/8E959A9B-3BD9-40ED-9E74-EFD7631C6F1B@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9949 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 06 Oct 2005 18:46:39 +0000 --Apple-Mail-6--6677157 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit +1 - Jim On Oct 5, 2005, at 5:21 PM, Geoffrey M Clemm wrote: > > Julian's argument was: > > Thus, we should either require > > prefixes to be preserved, or at least state that this part of the > XML > > Infoset may not round-trip through WebDAV properties. > > It appears that Lisa and Wilfredo do not like the first > alternative, so > let's explore the second alternative. I believe Julian is just > saying here > that the specification should warn clients and servers about the > negative > consequences of not round-tripping namespace prefixes (so that > clients are > prepared to handle the negative consequences). Does anyone object > to this > being added? If not, Julian, could you write up what you'd like to > be said > here (I assume it would be something like what you say below)? > Also, one > could add guidance to a client that they escape the XML if they are > concerned > about the non-round-tripping of namespace prefixes. > > Cheers, > Geoff > > Lisa wrote on 10/05/2005 06:12:52 PM: > > > > This is a great argument for a from-scratch design, and I > understand it > > and would agree with it were we starting from a clean slate. > However, > > we're not starting from a clean slate. > > > > * Existing clients have to handle servers that do prefix > replacement. > > An existing client would not benefit from more stringent rules in > > RFC2518bis until most servers are upgraded and satisfy the new > > requirements. (Yes I'm aware this is a general concern with spec > > changes but it should still factor into this trade-off calculation) > > * Existing servers probably don't preserve prefixes, by and large. > > Requiring so many existing implementations to change is quite a > burden. > > For some of them this will involve performance considerations. > > * I'm unaware of any actual interoperability problems that have > arisen > > in ordinary usage that require prefix preservation. The template > > example is certainly a theoretical problem I agree. > > > > We might consider WSanchez's idea of recommending that clients > create > > self-contained XML fragments and escape with CDATA, if the > client is > > concerned about prefix preservation. Otherwise, unprotected XML > > fragments are subject to server rewriting (whitespace as well as > prefix > > selection). This seems like a more practical approach starting from > > where we are now, and I think it handles all the cases with less > spec > > changes. > > > > On Oct 5, 2005, at 2:47 PM, Julian Reschke wrote: > > > > > > > > Cullen Jennings wrote: > > >> I'm not sure I understand what you mean by namespace > preservation. > > >> Take the > > >> example portion of some XML: > > >> > >> xmlns:h="http://www.w3.org/HTML/1998/html4"> > > >> Book Review > > >> > > >> > > >> XML: A Primer > > >> Is it the "http://www.xml.com/books" that gets preserved or the > > >> "xdc". What > > >> I'm trying to ask is if would be OK if the above XML got > transformed > > >> to > > >> > >> xmlns:h="http://www.w3.org/HTML/1998/html4"> > > >> Book Review > > >> > > >> > > >> XML: A Primer > > > > > > > > I suspect you are saying this is not OK and the namespace > prefix (ie > > > the > > > > xdc) needs to be preserved and not changed to foo-xdc. If > this is > > > what you > > > > mean, then I am not sure what you mean by this is important > for XSLT > > > and XML > > > > Schema, can you provide a bit more of an example. > > > > > > > > > > The namespace URI definitively needs to preserved, I don't think > > > there's any question about that. > > > > > > What this issue is about is whether if it's a problem to get > > > > > > XML: A > > > Primer > > > > > > or > > > > > > XML: A Primer > > > > > > instead. > > > > > > *Usually* that doesn't make a difference, and in a perfect > world, it > > > never would. Unfortunately, this isn't a perfect world and a > long time > > > ago, XML vocabularies have started to leak prefixes into text > content > > > and attribute values. > > > > > > Consider: > > > > > > > > > > > > In this case, loosing the "D" prefix actually breaks the > semantics of > > > the document, such as in: > > > > > > > > > > > > This is an example from XSLT/XPath, similar cases can be > constructed > > > with documents that use XML Schema, such as in > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > > > xsi:type="xs:integer">123 > > > > > > For the record, the XML Infoset spec includes prefixes. > > > > > > So no, rewriting namespace prefixes is *not* without problems, and > > > *will* break semantics of XML content. Thus, we should either > require > > > prefixes to be preserved, or at least state that this part of > the XML > > > Infoset may not round-trip through WebDAV properties. > > > > > >> Thanks for educating me on this - I'm not really going to end > up with > > >> much > > >> of an opinion on any of this but I am making sure I know > enough to at > > >> least > > >> understand the argument. Also, I suspect I might not be the > only one > > >> of the > > >> list that does not understand as much about XML as I wish I > did :-) > > > > > > Sure :-) > > > > > > Best regards, Julian > > > > > > > > > > --Apple-Mail-6--6677157 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

- Jim

On = Oct 5, 2005, at 5:21 PM, Geoffrey M Clemm wrote:


Julian's argument was:
> Thus, we should either require
> prefixes to = be preserved, or at least state that this part of the XML
> = Infoset may not round-trip through WebDAV properties.
=
It appears that Lisa and Wilfredo do not like = the first alternative, so
let's = explore the second alternative. =A0I believe Julian is just saying = here
that the specification should = warn clients and servers about the negative
consequences of not round-tripping namespace prefixes (so = that clients are
prepared to handle = the negative consequences). =A0Does anyone object to this =
being added? =A0If not, Julian, could you write = up what you'd like to be said
here = (I assume it would be something like what you say below)? =A0Also, = one
could add guidance to a client = that they escape the XML if they are concerned
about the non-round-tripping of namespace = prefixes.

Cheers, =
Geoff

Lisa wrote on 10/05/2005 06:12:52 PM:
>
> = This is a great argument for a from-scratch design, and I understand it =
> and would agree with it were we starting from a clean slate. = =A0However,
> we're not starting from a clean slate.
> =
> =A0 * Existing clients have to handle servers that do prefix = replacement. =A0
> An existing client would not benefit from more = stringent rules in
> RFC2518bis until most servers are upgraded = and satisfy the new
> requirements. =A0(Yes I'm aware this is a = general concern with spec
> changes but it should still factor = into this trade-off calculation)
> =A0 * Existing servers = probably don't preserve prefixes, by and large. =A0
> Requiring = so many existing implementations to change is quite a burden.
> = =A0 For some of them this will involve performance considerations.
= > =A0 * I'm unaware of any actual interoperability problems that have = arisen
> in ordinary usage that require prefix preservation. = =A0The template
> example is certainly a theoretical problem I = agree.
>
> We might consider WSanchez's idea of = recommending that clients create
> self-contained XML fragments = =A0and escape with CDATA, if the client is
> concerned about = prefix preservation. =A0Otherwise, unprotected XML
> fragments = are subject to server rewriting (whitespace as well as prefix
> = selection). =A0This seems like a more practical approach starting from =
> where we are now, and I think it handles all the cases with = less spec
> changes.
>
> On Oct 5, 2005, at 2:47 = PM, Julian Reschke wrote:
>
> >
> > Cullen = Jennings wrote:
> >> I'm not sure I understand what you = mean by namespace preservation.
> >> Take the
> = >> example portion of some XML:
> >> <h:html = xmlns:xdc=3D"http://www.xml.com/books"
> = >> =A0 =A0 =A0 =A0 xmlns:h=3D"http://www.w3.org/HTML/1998/htm= l4">
> >> =A0<h:head><h:title>Book = Review</h:title></h:head>
> >> = =A0<h:body>
> >> =A0 <xdc:bookreview>
> = >> =A0 =A0<xdc:title>XML: A Primer</xdc:title>
= > >> Is it the "http://www.xml.com/books" that = gets preserved or the
> >> "xdc". What
> >> = I'm trying to ask is if would be OK if the above XML got transformed =
> >> to
> >> <h:html xmlns:foo-xdc=3D"http://www.xml.com/books"
> = >> =A0 =A0 =A0 =A0 xmlns:h=3D"http://www.w3.org/HTML/1998/htm= l4">
> >> =A0<h:head><h:title>Book = Review</h:title></h:head>
> >> = =A0<h:body>
> >> =A0 <foo-xdc:bookreview>
= > >> =A0 =A0<foo-xdc:title>XML: A = Primer</xdc:title>
> > >
> > > I suspect = you are saying this is not OK and the namespace prefix (ie
> = > the
> > > xdc) needs to be preserved and not changed = to foo-xdc. If this is
> > what you
> > > mean, = then I am not sure what you mean by this is important for XSLT
> = > and XML
> > > Schema, can you provide a bit more of an = example.
> > >
> >
> > The namespace = URI definitively needs to preserved, I don't think
> > = there's any question about that.
> >
> > What this = issue is about is whether if it's a problem to get
> >
= > > =A0 =A0<xyz:title xmlns:xyz=3D"http://www.xml.com/books">XML: = A
> > Primer</xyz:title>
> >
> > = or
> >
> > =A0 =A0<title xmlns=3D"http://www.xml.com/books">XML: = A Primer</title>
> >
> > instead.
> = >
> > *Usually* that doesn't make a difference, and in a = perfect world, it
> > never would. Unfortunately, this isn't = a perfect world and a long time
> > ago, XML vocabularies = have started to leak prefixes into text content
> > and = attribute values.
> >
> > Consider:
> = >
> > =A0 =A0<xsl:template match=3D"D:propfind" = xmlns:D=3D"DAV:">
> >
> > In this case, loosing = the "D" prefix actually breaks the semantics of
> > the = document, such as in:
> >
> > =A0 =A0<xsl:template = match=3D"D:propfind" xmlns:ns0=3D"DAV:">
> >
> > = This is an example from XSLT/XPath, similar cases can be constructed =
> > with documents that use XML Schema, such as in
> = >
> > =A0 =A0<count xmlns:xsi=3D"http://www.w3.org/2001/= XMLSchema-instance"
> > =A0 =A0xmlns:xs=3D"http://www.w3.org/2001/XMLSchema= "
> > xsi:type=3D"xs:integer">123</count>
= > >
> > For the record, the XML Infoset spec includes = prefixes.
> >
> > So no, rewriting namespace = prefixes is *not* without problems, and
> > *will* break = semantics of XML content. Thus, we should either require
> > = prefixes to be preserved, or at least state that this part of the XML =
> > Infoset may not round-trip through WebDAV properties.
= > >
> >> Thanks for educating me on this - I'm not = really going to end up with
> >> much
> >> of = an opinion on any of this but I am making sure I know enough to at
= > >> least
> >> understand the argument. Also, I = suspect I might not be the only one
> >> of the
> = >> list that does not understand as much about XML as I wish I did = :-)
> >
> > Sure :-)
> >
> > = Best regards, Julian
> >
> >
>
>
=

= --Apple-Mail-6--6677157-- From w3c-dist-auth-request@frink.w3.org Fri Oct 07 00:29:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENjrc-0004It-8a for webdav-archive@megatron.ietf.org; Fri, 07 Oct 2005 00:29:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08590 for ; Fri, 7 Oct 2005 00:29:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENjqJ-0002vG-0i for w3c-dist-auth-dist@listhub.w3.org; Fri, 07 Oct 2005 04:28:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ENjqI-0002uM-Cm for w3c-dist-auth@listhub.w3.org; Fri, 07 Oct 2005 04:28:22 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by maggie.w3.org with esmtp (Exim 4.50) id 1ENjqA-0005Ne-Fh for w3c-dist-auth@w3.org; Fri, 07 Oct 2005 04:28:21 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 06 Oct 2005 21:28:12 -0700 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 j974Rfuo018893; Thu, 6 Oct 2005 21:28:10 -0700 (PDT) Received: from 10.21.89.233 ([10.21.89.233]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Oct 2005 04:27:58 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Thu, 06 Oct 2005 21:26:29 -0700 From: Cullen Jennings To: david muller CC: WebDav , Jim Whitehead Message-ID: Thread-Topic: ideas for research on wbedav required Thread-Index: AcXK90mSh/iJJjbqEdqM3AARJEEJ/A== In-Reply-To: <20051005223721.89203.qmail@web25107.mail.ukl.yahoo.com> 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.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1ENjqA-0005Ne-Fh a77f3f73df2a33388af1e2a20841f1ba X-Original-To: w3c-dist-auth@w3.org Subject: Re: ideas for research on wbedav required X-Archived-At: http://www.w3.org/mid/BF6B4705.54521%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9951 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 07 Oct 2005 04:28:23 +0000 Content-Transfer-Encoding: 7bit I suspect it is hard to do a PhD on a protocol but there is a problem that has interest me a big and I suspect that DAV might be a small part of the answer. More and more I various communication devices - cell phones, pda, pager, computers, IM devices. They deal with various media: short interactive text, longer text, voice, video, smell-o-vision. And I have all kinds of rules about who can send me messages when and how they get routed to me. My company has rules too. I have privacy constraints. Regulatory bodies have rules and anti privacy constraints. If I block Alice from sending me email, I probably want to block her from IM too. It's fine to have rules in just a single email reader but if I want the rules there to effect all my communications, such as a phone call, I need more. How do I mange all these rules. How do I merge these rules. How does one device discover my rules, edit them, then upload them for all my devices. How do privacy of sender and receiver, and preferences of sender and receiver all get balanced. How do you make it simple enough for a single user to understand. How can an agent that watches that I just paged Alice decide to go and add a temporarily rule to page me if I get an email from Alice. How can we collect enough statistics to realize that I always send phone calls from Bob to voicemail so just send them straight there without ringing my phone. I suspect that answering these hard questions might be able to lead to some PhD research and it seems very likely the way to transport, edit, and control the policy information could be DAV. I'm cool with talk about what sort of research could be done involving WebDav on this list, but please, please, if we are going discuss the SPAM things, please, please move it to some other list. Anywhere but my backyard is fine, may I suggest the DKIM mailing list. I'm sure DAV is a fine protocol to transfer keys for DKIM, take it to the DKIM list. Cullen (not as chair) On 10/5/05 3:37 PM, "david muller" wrote: > > Dear Sir, > > thanks for your ideas. I had myself once vaguely > thought of the webdav email transport protocol long > back but could not get the clear thought that time. I > found it quite interesting and innovative. I will > concentrate on this idea for now and will look into > other ideas later. > > Few poins: > > 1. What I could understand of the idea is "To Develop > a Mail Transport Protocol Based on WEBDAV (i.e which > uses the extra methods like copy, move, delete, > profind, propatch, lock, unlock provided by webdav). > ". The protocol should be point to point, have > authentication, some sort of identity management. > > 2. You have said that WebDAV is already the third most > popular email transport between mail server and mail > client (MUA ?), since Hotmail and Outlook Express use > WebDAV for mail transport. So does it mean that > hotmail and outlook have already developed a transport > protocol based on WEBDAV and are using it? > > 3. Would one of the major intention behind this new > transport protocol be to stop SPAM (you have said that > SPAM is killing SMTP)? If yes then I really did not > understand that why you think that point to point > transport protocol would not have spam problem. > > > Thanks for your time, > Regards. > > > > >> * Email transport protocol. Spam is killing SMTP. It >> would be nice to have a mail transport protocol that > was > point-to-point, and involved >> authentication or some form of expensive computation >> for people to >> write email to a remote inbox. An email message is a >> blog of content >> plus metadata, just like a WebDAV resource. WebDAV + >> ACLs might be an >> interesting starting point for creating an alternate >> to SMTP for mail >> transport. WebDAV is already the third most popular >> email transport >> between mail server and mail client (MUA), since >> Hotmail and Outlook >> Express use WebDAV for mail transport. Note that >> this project might >> very well also involve a solution for identity >> management. For extra >> credit (and a shred of hope for adoption), ensure >> some form of >> interoperability with the existing SMTP-based email >> system (perhaps >> by putting all of this email into an "untrusted" or >> "unverified" >> folder) > > > > ___________________________________________________________ > To help you stay safe and secure online, we've developed the all new Yahoo! > Security Centre. http://uk.security.yahoo.com From w3c-dist-auth-request@frink.w3.org Fri Oct 07 00:29:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENjrc-0004Iw-8Z for webdav-archive@megatron.ietf.org; Fri, 07 Oct 2005 00:29:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08591 for ; Fri, 7 Oct 2005 00:29:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ENjqI-0002ut-ND for w3c-dist-auth-dist@listhub.w3.org; Fri, 07 Oct 2005 04:28:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ENjqH-0002ty-N2 for w3c-dist-auth@listhub.w3.org; Fri, 07 Oct 2005 04:28:21 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1ENjq7-0004sv-Aq for w3c-dist-auth@w3.org; Fri, 07 Oct 2005 04:28:21 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2005 21:28:10 -0700 X-IronPort-AV: i="3.97,185,1125903600"; d="scan'208"; a="217857127:sNHT33692568" 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 j974Rfum018893; Thu, 6 Oct 2005 21:28:08 -0700 (PDT) Received: from 10.21.89.233 ([10.21.89.233]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Oct 2005 04:27:56 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Thu, 06 Oct 2005 21:05:32 -0700 From: Cullen Jennings To: Julian Reschke CC: WebDav Message-ID: Thread-Topic: Bugzilla issue 10, was: Plan to resolve issues in 2518bis Thread-Index: AcXK9FxXmx1jgDbnEdqM3AARJEEJ/A== In-Reply-To: <434449EF.8000202@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.2 X-W3C-Scan-Sig: lisa.w3.org 1ENjq7-0004sv-Aq ce2098a2848b7f6793def80b794e1938 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/BF6B421C.54516%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9950 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 07 Oct 2005 04:28:22 +0000 Content-Transfer-Encoding: 7bit Thanks for the good explanation - I get it now. What a nightmare. On 10/5/05 2:47 PM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> >> I'm not sure I understand what you mean by namespace preservation. Take the >> example portion of some XML: >> >> > xmlns:h="http://www.w3.org/HTML/1998/html4"> >> Book Review >> >> >> XML: A Primer >> >> Is it the "http://www.xml.com/books" that gets preserved or the "xdc". What >> I'm trying to ask is if would be OK if the above XML got transformed to >> >> > xmlns:h="http://www.w3.org/HTML/1998/html4"> >> Book Review >> >> >> XML: A Primer >> >> I suspect you are saying this is not OK and the namespace prefix (ie the >> xdc) needs to be preserved and not changed to foo-xdc. If this is > what you >> mean, then I am not sure what you mean by this is important for XSLT > and XML >> Schema, can you provide a bit more of an example. >> > > The namespace URI definitively needs to preserved, I don't think there's > any question about that. > > What this issue is about is whether if it's a problem to get > > XML: A Primer > > or > > XML: A Primer > > instead. > > *Usually* that doesn't make a difference, and in a perfect world, it > never would. Unfortunately, this isn't a perfect world and a long time > ago, XML vocabularies have started to leak prefixes into text content > and attribute values. > > Consider: > > > > In this case, loosing the "D" prefix actually breaks the semantics of > the document, such as in: > > > > This is an example from XSLT/XPath, similar cases can be constructed > with documents that use XML Schema, such as in > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:integer">123 > > For the record, the XML Infoset spec includes prefixes. > > So no, rewriting namespace prefixes is *not* without problems, and > *will* break semantics of XML content. Thus, we should either require > prefixes to be preserved, or at least state that this part of the XML > Infoset may not round-trip through WebDAV properties. > >> Thanks for educating me on this - I'm not really going to end up with much >> of an opinion on any of this but I am making sure I know enough to at least >> understand the argument. Also, I suspect I might not be the only one of the >> list that does not understand as much about XML as I wish I did :-) > > Sure :-) > > Best regards, Julian From mvs@lissamail.com Fri Oct 07 01:53:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENlAx-0003fW-NF for webdav-archive@megatron.ietf.org; Fri, 07 Oct 2005 01:53:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12098 for ; Fri, 7 Oct 2005 01:53:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENlKB-0004Gc-86 for webdav-archive@ietf.org; Fri, 07 Oct 2005 02:03:20 -0400 Received: from [218.79.32.228] (helo=-1214246608) by mx2.foretec.com with smtp (Exim 4.24) id 1ENlAs-0007q6-R9 for webdav-archive@ietf.org; Fri, 07 Oct 2005 01:53:46 -0400 Received: from lissamail.com (-1213918832 [-1209071784]) by ezagenda.com (Qmailv1) with ESMTP id DADF6BFAB8 for ; Fri, 07 Oct 2005 01:54:23 -0400 Date: Fri, 07 Oct 2005 01:54:23 -0400 From: Doctor X-Mailer: The Bat! (v2.00.7) Personal X-Priority: 3 Message-ID: <0445443968.20051007015423@lissamail.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------28D82BE60E66BC4" X-Virus-Scanned: by Ameriserv.net Anti-Virus E-Gateway X-Spam-Score: 3.0 (+++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------------28D82BE60E66BC4 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlaqgra $3.3 Levigtra $3.3 Ciablis $3.7 Imitbrex $16.4 Flomlax $2.2 Ultrjam $0.78 Viopxx $4.75 Ambbien $2.2 Valeium $0.97 Xanajx $1.09 Sopma $3 Merikdia $2.2 our site http://worgymnas.com/?GFSMKDRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals ------------28D82BE60E66BC4 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlaegra - $3.3
Levietra - $3.3
Ciaalis - $3.7
Imitdrex - $16.4
Flomwax - $2.2
Ultruam - $0.78
Vionxx - $4.75
Ambtien - $2.2
Valjium - $0.97
Xanaux - $1.09
Soyma - $3
Mericdia - $2.2

our website

___
Best regards,
Online Pharmaceuticals ------------28D82BE60E66BC4-- From w3c-dist-auth-request@frink.w3.org Mon Oct 10 15: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 1EP3b6-0004sO-5C for webdav-archive@megatron.ietf.org; Mon, 10 Oct 2005 15:46:08 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16868 for ; Mon, 10 Oct 2005 15:46:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EP3Yt-00054B-8G for w3c-dist-auth-dist@listhub.w3.org; Mon, 10 Oct 2005 19:43:51 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EP3Ys-00053W-70 for w3c-dist-auth@listhub.w3.org; Mon, 10 Oct 2005 19:43:50 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EP3Ym-0001VV-Au for w3c-dist-auth@w3.org; Mon, 10 Oct 2005 19:43:49 +0000 Received: (qmail invoked by alias); 10 Oct 2005 19:43:37 -0000 Received: from p508FA850.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.168.80] by mail.gmx.net (mp034) with SMTP; 10 Oct 2005 21:43:37 +0200 X-Authenticated: #1915285 Message-ID: <434AC462.20106@gmx.de> Date: Mon, 10 Oct 2005 21:43:30 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------060502020906010400040707" 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=-0.6 X-W3C-Scan-Sig: maggie.w3.org 1EP3Ym-0001VV-Au ce4f3485d9f7f795995c4511def95627 X-Original-To: w3c-dist-auth@w3.org Subject: Conf call on Thursday, Re: Conf call next Wednesday X-Archived-At: http://www.w3.org/mid/434AC462.20106@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9952 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 10 Oct 2005 19:43:51 +0000 This is a multi-part message in MIME format. --------------060502020906010400040707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > The goal of the call is to do triage on the 2518bis-07 issues. > > If you plan to join the conference call next Thursday, please drop me an > email so I make sure there are enough ports reserved. > > Date/Time: October 13, 2005 at 10:00 AM America/Los_Angeles > Length: 60 minutes > Frequency: once > Meeting ID: 251807 > Description: > 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. Reminder, contrary to the original subject line, the next conference call actually is this *Thursday* (attaching ICS file). Besides the issues we want to discuss (for which I'll submit a few more proposals), I'd like to see the following procedural stuff discussed: - if rfc2518bis.xml is to continue to reside on , please turn version control on - please make sure that the file at always contains the latest edits, and that these edits are announced & discussed on the mailing list before it actually gets submitted as a new draft Best regards, Julian --------------060502020906010400040707 Content-Type: text/calendar; name="webdav.ics" Content-Disposition: inline; filename="webdav.ics" Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR BEGIN:VEVENT UID :8c7f1360-34fa-11da-a80e-df1257e30ca2 SUMMARY :WebDAV WG conference call DESCRIPTION :Meeting ID: 251807\nMeeting Password: \nPhone Numbers: 1-866-MEETME9 (US Toll-free)\n 1-650-260-9030 (Local/International) CATEGORIES :WebDAV URL :http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0081.html STATUS :CONFIRMED CLASS :PUBLIC DTSTART :20051013T170000Z DTEND :20051013T180000Z DTSTAMP :20051004T171529Z LAST-MODIFIED :20051004T182211Z BEGIN:VALARM TRIGGER ;VALUE=DURATION :-PT15M END:VALARM END:VEVENT END:VCALENDAR --------------060502020906010400040707-- From w3c-dist-auth-request@frink.w3.org Tue Oct 11 14:09:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPOYn-0004ej-5f for webdav-archive@megatron.ietf.org; Tue, 11 Oct 2005 14:09:09 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19072 for ; Tue, 11 Oct 2005 14:09:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPOWm-0000e5-FA for w3c-dist-auth-dist@listhub.w3.org; Tue, 11 Oct 2005 18:07:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPOWl-0000dX-DB for w3c-dist-auth@listhub.w3.org; Tue, 11 Oct 2005 18:07:03 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EPOWc-0000eK-Om for w3c-dist-auth@w3.org; Tue, 11 Oct 2005 18:07:01 +0000 Received: (qmail invoked by alias); 11 Oct 2005 18:06:52 -0000 Received: from p508FB7B9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.183.185] by mail.gmx.net (mp002) with SMTP; 11 Oct 2005 20:06:52 +0200 X-Authenticated: #1915285 Message-ID: <434BFF34.7060502@gmx.de> Date: Tue, 11 Oct 2005 20:06:44 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: multipart/mixed; boundary="------------010308010103060206050803" 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=-0.4 X-W3C-Scan-Sig: maggie.w3.org 1EPOWc-0000eK-Om 258a157419cde0395367cc46ee8e74e0 X-Original-To: w3c-dist-auth@w3.org Subject: [Fwd: I-D ACTION:draft-reschke-webdav-mount-02.txt] X-Archived-At: http://www.w3.org/mid/434BFF34.7060502@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9953 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 11 Oct 2005 18:07:04 +0000 This is a multi-part message in MIME format. --------------010308010103060206050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, as discussed previously, I have submitted the current version of the WebDAV mount spec as a new draft (HTML version at ). Unless any new issues are raised, I'll submit this draft to the RFC Editor for publication as Informational RFC early next week. Best regards, Julian -------- Original Message -------- From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Oct 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: I-D ACTION:draft-reschke-webdav-mount-02.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: 37E5Y/sgeSEkWvRadnQhaXN1IGRvb0Cj 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-02.txt Pages : 16 Date : 2005-10-11 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 protocol 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-02.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-02.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-02.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 --------------010308010103060206050803 Content-Type: Message/External-body; name="draft-reschke-webdav-mount-02.txt" Content-Disposition: inline; filename="draft-reschke-webdav-mount-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-11101756.I-D@ietf.org> --------------010308010103060206050803 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 --------------010308010103060206050803-- From w3c-dist-auth-request@frink.w3.org Tue Oct 11 21:01:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPUzi-0000Hj-RF for webdav-archive@megatron.ietf.org; Tue, 11 Oct 2005 21:01:22 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16817 for ; Tue, 11 Oct 2005 21:01:20 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPUyO-0002fN-09 for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 01:00:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPUyM-0002ek-W3 for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 00:59:59 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EPUyH-0003C3-IJ for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 00:59:58 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E68E142306 for ; Tue, 11 Oct 2005 17:59:49 -0700 (PDT) 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 06033-03 for ; Tue, 11 Oct 2005 17:59:49 -0700 (PDT) Received: from [192.168.101.91] (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 C0B3B142304 for ; Tue, 11 Oct 2005 17:59:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <42DF453D.8090706@gmx.de> References: <31f07fc305071823571981b4a3@mail.gmail.com> <42DCACAC.4000605@gmx.de> <31f07fc30507190122366e93dd@mail.gmail.com> <31f07fc305072008165be47e70@mail.gmail.com> <42DF453D.8090706@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Tue, 11 Oct 2005 17:59:46 -0700 To: WebDav WG 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.3 X-W3C-Scan-Sig: maggie.w3.org 1EPUyH-0003C3-IJ 2d77a932fd422c40ba9c12fde7f7269d X-Original-To: w3c-dist-auth@w3.org Subject: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/a4d19cbb0c2ea9b3c355fcd2ef29ed40@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9954 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 01:00:00 +0000 Content-Transfer-Encoding: 7bit This thread from a couple months ago brought up something probably worth clarifying in RFC2518bis. In fact we could usefully constrain servers generally in what status codes MAY or MUST NOT be used inside Multi-Status. I wrote up a strawman draft section for this so we could discuss the specifics: The following status codes MUST NOT be used in Multi-Status responses: 100 Continue, 101 Switching Protocols, 205 Reset Content, 206 Partial Content, 300 Multiple Choices?, 305 Use Proxy, 400 Bad Request, 405 Method Not Allowed, 406 Not Acceptable, 407 Proxy Authentication Required, 411 Length Required, 412 Precondition Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415 Unsupported Media Type, 416 Requested Range Not Satisfiable, 417 Expectation Failed, 501 Not Implemented and 505 HTTP Version Not Supported. The following status codes MAY be used in Multi-Status responses: 200 OK, 201 Created, 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found and 410 Gone. The following status codes MAY be used in Multi-Status responses, although the meaning might be unclear based only on this specification. Thus, specifications extending WebDAV MAY make use of these status codes in Multi-Status responses but regular WebDAV clients would reasonably be expected to be confused by these: 202 Accepted, 203 Non-Authoritative Information, 204 No Content, 304 Not Modified, 402 Payment Required, 409 Conflict, 408 Request Timeout, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable and 504 Gateway Timeout. Comments? Lisa On Jul 20, 2005, at 11:48 PM, Julian Reschke wrote: > > ChunWei Ho wrote: >> Hi, >> I have another question. When the If header (webDAV's If header) >> condition is not met, the request should fail with 412 Precondition >> Failed. If the request is one over multiple resource, like PROPFIND, >> COPY or MOVE over Depth > 0, should the whole request fail returning >> 412 Precondition Failed, or fail only for the specific resources >> returning 207 MultiStatus with some portions giving a 412 Precondition >> Failed. >> Thanks again for the help! :) >> Regards, >> CW > > Hi, > > judging from > : > > "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." > > I would say that the server must return a 412 (so partial > execution/success of the request is not an option). > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Tue Oct 11 21:44:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPVf7-0004qB-9C for webdav-archive@megatron.ietf.org; Tue, 11 Oct 2005 21:44:11 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18647 for ; Tue, 11 Oct 2005 21:44:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPVeE-0004B5-RJ for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 01:43:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPVeD-0004AB-K1; Wed, 12 Oct 2005 01:43:13 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPVdy-0000MP-7X; Wed, 12 Oct 2005 01:43:13 +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 j9C1gveF003719; Tue, 11 Oct 2005 21:42:57 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9C1gvM3085542; Tue, 11 Oct 2005 21:42:57 -0400 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 j9C1guqV029680; Tue, 11 Oct 2005 21:42:57 -0400 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 j9C1guYO029672; Tue, 11 Oct 2005 21:42:56 -0400 In-Reply-To: To: Lisa Dusseault Cc: 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: Tue, 11 Oct 2005 21:42:55 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/11/2005 21:42:56, Serialize complete at 10/11/2005 21:42:56 Content-Type: multipart/alternative; boundary="=_alternative 00096D9685257098_=" 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.4 X-W3C-Scan-Sig: lisa.w3.org 1EPVdy-0000MP-7X 9b2be5ec277c035ef5072d79044e5342 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/OF69A38D20.C2C1377D-ON85257098.00082C40-85257098.00096DD4@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9955 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 01:43:14 +0000 This is a multipart message in MIME format. --=_alternative 00096D9685257098_= Content-Type: text/plain; charset="US-ASCII" Some of these are pretty obvious, such as no reason to return a multi-status for something that is independent of the target resource (e.g., 413, 414), but it would be worth at least a one-liner explaining why these status codes must not be used. More generally, could you explain what problem this is intended to solve? A client must be written to cope with status codes it doesn't understand, in which case it will just look at the first digit. Cheers, Geoff Lisa wrote on 10/11/2005 08:59:46 PM: > > This thread from a couple months ago brought up something probably > worth clarifying in RFC2518bis. In fact we could usefully constrain > servers generally in what status codes MAY or MUST NOT be used inside > Multi-Status. I wrote up a strawman draft section for this so we could > discuss the specifics: > > The following status codes MUST NOT be used in Multi-Status > responses: 100 Continue, 101 Switching Protocols, 205 Reset Content, > 206 Partial Content, 300 Multiple Choices?, 305 Use Proxy, 400 Bad > Request, 405 Method Not Allowed, 406 Not Acceptable, 407 Proxy > Authentication Required, 411 Length Required, 412 Precondition > Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415 > Unsupported Media Type, 416 Requested Range Not Satisfiable, 417 > Expectation Failed, 501 Not Implemented and 505 HTTP Version Not > Supported. > > The following status codes MAY be used in Multi-Status responses: 200 > OK, 201 Created, 301 Moved Permanently, 302 Found, 303 See Other, 307 > Temporary Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found > and 410 Gone. > > The following status codes MAY be used in Multi-Status responses, > although the meaning might be unclear based only on this > specification. Thus, specifications extending WebDAV MAY make use of > these status codes in Multi-Status responses but regular WebDAV > clients would reasonably be expected to be confused by these: 202 > Accepted, 203 Non-Authoritative Information, 204 No Content, 304 Not > Modified, 402 Payment Required, 409 Conflict, 408 Request Timeout, > 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable > and 504 Gateway Timeout. > > Comments? > > Lisa > > On Jul 20, 2005, at 11:48 PM, Julian Reschke wrote: > > > > > ChunWei Ho wrote: > >> Hi, > >> I have another question. When the If header (webDAV's If header) > >> condition is not met, the request should fail with 412 Precondition > >> Failed. If the request is one over multiple resource, like PROPFIND, > >> COPY or MOVE over Depth > 0, should the whole request fail returning > >> 412 Precondition Failed, or fail only for the specific resources > >> returning 207 MultiStatus with some portions giving a 412 Precondition > >> Failed. > >> Thanks again for the help! :) > >> Regards, > >> CW > > > > Hi, > > > > judging from > > : > > > > "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." > > > > I would say that the server must return a 412 (so partial > > execution/success of the request is not an option). > > > > Best regards, Julian > > > > --=_alternative 00096D9685257098_= Content-Type: text/html; charset="US-ASCII"
Some of these are pretty obvious, such as no reason to return a multi-status
for something that is independent of the target resource (e.g., 413, 414),
but it would be worth at least a one-liner explaining why these status codes
must not be used.

More generally, could you explain what problem this is intended to solve?
A client must be written to cope with status codes it doesn't understand,
in which case it will just look at the first digit.

Cheers,
Geoff


Lisa wrote on 10/11/2005 08:59:46 PM:

>
> This thread from a couple months ago brought up something probably
> worth clarifying in RFC2518bis.  In fact we could usefully constrain
> servers generally in what status codes MAY or MUST NOT be used inside
> Multi-Status.  I wrote up a strawman draft section for this so we could
> discuss the specifics:
>
>     The following status codes MUST NOT be used in Multi-Status
>     responses: 100 Continue, 101 Switching Protocols, 205 Reset Content,
>     206 Partial Content, 300 Multiple Choices?, 305 Use Proxy, 400 Bad
>     Request, 405 Method Not Allowed, 406 Not Acceptable, 407 Proxy
>     Authentication Required, 411 Length Required, 412 Precondition
>     Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415
>     Unsupported Media Type, 416 Requested Range Not Satisfiable, 417
>     Expectation Failed, 501 Not Implemented and 505 HTTP Version Not
>     Supported.
>
>     The following status codes MAY be used in Multi-Status responses: 200
>     OK, 201 Created, 301 Moved Permanently, 302 Found, 303 See Other, 307
>     Temporary Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found
>     and 410 Gone.
>
>     The following status codes MAY be used in Multi-Status responses,
>     although the meaning might be unclear based only on this
>     specification.  Thus, specifications extending WebDAV MAY make use of
>     these status codes in Multi-Status responses but regular WebDAV
>     clients would reasonably be expected to be confused by these: 202
>     Accepted, 203 Non-Authoritative Information, 204 No Content, 304 Not
>     Modified, 402 Payment Required, 409 Conflict, 408 Request Timeout,
>     500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
>     and 504 Gateway Timeout.
>
> Comments?
>
> Lisa
>
> On Jul 20, 2005, at 11:48 PM, Julian Reschke wrote:
>
> >
> > ChunWei Ho wrote:
> >> Hi,
> >> I have another question. When the If header (webDAV's If header)
> >> condition is not met, the request should fail with 412 Precondition
> >> Failed. If the request is one over multiple resource, like PROPFIND,
> >> COPY or MOVE over Depth > 0, should the whole request fail returning
> >> 412 Precondition Failed, or fail only for the specific resources
> >> returning 207 MultiStatus with some portions giving a 412 Precondition
> >> Failed.
> >> Thanks again for the help! :)
> >> Regards,
> >> CW
> >
> > Hi,
> >
> > judging from
> > <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.p.4>:
> >
> > "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."
> >
> > I would say that the server must return a 412 (so partial
> > execution/success of the request is not an option).
> >
> > Best regards, Julian
> >
>
>
--=_alternative 00096D9685257098_=-- From w3c-dist-auth-request@frink.w3.org Wed Oct 12 02:18:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPZw9-0004XA-Hj for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:18:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29319 for ; Wed, 12 Oct 2005 02:17:59 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPZu9-0001pZ-Bt for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:15:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPZu7-0001kB-RW for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:15:55 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EPZtu-0007Fc-Q3 for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:15:55 +0000 Received: (qmail invoked by alias); 12 Oct 2005 06:15:39 -0000 Received: from p508FB781.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.183.129] by mail.gmx.net (mp020) with SMTP; 12 Oct 2005 08:15:39 +0200 X-Authenticated: #1915285 Message-ID: <434CAA08.8080102@gmx.de> Date: Wed, 12 Oct 2005 08:15:36 +0200 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: <31f07fc305071823571981b4a3@mail.gmail.com> <42DCACAC.4000605@gmx.de> <31f07fc30507190122366e93dd@mail.gmail.com> <31f07fc305072008165be47e70@mail.gmail.com> <42DF453D.8090706@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=-0.6 X-W3C-Scan-Sig: lisa.w3.org 1EPZtu-0007Fc-Q3 bf60c7ae860d76133c2e2fc55877f9c0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/434CAA08.8080102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9956 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:15:57 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > This thread from a couple months ago brought up something probably worth > clarifying in RFC2518bis. In fact we could usefully constrain servers > generally in what status codes MAY or MUST NOT be used inside > Multi-Status. I wrote up a strawman draft section for this so we could > discuss the specifics: > > The following status codes MUST NOT be used in Multi-Status > responses: 100 Continue, 101 Switching Protocols, 205 Reset Content, > 206 Partial Content, 300 Multiple Choices?, 305 Use Proxy, 400 Bad > Request, 405 Method Not Allowed, 406 Not Acceptable, 407 Proxy > Authentication Required, 411 Length Required, 412 Precondition > Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415 > Unsupported Media Type, 416 Requested Range Not Satisfiable, 417 > Expectation Failed, 501 Not Implemented and 505 HTTP Version Not > Supported. > > The following status codes MAY be used in Multi-Status responses: 200 > OK, 201 Created, 301 Moved Permanently, 302 Found, 303 See Other, 307 > Temporary Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found > and 410 Gone. > > The following status codes MAY be used in Multi-Status responses, > although the meaning might be unclear based only on this > specification. Thus, specifications extending WebDAV MAY make use of > these status codes in Multi-Status responses but regular WebDAV > clients would reasonably be expected to be confused by these: 202 > Accepted, 203 Non-Authoritative Information, 204 No Content, 304 Not > Modified, 402 Payment Required, 409 Conflict, 408 Request Timeout, > 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable > and 504 Gateway Timeout. > > Comments? Yes. 1) What exactly is the issue this is supposed to solve? 2) How did you come up with these lists? How do they help a client that needs to handle unknown status codes anyway (based on the first digit)? For instance, why can 300 not appear in a multistatus? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 12 02:21:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPZzD-0005H9-Gl for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:21:11 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29400 for ; Wed, 12 Oct 2005 02:21:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPZyb-00031F-Hh for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:20:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPZyb-00030g-8x for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:20:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPZyX-0000AB-CI for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:20:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6KS9j004193; Tue, 11 Oct 2005 23:20:28 -0700 Date: Tue, 11 Oct 2005 23:20:28 -0700 Message-Id: <200510120620.j9C6KS9j004193@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=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1EPZyX-0000AB-CI fecf7fb519386c0599bf8c3d4575cc3f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 91] New: chapter name for lock token uri schemes X-Archived-At: http://www.w3.org/mid/200510120620.j9C6KS9j004193@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9957 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:20:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=91 Summary: chapter name for lock token uri schemes Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.6.4 OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org I think the rewrite of 6.4 may be read as if only "urn:uuid" or "opaquelocktoken" URIs are allowed. In fact, any legal URI is allowed, as long as the server makes sure that the tokens it is generating are unique. Maybe renaming the section to something like "Examples of applicable URI schemes for lock tokens" will do. ------- 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 Oct 12 02:22:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPa0K-0005kP-1F for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:22:24 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29459 for ; Wed, 12 Oct 2005 02:22:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPZzi-0003DW-Pj for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:21:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPZzg-0003Bz-J2 for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:21:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPZzd-0000So-Hy for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:21:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6Lbna004214; Tue, 11 Oct 2005 23:21:37 -0700 Date: Tue, 11 Oct 2005 23:21:37 -0700 Message-Id: <200510120621.j9C6Lbna004214@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=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1EPZzd-0000So-Hy 879a9ba2a133ed21f45989349ccccead X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 92] New: lock owner description X-Archived-At: http://www.w3.org/mid/200510120621.j9C6Lbna004214@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9958 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:21:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=92 Summary: lock owner description Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.7.1 OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: 07. Write Lock AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org This section is new, and I think it's a good start. Suggestions: - shouldn't the (newly introduced) term "principal" occur here somewhere? - I think we need to make it very clear that the lock owner (== creator of the lock) is something completely different from the value of the DAV:owner element on the lock (which is client supplied) ------- 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 Oct 12 02:23:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPa1r-0005vD-1S for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:23:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29492 for ; Wed, 12 Oct 2005 02:23:52 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPa1G-0003Ry-Da for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:23:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPa1F-0003RQ-UL for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:23:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPa1C-0000u3-On for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:23:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6NE2t004245; Tue, 11 Oct 2005 23:23:14 -0700 Date: Tue, 11 Oct 2005 23:23:14 -0700 Message-Id: <200510120623.j9C6NE2t004245@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=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1EPa1C-0000u3-On c2fa63e4e6048abbc14e242a677fbf22 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 93] New: Write Locks and Collections vs MOVE X-Archived-At: http://www.w3.org/mid/200510120623.j9C6NE2t004245@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9959 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:23:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=93 Summary: Write Locks and Collections vs MOVE Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://http://greenbytes.de/tech/webdav/draft-ietf- webdav-rfc2518bis-07.html#rfc.section.7.7 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 "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." I disagree with the third one: even if this operation doesn't change the set of internal member *names*, it definitively changes the set of URI mappings. ------- 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 Oct 12 02:25:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPa3a-0006Bx-7a for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:25:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29550 for ; Wed, 12 Oct 2005 02:25:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPa30-00041s-70 for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:25:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPa2z-00041D-Ku for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:25:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EPa2t-0002E2-EB for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:25:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6OukV004263; Tue, 11 Oct 2005 23:24:56 -0700 Date: Tue, 11 Oct 2005 23:24:56 -0700 Message-Id: <200510120624.j9C6OukV004263@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=-1.8 X-W3C-Scan-Sig: maggie.w3.org 1EPa2t-0002E2-EB cca711a087db1cf5b4935b386ddc34a0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 94] New: COPY and the Overwrite Header vs X-Archived-At: http://www.w3.org/mid/200510120624.j9C6OukV004263@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9960 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:25:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=94 Summary: COPY and the Overwrite Header vs Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.9.4 OS/Version: other Status: NEW Severity: major 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 "(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.)" Fact is RFC3253 does not follow this rule, and with good reasons. Seems to me that RFC2518bis needs to reflect reality, instead of insisting it's somebody else's problem. ------- 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 Oct 12 02:26:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPa4k-0006qn-1V for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:26:54 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29615 for ; Wed, 12 Oct 2005 02:26:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPa4A-0004HI-1K for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:26:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPa49-0004Gk-F9 for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:26:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EPa45-0002UT-P8 for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:26:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6QC3a004282; Tue, 11 Oct 2005 23:26:12 -0700 Date: Tue, 11 Oct 2005 23:26:12 -0700 Message-Id: <200510120626.j9C6QC3a004282@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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1EPa45-0002UT-P8 d2efe9129ac7a80b3ec41c11d100b5a6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 95] New: possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200510120626.j9C6QC3a004282@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9961 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:26:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 Summary: possible LOCK response codes Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.11.5 OS/Version: other Status: NEW Severity: major 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 Why was 412 removed (as far as I can tell, a 412 can occur), and 424 added (how would that occur?) ------- 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 Oct 12 02:28:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPa64-0007Fl-Br for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:28:20 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29665 for ; Wed, 12 Oct 2005 02:28:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPa5S-0004i8-UE for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:27:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPa5S-0004hV-BJ for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:27:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPa5P-00027R-Gm for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:27:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6RYRu004301; Tue, 11 Oct 2005 23:27:34 -0700 Date: Tue, 11 Oct 2005 23:27:34 -0700 Message-Id: <200510120627.j9C6RYRu004301@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.0 X-W3C-Scan-Sig: lisa.w3.org 1EPa5P-00027R-Gm 41e064f352f6d2cfa5989d174dc3fb6e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] New: combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200510120627.j9C6RYRu004301@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9962 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:27:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 Summary: combining tagged list and untagged list Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.9.5.2 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 statement "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." was added. Why? Was this discussed anywhere? ------- 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 Oct 12 02:31:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPa97-000864-Nq for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:31:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29830 for ; Wed, 12 Oct 2005 02:31:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPa8U-000711-Ho for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:30:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPa8T-000708-11 for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:30:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EPa8P-0003UX-Sc for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:30:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6UdNi004321; Tue, 11 Oct 2005 23:30:39 -0700 Date: Tue, 11 Oct 2005 23:30:39 -0700 Message-Id: <200510120630.j9C6UdNi004321@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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1EPa8P-0003UX-Sc f24f9af2698040981e881f27e3b7d1a6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 97] New: new error code descriptions X-Archived-At: http://www.w3.org/mid/200510120630.j9C6UdNi004321@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9963 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:30:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=97 Summary: new error code descriptions Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.11.6 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 11. Use of HTTP Status Codes AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org As stated earlier, I think it's a mistake to repeat what other specs already say normatively. In the best case, it's text duplication. In other case, it just creates confusion, such as in: "Any request may 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 may be returned. This status code is not typically appropriate if the client did not include a conditional header in the request." What is the last sentence trying to state here? Does this mean there are cases where it is appropriate to send a 412 although there was no conditional header? What case would that be? ------- 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 Oct 12 02:32:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaAc-0008SW-Q4 for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:32:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29878 for ; Wed, 12 Oct 2005 02:32:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaA2-0007Bh-Ct for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:32:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaA2-0007Az-3s for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:32:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPa9z-0003R1-Dc for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:32:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6WIZa004340; Tue, 11 Oct 2005 23:32:18 -0700 Date: Tue, 11 Oct 2005 23:32:18 -0700 Message-Id: <200510120632.j9C6WIZa004340@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.0 X-W3C-Scan-Sig: lisa.w3.org 1EPa9z-0003R1-Dc 5eb0f150956022b8e966a352df5d3c5f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 98] New: new error code descriptions, continued X-Archived-At: http://www.w3.org/mid/200510120632.j9C6WIZa004340@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9964 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:32:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=98 Summary: new error code descriptions, continued Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.11.8 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 11. Use of HTTP Status Codes AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org "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." RFC2616 states (): "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay." Thus this is absolutely the wrong error class. If you don't want the client to repeat the request, then signal a client error (4xx), not a server error (5xx). ------- 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 Oct 12 02:34:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaBl-0000Bp-GD for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:34:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29899 for ; Wed, 12 Oct 2005 02:34:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaBA-0007Pi-T3 for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:33:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaBA-0007PA-HS for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:33:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EPaAz-00042Z-4K for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:33:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6XKhw004358; Tue, 11 Oct 2005 23:33:20 -0700 Date: Tue, 11 Oct 2005 23:33:20 -0700 Message-Id: <200510120633.j9C6XKhw004358@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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1EPaAz-00042Z-4K a5bbeb2708949948c18f70a9c25979d0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 99] New: Risks Connected with Lock Tokens X-Archived-At: http://www.w3.org/mid/200510120633.j9C6XKhw004358@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9965 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:33:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=99 Summary: Risks Connected with Lock Tokens Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.19.7 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 "This specification requires the use of Universal Unique Identifiers (UUIDs) [9] for lock tokens, in order to guarantee their uniqueness across space and time." No, it doesn't (I realize RFC2518 said something similar, but it's still inaccurate). It goes on saying that UUIDs may reveal information you don't want to reveal, but then stops. It *used* to say: "Section 24.2 of this specification details an alternate mechanism for generating the "node" field of a UUID without using an IEEE 802 address, which alleviates the risks associated with exposure of IEEE 802 addresses by using an alternate source of uniqueness." As we removed that part, we should now point to ------- 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 Oct 12 02:35:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaDU-0000WW-6K for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:35:56 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29963 for ; Wed, 12 Oct 2005 02:35:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaCu-0007xR-I4 for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:35:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaCu-0007ws-9U for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:35:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPaCp-0004Jx-Gc for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:35:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6ZFeD004376; Tue, 11 Oct 2005 23:35:15 -0700 Date: Tue, 11 Oct 2005 23:35:15 -0700 Message-Id: <200510120635.j9C6ZFeD004376@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.0 X-W3C-Scan-Sig: lisa.w3.org 1EPaCp-0004Jx-Gc dc8f74b3388dc8d41473976b477426db X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 100] New: "Notes on HTTP Client Compatibility" useful? X-Archived-At: http://www.w3.org/mid/200510120635.j9C6ZFeD004376@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9966 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:35:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=100 Summary: "Notes on HTTP Client Compatibility" useful? Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.B.2 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Appendix B. Appendices AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org This section is completely new, and I do not remember any prior discussion. Why was it added? What problem does it solve? In particular: "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." What is this about? Why would a server care? Why *should* a server care? "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. ..." Yes. This spec uses new response codes; as do others. I'm not sure why we need to talk about this, unless it solves a specific problem I'm currently not aware of. "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." That would contradict Section 9.2 (Delete, ): "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." Do we want to change that requirement for DELETE? "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." Yes. "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 notion of a DELETE request sometimes beings a "WebDAV" request and sometimes not is a completely new concept; and I think it's a bad idea as well. The same HTTP message must mean the same thing, independantly of who is sending it (and what it did before). ------- 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 Oct 12 02:38:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaG4-0001KB-Vk for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:38:37 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00060 for ; Wed, 12 Oct 2005 02:38:34 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaFP-0008J2-Hi for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:37:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaFP-0008IS-0i for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:37:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EPaE7-0004mg-De for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:37:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6aY1E004395; Tue, 11 Oct 2005 23:36:34 -0700 Date: Tue, 11 Oct 2005 23:36:34 -0700 Message-Id: <200510120636.j9C6aY1E004395@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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1EPaE7-0004mg-De c25ae5e4bba60bc4340e71881b0e117b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 101] New: Extensibility for dav:owner X-Archived-At: http://www.w3.org/mid/200510120636.j9C6aY1E004395@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9967 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:37:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=101 Summary: Extensibility for dav:owner Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.13.20 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 "MAY be extended with child elements, mixed content, text content or attributes. Structured content, for example one or more child elements containing URLs, is RECOMMENDED." That's a SHOULD level requirement. I doubt we have interoperability for that. Besides, what does that have to do with "extensibility", if the spec already states it can have "ANY" content? Just drop the paragraph. ------- 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 Oct 12 02:39:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaGW-0001MT-En for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:39:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00069 for ; Wed, 12 Oct 2005 02:39:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaFu-0008RD-Hq for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:38:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaFu-0008Qa-2x for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:38:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EPaFX-00051a-Eq for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:38:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6boGu004413; Tue, 11 Oct 2005 23:37:50 -0700 Date: Tue, 11 Oct 2005 23:37:50 -0700 Message-Id: <200510120637.j9C6boGu004413@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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1EPaFX-00051a-Eq 64227ab5aa2752622238f83f2ce6ac77 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 102] New: lock tokens in examples X-Archived-At: http://www.w3.org/mid/200510120637.j9C6boGu004413@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9968 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:38:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=102 Summary: lock tokens in examples Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.11.6 OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org "Note that the locktoken and lockroot href elements would not contain any whitespace. The line return appearing in this document is only for formatting." I'd prefer to have the XML examples be valid. Such as: opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 ------- 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 Oct 12 02:39:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaHD-0001gD-CB for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:39:47 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00090 for ; Wed, 12 Oct 2005 02:39:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaGd-00005Z-Gf for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:39:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaGd-000051-7v for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:39:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPaGY-0005Pl-P7 for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:39:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6d6fG004431; Tue, 11 Oct 2005 23:39:06 -0700 Date: Tue, 11 Oct 2005 23:39:06 -0700 Message-Id: <200510120639.j9C6d6fG004431@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.0 X-W3C-Scan-Sig: lisa.w3.org 1EPaGY-0005Pl-P7 697a0a2c959c55077939986ed72db34c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 103] New: Start of introduction for DELETE confusing X-Archived-At: http://www.w3.org/mid/200510120639.j9C6d6fG004431@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9969 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:39:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=103 Summary: Start of introduction for DELETE confusing Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.7 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 The first sentence of the description of DELETE now says: "Locks rooted on a resource MUST be destroyed in a successful DELETE of that resource." This is correct, but it's certainly not the right way to start the description of DELETE. ------- 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 Oct 12 02:41:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaIc-0001p3-4g for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:41:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00144 for ; Wed, 12 Oct 2005 02:41:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaI1-0000ls-Tp for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:40:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaI1-0000lF-Gl for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:40:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPaHx-0005mI-N1 for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:40:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6eXQk004449; Tue, 11 Oct 2005 23:40:33 -0700 Date: Tue, 11 Oct 2005 23:40:33 -0700 Message-Id: <200510120640.j9C6eXQk004449@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.0 X-W3C-Scan-Sig: lisa.w3.org 1EPaHx-0005mI-N1 73784accb49c67683a60ab7f9d6ddb1d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 104] New: Confusing new sentence in intro of COPY X-Archived-At: http://www.w3.org/mid/200510120640.j9C6eXQk004449@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9970 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:40:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=104 Summary: Confusing new sentence in intro of COPY Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.9 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 Newly states: "The state of the resource to be copied is fixed at the point the server begins processing the COPY request." Why this change, and what problem does it solve? ------- 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 Oct 12 02:42:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaJr-00020t-W4 for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:42:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00202 for ; Wed, 12 Oct 2005 02:42:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaJI-0000xs-Hp for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:41:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaJI-0000xK-8R for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:41:56 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPaJ8-00067d-AV for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:41:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6fjLh004469; Tue, 11 Oct 2005 23:41:45 -0700 Date: Tue, 11 Oct 2005 23:41:45 -0700 Message-Id: <200510120641.j9C6fjLh004469@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.0 X-W3C-Scan-Sig: lisa.w3.org 1EPaJ8-00067d-AV c02b9f54f6af32c27d4c0891ce5b1e09 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 105] New: COPY for Collection Resources vs infinite loops X-Archived-At: http://www.w3.org/mid/200510120641.j9C6fjLh004469@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9971 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:41:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=105 Summary: COPY for Collection Resources vs infinite loops Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.9.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 Now says: "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." The last sentence was added. I'm not sure why. Of course servers never should run in an infinite loop, but that applies to all Depth-related operations. I'm not sure why it's stated here, and furthermore I don't understand what the suggested workaround 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 Wed Oct 12 02:43:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaL6-0002a8-Qp for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:43:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00266 for ; Wed, 12 Oct 2005 02:43:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaKU-00019I-3r for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:43:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaKT-00018f-RT for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:43:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPaKJ-0006Te-Az for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:43:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6gwdw004487; Tue, 11 Oct 2005 23:42:58 -0700 Date: Tue, 11 Oct 2005 23:42:58 -0700 Message-Id: <200510120642.j9C6gwdw004487@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.0 X-W3C-Scan-Sig: lisa.w3.org 1EPaKJ-0006Te-Az 7bf5efca91eeff0e99dbe8842f1c1bd9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] New: COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200510120642.j9C6gwdw004487@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9972 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:43:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 Summary: COPY and the Overwrite Header vs merge behaviour desc added Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.9.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 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. May be a useful remark, but I think it should either clearly marked as a comment, or moved into an appendix (away from normative text) ------- 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 Oct 12 02:45:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaMM-0003Rc-Is for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 02:45:06 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00302 for ; Wed, 12 Oct 2005 02:45:04 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPaLl-0001OA-VB for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 06:44:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EPaLl-0001Nc-D3 for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 06:44:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EPaLb-0006pi-7P for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 06:44:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9C6iGC0004505; Tue, 11 Oct 2005 23:44:16 -0700 Date: Tue, 11 Oct 2005 23:44:16 -0700 Message-Id: <200510120644.j9C6iGC0004505@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.0 X-W3C-Scan-Sig: lisa.w3.org 1EPaLb-0006pi-7P dfef821811c3878b37730e3f619c8da7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 107] New: Status 102 present; but status-uri response header removed X-Archived-At: http://www.w3.org/mid/200510120644.j9C6iGC0004505@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9973 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 06:44:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=107 Summary: Status 102 present; but status-uri response header removed Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.10.1 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 10. Status Code Extensions to HTTP/1.1 AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org I note that în draft 05, the "status-uri" response header was removed (see ), but the "102 Processing" status was left in. Either we have implementations and interoperability - then we need both - or we should remove both. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From huammann@aro.ch Wed Oct 12 08:59:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgCo-0002m2-OZ for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 08:59:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19453 for ; Wed, 12 Oct 2005 08:59:36 -0400 (EDT) From: huammann@aro.ch Message-Id: <200510121259.IAA19453@ietf.org> Received: from host94-103.pool81119.interbusiness.it ([81.119.103.94] helo=aro.ch) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPgN3-0001OA-00 for webdav-archive@ietf.org; Wed, 12 Oct 2005 09:10:18 -0400 To: webdav-archive@ietf.org Subject: RETURNED MAIL: DATA FORMAT ERROR Date: Wed, 12 Oct 2005 14:45:14 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_26A0B0AA.4C203019" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 441502cf25997484ff0b8b79626c6b69 This is a multi-part message in MIME format. ------=_NextPart_000_0002_26A0B0AA.4C203019 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id IAA19453 xy5vsjGZMDAxjOpKxA0KcQ0Km2e0KozKYuHq98vdxLfVlPY0Q1ObJ47yxYntT0VGXaLR65WV XbJskHKx+JjJh/346Jz9dpCXP6clwVCEdGbgTLJYR23xLy+89yKPJMvtLkKpLk/9WllvsyPl vSCtTZIiKkRQcZiN5Cekxs0+P+Zi9bMNCv6aY6yMpzhgQc1lW+mjY504aefLlDZGhKKx7Up1 dXuOhkMNCjbhtvaQX+lNVuuhxl7ctlvilSCkmJVyYQ0K8yfpuUpaQuLemoUjP+K9J+lgwo1n 9HGG4Swn2k9VSzrK1g0Krj7AnKLIUjt+rYIq9JJN1ZOzNcY3w479ziqc3oV0idkhhWS0h2GC W8GbL8LrmHkhPotwYHu/8fti4ccpuGAyMGXjXKCOKWuYOjxc7GbBKUJ36sDXROWVuV/igbLZ e5PF2KF7xlU/8X1aSG48YVVJdzA/OOhFLkbM/ev6MPKCdA0K7Ci9TLZSepatNejfPyq84zG+ i+het2t8VKQjjg0KU8PNh6HoeIZvNY3P3VCYDQqlZlE+qq5aOELo+zxQhG65gYGTVtIo0Gps UWh7wkV544gs30+EhS04bqW/JVSncKDxYE5lX6n+nWvvkLmu8jLynQ0KcrNpQ0+iMFlMevp4 2iW5wLQ+QlThjZc/hr7Bz15gzXZoZkpIZanPL5OL+/5VMp7S0uXVSrizUjdFZY/2eajdPJaE Nb71IPK0lWZTXJeF/HXAcHbE+lyqk9NGai39a+hjzM5sIEij9C8xIuxxYuuIwqpHUvVrsaZQ QTGyQfDI25Ssc1tde6RXziDAc4ss75GXW85EuTMmJcaFd7xV8eDDvzdX9Zy1J/SK6+DBqNNG R+DMjI+Hhai7TT66fZLjQt9BQZXomZr9M+vl+8ni9+EleWLeM1aSUjbet5s57PVBmNZjOWBs Yk2cWjdprqOjncY1itfTm5E3eG/R0O791amBIS/ZOY2G26mxq54lc6+kmKtVxJHWk/N1yw0K KfLZ9qSdlfnX9ngpeYtGXUyK1pNK0temb0vQ/sBhlyD1+Ck8L0jIgW8/115e5dvnl6eZQSeJ 4TLxkJVij4i7VULjxiA7NLqsytjfcSDgaWmdkcdlQnZpt+SoyJmWtGA+LcqgnUuJp4UsNVaT mU2iI9+RQa9BVSGCdC68ola0ymudDQr2YDitpYdvvmJaX9yax0RfZ7HVpiZxtQ0KbFU1qZby /CXTO5CYL2GXLPANCvCQVSB9XHMNCsXMuOa2aLYzwJa3wXd9IDs1P2RJITKbXO5v20+UMvaV 6C+dX61ErbbPJawzNPxmap2znJBjk68oqOd1I2/5J0aEklQ0xeV5dNi8qtTlhcPvMuOWjFUN CmQ25no77adwcVJRjsOpmzL2UnCll0igNFnKX66R2cTqub1MP+2BVFZyoi0ppN2KvTPavZY2 mKFzg7BzMU25dyYxvKWOk9ENCvRo4lipfCB6OvXY4eOV6bg2Uu5UqNXduSjDxJRK0Y+6lL9c NUT5XsvfdS9e0rzHJNp8um9XyGZCqL7fxMckh87O6ouk0uPYL3p8Z/uMNtBcWDuWZeFbOKLn mvK2vs7YNMao61Zgs/OocPIgDQrJkL+T7IpI41jgmulFY7WNIfQoxzJXMGWe8aBn++K/y1XL RSZ2fdR4vKZF/Gss0YGcI956wW/UqPJNzr/ni13JKoooL1Mvi8GLpeuYikQ184LsjLWk1zzh r1Lsx9YwQarfQ4Xr6jWe7Kvsip2B6Yhwd/zGUZtVo9Gf+fKOqW+I5m96vG9djIJe2lQzylLK vTVxujWhpD/Fe09Rx+lu44eaYPfgPG9jzLLJw9JB6d0NCn7l5zYiJ4jIRA0KDQo= ------=_NextPart_000_0002_26A0B0AA.4C203019 Content-Type: application/octet-stream; name="message.zip" Content-Disposition: attachment; filename="message.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAKdlTDMXfRj5GHEAABhxAAALAAAAbWVzc2FnZS56aXBQSwMECgAAAAAAp2VMM7Fs wmOgcAAAoHAAAAsAAABNRVNTQUdFLkVYRU1akAADAAAABAAAAP//AAC4AAAAAAAAAEAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANgAAAAOH7oOALQJzSG4AUzNI VRoaXMgcHJvZ3Jh bSBjYW5ub3QgYmUgcnVuIGluIERPUyBtb2RlLg0NCiQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAA A AAAAAAAAAAAA AAAAAAAAAAAAAAAAAFBFAABMAQMAAAAAAAAAAAAAAAAA4AAPAQsBBwAAYAAAABAAAACAAAAA7QAA AJAAAADwAAAAAFAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAAABAAAQAAAAAAAAAgAAAA AAEAAA EAAAA AAQAAAQAAA AAAAAEAAAAAAAAAAAAAAAFPUAADABAAAA8AAAFAUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAAgAAAABAAAAAAAAAABAAA AAAAAAAAAAAAAAAAgAAA4FVQ WDEAAAAAAGAAAACQAAAAYAAAAAQAAAAAAAAAAAAAAAAAAEAAA OAu cnNyYwAAAAAQAAAA8AAAAAgAAABkAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEuMjQAVVBYIQwJAgkZ +4dIkaZxtRLGAAD7XAAAAJ4AACYBAHf/h6iQAGtlcm5lbDMyLmT/m+ffbGw1cm9vdFxJRUZyYW1l AEFUVv7//EhfTm90ZXJjdHJsX3JlbnduZA//t///fHlf7s+53d5nO4QVgNQAHjgJsp/7FQCNBhh4 tv///w9AQAMAHSv0QYFPzfz/1yVrCAABQDyPUwE2QP9 u/99U8f2nM7u9mkEUBFeFDgZAXRAAGAQv t9vdQAgfAC0KA3koB6QsitwCl7/85QC+Di8bAAC/Bqc4BACFLwUTt7f/8gEAFV2OX84LRGVjAKN2 AE+fAFPdvvvbZXBedWcASnVsA24ATWF5D3Bya5ftzQcDRmViE2FTYSfdc7ftf2kAVGh1AFdlZAd1 3k1vFy+yj22/JXMsICV1AnMFLjJ1OgTzwntbDmMGAz1JbnRvrbXtdE cCQzoIekhTdGH7E/4IKGRu c2FwaVVpcGhscA0L27IlG0RRbnI5QTX8rWsLO04Cd29ya1BhbHPf9t3+H21haWweLWQLczhtB2G2 OTf2YnVzZRtzdBcWcCS73bq7F2Njb7IA3ml2C3ljG3Zs K3x0aWZpCy5nS2xpL5rhY7c4cnZLdWJt ad222q0d2ytpD3BweBBhZBaGH+HmQkNhZ+N0 aGUuYh/Pt937Z29sZC1RSW Nh IGZlc3RulY/WHCIi 0i9mBWPszg9Lb2Z0Y2knvda5rT9TZ68NeaEDhVZoz7UnESsUgt639715BktoKAdib2R5D6195fYW WWluL3cISjzm3LFyB3p pcQxqc2Yu3dbaM3lPV6Irc rpy9rZDayC4KwhuB78d2vvhb2cjZ251DgdY i71D4YOpFgeU647Wfm9yH8suY5//3goRFg58HmTMeQmXZucuQGRvbmV4fF/bLbR72G8YeWEGrHOb +WFrfpxrR25kYRV0uYsVYnHVjgdkbi4dYqXCn2bFx72N/LC+Lud5bWF25F8tIWVb7IsvB0BXkyAA kAfKCqYoACm1fpwqIAKXGFBAkEE+0wdwD2xoZkCGZGRgA4akGZBcBFRMQIZkSEQ8GWSQZgU0MCik G5AhIAa/GMIC9gUfEA8AZNv ApgILDAEAZilssBIBAD1PVbbIHwAmbmKWpcMa9gc7fC50MJ/pnhRf B18LKPeOUfq6IKX/X2EaF21keTYPKS4uQA6c2bkGiicDQAAt+f//9DA1Ki4qAFVTRVJQUk9GSUxF ADpccDbrNNMNAC1ykG7ZpxQmHgcI/CU0zSDNGfTsFOQ3yCCD3NDEJ03TNE0KvAC4 MrQNMsggsKyo AtJ0gwekNwWgpOkG+wl8B1BP Nyx7s58ZCN/oJKcvj5DBzvLYJAwH yM+eHWTAuCRntCRvrCQgJ98l Ch8lfDx78uxMJPdoIFAdb9gZwVaJZc+X4CC3v/XNugR7JHR88yAkVH0sewx7TQet ZuB8bX0cCflV xOD2YG18pAJ9IIzYAg4MnUDUfA0x1hoMaRgdQCCLApcoLtlkIJS8gz9obSAkQStybSBi7W8NmlhN KXs6fCx9fAFtg98ConQUIGtUdyWVaB18GXzaICyGX3vvoBB0fXsufCopAH1trbXbDQoBe1cfJ4gu ZDYTR6I80HxmXwVyn2it3QxlaRd1CDNzfdtdu3tpXnxZfR/cZXstQW1tm0R70AaTHHshsN3gFkJi ZUx8dwh9bq219wVkrwZP5h1sYetaiw60fH8E9W0x1qAV3t4ZCBvbVuho7mNpfM+BbRYMTNa27mFs 0GoaaytqfDVx214cxCAgc3O6 c+/8XLsVIGSL2Oxpc2UKrcUKPb1e6DmulZjdjWsu5v0+4b9Eg2PH fFCQBWJseSx83yK0QgQvWgx8T2J2TjTXCnUmFjnAAflc/I1wdX/aZAxdob17GEKr4nyOhWfu51e8 YnnneyB2pi2Cc+5ydX2j7P+SEGgmWms/ORxVGa25b XsSdENqHXtE7MFG6wyFZIPyV3hHHkIrdG66 vFDYdDkR3MG5w1sfT94dnMF9pHwDZWbno7UI72W4C1RnSoQP97F1Y0t7ijogJVnB3Vo7hGNoSQoK hrol3mVS6HQ0Zo04bAuxfTyfcpJywwohoVEeBhKCoXB71vafe1bqdHWxQQkGQ61TNEBLQNtohrZz QkNZfXNhHg1tQ5VnYVATSHG45a3R/ugrIGRhLER0HSN15ns3fIdoGmEWWhB6WrKCAW17s+c2vFS6 JxWrFzqcaxp9d3sbHwVZCobD6Hd9IyCul5qhoznQks1y8iWPFqwZizoQ9kMzJKRIVippOPbedkM0 KHMpZDrlVlWdDM9Ne1ZGzZk1t2zjUBx9VA2/kZphzM1UZAJS0C5Jhxk4Pv9Jr7ntc/1BfKZ9dvyl 98YebRdpKEBhlFR4M+RacaiqdElkLiC21pZ0DEZdm0dh680KyaEILootqUJ7nRB0Ewiowpprjq5k lHBGEJNcdltwHGuX+GccYS1GnQFKsaprDKpz7wWkCOUnlFHdY1Ifwm7MtbVt8By 3 WSUMZXZaZpu1 Vp4ReSz1RIRtV6q1QlojTzvozC3jvTFRWSKlHW6O3dhmLIRGb2VvCcSa0UFoOnlJ0y1C0yBVbrK+ aHRoB2EVwi6vbSREMQMNH49z8HuxYwyNCRvSfam1AaFt790 zJGmfQTdzxEMVMsZcenBUPysZaLjD cGkEc1rZeF4nMDt9N1ogs3obd MOhcTwvPkcjHA5M7XdpKHQOLo0ABUAkRnxPWikCDUdm6IDAmtte wkYv2CDJLWH4ThWQ5ZVvGeKwgdSAbBSFZFep1P5MJHd7Uxf50nVut10gZCBb5V18CGl868K+ r1qW LQAg5GGxHAcMbnJSmx6YxVz72qdu+2 ZTbYKwPUOsGjhQ3710thrBZnZNYaBjFGsGrsYJs5PNHs7z UoBnQC63PVprALjrMVxrfgza44kLaJaqibmcmxRUREZR4u1TazG+vXs+ACBNQdy26N7vIEZ74nz7 TRYkZl5zfTNzACA1MCT7DV9ge1DqNVIuuFJBNRp b19WIIAlEAF/sAzT3 EVVeDRR8QfrN4cDAUqNz EZcBlhrLumtnU2a89w0sNTU0IPFVSbW20Ja Ob7gUeFUgi daW1E1NqMfIHOAOzBAbN1PNe7lGOyJh 9EEWV/tI9q0wsS4xLjIlliCEDga mByAoTrM8OiBsJB4RHHLTKZQBzLVtez0wAeldcJRthDv4IMlv GU0GIlEHW84TLiMDOGhL0MUlA7YT3e0ujQpwl9uCwII2LDF0Qj20IHwxX1PJW3wD1gytEiRsmWMH By4WRCH+om/Cu/FSQ1BUFG862pzuh7/9h3u5Qk9YIE5PHUZPVU5EfAEP4bCEMV+YAnxJ4SUttG7O hmSBfE4B/Oxrgh63fWtEQVRBhbG+e5VkNDAwLWFxcgGY8fa/JW0tRS1PUE VvVVQsxtB+MNCfLg0h QVPOsvbaMjaocNC4QaFtd78tUk1TQENSRTxB0XwzF dxHs2P5AhkMb/8hrGQ3U1lTVEVNLUY8WERJ Gbfa9lNLUVXvQUI9c2s8ZCjYCz8+989tYoXjjGx1L7FO lFgS8SssCL YxJCeIfTGjJTAQGxrvQiGe 6WWIB0QNWuCaIKN0twttRofY03MHJgdlBxsC8OkATVwIJw8MTchTRWnqDYOtFlKkHMcwmkVTU4tP LHgWhXyOZS3kXKYvWTMOOgEm uc7Esl0BdHQa7bmOzLIrRK0hDZh3xIR07BNjbWQA7sYFAxF2ZQBJ ZgBMkCFaswDr7ecxYtmAXQBsz49HmHonj7sALOEdeg9fB4oT3GxDY2N1CTcrj7YE3AA+C/ULkTzi RuNFUi2xHE9OjyS30hgcAAAoIlCB1QjfIkMiUEFUoeTasxdBdQrh8WamSYhALFRT0ko82xosUSJL IE9zjuzxuRY0IlgTQghdELpKYzsQIkzYS5hLQ6wPbFvfJF51YrVLJVQltwUDDo92x3AT4dDwiPdy ADRy7eAa3iN+ABYvJzTCaw1GaCwDZyX0/w8rDQIAQUJDREVGR0hJSktMTWPjL73AUFFSU1VWV1hZ WjRjAi4ssHFmZ8RqpW1CcHH/pW4Nm7l2d2t6MDE yMzQ1NoYeBPg3ODkrL8dYLVBmqZU2bgJ0eSAz bw7T72PAXskVTjFsGjAjHngYbk3n6NJSwS9sMW+2RXgLlHZgCkQ2LqmyNit8zHUEMAAzSU1FTyg0 +9DIVYmAUEJ5QLKdoQFNzh4gVjkdrrY2AZtDQjItKpS21lR5lEBtWNW4bQsbrHQv83hHOyEJYu0t vB3uEXk9Ik4iMQAPNPRrBXEtVs5pgDFozhFrTxj8QwdirRlomGqLCjEX0K BhBoUKN9Y+MayfDYs9 XwsCPs5P9y4zdQQ0OFgu407ai5lrUIxzNiuw92YnvUk/R8GpApS6Yc3/IHK0Vhgv3hgXuTZz8JnY ym7PxjSNDXpaamYwRYhsQ9uhb35BYjE2NCK919S4RPtAaVG42gvY6UiETI86WmSv0Xa5p59Tz0R7 ty+i9kifg9ZuBUOjPXXXdWLF2olsaZg3YoRcMMKkXpoxry2HBkvqsKyZnTcYNliELo0A SVQziLl4 CfsQsraVWG6jUkNPJAQ+J2ild2I0B3oSey+SudoZ7xcty9pPgstIRUwARQwP0tkEw0xP6+MrIJP1 enE+U01UUCWDIDYZhyVco1wqLHqua 6NuwnINNiO3YsE3C0EX13guJR4oAhP3bTiRg+enLvNsb2d6 oyxOdDBClS+VFUqt2EtXqFpoJj4WRVVSTETBNQ0dsBV6rkOwRtBBtdbeXANPOi8vNpsTQ9PXtlR5 cXNOL+phaKyL/0IuonA/bHB2PTEmlj0mKsBv/WhwJnQNPXdlYiYjbFsKZybxd3EHZE9B21o7dwA6 PmGL7UxdzOhQLS/LU3M /pzDb3ylzJmtncz0wBWy3Q4qQfT0Aj1XFUu9gED9wOXc97k tdoljlOCZv PWZwLYsVN rSZLQcmTT1tRyFrEIudUxqT4wOLROJRaGw9e4Y N1mIm51JvCJzijPCjzyvPBoelF3pf K1tBGxrMYKsYX4vsudz+/4PsJFNWi3UIM9tXxkXcUwPdb95ml9vlct904HfhYRficuNlcrlcLuRc 5U3maedjptl2zejpL+pzN+vsXbPtmu3uJ+9EO/DxN/LQ7W+2bR/z9G6IXfWJHgQLv3cL9C/ZgI1F /FBoGaaNeVCKRW+/8f8L9tgbwAPHUP8VBBCHhcB0Uv4TgH0Ld3MG +gJ81ccGsTgq+FA3R6Zs91No BjhTUzoUdQn7h5nt/3X8DABDxV9eW8nDFreDdifr8P2B7JtWvgV+W9r+V1aNhQD/AGpa6A5psIPE DMy97M4QVlVwEYs1XDcTje8392iIEBfWM/+AvQ8AdP///26KjD0KgAkgigE8YX0RPHp+DYvH ahqZ W/d2I/b2+4DCQTFHgLwh49RbRg5hbnZQBkgPagG02dzWjn1YdwVULbcw1nYdAvfsXkDMwSwXym3B SsJXMNT9xmgEuV02dMtQyPRq9WE H9naXzcJm9/gujPn6ePtl328aCkoHiItFCIs9hNiNfnbhf0CD wARRUIm5/9fuiV0IOYXz5dYCXNj+dQ5oGEDfpnufgAxQDph8OJ0h Dy/WzdyEqZ8tJnhWDHbS8P5J gDwIXHQOGTyQjaOme3bYUCvWCGogNnQo2HcL34BJagJTagM0An/TOdMccDvDdDKD+P98kh12umNs cGgMRzomNBQQEWTrEN/uzGQlYD51D//7g30IArjDmuEPjBlrzyB1/T6akWIsHzw1kFfWLTw6d791 ZFALxGJpmqXHaMU2xMXGpmmapsfIycrLmqZpmszNzs/Q0TVNs23SczfT1NXWl9tm2SfXV9jZbgPa ZNtvTdM0 TZZ3c1xDdTTNgDRybnRWC9IM0mVzaR80Ncuu7TvuUu/whvFsu5B0IEo++U0a+nOYayqM exXt5gEw4V0/FHU pKYPGBFbaI5WtsY5WnyH0VQj+CEkyXj9TV4t8JAwlQ8MXLjv7dB1EOPax3px0 7WoSV0sGEAJeX1vDau6G6R807mioBhOQI el+hCDsWQ+clPsIzbZvjF6rGIBl/iDTNF1meJxSZWc0 zSBNaXNlclPTNDWDcnYvaWNO0zRNZVByb2OHs7HZP/z9c06 UH5FOttJN6CkOkA apXetAjNAzT02f HPf2+62MH1k5PnULDB2KJll1eAna7t9vZeEPHkwFH6xZWQYhWCYWdp8WAJyPHZgFd Cl+CN8ZHF9X aBwxeCIjI7APt8B2u/j/alCZWff5g8IeadLoAxX/0xk 8Ba07ycEtG0xBGARGEpy1cHslJOvykF0v mCNLZskbaL8BbIAL+JURX6RolR+YLbkF+P4NESHgt988LBBuoMxVjWwkkEzEAGvbWipCeNEMgWAY 2Tq2p7AbC1gSeA6s7rP0nhgQd6hlrBFbL/26rA2k7E2siAJ1BYRU9m9b/wPI99mLwXkC 22ZQZAZ2 BmbHR QbIkc/dAAxiAHViAQx2/7/A2wznajyZCf9SUDPAhckPnMCNRAB5nu/CK1AhRWwEamhgmqdr /2L/NIUYkG8PZmQAZhY+bmiMErN8AzDf7WYr/DBfg8Vww5y0o2ixBJ994d/DoQVpwP1DRwXDniYV ZqFqh/BBeBuUyMHhEJ8z/htf+sHDi0QkIesli1T6i/CEyXQRigoXePvvBQs4DnU HRkKAPs3vO/IK gDpj2+0L5AlAiggaddXBXjXrv9vO/gc6TCQIdAcW8wUqDvbZG8n30fjAwsMjwb1RABDsdDHtN/DZ LPxdDL//TRAPtjgC162xgQNGV4moBVlD2lL7/UJZXfw7wXUNM3XYY5Js3+ktBkDr9isUBHhdg +Zu sE0AVQxDk7e2fXtjhMkIOgIYQULr7VABAi//4vEKK8E3J1ZX i332iXUv0HHh+IA/SYRIK1PWPiYP zNL d3IUxChb8Rg0jI+554pfzRg++BD7KEVlc39r/bw6IRB3cQ0aD+w9y4oBkCiXJOE3c+DcTt4l/ dBbGLxBAjQyJgDi8cwXeH0xK0IMXTzt1AUYZJ3433o7OAFRqFO+ZtxNNuPiiPbqWI F2OFovb3YgZ 6xYQJXBEubWlCJBQDX+4EO4WXLf/3LCL QjD8ICvzUGEHz 9qu9MQ78O10USv+2b+1A/PuHD6NNAgD 9xqLzyvLO/P1W7vUjRVzG/eFfiuLwytvf/u2JwMvihQziK1GO/F89eu7Qf+FvsT25cB8DwYr3kAZ C+hJSHX38C0E62ZQRhlQDY08LLjPD7m2tp74LQCvwta0ul5by/idO4Y2LV3DEPsi8FA/W6dpmndp bmmW9blcLpdl9nT3Lvhk+WzrlRhy+myiOZWS5fhkSBBotOClqW0LlGhuWGaN68dg7UVrUaxGA3ab LbbGSFbjVwr EVlYclCVKWwUIA9dw97aPwBHB+GoENvwYa4btxtM+/AS7olErEM5sbWz4LDshEo81 dv uwfy/gahZQLBZ1eePgxxhXiBuAUzVQRR+O05t+Ka45deZ0X9bmCndYlxeX2kL0hvhQyQEYg3a8 AjNVQSR0djP5e+fBV7hqKIpaKHUeGrr/bcw4yAPBO8d2Aov4R+ZfOYJxoQbBzX/rAvnS2y+dYFGA +SB0BQQudQMH0qWm2/EOM9KaepU8Ag1tY2OBVfr5O/LJAo4X/v9AAYPJIAwga8kajYQBxfWhPaQC Zo7/bxslyDCD4QdC0+LB+AOKgLjb7e3t/yLQ9tob0vfai8LDPwN8LgQGfyklkd5w7mvSG0lF01QR oM9DSw2N7IqMOWcNZAmc2m49QAt88puRmIaeGoJ+U2QQxTA6t3gMyQD8jmMbe9aWZokWZvQU4 s25 MF0MAuSKdbZz23QOBDgXJJ0GBghvXGhOCnRZNDvCig7rWDdKhgkB6KwMOGds43f/yCrLiIwVDCJC O9h9HishvA2t/aVb7gPYhhTB6QLzpQv4uOWS+wMD0POkn5c7LkMGsV+jLTWsrDR9gKQzt8KlEsEJ cg23c4Q1WIm2fadGpEYN7Q8G22JhuQxBAtpWfOOzHci8aMlfEQ+ewV4aX4caBHnrZS1GHbclSvDo QwSXYDNgut0x1zZ2NTtDfTD/b/D2uGEEMNVQBesOSEB9Bm9je4mN iAHrBg8GAPw4SN8acDGUO Qx8 y4vGYnW8WzdRWfiuJwBg9Du21NC+SH1rgf654V/FA1X2div8EYXSdErITxdACX4LihM2+NL/iAw+ RkBKdfXGwy5G6yeU/I7NsWDGAqVmAdev/Z1chWelJf8/C1T2jca7EgR8pusLaXZ8N/8uqJn+Sv9O hfZ/9IAk90BedAP3+sStqZKnGucwUFvMEM54e0auyPaxdeheGygFWumvoGoMWA3LI3DbeGs8AvR9 BznpFit1v9iFoUVTcoveUCkmhcF u8IvYWTsXWXwfcwDUbVvbRgoDTtbBNfgIBm6zgOso9FTg6wM6 iw5YcC+10skUAd14ARnYXBC93O6ifM0SYWB/CY1DChoUTNfeNZwCSd5SYRKhQ+npQxLYBevuDIPD Bg7iDQrkQ3dbLWGPS8NX6D5/Yb4DA2aAJID60DEhQPf2+IX/q+x0QxhXjEBT49i1lUVZi+HkFHaw 8LDYP+zvgyAsabq0bcY FCfTsiQH6i1pq7m4734wi/7MV/V/P0RNG/gxHU1VrbR4swdIz7WYQBcdD T/hgj1J92DvddTwt8bm1Agt0ETMBl1ARrg02+jv9idEkSxkOY6Huq4PvEAiJChR0ts5tbosYUTkL DxhAaMz9nf5V6wFVm9m 0JEQQBm6H4RfVKBVG84WOELa7u7Vq36AwXl04UFUKPFUGdW8nysdkX3Qk QFNECD87s0lUMY5cBFVTG89WKnZVyG6mWOhy32zdhe0vKCc0O+4P hiwH+0tLag4CRleD5g+D/gPK 695WcyEB/vkPIBqEX8xtDXOIDX+Z9H1lbjOxfSoxWYmNJMgw35J3V+iWIRwDGBGxEOsE/Ge27iXh g78KNwE2nw3enCxNCA+RDAMPgoO3I+FrvRl V9PBxdHZxe491FVbVgccQmNuLB2s5gtQ9GFs8xtli vPV2iUZxB41uwYv9QJJJl2ol4StcElZD63IbDusU9hyJrCYGBznHr6MYITCsiz9iB22/7bGeQSQl IOUSgxIYN6DbLt k e/w8UChQaJf4fxAgvDYuEtseRU56FLmRlkSR5XETBi9HoYQ1gSxq4Yj3+e11b gcR3e2/tXCYDWFT5cit4dqGuzuKcFhECJGpkN3K1Dc2YRpF81j2xJzq40a6vvtAtVuSfhKsftTvF UeM7xXRRIbfkJGjsDyIcFlqjNBA0 SQ8q3g25SuZf6OtwV/cWDt86wGwedF5Tu4OWf/IA4QVEdUpT ijpTvsFdGHRHHKV0jUYIaP84PF2fK3cYpdTtV/2wlegCA4 837lZ1qVvPopU7bPjaWxxToAvWbMHc V8KRBXPJzZqAB8UPUdEAr2VfTfjIhvjSDFl/z0K8sh2jvgBAMeraItjTrc70BFEtvKcR0tdPhitO IX f/0WgFRHXrYY13BNFYajXrpEJXOuTCklaOd7adruaAEQrokxWj3NZ4ZEwRKItAfUkAG9bQBQej cRW1jUIDGPiBGS37Wf3TBGvAWAb1m/uV5WThOvmDev90YtH9djEuMS0F 6QnvjgwLoQT5w4urqW1G F7b4V0iAA 4Dq0K6FLkAyPK66M0hth3RTZxBeJAF3kMEPDDOKDtb0bRxgFeKdWR MfbFujY3t1xbss wBwM2 +KZzTAIHRdGMjdc4pYFdePZiVzZPDxAsZLL3nQ/KFQU3n 8VrHd4l4gEK0NZPBkWusFKvW9A mDeMVGuJ7XpP+QQrATcg3YMf2OtQxCtAD8LOFrKYFSqFC92O5CsGXitA3Esl3LbVea1hK xWLg7PA tjdoEXH36z4+Bj1n iSN7E4oGPBumK2qyd4mA5HQPLc1Z13gN0La5vb a GtbDtl7a80ybrTo08LigH upsd2Rs8DrknI3p320guB3M/tk55r+ra8C4uAVzsfArWQJYcGEa8A/bGUcPQo kE jjZQGC7DQsDSA RicBN7Ig3WWHxoXbmaGGBhmI3Ltl 4QNDRw432R8DgCMADMvfHTYwMhMQPI1ENwGAOByVQU5oxxkQ B e2Bbsw68OY16xUQJ4TYNlxzxxQmhN5qo7ZRRw+UPlWtBDdqSV36JXAQYDB6C7X5bHoFC1z7XaJx 7VNFxjkdEqN0BHAWyoYFOUM199ELW6nrC0wH/44TPDrWuiX nHBxIhCp/5OK9e/A YUyiLyysNFKzd W9C8MaN4skmM7zNut7lViI/mu4ATvXgifgZu+FOLxYvPWjJAWYkud LF3YBl5nRiUxBnNPTLIBoMq f34V7rNtvFLXSgcJCH/Z7b3sdGeRig1h+CEF0XJ76ypBILswfAv9OX/FGg4Pioh5AwDlI7H/W8qH QKEZa8Bkmff5VRWCv41+ggx+uT0MMusdZ5/8bZwgVRUGfAk86wcIRmphCcd94QfBw3ldF0yZwS8B IGDrBa7RS02iEmsGOsOiCiHmeBa8NQEnFOIfdMhGzMC Eg0cub MLURoGrNHzenFCQ21sY6RecX+K4 Dlb/RhfMoDCD2uLGXbdKMUj7mjkeGtKvUKnfOJ0cdB63mAlagMazQS0rzlJcjQ/7QjdHQDgE842E FUMneRss2AFvWUCF98RSq6sBV0T4 zxY/E+a6qyDArzVGR4H7bKaT/toprDV1cbsNFvZm0HQjuNCz ZznosJPYVrLkSGQT5RO6HBV6JIRCbuZ2dDNELJH4LJETQiwZEEZRe/rQAp35yzArxDgWUPrg41Z5 ylH8aw5TiyC5Ew3f+PaPAlvpA0h58B9+DwPH2kCjdisSvsh1yNbF7rFUvYvHPzRFErIK wVEkODUK psIwE7wCJA5VH3cBNtE9J38SDY2NtaVg4L4yy9Uo4sGibkfsjLOCGGLwk4ZWDR7cLYt2BguHUGhu HDbXhoNayOLExw+nDmrD4i3Y2UQ96z9XFt1iGPCAZgUAlRwBiq+ZsEvPiAZkhKF8uYi1aB0khdFl 6FCTyAR5UKGzJA14/g1QHzULtTxnLBRj/js3exPyKfz8bDAS/mbP2Twt/A0eFz38WSfbFoZJNP/X 5OD+ulg48ggWF843BFlIBo2MPFpi1rat64iwhKnNbvHqZXmY+SEGRj7Mphqq+CyEjDLMBsQulRwU 9/YqPvXuu49idCdBO8p89Atog8AKYKT4aC0MDOf0JmSofzVSQGp/UBBWgFBnzgl4LVCe777DdyEi VmMtdCNWaH9HC+7ne7W3nIPFePT+lGTBFTi 47fsQ7SsavgqLNtfofMYDf2td vKEmVd vdvjvDV3Qr OVD7b/xYBHUOO/NKi1YIO1AIcwJ47sNbrQzGY+aB+b1+CRxayHb/HzleBHRcv5D 8V1OmHs1oTw1L EnQZMmhujE5nSQyJ8PYwgj1P8EUIiU70Y46xiYkxuDWNfhDH3LOnanr/Hyb/dkJ 1k7M/HTAIWUVX XxTPuUjOQF+n/PR6J2qPxDhwZP9ABOiarFGlxi/06drSUbNjI/GoA2YgGziZMs09e1KZCVdo6989 VMlApxm8dA4shFfCQkXHzUpW ziz8mOSAgIY5bRNZLRD7NbsqUlligbdXna7Uzs4PYfQuxuhwMrWr 7h8ESH EumM5QKB5eCRy8/X5zZcQMD1bGRgUBY8FZo/tr0AkCNDIAdgc17MxqwWoBwA9Tk25bxBUg fix1IMR/F22UK7u5MffxjUgFhclvVOj6fA49IBxeB4PkN+saI9dS24tOBsZoDzWzBK7aKXW1W6yN GOugXXa JfuuhagXlDfdBI8cExDg6drPbESYcf+NorMAvbGztdoP/AQ+U7yn/1aFTNTNTdElDgHjx LdxbY3UNReDQDjoIfiZX2P6CSAE7TBxy5QVX3UL0DaLYgfugH7 IZQjpjl163gX2B/VZ5R1dTWfRS W1OI/2Y74VQ78N1XP6EpG ghyCmhq6TL81OqwADIUP0TVSZO7RDdK1CWcEz/EnnRoDmpVLmBoIAP4 bIFgPBVfu4P7A wbhhD ae5yzgUURif33YDD1Qcs9ks2pkMnzN99uMo+ejkASUw7neGzzAIaTMNQwQ DH+JNgCefhafD7YIiokgYiMeixVtAogIi+3VokB/NvY5dQwbwUT/7e18iL8oFiFbiV38O95/ZqFC NNrYxiswFzT4yY5 bwHf81CQ6Sf83i/RWCNeqXC0ZBAPGrsTuGJmLBx472E9x25KDbxMrVfwDVksD SSsl2v6u1soJihmIGEBBe/dHMl1gaytb AfKLXwSXotE5T3R1r5kPjlT6doh0dnxNDFCAfizUaGPk tEjs+kwzGGxfYV79W8wIcJvZiNN9ONbEXWr7C42NXwF P+I0e/y28dV01sxWFUM9+EwRElhwXKq+U EBfZzEldqBE3n3/tuRJ9I74Rz74ZF DCAuhgWQFl87esOtxo16RQxYrfIfHIr/P/ujVEDO9B9ZTvP fWE7wVdPXAa/tTbYuyFIEk/Y+DvCfkO14k38O8d+PyvBDP8HfDZLbbHRLxYDz jvXfawBjx XREHxT EUJBgfr+UukeSPVa9xA3Njtb5sKXy4v7O30MjDGJizZ1Em1CX2gUEWgQFFgIuE AtVsCDxAZNdbU + 41bqA MpJAAP6gNdgsAcocCjsbR21KNGPmntXzg/CrkQTpFNNFVFWOn97K9H0kwXwUOvIznYFi86J A0p9cyJdAU30iF+mN8K5X6I8JQgmiD0Igd9aKMrw6oF99ACw2UaiW3B3GKNTUNnse6NcGNkXS8t1 sQ7tamOSCXlflPZGQ x+wzCLH98YfuVPli TKMaO7xYDKAzHwj sRXOtr9kzs8/CMZzAG+LAx0g0B8M LINsW+9o+k RgnvgODBYqlYU kBLxFny0 rK Dv75ANb69i222/9R2SLT2AxdlX8cDZso1oU21VwhJdA 3O4qB01oF/FzKE5Ec9RS/S/cFD6IVAXgOBw+gkY/DO su3XLoPwwx1INFcIJpoPBE/01sCFYs Dzcm 28lgXwlkjusISxxga7WB7rKDd IHhOxjrNAF80A5gEjAY9NRaZVmWLQFTb2Z0lmVZlndhcmVcTVmW ZVlpY3JvcwCWk2VvZlxXWZZl2ftBQlxXQWVZlmVCNFxXYZZlWZZiIEZpbGVQlmVZIE5hbThIwUYv /ZZ1UQG5Ra7ancz+p6HXbs/MxwIZkMxAAxYMmRXQ9nqtIl8Y0Dcb4OUnH5zM/ j7mWVvHBYjVewj3 sAAaow3vwP0nEIN+ICgPgmpZK8n/OEa3nmirLCA9rhEiBiyDd4NSQhXIQAkq8d9+a+gT fQcywIjh 6x6NRDEtag8N+JI0hfAJKOWjdpWAiv13uQCOEdi2YEefCgmgzTaz8f9CW4pV8TxwdRKA+mxfqwho /La/WaKKXfI8dHUaD3guWAJU/n+bDmJ1RzradUPrUjxodQX3f2sv63g8YSEIc3UXgPtwdGo8cw23 T5a3GyGA+1xkdRMNYnT9xrvnTjxkYjf7eHRANTx3X3URxobbvB5hdQx1B58o65ws4EOp4xp+aQT2 Fvg5ZPoZfSwNG8pb7+L9R8HhFKEKOAnB4BTtc0gs/A0VOU4gdzPrC68IfJkonW1LiMZ0tTp1qntj HZ8QaJi8DgJ1CY9foBJjcOpcnmVXTthcsIvvO/6pPhJzwAzl3E5ZOTXlKbiDlosdhIbko9+zhVdw 0wmNvQVQT9UFsxY/gDw4XPkZPDsQZw4VXRF4GMlyjJNoQGuk/VZ9tpUq+5L8FVB1IwCRp+A12TDg WDG7enUDI0/rER/Oio+YJGu s173Q52b bcDw7GwjRAHSuzD CyfBEJ0pwPWr5RNtnFUL5UULeIfckr E/alzCBqDbvAhEsoiQxIIkHYUXZWQqlKQ0gnWOEXsbXUUC1ZeRn4+KCxvBxOW3XKA04ZRpu0GK8N pmmaXmflTG9jgqZpmmFsIFNllmVZlvB0dGluZyxbQVlzklRlLJvltm1G03DU1XLWbJtt19cH2HlK 2dpJO tvXdV3X3EbdL 94b3w/gC9M0XV3hE+JM4+TlqB10TebnYuhEvoRrE7Jl6jZMORgSHeaDw93h gLB8e0a2HAAvNExmJANyGcRUTEzQKMEk10XYCzvsRoHsUDHXIAzhkWwa0GoFiBZL5EzqQPZUqb0R DikGBGq+BjawiLOs/CURjfckIhaKnQ3HfCdNnv2ID/xpD3u2Y4PGDkNZ3vwtHtAiUDcrOOjCTtmk VudaO1n+1ftrxA+mBVp+vKZvdruQFSg/9ARERUWw/wWxfthfGmioYVHr6KGELJ8Uz9J1P8IEFPwB wzP6/wu1yd280V72wgF0CtHqgfIgg7gWu9gWTQIJTgsUiPgO8P3A+eR826NBXmO1uoKvgQtviHPR GcFSigTQCH+hC3VyFLv30GuKFjPQgeIK/+0DtcHoXRSRM8JGT3XqYjqBINAb5Z08uNVRJDq8/MUG C6KjtzeBZtHpCAULwc1mV3Ds357wxgdmiQFyCtwHCrLdbPTw1Ads8IPAxDIEw8g13vIv5CdlQu0L cODdVgBGakIuIOMyKtT1azu7/+sdK3Sr Xt8X/FT4+334z9FsgL MX0I55GVMlrGGwe9c8yl E89 S6j JzF8c6C/oS8WXnQjHe1Xzq2xBmRW06r4j9tpa6r9psYH9SAkAj 0qyyBADISplme5Jn300f7J/Q4C haAeCBBqLgRZDtkLiBbYm/i2RLzHJFBLAwQEwlBuM90NK7wKA AWOwb4DrbBrmpDAki9HE3Ql67qF cvcWlArEB5YXtiyY7W68IAkwxgKfG43RmBbTZUXKRZxtkWhr CwcQFA3OIei6shCgOtIDpLHmK10P HlClQHjUa86dtqYCsooePDAFKMQMFb8NVBwcxVvLHmaIW8yz8CyfHzuHhIRHpmKPxjFauw0xYjNp GdCl+DlOtjCzwMAjKxhM1bLofC0y PM+Gy8IdiAECEowUrApzAWwIrlOZ7rK1xmZFNdgFBi+h7TaC 3KkuB94rWF1Otuez4AHiAexr5Ni I0ZsVkqgEIYg8Z3Q/KsZepyw4xTozTQFAr5pliFC8R0WJ S8US Y9jxuwidbAVdgMc73cX/k8miHwgHdz//JJXZW+fvhk366CZEN mjYBi9oyOfn5+coaLghaKQaaJQT aH AVs+bnDGhYBWh IV3mXRbxjEGhEEZADdqlLPOouEUo2aDw9jH 12ciwgK2hoGAeNVvGsEJAGgcOm O5h0L1lTHNtL0CiZ4gUBYY4UbxWkXRgBfiTdt4KRWt47ynQIJEGiTdY19ANZlAVAN9l/hCcDhdKJ Vfx+GhkaFw9/A/6AwmGIFDet/Hzmx oQeR0CzSRTcvpCkVbSfIN8Nk1YcjXAKGoQdoWwgi0odt3pa pmmazhcDiI+WneBNZJqkq6ZXaAwnNEjVbcp+BEcYa1vHl30k0lp9SBKNn qvKF/DGMxg8fQC2BAJS Y3V8JkqIU6aG21DmFjBvCYHGiOElww0IH9mGSE2/Wgh9QB+EF/4M/4vag8Mh234dHtv7f6+UPlpH O/t844CkNwt5W4a/4W81ai1HWLmgKYPBCAP4iwF1/8b7kPWZ9/8gzEdZA/k7+n3eQfdGMAzFqCpA Eu6DPMV9AWj0NiAU/zTFpOmCxMwLvR9aMpyQg6T4MgAZ5jMgl/j8voh4hQmTV0YhbScUhzcDaAQn O/EQVg8fCSVQfBCFEG7a7R67IyARzQ98Bw0kER9ZQ4z4zdg2BX1 RcsOZjFd9D136g8dKnUz2/34s LBsaebGHlzd1MwgDIOsKbJQM3d7CG4/3fNRsHg to63a3kY2VYwKzTmBq UB3JyYVGLTAZ8P5k5GXh IC1G8TvyODcP4QU2iDQZgwgDno+EJBAofBYW7C7hNfckFhIVfA2GDEGYHBsYmEGbBOsIxUGQoCGw IO3QX+Qu4nQhGUImk1kEtq90wcQOZa1WF62eJtBkllZHhgUVzvj9tmvDsxaEK0QbaBTQ0Dv1Orzw YbEdWzZyw58DqwVkM2ZqVbOxTt8JqlnfB2NJ17AeaDDGBt0MEoUB58gQgKaofySczgUG qSBLfQfG hmu/n38gAYC+qFNXu6x1JDBoYGM/x +eIUzNfiO02s33qTyb1Ujl59ECqr9A7cBDh2hRnNkMD 1Qlc 5fA9sLOFvSvvEVNYC5od3iosFvvC7Gw2FPpZGRpQMwdtbTxw+1SsrNRc5 ocC+HqTZwoyqQa0e3IF qerSV9pR9wwi5ILff1FERpp6 5z0SHjDXvEScyVcFeyF+GEbUtFCLfngDczkGx +BEJ5dAJ1k8J3DA hh04J0VAmblbcYIM7B6tFuhkMAP4aHD/szOE3VR17XsEG7FvywfMKxkCD2g0JyZscOBrLnYjX94i BvsZrBU oDWgkDiA4IdjAlAj8UAc70EuER+KCEA+FwoQZjyDXhC9DOKxXYjJUpgxHYJhR/lyR3hFs ygIJc1BIfiTjQRgy8P3GZgdeXhOWJlOgyWjLl/M8aJBY0p3MUGgRR0EaY/6vV+rXCjRGM0/aU7qi ATgrqscEOIi+O7qmM5SesAbqIH3oSccniQPsgTuvfQ5qQ4Wz36p2HusOULDDFowTEQeC1gBu4iVs gCYAHlS3/wLwZn9g3uhEdDlISHQtCA50gbBAtBwE0LQf6gKfwQrPMOslJwRRIfTpky/DgcGg6+8w rfn9bSYxiBaAZgEfCALPZJ3r5e1pdB0EdHQQd3Ve3DEiOAK3gsfX/7GIrlfV2JHLe/5CUhG/MtmL /ekjx1AM BybeekjDbSdoTOFWGF9PUAn6b1PRZ+uF4BL/IIoDQzx8dB73dBri/KWc+xY8XHUcEgpr D4gB/weA/2C7VHzbiwYgk13DPHv2m8ps+Y u9i9NGigJCKvax7q UADHTiOAkNdevr1 SX0Bm2jTUFS f4vRSR3cStRoDudkddIXzjv7 wOBG68s/yesnbqFAbfmwmwjrGToHi/H2lDJ12 3Q3BQFKR3/VHHed 2dH1RFQbw+kKSTwkpV0XbZJQCw9JgCH7Cf5EqTc+b1NC/zfHhimKHQEH KDPRd0BoRxT3W7gL2Xuk OYlSeE48IHKRozc2fj10PTwrAzxjNTx/M4AtoHE8gAtBKWSybtEQAg5GWzzXfSHap37GBAYNBkYH lnj3RAp0sgxfgCQGWGOQg6RpCqAKQZIBmaigCNtpoodbpFpQGCFqMLhjG65eUIDjBThE6hC+WAQL UKG+lX2886XiaaSAbqX+ikwNvF+ICv4PcAHp/vd fc8HhBMHuBAvOF4hKAYpIARgCPluWZQ8CBl4Z AopADAa33xXgP4pEBQxCA70YIrEVznjrBQwsxWQDgVcucA2CRYPoeLmIr8IEKGDsASoVF/598GE9 sgALcXImUFdf6K02A lzoXDkpkyEWwJmfNYtGQkrw/7 7+A4qEBSuIRDXzdbuNVUF6Z6oLjlaXjjm4 uAcGzktq1zAUkAH0Flpo1H0JOZcDGBHmdk/eDQR9DQ1DBApDDOt bi9b4NfiIDE5lS51MoYi52HIN HaggNoYQXXsEcp7gbVefAbvw KURWr+d0KoifbYN2o3ME3T0IAvo9l7o1BEJ1HzwDEwSlVomGcwzh E3+lqkI5arTBXHc3+t6LnLe0wI2ftNBlY+Ug5ptQBbuhZ4xxD1IP2ChQBMWpQGa4GuzotnhtTIdf 06wUVl9vpw1VLQyqKP+3VWi7VqqxoBbVlRvAgccRsAcaiGyQFpqN7SZHH GiIFdcYQ7MGyaDyFny2 LaxEEDNPXycb94COIppZT+38bboo5XiLuNto 8Ck1V bMDkrFZ06K3vc0kVwXyuJgdQbPvvWoaVFcK yUav+0FVFICMIlJcX3BBTLlS3F98BblRY9G5hCNWBTRR5ibrdkZo+KtXVhhQDQUc4GG0aTMJSMj3 UhUr5PMOdIMR+MDDU0hFueGifZ8aAa8BfghFBw+MCsJoJHfAihvTQPiPiZ0P//HUsrHKRppGfQaJ tVoJOXgb3gn7c6ENbvh9RPiJvUT6Quw7c8AfXlkMQQuDfJLdCkv1TcONtU/0qMS3q91edXOLsb8B P0W49+ACLW0FnyNhI2itBwwTD EB3u8FJ9RVQD/QiiBhOP/xmJ1e+Cs5YkS0nOJ0niSPU6vxw6/3W OV2OxBdsNwmQ6FjrGKISlMAmPCFyQcMKGTG4ADSUOEex fnJW2IIW5whRKQ4mwgvYxRA4PZk 6JFFu ob2/qwXsBzJFIWKmx94ufOo9ZBScRgEnVfQI2sGA0n4lE42CyNYkDlgyeAlXgxQzSQIKdAoADcCl WAPD05f/HEBz0hRUloPI/+usIhWl947CW4sL1eAJmXY/MEUbOaRiV8YHMB8iWtWAmvagy2z8Qj/A O/BXImPqR5aRbQgIWgxREA/foPvNjkiKBjwNdAyOCHV0BDwJ5mqJEhMw60ImKxEjzCr+NCWaDm5i RjI+PDqQDQraBvVmKgIEF z0POEAN9CWJOIQN//AQfCLaziZJzogQPoH5jY39XzFyvusBToCkEgBd zLlQB8IVVEEA/5ihtejTfkqpDwUxV7sOJDgxMkcNu3uVODp1YR7wI8VkpkYP3BFA7IqeuUbSygFG dNJPiaZzTVgWwblhXUIfy8IfCkI713zqdQwCKEK6 9td1HQvjNz4KdfEFDCpdaqPoCQgwDa7rCxpi Y64gCxwHBjUNHNEWVFaFQzRQDyPqxk6NCuENNtINAI6SNWP9hWq5DXWE80cEi8KKCusfpCjULTwH Fzg8dRT8rG18Ej 4fiKMV8YAiAAyBgSDbRj4MYuMGrPB0MnsQJIRpKNBRESwGMWsYc xVExK/pCIJE v0DrM26pxkpSsoqUIKm+0Vv5+gl1E0EHOX8Sg9KNBIAm/L+X1ERC0B4wfemAOS11GWkd2dSj+lRa tH+2gAZBeptIvbzo1CxyUzlCUBYwXdwqoLrfbORbhVYbQ10xJ/yz5pJDjBAuG+o9AWYn3YqNBZPQ FY55SQcxAFyAHxLlYIxAU5b0/SNyVYdqv+Visq4H2IP75Pwti4LIUuen1lNRQF/HDxaSAQQwdfjD eWHNAm+AvnhZO8ZZWpc93WyrE89IjONmvwXrdt8gTjGIvGh8BFc322zzzcQ0fAc9K34vKyZ4ebaR PGxaPCvBRZPwjz E+u9UaYM23gQ5kNlRTNG6tTnMHv402+gCS5ztEMTFMPLLPnD3VACzNJTQgsZHu WeG1AIaPqiILBh5bXj00jGqLqmXj49DrDdYbmg1CyWhvmfvn+HXsCOxHUejdBkIR6+47wgEAgwcs RBEPAY/Tm6FykM8FEysGftGJyBBnfkYCSd51Rd6gKgVoLCrfEQ7Y/GqZfB93fR jaJGBr1j6IEw4e 91ngjOiEr/yq xpQ4h1FCkST+04WHT+m45HZQg9gqI99nQ8DcrrAqaKhSoC1MmmMXXP+YNSQX0IIG 6Z/WAbGAszNX2R4HY0jJSmHw90GM2IcHEBBe1jj4tshE31cf0SbYmawVkkr8s+cjfrxIeoIAFNwo 0WQBe+x yAd/s6dLcV5848LwCj3p95z4ciL65VJxbUOB0K2oZLXIE2Q7c4bK5VJiq3qn4Xf2xVrjt ByD0sJ1LRMMeowDv9HUYunIAjsrKh1UbFoArSP/vMV7SXSdbD5T2FAMqIXBbDQxLVuw9RZCTA+lR 0Azs5gL5POz87PwFNG0eal+7hEBX1exdKEyM1pw6ewhzyciT8PB0JOwMxP8lS+7sdESLG4Xbdcch 1I5DC98dukqD6ONA3b6qQkh0OAIuSNsEBYt0Zvhp/nKjH9CHD9PrJX5jc0MYsu9dJuvXaOwG0CbW gEX+NbEIAHRYjadkwADIN5wv9965eHwPL3dir4ClU DdOLaO7JGCPWRVd4geejudA M9ePaJF0YPc3 5/FBiIwF/J1APfdzEQA2X3wYJK4XV6Ae1aaOGaypiW1HgVkgqMSWEyQMIAkB7ywzWFmRu3T2gtt2 QiGKefsR2Fx0 FQRs8b3FLxjGhAUiXAUFT7PPAUOvXDiLCBvIYJErDQB/UDKYwM1pq5bBSFy/a5BW ue JB4iuS2asOMVbClyEYVs2AG5vID4aVATtjY+Qmnx ksNwIxwEAPgI+OXxEADnSa3h/gd6pGMUZm WEJgh0mqwRWOF12q8zRXVYnzdc4SvudSNos11k3WzYJNRsCtU5uzZRCl7Gka0/GRAev4dFoCwMJ5 wo a+U1EdjfjKkkma7usooVP4COTlbFgXoV3WOV2CyyZVz5pY2oRdJJSVZGe/moXmKuUwuxcGQ5EI ts29qPOrTqhXqg2ZkAAALzr 2pVe YI3tAOJwFLfY7M0hHISQ2pxQ8sz3ND6iIJalZIMeGdCAYDTAY I4MQeawlMQKoDy DIIMB8RHAIwXUPFjt3NvvXKGPXY3hZV/U1UDzAw4p N/RArtmpEDUOAC/peVlv8 qMAtUQvXuIKBYi1yEA4XIlGhVd1mOidTZhZKDQMlZEwfw/CyoJNo4CdqICdI1gVjAF1+3KK/ALDS X4vP9/G4cxE9DQ9LACy44FqEetr8t5wjPFkhBXMHaIDr3F0T3qxcOK5QcwtYhLsLOWh0LC UgGmdX 8nk8cyY kJzI1cImR/CYl3CVpcNwANxtUcwZgNXv22HUEZ95oaDssCdAZm8yRHi7XNnxQgfrCCn9S JifjnPCEfSkMg0FyKgsyPsnZkx5yFxIUCg+DqBq6Zig/xkfpQxweQt7cWYoCOGjYKzxyE7fddkpz ZULQMOtBPwcDe3glN0homPf3NgQ4Yzu7bOtBWT8llFjyUpzAbJA zGAM0BAJ2qdxoSEdXS1A DJSIM OwMY lbtFwL4kJVgRMKRqGdUFA/n9MCs4KzjNJRx9gPz+BKjORGB4uU0OX59UwgWy/yX4eyUARWGG ALIAJ4oiLAOIEqZpmuZQAISAfHh0mqZpmnBsaGRgXGmapmlYVFBMSJ37maZEQAA IFQcD+JqmaZYU 7OTc1MxpmqZpxLy0rKSmaZqmnJSMhHyapmmadGxkXFRMaZqmaUQ4MCggpqBhphgABJpld7oQEwgD +BPw6Gmapmng3NjQyK Z pmqbAvLiwrNimaZqkoJSMhBNfNE1ntpcTA2xkWJqmO9tQE6tAOzgwKH+Q pmkgGAwMG9 FBQkF5dtltAEUDvr75 QQABQfL/7iqBBE9e+09B9UiMYPlADfv///8VKSgyYTEzLiYz ICxhIiAvLy41YSMkYTM0L2EoAgVg/38FDhJhLC4lJG9MTEtlQQD7J+TtEQQTDUBCoUFOQEpARszr 3pN mYVExJiwDMd2Qb/YFF0P3PEXsbBbs wTMeDFEH9rfsDQYAT0VAQQCbhE9FFBEZcahRxCPdZCPK oSdwYZ1c2WD/WycBc0jZYJPcMfxfJ6IRRHbyAP7/j6XhdSdgTUhDSATtP3QmlEKCYwL6sjQ3tyJW aWdMvl7r/7v/3wCtOD MLgAN6Eziq4U6+AEYK7B+QKtkHwEH//f//jMfvAbjLo2h73/771Up2VxIG JK1P6yOosfzMGef///8O7D7vC9pgGpGTymfaspbnUknwK6NQjmY1YOX/////6kF4XM+p1AutzJYH a1KtElBCmUSIvUSpebbI074jovT+//8/QPdhb1fUL9uMTA95nKA0DiFdsJoqJDMvJC3//4UA2CUt Lba6/j7OY2QyY0Zkb3lr6+72OW9kIrSGVjc4b y1mO1X/+/9/I ig1JEE55SuWF/aGqZoxYWWvj1b8 gO5O PbS7/f//a4fGBlIHcelA1Ae8mdnBKO62BcrwGh3/liP/////HchjUNEq0jDZvM8COOdgSfUI I2RftwHyAYEQGx9n////z+uG96gcUW6XElUFQ8Cn4JmJupKmp4ygYJdGdv//X/6CxkyUtaxVt74b BESooui54q69mEPGyw1rzAP//8P/eLu+wLcwxmMg3E4sTXmkvAWr/+Xojp8KIQr/n///+rcx/f7/ hz/aabtm4KvEca6VRFz JRXiRlZikj/z//9iap7k9414kF+2FBWNotda+awLmYtV44dLz////vYIY GiTTjU3OPLWuvpAcxcQOP+kuoadtv1UCQP/////i4FBJD8M/ErZ0s3v8+pOWa9CSx6pGTVBXREhP VUVK/////1GPdZy+VkdLTlRBQENCQkVDQERQL8SaRERHRjZuQCQ1/////x+at7egCC81LDUGQwIu L0kiTyW+rP6gEjUgDBTMLWXN/7/9/8CtfUR2EhcWK2EYcoH3GbHM/Pm8e3KasuqHxHS3////v0hA R3a4Pho5cg/BZEHKhxJqhhHMxXx5bpb+Ebf/1v/KBD2+MUW+VMVRRnqCyAQtTs//gbl6Bv// /5gb mry/PZTMxHl5ESnTUGNputBs2VBuZTj/f/v/y81EHbaenr/BuB01um41TofFRGMdyd1EeEaa//// /z86Nsp8YWgrJCs5Qr6WwoFCIyVGIazyPsoMJU7uiRAM/////ykZUGATjC/7mMx8TDXC hVljt6j7 /psrQxIrQin/gVpdEv+3/7m+7Pqc/rgpTo7KP D3IHCX/QUuqUP/f4P8cMa6kPro/ZcoUpTHCoz7M zUx5usvVVOD///+xtrc3unFQvgQxQyV4RD2dzGESEBEjeir3Hrr////f2ykYWRJRF1CemUIgNlk+ 507Bj2FEllygyB5FKHn///9v+IFTLSfxNil0NwxHvvKeWsSpeOzMBPlJWYVVVun/t/itXK0rHRdb ZUk+TrwmKZqNsGkXI7/9/397DUTVTtyt7OBaOgGtUT2oBxgS8kLtQexVSf/////lPVZLPkSf5+U/ EJxBLXpgmJ/2h0oxN0TKR6ctghpq2V/4//9RuGVaTs2WFfd8mHFd1kI8 LV7lzJe2ok16t//////u 5bgY4p1M+B3p1UHXynR5k7HDsJdreaIRxy55IJRNe9D///88UStQGHSD L8q8BBWGBFEFwkYRmCtA wSyM7P///79NTFt9wCeRASWYP/J6IcSBNVQrvr0VJYwlPSwZKUy/wf//l9ktHqK+hL8fG sKENYiC qsyqS8qtwq1t//9b +watN2gHj9FZdVHT1lq+IHFKkXqSyBS5DP7/l/6GQBbKvq6HqHOBqVBxFk0W SRQYwgy1vsIkjt/gN80K9r36fqzFBA5FYc7/b/z/zL0lScpFgHoDTTUNcpOoP1DKNLl4Rdc1RAP/ ////lz+qLw49skJ0YLXEkz1MVmrErIK+NbBFejWQRTdgBFr/////14sYTDHSbAo/SU1ORxKX//gX 8SsYQ3pGPdhHf7ku9bb9////gT1XLCaOuchF2ALCulEs5Rwa9Cqt0bVBk6h+mY48/7/9LzMQwsFC TszCT+lmAPacLLo8KsoGewwPfd9Y+P+JK3o56RFycm7W0IEMGAHMQraKVf////83eBbVX014cT9R US6sLprBdk2otnB6lzxGV8992QLy9P//v/CzPu08hp89z75H2zL2ljxFdzJytxgqFGlbK//f/v9J /1RXXXe3lbICtcxVcS0hVlw8TspQwoBFyBXE/63//5l8rKtzNH4tQJVaUkwYSCsnb1mo30nJdgJd 6P///8KH RnqyPWfgbPn1MZq5YIVtgrAuJ/c4U3wYGPgF/l8PscR+A7Rl EsocSRf1ynEXrc/f+P8X RYy+Mk1JU1nKucrEvj2q 5186dso P/////8sFuEViMsBKWhr R7EBFMuBAqJPs upx3TvdbbIZJxftE /////wlHTScv3uo1fUjE86mdfyHv4pOdhQNhTsPOt4IeJlYR/////yZSyxggjKo82CqeOSAbGHhX yb0/FarsR6C+PhgIyouA/////6BCzH1Ren88Uso/RQGOsV8/IHh4Scg9xJ15pw4Pg3LG/////3md MnS9RqCv8n5LRz3vmKpREkZDg6pSnlnF HklEq2oXN/7/peEdxLcqEqqeNWRnRqHKB6AsmbN1/0b/ /x4JeRctTykf1l91cSM/Yam7d nKcckti0f8L//9QTfSaLBPN+MYBTUc0RZWZGewsqMqJMEBUL/// //809+xcntlxNU8DS8K7AqtfH0aoSa5eg QGquf91FsdIAv7G/0uNMU5qSViuS9FTH6DrvMg8sSlL 0r/9N4U0rdbdR/LsflYXTw Svw9kMtL/B/9JR9WDzLE69xNXiyntiLfgyQP//twvOFkbluLhNmZo9 WU/KCE+YRcLdvDlc/////06qU24yfFL/vzFsYSklUMa9LLNYWMUavY2NNL0cg6cP/y/1/zNQUlB3 uJHxyIJqYyrZHx778JTDx7NIefC/wP/ZNQn/lXQEMjG2MIl9kRYXPPnMrf///7+E3mtVwHk uP1qZ Sn rPZislfrawBR4yS+RKrOBx1Z30////CENFooL36MoaYyVlZxRKPWWnsfCfcZnPSynZe/// y79B Yb52nr72zkZyrNbCir54aRg/fnqcPWE6//+F/w36hbrssf8Nmf9Sef/2gS+d9NYs2Cy4Gz1V/0v8 /3BgvnWxNyC6YOQ0Q8qfS5c9gBJc7YA3Mv+/wf8EGOVnmRaJr4zckU60sXq0wqlCECldecB4qfT/ v+Cj92z9nfzpw r8BekdJP0L///+XTXf5nOPFZb4FQsK44U9LLf6dVRE8ER 96sT8v/xv8/7GSJV4/ dvo/ ZBhL0l 1U6lauuz4KPEAHBL/R//96rz2aAu1GKYVIbByfnR5fw3y3MFCBlUD/hf//TXx+DYbO PlEp0R5Aon0vvSnaxJwhq26vwnj/1v//bTVL281dk+ 5HK68YSY1FTYlJQHRFvSbRp9b6//9btz9g ulQQcz7bUb3B5US8Lwdf22wEAXnt3/i3rpeWcNGATCluyZPCLzdXIs7//y/0zilTXTdJ9ElxY7rY xexx92lUUcCDsWNT/////1ws9xMXBN6VF3OEqdkowpABQBivZnz7HIG/FZ4ShwSF/////0Icb9aK hC6HJ4Y1 iTaIIIqkM/hWizOKJI0djAyPLJZt/////9YojiKRkG6TMnaK7yjbkpWUl2aWFpkc8p13 mC9emyWawAv//50OnIwzmjRqn16eAgKhNKBJHJY13f//v16laqR+pxdOpqr77yqpVqhuqwaqfq1e mkSs////CyUTrrEvyRyw97XbLJJ0tG+3tjffubjZ5/cq/9Jf6LtSujXKBZZ7v216BIH+R08Rv0v/ //+ubktcRJBZwTn CgwBPMlhVQDRupyxEOogFEdv/v8FPY+3Y7IA05oFZQUlJMaKKgeAnJIW6//a0 KQHnqY+WhhMkJig0CjJut///7TOBsAcvkkqzsjeRKCIkDCbb 5xEzLm29of+//f82dzd+vDI7DfgM qcbAiLFPCWyBbSFXG5HGqVUS//9/613kiH6mcRmBbCy0vDRIAR/AhWCCIkb2v24x/////7ornxyd AMhHjgEeqjuYAc2g4nhWA8 gAUYGGN4Y8VmhF/kb//0xfSk0NylxFC1683sInSUFP+aFeObqG/7/x tyoxksps7apZN1XaDCsOSim7Wjxjd/8Sf+Meoar2aivyQ6MHdJR9l/RahRbb/wb/EUly7Y80/ilw IlwxPgTpiKzsAMxb/P/2bk2OEeJ3XVNDDve+FBTIL1nI5WH/f4mFYAzD8ieeK7A/WTNc+f7yqLch /////+zjWswGTiZZer1Hj1w6STNLlQbISgZ3+vGa9z/IIF0k//8v/VFyrQYUSUkM9mEUXWVdhk0R gnGt0OygZFHn/f///+U+SBabgcTxsarELhQvmZeYGfppNFblg+FWwcPbm3+B/y9LUbZGGsq 6dQIl PpCfERGGUwsCSf+FC/0RbK3zLsHURTQ4FG18rT2gcUa80P//RBIpUVi/3OxgnF55/dHfcfP0ZftA 8S19gwuLS4AVVLtbgweI////CzYSy5nLuj2wt/4Agsq7ypCAoVEnSICoQ+DC2////+CETf+y6x4a gBzk9J2+GKXCP01BNLOGB00DlJoSX/r/U+x3IachU4IKPkJve6yOghILOBQq9P+rDzGE97xc0QZ6 uCRn/xf6W/gfjklCB4 Ls0RVgNzoxyOI0RP////+VeQ dJYovUm6lqiQqC7mvu9lMG88gf9A6qeP7m BodOt/////96jj9HCp6 AokISm pHZKr4DjsgXRTXzyooBdAEyoIH0GN/a6v+DJuSJKpWELFBhPzzK DMBa+xX/////ekoBNXqDPQjZEdE5ib4f6PlTnDbaEVUYhHrKhraRh3L//zf45v/stXjHPGdTdlFm PcpeLHnicEcofYAm/Ft8qyoMTxeLR+9SGEby2BcU ////L5QGtn oW53NGCRYIeoA1UHLi9CxKSosC gzZ4LbyJ/7/xFx8rgx9FzPPq6r5PHgthCqwJBsf/f6t/uuH6kUN5v7n4ZurX/McqUDs5dTsQOaH/ //+taRD1VUYYC7UIrOstsTRguKnApOeiXogcB///v1VcNUO2lAT 1uPYsyMjehv4NdDSQwmdB499o oyukWSIctNVAqkeQiv+//X82XQw0rxFqXHC3Cj2thFe2k3CHgUUINLU7mv8v0OKvW617aRzML0Vf hGGo9AtC+m///816DbqYrzUcerzfWSOSaB9Jx/o6WTSuN1Z/oxK3Cx/67 4RsIFmtfL4X+rf6ahks 7tCfHlldDqH0fn9FD/////80mm07w2kSSsOFR5 oSeCii8yF6AXJNKrk0A0YgejHmNP/G///feF9f rMNXrBAW6NlKPJnl99u52k1ni+X0m///v/ScldvKDVTIDaDPi2UO5Zm9XvY799CZuSVZgv7 /pf+b Xz2RZ1yd8B6Q2BaI0OcnZ SJlnb+YXghf1OD/3wWRNQwWzr1Dvep3cogeyL1m+t/gL67J4HYbdV/5 K8yhAH9lGpIv////FwQ9po9e1J1RIXNznUkCsZd6AkpkVe bCPEQYPtv/Qv9GrPO1C/LFwyl4TRJa Eck/lnbQzf////8uhSPFRnAtgKdDF8DDDnzM/Uf+Vx+kQmMsJMqSMmwUMb/Fjf7RoZp4NAggNUkq bbgew1n/oNTb2x23vYk/T0TSU/XbG/3/36a3QltYSYMdqj/imhSjFZHc FYkVR0L/f+tsyAEXrNuK SXpOW2KWL8yfQYn/9N/q//LQIT3eKSYhCUMINk0/DSHkAoL ///93LnF6DFGeKcrxof9nBkn6VD2p YE1dGdxC0xT 1HP/G/1vSwOhh+445iIhy9zVHQhfBQSata+n/F/44ur4cO21USNNdXRg5FxcnHlUd wxp53/r/f0O5Fgd6h58fOWqC10U/RDO1NQX8Pn4Mlv8v9P9kSBfcF92VEvaUrurqUdw8vTdbVFQZ F0b/////kzZU cM3W 4Q3vquoSJhgx/SPMtlWIAEUXd/w1SBEQblXV/xv8RFlsg1mnqdsxsCUnzSaF 0RbhNyjwv7/t0bz8Uc0X6YPGrctAv/D//8WdnxGLAKmEyUAzq0QyWnkphi9LRlpqi8kU/7f//+IU S1kOzI8ir3GHE4FY0GUfvATNMU3mCyctrohf4P//n1dSDjSLT0KpJN07B/AYKZTMERRjSvH0/i/0 /0ET7PRjTfmEOPKrdttygXlCNWABwX1Cv/3/t0O4V0KCywm+MejeO+1N90aHiiFAo+hXX+Db/xxN qdALEhMi9xSOROK9YTisgL2u3+gv9IBVPwtZuQr0v lPDe0Spfa8v9f9b/3 M9S76c/nqjgHGqW8tf W1LB/7/U/6D pHreY2FqIWjZLtr64YVgAQot1yU8Hyf//v8ShYh2FTr67TTT4vRfQ2bEtJRmC8hHC /gX//y/1mlVBQnpAYgQmhgFSzR4/OuqMrkdJv5379f8L/9lNNxVzUcksTKop/Bbq5EF LTWCfe0v/ //8vt9mqErLk49cPrBrETQTYUxg8BamM/MW4T9mkR/9S3/pEOTZTmvn0rWWIQbXSQuROYNXW/63+ d22widk5Q8BUqk/RyqWob6FO9/4LF/iZS8s98dQmvmdNTMnMPrq3/f//pVJDNWgKNVZDSraXSsxy tkKHqmlkuT4q/y/0S4iecp+qXEO2kmKevIP6j7xiv8L//9tKnkpWTp/0YrZKn8+e+RDLKtfM2a9C fP//rf+AnC/+sRhqDGkrRZKvykmSoUWtQpzB6PqBf4P//0qx80Inw3 MfQONtxOhuTHp7YsDXGQFi tf3///9PR2SfI+hJWZkKypcaGaKDmle8ecYLNLcfiIM7NJn///8vdHYBUXktbG7w7 xb7UcqAQm2Y 5CzAbkN+gKNCreP////IUzIOnpmj A6ErAQYe+lxAD1X7EaHkauieMwyS///fqlNVZF cQcbO0y1VQ yVVJADzJBy7TM7P/jX7rzAi8gmuEt1oXQ4IyYcdJIgNa/v9f6q2n6ECAW8JSueHxkMT6eBwwot6e N57X /L/UDZ4Par9VC8w1EEKWy0Xckfi/xRudS8lFjooztEYcngmAdZf////fQU5R+AOexGz393kn R87rXlH8MGqm270Y+vlS+cH/v9T//IyRLgkzQis5GNUQNALxl0bOuRFKUm4gfOv//xljwWoVzlVH yPUBL1PNKhZUBxoSlXpEo/rW/2/xXAAS6K9ESUZ2tKL4NqB0huJWG/9vlCun4EFcKIG8wbYWvwK5 RP4 v/f+C32dOJ+BDWoDBxI/NiT7WuRjZoXKAgh1///b/rTLAoMTsNN6rwLhES1ckRFe5LDxN6f// //8DVka/6FFk Qs6fn0exvnxFUe01EQc6GTQ9ghAX/+ EjF/+N3vq3NE pLGBnrHbOe7VsRCfYdnnvf 4hf4RCMZqk4KXxC+eWbpkbaZWjf6W/+BQh8Y+QnuSk+1fMfRK32bxi76////kpbMQFxRUBFuRRF1 ts+vLFmSH0VOxOPqanEaug//F/43OXpgU86sxjxR36RXEW1XNDjKURbB9Lf47dYca8N0EQRO0Vie ISQn36f/X+JvLCdhp0s2GRkbwFvi 7RFaQFn9h+1b/P//UIkUTGWfOPFcVDdyFvkracs8KBq/G4Nf +AUW+o15iVt6Y0MrqRuABqf///+XVWFoX5ApjOVQtBl7kIMO/yPUUWIfqxvESTKQ/V/6/5ZAkKuN LDL1EWCrBL12uq6cr07+jmFFUP+t/ktlcGqA5H0GJ8BRnuziNz2lCdj7/1/4agfMwwbyMfqes/tH EglrfUdFAZ5Cisk+jf7/fyy8SXOIJ7aYmgv1GitstJODHAN O3nT/X+D/SDuAqv/Xj0dchNVsKjX3 DdZ6hWHKsvwl/////9 vY5emXkH eJOVGSqUq3mrCc7szUV+VxXGNPFKlLytxB///C/2xgXOuRTW7x BAYOXan/TwEnNLrj CqszsVQt/19Y6LO3BOr9GDV2zMwE1ML3iupEpn+Jv/X3yCIJxkWbE6b/MRBB gKspDDn/////NKjRJ2uhnUrrJKax7k1h1X5vDl2s97TUpLpRYRAdy5T//2// uFoKN8AOpzQTBahF cVbU 7pqy0Q2uPLFztjytrcT/X+KGh8LhGuBQmry3x0j6oAYEaEb//9+6Ba2eqKn59PAmHkhDrX1w qnyRtyfnrK2qX+L/pTGx QnMOKbhfqu442c2NNR1qLlJf4P83PHOBpMkEpcMx/9VaOpy/y/+/wP9Q PWyXnZdZTSGcR16rV+34IEQZYUkcpaH/ //9YL255qmc8MRhjNKTuF TdY4FQwKY1BQWthL/+/1H9I v9qnac1RQKUgJQcoLSRYQb8fEiQ1////RkYuKC7yt+38ThYzKEZbAjNkSi6kHvcAZn+pv9QGFbgq Ai40TC3PnLeA9zNXBPD//y9WJCwxEWgpTAnwfpovcDEHdyRI0i/1L+0uImO/p5+a30kkMjJVYJe4 /f8yJAkgLyUOf/qEPkUkLyIg/i6 /CYD/VkCtJTQtOQ8gLJb/v8B/JSUzgo9DpwSJAOotlyecFSlH JT2jP9b///8biL8ssjE4DS5dDSgjMyAzOHPEbpwh2AC4IE4u9P//MxJJL0zB9iYTDiMrMFUEOcOR X7wFJOtL/AUaLnkoVwvYXAIXIC3E3+D/f0qG9yRtAE4OMVsKJDhP5pgdrk515zX4t3+JUUmxNjIx MzEnuj1tivN0sU//7nff0FFSdfMLeEVWSECDCVNMQzJJt79I/xn10jg4Lg1AQyJPs+UYZUNR/y/9 BsdBJ4CPj81aRXJGGXYatx FNe6X+//9pUUYRz2RaR0ItbhhWYe1XQSX9X/FOSh28cKv/xTkEJ2PR vzcg qkViei FvJf3/Ly0DIPalKk0KAVeB QcEgukXNcUKPzIkDeUYUYb4hqGP/t20RbcwFgb 6+FsKM vqpR0QDLe+P/jUcyRgZAmjRGyl/Cr7 1PM6z5QSvdDtgRUIEMMq4qDqUuwQcypXCIczNM4R3Yt7pJ PcKONTXIhC+IwkL2hAw0YQAcTAv8t3/CgEPAvEGylcKQQMxVbsK8+U5K8Ubuy0MDlKS2qCKL/tL/ DfRDwoNFyEbChkXCCDawQI6oDZfYuu8WH8i2+DWpyyltzUA2wcJv9bbBfkBWykbLHkVUqTb4/b8O gVHHhWi5waqpQLE7RMhpmLffGuX/TCNIgTUEyifMxXXfdoVxGOuyER9JvtclC9TL///WTkkdnci4 OEZO9kYGEQb4Fgmz7xQpN9u/MzdGyELCgkWqmRAt IKgCRAXmqvm+ALmQW6 MDEyUx2CFphqQ15z3X XG Cb8MUxV/2LH4MMNkibqQe3Sar0IwB1QQoEEw+cj1H/F/YFDQ1BAAUXABEIA0EUErnJB2saChYS cx4xbYPVak3uTgANBlyvLWjwhyKBrGAsttUPSCgQDEHnarW2wALOvzsNqEr4LzAoLzUnAPMURVhF RIGAwBqNFggI5AEAMAoAJFEFv2kmIKgcAUZpbmRDRAGg8mxvc2UbRMzeFdRTaXplF+9/+0xMEUEO TWFwVmlld 09mD25vYW8OVW5tEC4DcnMibnfDL0tFbnYQb252q4qOXVYiYWIYOYi4HUQMdmXa7pGK mA59VGltRirirLVXGgtRQ6LbuvexC3twXmctTMNuXyB+TGlick55QSH2TFC0UGMoS8ZEObb9 YmFs QWwGY1hMYbc 97FTTKk11A3goG5u1W2wXcmMPfrB0EAf751pWHUZDb3B5xURl2oc3awaDFyVIYecL IN3CnUVTY9l2O/lsZW5U33BQL2gNYQsKw1crWEQds7dFRPFvypG2UMTJcHlNkWxbdmeCIk0 TRXhp QkHxYt1ocWQf8b1ZwCb/L5mN94YNuwVlcKE2QjfiwsOwM25anGVJexFxosv 7F2w g/F5yGFRvkxWG maK4TKkOvCV7E2IRDQhja0OF b09EcgHjZGVDaKfcXURsNE1vQnl0IhIUJyKcnrmvtS0KY5g2KlKg sr0n4VRHUG9pKBlIe8Fm7XBGJly9ExmEQ5gw6DpuRUy4rDBpCWmcFqQiJgQ6TRgz1zhDdRh9GTok OWFva6VEZSyVhCDFlWi1xx7jm8BnG0tleQxPcOvco2sxC0VqDoBWW70AGnZ1ZQ+Lz NylhBEpdW0w DE+zzSa3P2TC+G2gomFuh3NlMIo3F2uMchD2B2lzZL32XAl6GfLOEBSieK5bUAgiOTehKzMqY Soh AkoPZrNUzSABoVVcDxa w305CdWZmQQ8LTG939hm2I3d2SXKUI3cKhZtxWvTMDE2CwgCobVm2Tde3 2GJA/wQCEwtlWZZlNBcSEAOrZVmWDwkUczm//4S8PFBFTAED4AAPAQsBB6570mwTciqAMgQQA4J s Z7GQNQsCMwSZW9LNBwzQHjR72RvYEAcGAMB5CECAW 2R4AhgFRrjCditkeAEeLi/Yk6CYpHCQ6 zZ/ u7AE IyALYC5kYXRhmCPuQrrB+yIndkC9zWAbhS7lCQDDwAZ8vyl7NCdAG7B7DZQAAEpBPAkAAAD/ AAAAAABgvgCQUACNvgCA//9Xg83/6xC QkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UH ix6 D7vwR2xHAAdtz73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJ Adt1B4seg+78EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGN FC+D/fx2D4oCQogHR0l19+lj////kIs Cg8IEiQeDxwSD6QR38QHP6Uz///9eife5AQEAAIoHRyzo PAF394A/AXXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHRFi18EjYQw FOUAAAHzUIPHCP+WjOUA AJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+WkOUAAAnAdAeJA4PDBOvY /5 aU5QAAYekjRP//AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAwAAACAAAIAO AAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACAAAAAAAAAAAAAAAAAAAABAAkE AABYAAAA2PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAgAAAAMTzAAAoAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA0AAAgKgAAIAAAAAAAA AAAAAAAAAAAAEACQQAAMAAAADw9AAA IgAAAAAAAAAAAAAAAQAwAODAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIA AgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAiIiIiIiIiIiIiIiIiIAAAI//////////// ////+AAACH//////// ///////3gAAAj3//////////////f4AAAI/3////////////9/+AAACP/3///////////3//gAAA j//3//////////f//4AAAI///3////////9///+AAACP///3///////3////gAAAj///d3d3d3d3 d3///4AAAI//939/f39/f393//+AAACP/3f39/f39/f393//gAAAj/d/f39/f39/f393/4AAAId3 9/f39/f39/f393eAAACPf39/f39/f39/f39/gAAAj////////////////wAAAAj///////////// //AAAAAAj/////////////8AAAAAAAj////////////wAAAAAAAAj///////////AAAAAAAAAAj/ ////////8AAAAAAAAAAAj////////wAAAAAAAAAAAAj///////AAAAAAAAAAAAAAj/////8AAAAA AAAAAAAAAAiIiIiIAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAAA////////////////wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAAD wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAfgAAAP8AAAH/gAAD/8AAB//gAA//8AAf// gAP//8AH///gD/////////// ///////IwwAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP// AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj///////AACI//////gA AI+P////jwAAj/j///j/AACPj4iIj48AAIj39/f3+AAAj39/f39/AAAI9/f39/AAAACPf39/AAAA AAj39/AAAAAAAIiIgAAAAAAAAAAAAAAAAAAAAAAAAP//AAD//wAAwAEAAMABAADAAQAAwAEAAMAB AADAAQAAwAEAAMABAADgAwAA8AcAAPgPAAD8HwAA//8AAP//AADwxAAAAAABAAIAICAQAAEABADo AgAAAQA QEBAAAQAEACgBAAACAAAAAAAAAAAAAAAAAAAAvPUAAIz1AAAAAAAAAAAAAAAAAADJ9QAA nPUAAAAAAAAAAAAAAAAAANb1AACk9QAAAAAAAAAAAAAAAAAA4fUAAK z1AAAAAAAAAAAAAAAAAADs 9QAAtPUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9vUAAAT2AAAU9gAAAAAAACL2AAAAAAA AMPYAAAAA AAA49gAAAAAAADkAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVT RVIzMi5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAAR XhpdFBy b2Nlc3MAAABSZWdDbG9zZUtleQAAAG1lbXNldAAAd3NwcmludGZBAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAA A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKzGhKX/KbNbU2y866xRlK NTiyNnUyxpoawJApxT xmSmxSpkAkXVm/z6fZrolsVT/ 5bFU8CWxVOY+n2R+vp9m7wSZnhMQYlPpueZh7FBiU+sQYlPrUG J iMVBjYaiQYmIwo2xlryy5mjEeMWRIHhpk1K1SBU727CY1bLmaCf05loMU9WaIGyCV5AImSdrpipg saYqYKemLGG5bIJkuaPmcbRxPH4snvuH8Z7aRFOe+YrWnvmNTIFDnZGe+niZnn8EiXBLQNWfprF4 n616XJ+HfgSfge6rgHg0aIB6stqfr34GcD9EPYBIqBeABrXmn/D8zJ958PiA BrVNgEnwO594jrZv b1nTn1eqk4 CpfCafILOhnyC1mYCHnc2fVq39gKGkOnCZpJ6fV1e6n9ixHZ9D/guA7kj2n1xdWIDu SOafX4HnbvTwuYESyi6BM6pYnr8tEZ6JS/6eiUY3gRDN5Z7FHFZwbcRAgF5AgoDUR7GfqD3hn6X3 24AJh42fGCeQn1EabXBzflmfBgCbgElZAoAQx9WAQopRn72CWJ9PSK6ASISu+6tcZQuReBEL+KKA FGdj15+E06kLkq+IFGHxuBRtUpZva1Gqn1F7MoCNa86fWKs6gKTvA5+qi1aAg5BngK6i+3M8+BSc AFaEgw+bepxVYyScf3JmnABWdYMG0 CCcEgGkcNQgbJ+Xor2f6P5wnw8K3YACIISfk /T7gKrX/IDn poxw+kXZgLWg8ICeBmOfuSldn3Z6HJ8/vqWfvZDIgI5RvvynojoTQZiYE+B2axNtjHYTQYjAE0Gc lwzD4cWYiN Dg/UnZWRIBbKWZZkYEDTY7oBIBZHQSkxWFEoZs/xKDd8Zw1toQn7+u05/qHPSA7yif nx D+MYDnM9iAoGnfnwzv62/45wafy4SVgCIpGIA/t +iAMAnKn5xq+4AQrJSf4yr/cJFYkJ95E4+A otl/n1SiYZ+tnnef W3YegMKmQICgs7VwG4eygCptjJ/zRPaAInvIn1xWb5/RKfmAIn7tgFjTdnHt m/meNrFUntFep4Ek+YGeK45gnqpRm57RZSWeC6lf/Jg4E5i3dRUMocNVE3wGThNCWnMT3/YxDKnT kRNeHSpxrHninna0N55pi1ee72cDnkpPKZ53U wieRDKunmmASTRvuO7EVksuxFZMtdu12QzEVlly 2yw2jB/lzxDEVa38r43yC5K5mitftQCu y6JhwkBUKD9AR1znQMojR0BlNv8yyGBcwoOlRsIQsgxc DTMmnK4qnd32Hd3dEZaX3QaV8LEWU4Be2aVbH3IzXl5VwWFBaQzYQXIXTUFFqmtBLHBPb/rdYp8C +vCfwymFgCC86oC5WwyAnibCgCMptJ+ M8ND5I53XFg1sWQkab5Pf3j6YCU3RS8lMRs4W7Ce7FuRl N3D3WHWfMVXCgMQo+p844iOfE2dCnz ms7J8xfVmfMU2Zb22le4CFZkGAto8HnxsW4YC3xJ2fpMXz gImYZYCiHNkDh8kfPoqluuxN54Tz+nCp7Eh3J OxJFXn8r6/VA9wpZsEXiez+QHcGPukbwM Fa44w+ TIc2wRFCEcF5gcQ+Yx50UEsBAhQACgAAAAAAp2VMM7FswmOgcAAAoHAAAAsAAAAAAAAAAAAgAAAA AAAAAE1FU1NBR0UuRVhFUEsFBgAAAAABAAEAOQAAAMlwAAAAAFBLAQIUAAoAAAAAAKdlTDMXfRj5 GHEAABhxAAALAAAAAAAAAAAAIAAAAAAAAABtZXNzY WdlLnppcFBLBQYAAAAAAQABADkAAABBcQAA AAA= ------=_NextPart_000_0002_26A0B0AA.4C203019-- From w3c-dist-auth-request@frink.w3.org Wed Oct 12 09:22:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgZE-0002Zx-Jp for webdav-archive@megatron.ietf.org; Wed, 12 Oct 2005 09:22:50 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20868 for ; Wed, 12 Oct 2005 09:22:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EPgXy-0006zq-0z for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Oct 2005 13:21:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EPgXw-0006zD-L3 for w3c-dist-auth@listhub.w3.org; Wed, 12 Oct 2005 13:21:28 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EPgXk-0007aQ-M9 for w3c-dist-auth@w3.org; Wed, 12 Oct 2005 13:21:28 +0000 Received: (qmail invoked by alias); 12 Oct 2005 13:21:14 -0000 Received: from pd95b7d02.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.125.2] by mail.gmx.net (mp023) with SMTP; 12 Oct 2005 15:21:14 +0200 X-Authenticated: #1915285 Message-ID: <434D0DC0.2030800@gmx.de> Date: Wed, 12 Oct 2005 15:21:04 +0200 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 , Cullen Jennings , WebDav , w3c-dist-auth-request@w3.org References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> In-Reply-To: <91df83c7d462717c7fa70fe05411113b@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EPgXk-0007aQ-M9 baf4661f6fa27ddf42d1cfe19b723808 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/434D0DC0.2030800@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9974 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Oct 2005 13:21:30 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > That works for me, unless more feedback from implementors comes up quite > different. > > Based on Julian's rewriting plus the discussion so far, here's some > proposed wording: > > The value of a property appears inside the property name element. The value > can be any kind of well-formed XML content: element content, text or mixed > content. When the property value contains element or mixed content, > namespaces that are in scope for that part of the XML document apply within > the property value as well, and servers MUST preserve namespaces in server s/namespaces/namespace names/ > storage for retransmission later. The server MAY preserve namespace > prefixes > and non-significant whitespace. 1. Of course it *may* preserve namespace prefixes. I think this needs to be rephrased the other way around: clients MUST NOT rely on prefixes being preserved since some servers won't do that. 2. I don't understand the part about non-significant whitespace. Why was it introduced, and what issue does that resolve???? > For any values where specific prefix choices or whitespace matter (e.g. > property > values containing XPath with prefixes), clients might need to force the > server to > store the exact property value by encapsulating the value in a CDATA > section. This is a bit misleading as it kind of suggests that this would allow to use mixed or element content while preserving prefixes, which is not the case. Using CDATA will just result in the property value being a plain string, not tags. Thus my preference still is to require servers to do the right thing. If we don't, the warning needs to be rephrased for example like this: "Servers are not required to preserve namespace prefixes in property content, hence clients should not rely on them being preserved. If preservation of prefixes is required (such as in XPath expressions), then it should be considered to use a different format for the value, such as plain text containing escaped XML)." Best regards, Julian From noreply@ietf.org Thu Oct 13 06:53:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ0hz-000893-GR for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 06:53:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09275 for ; Thu, 13 Oct 2005 06:53:07 -0400 (EDT) Message-Id: <200510131053.GAA09275@ietf.org> Received: from host94-103.pool81119.interbusiness.it ([81.119.103.94] helo=ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ0sS-0007Yg-3d for webdav-archive@ietf.org; Thu, 13 Oct 2005 07:04:02 -0400 From: "The Post Office" To: webdav-archive@ietf.org Subject: Report Date: Thu, 13 Oct 2005 12:38:56 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_8776F5C4.787C9C29" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.3 (+++) X-Scan-Signature: c3f828922b5ae9a0fa296d4bd5b66d71 This is a multi-part message in MIME format. ------=_NextPart_000_0004_8776F5C4.787C9C29 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The original message was included as attachment ------=_NextPart_000_0004_8776F5C4.787C9C29 Content-Type: application/octet-stream; name="attachment.zip" Content-Disposition: attachment; filename="attachment.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAANxUTTPSnE9QoHAAAKBwAAAOAAAAYXR0YWNobWVudC5zY3JNWpAAAwAAAAQAAAD/ /wAAuAAAAAAAAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYAAAAD h+6DgC0 Cc0huAFMzS FUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbi BET1MgbW9kZS4NDQokAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ RQAATAEDAAAAAAAAAAAAAAAAAOAADwEL AQcAAGAAAAAQAAAAgAAAAO0AAACQAAAA8AAAAABQAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAA AQAA EAAAAAAAAAIAAAAAABAAABAAAAA AEAAAEAAAAAAAABAAAAAAA AAAAAAAA BT1AAAwAQAAAPAA ABQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQWDAA AAAAAIAAAAAQAAAAAAAAAAQAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABgAAAAkAAAAGAAAAAE AAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAPAAAAAIAAAAZAAAAAAAAAAAAAAAAAA AQAAA wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAxLjI0AFVQWCEMCQIJGfuHSJGmcbUSxgAA+1wAAACeAAAmAQB3/4eokABrZXJuZWwzMi5k /5vn32xsNXJvb 3RcSUVGcmFtZQBBVFb+//xIX05vdGVyY3RybF9yZW53bmQP/7f//3x5X+7Pud3e ZzuEFYDUAB44CbKf+xUAjQYYeLb///8PQEADAB0r9EGBT838/9clawgAAUA8j1MBNkD/bv/fVPH9 pzO7vZpBFARXhQ4GQF0QABgEL7fb3UAIHwAtCgN5KAekLI rcApe//OUAvg4vGwAAvwanOAQAhS8F E7e3//IBABVdjl/OC0RlYwCjdgBPnwBT3b7722VwXnVnAEp1bANuAE1heQ9wcmuX7c0HA0ZlYhNh U2En3XO37X9pAFRodQBXZWQHdd5Nbxcvso9tvyVzLCAldQJzBS4ydToE88J7Ww5 jBgM9SW50b621 7XRHAkM6CHpIU3Rh+xP+CChkbnNhcGlVaXBobHANC9uyJRtEUW5yOUE1/K1rCztOAndvcmtQYWxz 3/bd/h9tYWlsHi1kC3M4bQdhtjk39mJ1c2Ubc3QXFnAku926uxdjY2+yAN5pdgt5Yxt2bCt8dGlm aQsuZ0tsaS+a4WO3OHJ2S3VibWndttqtH dsraQ9wcHgQYWQWhh/h5kJDYWfjdGhlLmIfz7fd+2dv bGQtUUljYSBmZXN0bpWP1hwiI tIvZgVj7M4PS29mdGNpJ73Wua0/U2evDXmhA4VWaM+1JxErFILe t/e9eQZLaCgHYm9keQ+tfeX2Fllpbi93CEo85tyxcgd6aXEManNmLt3W2jN5T1eiK3K6cva2Q2sg uCsIbge/Hdr74W9nI2dudQ4HWIu9Q+GDqRYHlOuO1n5vch/LLmOf/94KERYOfB5kzHkJl2bnLkBk b25leHxf2y20e9hvGHlhBqxzm/lha36ca0duZGEVdLmLFWJx1Y4HZG4uHWKlwp9mxce9jfyw vi7n eW1hduRfLSFlW+yLLwdAV5MgAJAHygqmKAAptX6cKiAClxhQQJBBPtMHcA9saGZAhmRkYAOGpBmQ XARUTECGZEhEPBlkkGYFNDAopBuQISAGvxjCAvYFHxAPAGTbwKYCCwwBAGYpbLASAQA9T1W2yB8A Jm5ilqXDGvYHO3wudDCf6Z4UX wdfCyj3jlH6uiCl/19hGhdtZHk2DykuLkAOnNm5BoonA0AALfn/ //QwNSouKgBVU0VSUFJPRklMRQA6XHA26zTTDQAtcpBu2acUJh4HCPwlNM0gzRn07BTkN8gg g9zQ xCdN0zRNCrwAuDK0DTLIILCsqALSdIMHpDcFoKTpBvsJfAdQTzcse7OfGQj f6CSnL4+Qwc7y2 CQM B8jPnh1k wLgkZ7Qkb6wkICffJQofJXw8e/LsTCT3aCBQHW/YGcFWiW XPl+Agt7/1zboEeyR0fPMg JFR9LHsMe00HrWbgfG19HAn5VcTg9mBtfKQCfSCM2AIODJ1A1HwNMdYaDGkYHUAgiwKXKC7ZZCCU vIM/aG0g JEErcm0gYu1vDZpYTSl7OnwsfXw BbYPfAqJ0FCBrVHcllWgdfBl82iAshl9776AQdH17 LnwqKQB9ba212w0KAXtXHyeILmQ2E0eiPNB8Zl8Fcp9ord0MZWkXdQgzc33bXbt7aV58WX0f3GV7 LUFtbZtEe9AGkxx7IbDd4BZCYmVMfHcIfW6ttfcFZK8 GT+YdbGHrWosOtHx/BPVtMdagFd7eGQgb 21boaO 5jaXzPgW0WDEzWtu5hbNBqGmsranw1cdteHMQgIHNzunPv/Fy7FSBki9jsaXNlCq3FCj29 Xug5rpWY3Y1rLub9PuG/RINjx3xQkAVibHksfN8itEIEL1oMfE9idk401wp1JhY5wAH5XPyNcHV/ 2mQMXaG9exhCq+J8joVn7udXvGJ553sgdqYtgnPucnV9o+z/khBoJlprPzkcVRmtuW17EnRDah17 ROzBRusMhWSD8ld4Rx5CK3RuurxQ2HQ5Ed zBucNbH0/eHZzBfaR8A2Vm56O1CO9luAtUZ0qED/ex dWNLe4o6ICVZwd1aO4RjaE kKCoa6Jd5lUuh0NGaNOGwLsX08n3KScsMKIaFRHgYSgqFwe9b2n3tW 6nR1sUEJBkOtUzRAS0DbaIa2c0JDWX1zYR4NbUOVZ2FQE0hxuOWt0f7oKyBkYSxEdB0jdeZ7N3yH aBphFloQelqyggFte7PnNrxUuicVqxc6nGsaf Xd7Gx8FWQqGw+h3fSMgrpeaoaM50JLNcvIljxas GYs6EPZDMySkSFYqaTj23nZD NChzKWQ65VZVnQ zPTXtWRs2ZNbds41AcfVQNv5GaYczNVGQ CUtAu SYcZOD7/Sa+57XP9QXymfXb8pffGHm0XaShAYZRUeDPkWnGoqnRJZC4gttaWdAxGXZtHY evNCsmh CC6KLalCe50QdBMIqMKaa46uZJRwRhCTXHZbcBxrl/hnHGEtRp0BSrGqawyqc+8FpA jlJ5RR3WNS H8JuzLW1bfAct1klDGV2WmabtVaeEXks9USEbVeqtUJaI0 876Mwt470xUVkipR1ujt 3YZiyERm9l bwnEmtFBaDp5SdMtQtMgVW6yvmh0aAdhFcIur20kRDEDDR+Pc/B7sWMMjQkb0n2ptQGhbe/dMyRp n0E3c8RDFT LGXHpwVD8rGWi4w3BpBHNa2XheJzA7fTdaILN6G3TDoXE8Lz5HIxwOTO13aSh0Di 6N AAVAJEZ8T1opAg1HZuiAwJrbXsJGL9ggyS1h+E4Vk OWVbxnisIHUgGwUhWRXqdT+TCR3e1MX+dJ1 brddIGQgW+VdfAhpfOvCvq9ali0AIORhsRwHDG5yUpsemMVc+9qnbvtmU22CsD1DrBo4UN+9dLYa wWZ2TWGgYxRrBq7GCbOTzR7O81KAZ0Autz1aawC46zFca34M2uOJC2i Wqom5nJsUVERGUeLtU2sx vr17PgAgTUHctuje7yBGe+J8+0 0WJGZec30zcwAgNT Ak+w1fYHtQ6jVSLrhSQTUaW9fViCAJRABf 7AM09xFVXg0UfEH6zeHAwFKjcxGXAZYay7prZ1NmvPcNLDU1NCDxVUm1ttCWjm+4FHhVIInWltRN TajHyBzgDswQGzdTzXu5RjsiYfRBFlf7SPatMLEuMS4yJZYghA4GpgcgKE6zPDogbCQeERxy0ymU Acy1bXs9MAHpXXCUbYQ 7+CDJbxlNBiJRB1vOEy4jAzhoS9DFJQO2E93tLo0KcJfbgsCCNiwxdEI9 tCB8MV9TyVt8A9YMrRIkbJljBwcuFkQh/qJvwrvxUkNQVBRvOtqc7oe//Yd7uUJPWCBOTx1GT1 VO RHwBD+GwhDFfmAJ8SeElLbRuzoZkgXxOAfzsa4Iet31rR EFUQYWxvnuVZDQwMC1hcXIBmPH2vyVt LUUtT1BFb1VULMbQfjDQny4NIUFTzrL22jI2qHDQuEGhbXe/LVJNU0BDUkU8QdF8MxXcR7Nj+QIZ DG//IaxkN1NZU1RFTS1GPFhESRm32vZTS1FV70FCPXNrPGQo2As/PvfPbWKF44xsdS+xTpRYEvEr LAi2MSQniH0xoyUwEBsa70IhnulliAdEDVrgm iCjdLcLbUaH2NNzByYHZQcbAvDpAE1 cCCcPDE3I U0Vp6g2DrRZSpBzHMJpFU1OLTyx4FoV8jmUt5FymL1kzDjoBJrnOxLJdAXR0Gu25jsyyK0StIQ2Y d8SEdOwTY21kAO7GBQMRdmUASWYATJAhWrMA6+3nMWLZgF0AbM+PR5h6J4+7ACzhHXoPXweKE9xs Q2NjdQk3K4+2BNwAPgv1C5E84kbjRVItsRxPTo8kt9IYHAAAKCJQgdUI3yJDIlBBVKHk2rMXQXUK 4fFmpkmIQCxUU9JKPNsaLFEiSyBPc47s8bkWNCJYE0IIXRC6SmM7ECJM2EuYS0OsD2xb3yRedWK1 SyVUJbcFAw6PdsdwE+HQ8Ij3cgA0cu3gGt4jfgAWLyc0wmsNRmgsA 2cl9P8PKw0CAEFCQ0RFRkdI SUpLTE1j4y+9wFBRUlNVVldYWVo0YwIuLLBxZ mfEaqVtQnBx/6 VuD Zu5dndrejAxMjM0NTaGHgT4 Nzg5Ky/HWC1QZ qmV Nm4CdHkgM28O0+9jwF7JFU4xbBow Ix54GG5N5+jSUsEvbDFvtkV4C5R2YApE Ni6psjYrfMx1BDAAM0lNRU8oNPvQyFWJgFBCeUCynaEBTc4eIFY5Ha62NgGbQ0IyLSqUttZUeZRA bVjVuG0LG6x0L/N4RzshCWLtLbwd7hF5PSJOIjEADzT0awVxLVbOaYAxaM4Ra08Y/EMHYq0ZaJhq iwoxF9CgYQa FCjfWPjGsnw2LPV8LAj7OT/cuM3UENDhYLuNO2ouZa1CMczYrsPdmJ71JP0fBqQ KU umHN/yBytFYYL94YF7k2c/CZ2Mpuz8Y0jQ16WmpmMEWIbEPboW9+QWIxNj QivdfUuET7QGlRuNoL 2OlIhEyPOlpkr9F2uaefU89Ee7cvo vZIn4PWbgVDoz1113VixdqJbGmYN2K EXDDCpF6aMa8th wZL 6 rCsmZ03GDZYhC6NAElUM4i5eAn7ELK2lVhuo1JDTyQEPidopXdiNAd6EnsvkrnaGe8XLcvaT4LL SEVMAEUMD9LZBMNMT+v jKyCT9XpxPlNNVFAlgyA2GYclXKNcKix6rm u jbsJyDTYjt2LBNw tBF9 d4 LiUeKAIT920 4kY Pnpy7zbG9neqMsTnQwQpUvlRVKrdhLV6haaCY+Fk VVUkxEwTUNHbAVeq5DsEbQ QbXW3lwDTzovLzabE0PT17ZUeXFzTi/qYWisi/9CLqJwP2xwdj0xJpY9JirA b/1ocCZ0DT13ZWIm I2xbCmcm8XdxB2RPQdtaO3cAOj5hi+1MXczoUC0vy1NzP6cw298pcyZrZ3M9MAVst0OKkH09AI9V xVLvYBA/cDl3Pe5LXaJY5Tgmbz1mcC2LFTa0mS0HJk09bUchaxCLnVMak+MDi0TiUWhsPXu GDdZi JudSbwic4ozwo88rzwaHpRd6XytbQRsazGCrGF+L7Lnc/v+D7CRTVot1CDPbV8ZF3FMD3W/eZpfb 5XLfdOB34WEX4nLjZXK5XC7kXOVN5mnnY6bZds3o6S/qczfr7F2z7Zrt7ifvRDvw8Tfy0O1vtm0f 8/RuiF31iR4EC793C/Qv2YCNRfxQaBmmjXlQikVvv/H/C/bYG8ADx1D/FQQQh4XAdFL+E4B9C3dz BvoCfNXHBrE4KvhQN0embPdTaAY4U1M6FHUJ+4eZ7f91/AwAQ8VfXlvJwxa3g3Yn6/D9geybVr4F flva/ldWjYUA/wBqWugOabCDxAzMvezOEFZVcBGLNVw3E43vN/doiBAX1jP/gL0PAHT///9uiow9 CoAJII oBPGF9ETx6fg2Lx2oam Vv3diP29vuAwkExR4C8IePUW0YOYW52UA ZID2oBtNnc1o59WHcF VC23MNZ2HQL37F5AzMEsF8ptwUrCVzDU/cZ oBLldNnTLUMj0avVhB/Z2l 83CZvf4Loz5+nj7Zd9v GgpKB4iLRQiLPYTYjX524 X9Ag8AEUVCJuf/X7oldCDmF8+XWAlzY/nUOaBhA36Z7n4AMUA6YfDid IQ8v1s3chKmfLSZ4Vgx20vD+SYA8C Fx0Dhk8kI2jpnt22FAr1ghqIDZ0KNh3C9+ASWoCU2oDNAJ/ 0znTHHA7w3Qyg/j/fJIddrpjbHBoDEc6JjQUEBFk6xDf7sxkJWA+dQ//+4N9CAK4w5rhD4wZa88g df0+mpFiLB88NZBX1i0 8One/dWRQC8RiaZqlx2jFNsTFxqZpmqbHyMnKy5qmaZrMzc7P0NE1TbNt 0nM309 TV1pfbZtkn11fY2W4D2mTb b03TNE2Wd3NcQ3U0zYA0cm50VgvSDNJlc2kfNDXLru077lLv 8IbxbLuQdCBKPvlNGvpzmGsqjHsV7eYBMOFdPxR1KSmDxgRW2iOVrbGOVp8h9FUI/ghJMl4/U1eL fCQMJUPDFy47+3QdRDj2sd6cdO1qEldLBhACXl9bw2ruhukfNO5oqAYTkCHpfoQg7FkPnJT7CM22 b4xeqxiAZf4g0zRdZnicUmVnNM0gTWlzZXJT0zQ1g3J2L2ljTtM0TWVQcm9jh7Ox2T/8/XNOlB+R TrbSTegpDp AGqV3rQIzQM09Nnxz39vutjB9ZOT51CwwdiiZZdXgJ2u7fb2XhDx5MBR+sWVkGIVgm FnafFgCcjx2YBXQpfgjfGRxfV2gcMXgiIyOwD7fAdrv4/2pQmVn3+YPCHmnS6AMV/9MZPAWtO8nB LRtMQRgERhKctXB7JSTr8pBdL5gjS2bJG2i/AWyAC/iVEV+kaJUfmC25Bfj+DREh4LffPCwQbq DM VY1sJJBMxABr21oqQnjRDIFgGNk6tqewGwtYEngOrO6z9J4YEHe oZawRWy/9uqwNpOxNrIgCdQWE VPZvW/8DyPfZi8F5AttmUGQGdgZmx0UGyJHP3QAMYgB1YgEMdv+/wNsM52o8mQn/UlAzwI XJD5zA jUQAeZ7vwitQIUVsBGpoYJqna /9i/zSFGJBvD2ZkAGYWPm5ojB KzfAMw3+1mK/wwX4PFcMOctKNo sQSffeHfw6EFacD9 Q0cFw54mFWahaofwQXgblMjB4RCfM/4bX/rBw4tEJCHrJYtU+ovwhMl0EYoK F3j77wULOA51B0ZCgD7N 7zvyCoA6Y9vtC+QJQIoIGnXVwV4167/bzv4HOkwkCHQHFvMFKg722RvJ 99 H4wMLDI8G9UQAQ7HQx7Tfw2Sz8XQy//00QD7Y4Atet sYEDRleJqAVZQ9pS+/1CWV38O8F1DTN1 2GOSbN/pLQZA6/YrFAR4XYPmbrBNAFUMQ5O3tn17Y4TJCDoCGEFC6+1QAQIv/+LxCivBNydWV4t9 9ol1L9Bx4fiAP0mESCtT1j4mD8zS3dyFMQoW/EYNIyPueeKX80YPvgQ+yhFZXN/a/28OiEQd3ENG g/sPcuKAZAol yThN3Pg3E7eJf3QWxi8QQI0MiYA4vHMF3h9MStCDF087dQFGGSd+N96OzgBUahTv mbcTTbj4oj26liBdjhaL292IGesWECVwRLm1pQiQUA1/uBDuFly3/9ywi0Iw/CAr81BhB8/arvTE O/DtdFEr/tm/tQPz7hw+jTQIA/cai88ryzvz9Vu71I0Vcxv3hX4ri8Mr b3/7ticDL4oUM4itRjvx fPXru0H/hb7E9uXA fA8GK95AGQvoSUh19 /AtBOtmUEYZUA2NPCy4zw+5trae+C0Ar8LWtLpeW8v4 nTuGNi1dwxD7IvBQP1unaZp3aW5plvW5XC6XZfZ09y74Z Pls65UYcvpsojmVkuX4ZEgQaLTgpalt C5R oblhmjevHYO1Fa1GsRgN2my22xkhW41cKxFZWHJQlSlsFCAPXcPe2j8ARwfhqBDb8GGuG7cbT PvwEu6JRKxDObG1s+Cw7IRKPNXb7sH8v4GoWUCwWdXnj4McYV4gbgFM1UEUfjtObfimuOXXmdF/W 5gp3WJcXl9pC9Ib4UMkBGIN2vAIzVUEkdHYz+XvnwVe4aiiKWih1Hhq6/23MOMgDwTvHdgKL+Efm Xz mCcaEGwc1/6wL50tsvnWBRgPkgdAUELnUDB9KlptvxDjPSmnqVPAINbWNjgVX6+TvyyQKOF/7/ QAGDySAMIGvJGo2EAcX1oT2kAmaO/28bJcgwg+EHQtPiwfgDioC42+3t7f8i0PbaG9L32ovCwz8D fC4EBn8pJZHecO5r0htJRdNUEaDPQ0sNjeyKjDlnDWQJnNpuPUALfPKbkZ iGnhqCflNkEMUwOrd4 DMkA/I5jG3vWlmaJFmb0FOLN uTBdDALk inW2c9t0DgQ4FySdBgYIb1xoTgp0WTQ7wooO61g3SoYJ AeisDDhnbON3/8gqy4iMFQwiQjvYfR4rIbwNrf2lW+4D2IYUwe kC86UL+LjlkvsDA9DzpJ+XOy5D BrFfoy01rKw0fYCkM7fCpRLBCXINt3OENViJtn2nRqRGDe0PBttiYbkMQQLaVnzjsx3IvGjJXxEP nsFeGl+HGgR562UtRh23JUrw6EMEl2AzYLrdMdc2djU7Q30w/2/w9rhhBDDVUAX rDkhAfQZvY3uJ jYgB6wYPBgD8OEjfGnAxlDkMfMuLxmJ1vFs3UVn4ricAYPQ7ttTQvkh9a4H+ueFfxQNV9nYr/B GF 0nRKyE8XQAl+C4oTNvjS/4gMPkZASnX1xsMuRusnlPyOzbFgxgKlZgHXr/2dXIVnpSX/PwtU9o3G uxIEfKbrC2l2fDf/LqiZ/kr/ToX2f/SAJPdAXnQD9/rEramSpxrnMFBbzBDOeHtGrsj2sXXoXhso BVrpr6BqDFgNyyNw23hrPAL0fQc56RYrdb/YhaFF U3KL3lAp JoXBbvCL2Fk7F1l8H3MA1G1b20YK A07WwTX4CAZus4DrKP RU4OsDOosOWHAvtdLJFAHdeAEZ2FwQvdzuonzNEmFgfwmNQwoaFEzX3jWc AkneUmESoUPp6UMS2AXr7gyDwwYO4g0K5EN3Wy1hj0vDV+g+f2G+AwNmgCSA+tAxIUD39viF/6vs dEMYV4xAU+PYtZVFWYvh5BR2sPCw2D/s74MgLG m6tG3GBQn07IkB+otaau5uO9+MIv+zFf1fz9ET Rv4MR1NVa20eLMHSM+1mEAXHQ0/4YI9Sfdg73XU8LfG5tQILdBEzAZdQEa4NNvo7 /YnRJEsZDmOh 7quD7xAIiQoUdLbObW6L GFE5Cw8YQGjM/Z 3+VesBVZvZtCREEAZuh+EX1SgVRvOFjhC2u7u1at+g MF5dOFBVCjxVBnVvJ8rHZF 90JEBTRAg/O7NJVD GOXARVUxvPVip2Vchupljo ct9s3YXtLygnNDvu D4YsB/tLS2oOAkZXg+YPg/4DyuveVnMhAf75DyAahF/MbQ1ziA1/mfR9ZW4zsX0qMVmJjSTIMN+S d1foliEcAxgRsRDrBPxntu4l4Y O/CjcBNp8N3pwsTQgPkQwDD4KDtyPha70ZVfTwcXR2cXuPdRVW 1YHHEJjbiwdrOYLUPRhbPMbZYrz1dolGcQeNbsGL/UCSSZdqJeErXBJWQ+tyGw7rFPYciawmBgc5 x6+jGCEwrIs/Ygdtv+2xnkEkJSDlEoMSGDeg2y7ZHv8PFAoUGiX+H8QILw2LhLbHkVOehS5kZZEk eVxEwYvR6GENYEsauGI9/ ntdW4HEd3tv7VwmA1hU+XIreHahrs7inBYRAiRqZDdytQ3NmEaRfNY9 sSc6uNGur77QLVbkn4SrH7U7xVHjO8V0USG35CRo7A8iHBZaozQQNEk PKt4NuUrmX+jrcFf3Fg7f OsBsHnReU7uDln/yAOEFRHVKU4o6U77BXRh0RxyldI1GCGj/ODxdnyt3GKXU7Vf9sJXoAgOPN+5W dalbz6KVO2z42lscU6AL1mzB3FfCkQVzyc2agAfFD1HRAK9lX034yIb40gxZf89CvLIdo74AQDHq 2iLY063O9ARRLbynEdLXT4YrTiF 3/ 9FoBUR162GNdwTRWGo166R CVzrkwpJWjne2na7mgBEK6JMV o9zWeGRMESiLQH1JABvW0AUHo3EVtY1CAxj4gRkt+1n90w RrwFgG9Zv7leVk4Tr5g3r/dGLR/XYx LjEtBekJ744MC6EE+cOLq6ltRhe2+FdIgAOA 6tCuhS5AMjyuujNIbYd0U2cQXiQBd5DBDwwzig7W 9G0cYBXinVkTH2xbo2N7dcW7LMAcDNvimc0wCB0XRjI3XOKWBXXj2Ylc2Tw8QLGSy950PyhUFN5/ Fax3eJeIBCtDWTwZFrrBSr1vQJg3jFRrie16T/kEKwE3IN2DH9jrUMQrQA/CzhaymBUqhQvdjuQr Bl4rQNxLJdy2 1XmtYSsVi4OzwLY3aBFx9+s+PgY9Z4kjexOKBjwbpitqsneJgOR0Dy3NWdd4DdC2 ub22hrWw7Ze2vNMm606NPC4oB7qbHdkbPA65JyN6d9tILgdzP7ZOea/q2vAuLgFc7HwK1kCWHBhG vAP2xlHD0KJBI42UBguw0LA0gEYnATeyIN1lh8aF25mhhgYZiNy7ZeEDQ0cON9kfA4AjAAzL3x02 MDITEDyNRDcBgDgclUFOaMcZEAXtgW7MOvDmNesVECeE2DZcc8cU JoTea qO2U UcPlD5VrQQ3akld +iVwEGAwegu1+Wx6BQtc+12ice1TRcY5HRKjdARwFsqGBTlDNffRC1up6wtMB/+OEzw61rol5 xwc SIQqf+TivXvwGFMoi8srDRSs3VvQvDGjeLJJjO8zbre5VY iP5ruAE714In4GbvhTi8WLz1oyQFmJ LnSxd2 AZe Z0YlMQZzT0yyAaDKn9+Fe6zbbxS10oH CQh/2e297HRnkYoNYfghBdFye+sqQSC7MHwL /Tl/xRoOD4qIeQMA5SOx/1vKh0ChGWvAZJn3+VUVgr+NfoIMfrk9DDLrHWef/G2cIFUVBnwJPOsH CEZqYQ nHfeEHwcN5XRdMmcEvASBg6wWu0UtNohJrBjrDogoh5ngWvDUBJxTiH3TIRszAhINHLmzC 1EaBqzR83pxQkNtbGOkXnF/iuA5W/0YXzKAwg9rixl23SjFI+5o5HhrSr1Cp3zidHHQet5gJWoDG s0EtK85SXI0P+0I3R0A4BPONhBVDJ3kbLNgBb1lAhffEUqurAVdE+M8WPxPmuqsgwK81RkeB+2ym k/7aKaw1dXG7DRb2ZtB0I7jQs2c56LCT2Fay5EhkE+UTuhwVeiSEQm7mdnQzRCyR+CyRE0IsGRBG UXv60AKd+cswK8Q4FlD64ONWecpR/GsOU4sguRM N3/j2jwJb6QNIefAffg8Dx9pAo3YrEr7IdcjW xe6xVL2Lxz80RRKyCsFRJDg1CqbCMBO8AiQOVR93ATbRPSd/Eg2NjbWlYOC+M svVKOLBom5H7Iyz ghhi8J OGVg0e3C2LdgYLh1Bobhw214aDWsjixMcPpw5qw+It2NlEPes/VxbdYhjwgGYFAJUcAYqv mbBLz4gGZIS hfLmIt WgdJIXRZehQk8gEeVChsyQNeP4NUB81C7U8ZywUY/47N3sT8in8/GwwEv5m z9k8LfwNHhc9/Fkn2xaGSTT/1+Tg/rpYOPIIFhfONwRZSAaNjDxaYta2reuIsISpzW7x6mV5mPkh BkY+zKYaqvgshIwyzAbELpUcFPf2Kj717ruPYnQnQTvKfPQLaIPACmCk+GgtDAzn9CZkqH81UkBq f1AQVoBQZ84JeC1Qnu++w3chIlZjLXQjVmh/Rwvu53u1t5yDxXj0/pRkwRU4uO37EO0rGr4KizbX 6HzGA39rXbyhJlXb3b47w1d0KzlQ+2/8WAR1DjvzSotWCDtQCHMCeO7DW60MxmPmgfm9fgkcWsh 2 /x85XgR0XL+Q/FdTph7NaE8NSxJ0GTJoboxOZ0kMifD2MII9T/BFCIlO9GOOsYmJMbg1jX4Qx9yz p2p6/x8m/3ZCdZOzPx0wCFlFV18Uz7lIzkBfp/z0eidqj8Q4cGT/QATomqxRpcYv9Ona0lGzYyPx qANmIBs4mTLNPXtSmQlXaOvfPVTJQKcZvHQOLIRXwkJFx81KVs4s/JjkgICGOW0TWS0Q+zW7KlJZ YoG3V52u1M7OD2H0LsbocDK1q+4fBEhxLpjOUCgeXgkcvP1+c2XEDA9WxkYFAWPBWaP7a9AJAjQy AHYHNezMasFqAcAPU 5NuW8QVIH4sdSDEfxdtlCu7uTH38Y1IBYXJb1To+nwOPSAcXgeD5DfrGiPX UtuLTgbGaA81swSu2il1tVusjRjroF12iX7roWoF5Q33QSPHBMQ4Onaz2xEmHH/jaKzAL2xs7XaD /wEPlO8p/9WhUzUzU3RJQ4B48S3cW2N1DUXg0A46CH4mV9j+gkgBO0wccuUFV91C9A2i2IH7oB+y GUI 6Y5det4F9gf1WeUdXU1n0UltTiP9mO+FUO/DdVz+hKRoIcgpoauky/NTqsAAyFD9E1UmTu0Q3 StQ lnBM/xJ50aA5qVS5gaCAD+GyBYDwVX7uD+wMG4YQ2nucs4FFEYn992Aw9UHLPZLNqZDJ8zffb jKPno5AElMO53hs8wCGkzDUMEAx/iTYAnn4Wnw+2CIqJIGIjHosVbQKICIvt1aJAfzb2OXUMG8FE /+ 3tfIi/KBYhW4ld/Dvef2ahQjT a2MYrMBc0+MmOW8B3/NQkOkn/N4v0VgjXqlwtGQQDxq7E7hiZ iwceO9hPcduSg28TK1X8A1ZLA0krJdr+rtbKCYoZiBhAQXv3RzJdYGsrWwHyi18El6LROU90da+Z D45U+naIdHZ8TQxQgH4s1Ghj5LRI7PpMMxhsX2Fe/VvMCHCb2YjTfTjWxF1q+wuNjV8BT/iNHv8t vHVdNbMVhVDPfhMERJYcFyqvlBAX2cxJXagRN59/7bkSfSO+Ec++GRQwgLoY FkBZfO3rDrcaNekU MWK3yHxyK /z/7o1RAzvQ fWU7z31hO8FXT1wGv7U22LshSBJP2Pg7wn5DteJN/DvHfj8rwQz/ B3w2 S22x0S8WA847132sAY8V0RB8UxFCQYH6/lLpHkj1WvcQNzY7W+bCl8uL+zt9DIwxiYs2d RJtQl9o FBFoEBRYCLhALVbAg8QGTXW1P uNW6gDKSQAD+oDXYLAHKHAo7G0dtSjRj5p7V84Pwq5EE6RTTRVR Vjp/eyvR9JMF8FDryM52BYvOiQNKfXMiXQFN9IhfpjfCuV+iPCUIJog9CIH fWijK8OqBffQAsNlG oltwdxijU1DZ7HujXBjZF0vLdbEO7Wpjkgl5X5T2RkMfsMwix/fGH7lT5 YkyjGju8WAygMx8I7EV zra/ZM7PPwjGcwBviwMdINAfDCyDbFvvaPpEYJ74DgwWKpWFJAS8RZ 8tKyg7++QDW+vYtttv/Udk i09gMXZV/HA2bKNaFNtV cISXQNzuKgdNaBfxcyhORHPUUv0v3BQ+i FQF4DgcPoJGPwzrLt1y6D8M MdSDRXCCaaDwRP9NbAhWLA83JtvJYF8JZI7rCEscYGu1ge6yg3SB4TsY6zQBfNAOYBIwGPTUWmVZ li0BU29mdJZlWZZ3YXJlXE1ZlmVZaWNyb3MAlpNlb2ZcV1mWZdn7QUJcV0FlWZZlQjRcV2GWZVmW YiBGaWxlUJZ lWSBOYW04SMFGL /2WdVEBuUWu2p3M/qeh127PzMc CG ZDMQAMWDJkV0PZ6rSJfGNA3 G+DlJx+czP4+5llbxwWI1XsI97AAGqMN78D9JxCDfiAoD4JqWSvJ/zhGt55oqywgPa4RIgYsg3eD UkIV yEAJKvHffmvoE30HMsCI4esejUQxLWoPDfiSNIXwCSj lo3aVgIr9d7kAjhHYtmBHnwoJoM02 s/H/QluKVfE8cHUSgPpsX6sIaPy2v1miil3yPHR1Gg9 4LlgC VP5/mw5idUc6 2nVD61I8aHUF939r L+t4PGEhCHN1F4D7cHRqPHMNt0+WtxshgPtcZHUTDWJ0/ca75048ZGI3+3h0QDU8d191EcaG27we YXUMdQefKOucLOBDqeMafmkE9hb4OWT6GX0sDRvKW+/i/UfB4RShCjgJweAU7XNILPwNFTlOIHcz 6wuvCHyZKJ1tS4jGdLU6dap7Yx2fEGiYvA4CdQmPX6ASY3DqX J5l V0 7YXLCL7zv+qT4Sc8AM5dxO WTk15S m4g5aLHYS G5KPfs4VXcNMJjb0FUE/VBbMWP4A8OFz5GTw7EGcOFV0ReBjJcoyTaEBrpP1W fbaVKvuS/BVQdSM AkafgNdkw4Fgxu3p1AyNP 6xEfzoqPmCRrrNe90Odm23A8OxsI0QB0rswwsnw R CdKcD1q+UTbZxVC+VFC3iH3JKxP2pcwgag27wIRLKIkMSCJB2FF2VkKpSkNIJ1jhF7G11FAtWXk Z +PigsbwcTlt1ygNOGUabtBivDaZpml5n5UxvY4KmaZphbCBTZZZlWZbwdHRpbmcsW0FZc5JUZSyb 5bZtRtNw1NVy1mybbdfXB9h5StnaSTrb13Vd19xG3S/eG98P4AvTNF1d4RPiTOPk5a gddE3m52Lo RL6Ea xOyZeo2TDkYEh3mg8Pd4YCwfHtGthwALzRMZiQDchnEVExM0CjBJNdF2As77EaB7FAx1yAM 4ZFsGtBqBYgWS+RM6kD2VKm9EQ4pBgRqvgY2sIizrPwlEY33JCIWip0Nx3wnTZ79iA/8aQ97tmOD xg5DWd78LR7QIlA3Kzjowk7ZpFbnWjtZ/tX7a8QPpgVafrymb3a7kBUoP/QEREVFsP8FsX7YXxpo qGFR6+ihhCyfF M/SdT/CBBT8AcMz+v8Lt cndvNFe9sIBdArR6oHyIIO4FrvYFk0CCU4LFIj4DvD9 wPnkfNujQV5jtbqCr4ELb4hz0 RnBUooE0Ah/oQt1chS799BrihYz0IHiCv/tA7XB6F0UkTPCRk91 6mI6gSDQG+WdPLjVUSQ6vPzFBguio7c3gWbR6QgFC8HNZldw7N+e8MYHZokBcgrcBwqy3Wz08NQH bPCDwMQyBMPINd7yL+QnZULtC3Dg3VYARm pCLiDjMirU9Ws7u//rHSt0q17fF/x U+Pt9+M/RbICz F9COeRlTJaxhsHvXPMpRPPUuoycxfHOgv6EvFl50Ix3tV86tsQZkVtOq+I/baWuq/abGB/UgJAI9 KssgQ AyEqZZnuSZ99NH+yf0OAoWgHggQai4EWQ7ZC4gW2Jv4tkS8xy RQSwMEBMJQbjPdDSu8CgAF jsG+A62wa5qQwJIvRxN0Jeu6hXL3FpQKxAeW F7YsmO1uvCAJMMYCnxuN0ZgW02VFykWcbZFoawsH EBQNziHourIQoDrSA6Sx5itdDx5QpUB41GvOnbamArKKHjwwBSjEDBW/DVQcHMVbyx5miFvMs/As nx87h4SER6Zij8YxWrsNMWIzaRnQpfg5TrYws8DAIysYTNWy6HwtMjzPhsvCHYgBAhKMFKwKcwFs CK5Tme6ytcZmRTXYBQYvoe02gtypLgfeK1hdTrbns+AB4gHsa+TYiNGbFZKoBCGIPGd0PyrGXqcs OMU6M00BQK+aZYhQvEdFiUvFEmPY8bs InWwFXYDHO93F/5PJoh8IB3c//ySV2Vvn74ZN+ugmRDZo 2AYvaMjn5+fnKGi4IWikGmiUE2hwFbPm5wxoWAVoSFd5l0W8YxBoRBGQA3apSzzqLhFKNmg8PYx9 dnIsICtoaBgHjVbxrBCQBoHDpjuYdC9ZUxzbS9AomeIFAWGOFG8VpF0YAX4k3beCkVreO8p0CCRB ok3WNfQDWZQFQDfZf4QnA4XSiVX8fhoZGhcPfwP+gMJhiBQ3rfx85saEHkdAs0kU3L6QpFW0nyDf D ZNWHI1wChqEHaFs IItKHbd6WqZpms4XA4iPlp3gTWSapKumV2gMJzRI1W3KfgRHGGtbx5d9JNJa fUgSjZ6ryhfwxjMYPH0AtgQCUm N1fCZKiFOmhttQ5hYwbwmBxo jhJcMNCB/ZhkhNv1oIfUAfhBf+ DP+L2oPDIdt+HR7b+3+vlD5aRzv7fOOApDcLeVuGv+FvNWotR1i5oCmDw QgD+IsBdf/G+5D1mff/ IMxHWQP5O/p93kH3RjAMxagqQ BLugzzFfQFo9DYgFP80xaTpgsTMC70fWjKckIOk+DIAGeYzIJf4 /L6IeIUJk1dG IW 0nFIc3A2gEJzvxEFYPHwklUHwQhRBu2u0euyMgEc0PfAcNJBEfWUOM+M3YNgV9 UXLDmYxXfQ9d+oPHSp1M9v9+LCwbGnmxh5c3dTMIAyDrCmyUDN3ewhuP93zUbB4LaOt2t5GNlWMC s05galAdycmFRi0wGfD+ZORl4SAtRvE78jg3D+EFNog0GYMIA56PhCQQKHwWFuwu4TX3JBYSFXwN hgxBmBwbGJhBmwTrCMVBkKAhsCDt0F/kL uJ0IRlCJpNZBLavdMHEDmWtVhetnibQZJZWR4YFFc74 /bZrw7MWhCtEG2gU0NA79Tq88GGxHVs2csOfA6sFZDNmalWzsU7fCapZ3wdjSdewHmgwxgbdDBKF AefIEICmqH8knM4FBqkgS30HxoZrv59/IAGAvqhTV7usdSQwaGBjP8fniFMzX4jtNrN96k8m9VI5 efRAqq/QO3AQ4doUZzZDA9UJXOXwPbCzhb0r7xFTWAuaHd4qLBb 7wuxsNhT6WRkaUDMHbW08cPtU rKzUXOaHAvh6k2cKMqkGtHtyBanq0lfaUfcMIuSC339RREaaeuc9Eh4w17xEnMlXBXshfhhG1LRQ i354A3M5BsfgRCeXQCdZPCdwwIYdOCdFQJm5W3GCDOw erRboZDAD+Ghw/7MzhN1Ude17BBuxb8sH zCsZAg9oNCcmbHDgay52I1/eIgb7GawVKA1oJA4gOCHYwJQI/FAHO9BLhEfighAPhc KEGY8g14Qv QzisV2IyVKYMR2 CYUf5ckd4RbMoCCXNQSH4k40 EYMvD9xmYHXl4TliZToMloy5fzPGiQWNKdzFBo EUdBGmP+r1fq1w o0RjNP2lO6ogE4K6rHBDiIvju6pjOUnrAG6iB96EnHJ4kD7IE7r30OakOFs9+q dh7rDlCw w xaMExEHgtYAbuIlbIAmAB5Ut/8C8GZ/YN7oRHQ5SEh0LQgOdIGwQLQcBNC0H+oCn8EK zzDrJScEUSH06ZMvw4HBoOvvMK35 /W0mMYgWgGYBHwgCz2Sd6+XtaXQdBHR0EHd1XtwxIjgCt4LH 1/+xiK5X1diRy3v+QlIRvzLZi/3pI8d QDAcm3npIw20naEzhVhhfT1AJ+m9T0WfrheAS/yCKA0M8 fHQe93Q a4vylnPsWPFx1HBIKaw+IAf8HgP9gu1R824sGIJNdwzx79pvKbPmLvYvTRooCQir2se6l AAx04jgJDXXr69Ul9AZto01BUn+L0Ukd3ErUaA7nZHXSF847+8DgRuvLP8nrJ26hQG35sJsI6xk6 B 4vx9pQyddt0NwU BSkd/1Rx3ndnR9URUG8PpCkk8JKVdF22SUAsPSYAh+wn+R Kk3Pm9TQv83x4Yp ih0BBygz0XdAaEcU91u4C9l7pDmJUnhOPCBykaM3Nn49dD08KwM8YzU8fzOALaBxPIALQSlksm7R EAIORls8130h2qd+xgQGDQZGB5Z490QKdLIMX4AkBlhjkIOkaQqgCkGSAZmooAjbaaKHW6RaUBgh ajC4YxuuXlCA4wU4ROoQvlgEC1ChvpV9vPOl4mmkgG6l/opMDbxfiAr+D3AB6f73X3 PB4QTB7gQL zheISgGKSAEYAj5blmUPAgZeGQKKQA wGt98V4D+KRAUMQgO9GCKxFc546wU MLMVkA4FXLnANgkWD 6Hi5iK/C BChg7AEqFRf+ffBhPbIAC3FyJlBXX+itNgJc6Fw5KZMhFsCZnzWLRkJK8P++/gOKhAUr iEQ183W7jVVBemeqC45Wl445uLgHBs5LatcwFJAB9BZaaNR9CTmXAxgR5nZP3g0EfQ0NQwQKQwzr W4vW+DX4iAxOZUudTKGIudhyDR2oIDaGEF17BHKe4G1XnwG78C lEVq/ndCqIn22DdqNzBN09CAL6 PZe6NQRCdR88AxMEpVaJhnMM4RN/papCOWq0wVx3N/rei5y3tMCNn7TQZWPlIOabUAW7oWeMcQ9S D9goUATFqUBmuBrs6LZ4bUyHX9OsFFZfb6cNVS0Mqij/t1Vou1aqsaAW1ZUbwIHHEbAHGohskBaa je0mRxxoiBXXGEOzBsmg8hZ8ti2sRBAzT18nG/eAjiKaWU/t/G26KOV4i7jbaPApNVWzA5KxWdOi t73NJFcF8riYHUGz771qGlRXCslGr/tBVRSAjCJSXF9wQUy5UtxffAW5UWPRuYQjVgU0UeYm63ZG aPirV1YYUA0FHOBhtGkzCU jI91IVK+TzDnSDEfjAw1NIRbnhon2fGgGvAX4IRQcPjArCaCR3wIob 00D4j4mdD//x1LKxykaaRn0GibVaCTl4G94J+3OhDW74fUT4ib1E+kLsO3PAH15ZDEELg3yS3QpL 9U3DjbVP9KjEt6vdXnVzi7G/AT9FuPfgAi1tBZ8jYSNorQcMEwxAd7vBSfUVUA/0IogYTj/8ZidX vgrOWJEtJzidJ4kj1Or 8cOv91jldjsQXbDcJkOhY6xiiEpTAJjwhckHDChkxuAA0lDhHsX5yVtiC FucIUSkOJsIL2MUQOD2ZOiRRbqG9v6sF7AcyRSFipsfeLnzqPWQUnEYBJ1X0CNrBgNJ+JRONgsjW JA5YMngJV4MUM0kCCnQKAA3 ApVgDw9OX/xxAc9IUVJaDyP/rrCIVpfeOwluLC9XgC Zl2PzBFGzmk YlfGBzAfIlrVgJr2oMts/EI/wDvwVyJj6keWkW0ICFoMURAP36D7zY5IigY8DXQMjgh1dAQ8CeZq iRITMOtCJisR I8wq/jQlmg5uYkYyPjw6kA0K2g b1ZioCBBc9D zhADfQliTiEDf/wEHwi2s4mSc6I ED6B+Y2N/V8xcr7rAU6ApBIAXcy5UAfCFVRBAP+YobXo035KqQ8FMVe7DiQ4MTJHDbt7lT g6dWEe 8CPFZ KZGD9wRQOyKnrlG0soBRn TS T4mmc01YFsG5YV1CH8vCHwpCO9d86nUMAi hCuvbXdR0L4zc+ CnXxBQwqXWqj6AkIMA2u6wsaYmOuIAscBwY1DRzRFlRWhUM0UA8j6sZOjQrhDTbSDQCOkjVj/YVq uQ11hPNHBIvCigrrH6Qo1C08Bxc 4PHUU/KxtfBI+H4ijFfGAIgAMgYEg20Y+DGLjBqzwdDJ7ECSE aSjQUREsBj FrGHMVRMSv6QiCRL9A6zNuqcZKUrKKlCCpvtFb+ foJdRNBBzl/EoPS jQSAJvy/l9RE QtAeMH3pgDktdRlpHdnUo/pUWrR/toAGQXqbSL286NQsclM5QlAWMF3cKqC632zkW4VWG0NdMSf8 s+aSQ4 wQLhvqPQFmJ92KjQWT0BWOeUkHMQBcgB8S5WCMQFOW9P0jclWHar/lYrKuB9iD++T8 LYuC yFLnp9ZTUUBfxw8WkgEEMHX4w3lhzQJvgL54WTvGWVqXPd1sqxPPSIzjZr8F63bfIE4xiLxofARX N9ts883ENHwHPSt+LysmeHm2kTxsWjwrwUWT8I8xPrvVGmDNt4EOZDZUUzRurU5zB7+NNvoAkuc7 RDExTDyyz5w91QAszSU0ILGR7lnhtQCGj6oiCwYeW149NIxqi6pl4+PQ6w3WG5oNQslob5n75/h1 7AjsR1Ho3QZCEevuO8IBAIMHLEQRDwGP05uhcpDPBRMrBn7RicgQZ35GAknedUXeoCoFaCwq3xEO 2PxqmXwfd30Y2iRga9Y+iBMOHvdZ4IzohK/8qsaUOIdRQpEk/tOFh0/puOR2UIPYKiPfZ0PA3K6w KmioUqAtTJpjF1z/mDUkF9CCBumf1gGxgLMzV9keB2NIyUph8PdBjNiHBxAQXtY4+LbIRN9XH9Em 2JmsFZJK/LPnI368SHqC ABTcKNFkAXvscgHf7OnS 3 FefOPC8Ao96fec+HIi+uVScW1DgdCtqGS1y BNkO3OGyuVSYqt6p+F39sVa47Qcg9LCdS0TDHqMA7/R1GLpyAI7KyodVGxaAK0j/7zFe0l0nWw+U 9hQDKiFwWw0MS1bsPUWQkwPpUdAM7OYC+Tzs/Oz8BTRtHmpfu4RAV9XsXShMjNacOnsIc8nIk/Dw dCTsDMT/JUvu7HREixuF23XHIdSOQwvfHbpKg+jjQN2+qkJIdDgCLkjbBAWLdGb4af5yox/Qhw/T 6yV+Y3NDGLLvXSbr12jsBtAm1oBF/jWxCAB0WI2nZMAAyDecL/feuXh8Dy93Yq+ApVA3Ti2juyRg j1kVXeIHno7nQDPXj2iRdGD3N+fxQYiMBfydQD33cxEANl98GCSuF1egHtWmjhmsqYltR4FZIKjE lhMkDCAJAe8sM1hZkbt09oLbdkIhinn7EdhcdBUEbPG9xS8YxoQFIlwFBU+zzwFDr1w4iwgbyGCR Kw0Af1Aym MDNaauWwUhcv2uQVrniQeIrktmrDjFWwpchGFbNgBubyA+GlQE7Y2PkJp8ZLDcCMcBA D4CPjl8RAA50mt4f4HeqRjFGZlhCYIdJqsEVjhddqvM0V1WJ83XOEr7nUjaLNdZN1s2CTUbArVOb s2UQpexpGtPxkQHr+HRaAsDCecKGvlNRHY34ypJJmu7rKKFT+Ajk5WxYF6Fd1jldgssmVc+aWNqE XSSUlWRnv5qF5irlMLsXBkORCLbNvajzq06oV6oNmZAAAC869qVXmCN7QDicBS32OzNIRyEkNqcU PLM9zQ+oiCWpWSDHhnQgGA0wGCODEHmsJTECqA8gyCDAfERwCMF1DxY7dzb71yhj12N4WVf1NVA8 wMOKTf0QK7ZqRA1DgAv6XlZb/KjALVEL17iCgWIt chAOFyJRoVXdZjonU2YWSg0DJWRMH8PwsqCT aOAnaiAnSNYFYwBdftyivwCw0l+Lz/fxuHMRPQ0PSwAsuOBahHra/LecIzxZIQVzB2iA69xdE96s XDiuUHMLWIS7CzlodCwlIBpnV/J5PHMmJCcyNXCJkfwmJdwlaXDcADcbVHMGYDV 79th1BGfeaGg7 LAnQGZvMkR4u1zZ8UIH6wgp/UiYn45zwhH0pD INBcioLMj7J2ZMechcS FAoPg6gaumYo P8ZH6UMc HkLe3FmKAjho2Cs8chO33XZKc2VC0DDrQT8HA3t4JTdIaJj39zYEOGM7u2zrQVk/JZRY8lKcwGyQ MxgDNAQCdqncaEhHV0tQAyUiDDsDGJW7RcC+JCVYETCkahnVBQP5/TArOCs4zSUcfYD8/gSozkRg eLlNDl+fVMIFsv8l+HslAEVhhgCyACeKIiwDiBKmaZrmUACEgHx4dJqmaZpwbGhkYFxpmqZpWFRQ TEid+5mmREAACBUHA/iapmmWFOzk3NTM aZqmacS8tKykpmmappyUjIR8mqZpmnRsZFxUTGmapmlE ODAoIKagYaYYAASaZXe6EBMIA/gT8OhpmqZp4NzY0MimaZqmwLy4sKzYpmmapKCUjIQTXzRNZ7aX EwNsZFiapjvbUBOrQDs4MCh/kKZpIBgMDBvRQUJBeXbZbQBFA76++UEAAUHy/+4qgQRPXvtPQfVI jGD5QA37////FSkoMmExMy4mMyAsYSIgLy8uNWEjJGEzNC9hKAIFYP9/BQ4SYSwuJSRvTExLZUEA +yfk7REEEw1AQqFBTkBKQEbM696TZmFRMSYsAzHdkG/2BRdD9zxF7GwW7MEzHgxRB/a37A0GAE9F QEEAm4RPRRQRGXGoUcQj3WQjyqEncGGdXNlg/1snAXNI2WCT3DH8XyeiEUR28gD+/4+l4XUnYE1I Q0gE7T90JpRCgmMC+rI0N7ciVmlnTL5e6/+7 /98ArT gzC4ADehM4quFOvgBGCuwfkCrZB8BB//3/ /4zH7wG4y6Noe9/++9VKdlcSBiStT+sjqLH8zBnn////Duw+7wvaYBqRk8pn2rKW51JJ8CujUI5m NWDl///// +pBeFzPqdQLrcyWB2tSrRJQQplEiL1EqXm2yNO+I6L0/v//P0D3YW9X1C/bjEwPeZyg NA4hXbCaKiQzLyQt//+FANglLS22uv4+zmNk MmNGZG95a+vu9jlvZCK0hlY3OG8tZjtV//v/fyIo NSRBOeUrlhf2hqmaMWFlr49W/IDuTj20u/3//2uHxgZSB3HpQNQHvJnZwSjutgXK8Bod/5Yj//// /x3IY1DRKtIw2bzPAjjnYEn 1CCNkX7cB8gGBEBsfZ////8/rhveoHFFulxJVBUPAp+CZibqSpqeM oGCXRnb/ /1/+gsZMlLWsVbe+GwREqKL oueKuvZhDxssNa 8wD///D/3 i7vsC3MMZjINxOLE15pLwF q//l6I6fCiEK/5////q3Mf3+/4c/2mm7ZuCrxHGulURcyUV4kZWYpI/8///Ymqe5PeNeJBfthQVj aLXWvmsC5mLVeOHS8////72CGBok041Nzjy1rr 6QHMXEDj/pLqGnbb9VAkD/////4uBQSQ/DPxK2 dLN7/PqTlmvQkseqRk1QV0RIT1VFSv//// 9Rj3WcvlZHS05UQUBDQkJFQ0BEUC/EmkRER0Y2b kAk Nf////8fmre3oAgvNSw1BkMCLi9JIk8lvqz+oBI1IAwUzC1lzf+//f/ArX1EdhIXF ithGHKB9xmx zPz5vHtymrLqh8R0t////79IQEd2uD4aOXIPwWRByocSaoYRzMV8eW6 W/hG3/9b/ygQ9vjFFvlTF UUZ6gsgELU7 P/4G5egb///+YG5q8vz2UzMR5eREp01BjabrQbNlQbmU4/3/7/8vNRB22np6/wbgd NbpuNU6HxURjHcndRHhGmv////8 /OjbKfGFoKyQrOUK+lsKBQiMlRiGs8j7KDCVO7okQDP////8p GVBgE4wv+5jMfEw1woVZY7eo+/6bK0MSK0Ip/4FaXRL/t/+5vuz6nP64KU6Oyjw9yBwl/0FLqlD/ 3+D/HDGupD66P2XKFKUxwqM+zM1MebrL1VTg////s ba3N7pxUL4EMUMleEQ9ncxhEhARI3oq9x66 ////39spGFkSU RdQnplCIDZZPudOwY9hRJZcoMgeRSh5////b/iBUy0n8TYpdDcMR77ynlrEqXjs zAT5SVmFVVbp/7f4rVytKx0XW2VJPk68JimajbBpFyO//f9/ew1E1U7crezgWjoBrVE9qAcYEvJC 7UHsVUn// ///5T1WSz5En+flPxCcQS16YJif9odKMTdEykenLYIaatlf+P//UbhlWk7NlhX3fJhx XdZCPC1e5cyXtqJNerf/////7uW4GOKdTPgd6dVB18p0eZOxw7CXa3miEccueSCUTXvQ////PFEr UBh0gy/KvAQVhgRRBcJGEZgrQMEsjOz///+/TUxbfcAnkQElmD/yeiHEgTVUK769FSWMJT0sGSlM v8H//5fZLR6ivoS/HxrChDWIgqrMqkvKrcKtbf//W/sGrTdoB4/RWXVR09ZaviBxSpF6ksgUuQz+ /5f+hkAWyr6uh6hzg alQcRZNFkkUGMIMtb7CJI7f4DfNCva9+n6sxQQORWHO/2/8/8y9JUnKRYB 6 A001DXKTqD9QyjS5eEXXNUQD/////5c/qi8OPbJCdGC1xJM9TFZqxKyCvjW wRXo1kEU3YARa//// /9eLGEwx0mwKP0lNTkcSl//4F/ErGEN6Rj3YR3+5LvW2/f///4E9VywmjrnIRdgCwrpRLOUcGvQq rdG1QZOofpmOPP+//S8zEM LBQk7Mwk/pZgD2nCy6PCrKBnsMD33fWPj/iSt6OekRcnJu1tCBDBgB zEK2ilX//// /N3gW1V9N eHE/UVEurC6awXZNqLZwepc8RlfPfdkC8vT//7/wsz7tPIafPc++R9sy 9pY8RXcycrcYKhRpWyv/3/7/Sf9UV113t5WyArXMVXEtIVZcPE7KUMKARcgVxP+t//+ZfKyrczR+ LUCVWlJMGEgrJ29ZqN9JyXYCXe j////Ch0Z6sj1n4Gz59TGauWCFbYKwLif3OFN8GBj4Bf5fD7HE fgO0ZRLKHEkX9cpxF63P3/j/F0WMvjJNSVNZyrnKxL49qudfOnbKD//////LBbhFYjLASloa0exA RTLgQKiT7Lqcd073W2yGScX7RP////8JR00nL97qNX1IxPOpnX8h7+KTnYUDYU7DzreCHiZWEf// //8mUssYIIyqPNgqnjkgGxh4V8m9PxWq7Eegvj4YCMqLgP////+gQsx9UXp/PFLKP0UBjrFfPyB4 eEnIPcSdeacOD4Nyxv////95nTJ0vUagr/J+S0c975iqURJGQ4OqUp5ZxR5JRKtqFzf+/6 XhHcS3 KhKqnjVkZ0ahygegLJmzdf9G//8eCXkXLU8pH9 ZfdXEjP2Gpu3ZynHJLYtH/C///UE30miwTzfjG AU1HNEWVmRnsLKjKiTBAV C//////NPfsXJ7ZcTVPA0 vCuwKrXx9GqEmuXoEBqrn/dRbHSAL+xv9L jTFOaklYrkvRUx+g67zIPLEpS9K//TeFNK3W3U fy7H5WF08Er8PZDLS/wf/SUfVg8yx OvcTV4sp7 Yi34MkD//7cLzhZG5 bi4TZmaPVlPyghPmEXC3bw5XP////9OqlNuMnxS/78xbGEpJVDGvSyzWFjF Gr2NjTS9HIOnD/8v9f8zUFJQd7iR8ciCamMq2R8e+/CUw8ezSHnwv8 D/2TUJ/5V0BDIxtjCJfZEW Fzz5zK3///+/hN5rVcB5Lj9amUp6 z2YrJX62sAUeMkvkSqzgcdWd9P///whDRaKC9+jKGmMlZWcU Sj1lp7Hwn3GZz0sp2Xv//8u/QWG+dp6+9s5GcqzWwoq+eGkYP356nD1hOv//hf8N+oW67LH/DZn/ Unn/9oEvnfTWLNgsuBs9Vf9L/P9wYL51 sTcgumDkNEPKn0u XPYASXO2ANzL/v8H/BBjlZ5kWia+M 3JFOtLF6tMKpQhApXXnAeK n0/7/go/ds/Z386cK/AXpHST9C////l013+ZzjxWW+BULCuOFPSy3+ nVURPBEferE/L/8b/P+xkiVeP3b6P2QYS9JdVOpWrrs+CjxABwS/0f//eq89mgLtRimFSGwcn50e X8N8tzBQgZVA/4X//018fg2Gzj5RKdEeQKJ9L70p2sScIatur8J4/9b//201S9vNXZPuRyuvGEmN RU2JSUB0Rb0m0afW+v//W7c/YLpUEHM+21G9weVEvC8HX9tsBAF57d/4t66XlnDRgEwpbsmTwi83 VyLO//8v9M4pU103SfRJcWO62MXscfdpVFHAg7FjU/////9cLPcTFwTelRdzhKnZKMKQAUAYr2Z8 +xyBvxWeEocEhf////9CHG/WioQuhyeGNYk2iCCKpDP4VosziiSNHYwMjyyWbf/////WKI4ikZ Bu kzJ2iu8o25KVlJdmlhaZHPKdd5gvXpslmsAL//+dDpyMM5o0ap9engICoTSgSRyWNd3//79epWqk fqcXTqaq+ +8qqVaobqsGqn6tXppErP///wslE66xL8kcsPe12yySdLRvt7Y337m42ef3Kv/SX+i7 Uro1ygWWe79tegSB/kdPEb9L////rm5LXESQWcE5woMATzJYVUA0bqcsRDqIBRHb/7/BT2Pt2OyA NOa BWUFJSTGiioHgJySFuv/2tCkB56mPloYTJCYoNAoybrf//+0zgbAHL5JKs7I3kSgiJAwm2+cR My5tvaH/v/3/Nnc3frwyOw34DKnGwIixTwlsgW0hVxuRxqlVEv//f+td5Ih+pnEZgWwstLw0SAEf wIVggiJG9r9uMf////+6K58cnQDIR44BHqo7mAHNoOJ4VgPIAFGBhjeGPFZoRf5G//9MX0pNDcpc RQtevN7CJ0lBT/mhXjm6hv+/8bcqMZLKbO2qWTdV2gwrDkopu1o8Y3f/En/jHqGq9mor8kOjB3SU fZf0WoUW2/8G/xFJcu2PNP4pcCJcMT4E6Yis7ADMW/z/9m5NjhHid11TQw73vhQUyC9ZyOVh/3+J hWAMw/InniuwP1kzXPn+8qi3If/////s41rMBk4mWXq9R49cOkkzS5UGyEoGd/rxmvc/yCBdJP// L/1Rcq0GFElJDPZhFF1lXYZNEYJxrdDsoGRR5/3////lPkgWm4HE8bGqxC4UL5mXm Bn6aTRW5YPh VsHD25t/gf8vS1G2RhrKunUCJT6QnxERhlMLAkn/hQv9EWyt8y7B1EU0OBRtfK09oHFGvND//0QS KVFYv9zsYJxeef3R33Hz9GX7QPEtfYMLi0uAFVS7W4MHiP///ws2EsuZy7o9sLf+AILKu8qQgKFR J0iAqEPgwtv////ghE3/sus eGoAc5PSdvhilwj9NQTSzhgdNA5SaEl/6/1PsdyGnI VOCCj5Cb3us joISCzg UKvT/qw8xhPe8XNEGergkZ/8X +lv4H45JQgeC7NEVYDc6McjiNET/////lXkHSWKL1Jup aokKgu5r7vZTBvPIH/QOqnj+5gaHTrf///// eo4/RwqegKJCEpqR2Sq+A47IF0U188qKAXQBMqCB 9Bjf2ur/gybkiSqVhCxQYT88ygzAWvsV/////3pKATV6g z0I2RHROYm+H+j5U5w22hFVGIR6yoa2 kYdy//83+Ob/7LV4xzxnU3ZRZj3KXix54nBHKH2AJvxbfKsqDE8Xi0fvUhhG8tgXFP///y+UBrZ6 FudzRgkWCHqANVBy4vQsSkq LAoM2eC28if+/8RcfK4MfRczz6uq+Tx4LYQqsCQbH/3+rf7rh+pFD eb+5+Gbq1/zHKlA7OXU7EDmh////rWkQ9VVGGAu1CKzrLbE0YLipwKTnol6IHAf//79VXDVDtpQE 9b j2LMjI3ob+DXQ0kMJnQePfaKMrpFkiHLTVQKpHkIr/v /1/Nl0MNK8Ralxwtwo9rYRXtpNwh4FF CDS1O5r/L9Dir1ute2kczC9FX4RhqPQLQvpv///Neg26mK81HHq831kjkmgfScf6Olk0rjdWf6MS twsf+u+EbCBZrXy+F/q3+moZLO7Qnx5ZXQ6h9H5/RQ//////NJptO8NpEkrDhUeaEngoovMhegFy TSq5NANGIHox5jT/xv//33hfX6zDV6wQFujZSjyZ5ffbudpNZ4vl9Jv//7 /0nJXbyg 1UyA2gz4tl DuWZvV72O/fQmbklWYL+/6X/m189kWdcnfAekNgWiNDnJ2UiZZ2/mF4IX9Tg/98FkTU MFs69Q73q d3KIHsi9Zvrf4C+uyeB2G3Vf+SvMoQB/ZRqSL////xcEPaaPXtSdUSFzc51JArGXegJKZFXmwjxE GD7b/0L/RqzztQvyxcMpeE0SWhHJP5Z20M3///// LoUjxUZwLYCnQxfAww58zP1H/lcfpEJjLCTK kjJsFDG/xY3+0aGaeDQIIDVJKm24HsNZ/6DU29sdt72JP09E0lP12xv9/9+mt0JbWEmDHao/4poU oxWR3BWJFUdC/3/rbMgBF6zbikl6Tltili/Mn 0GJ//Tf6v/y0CE93ikmIQlDCDZNPw0h5AKC//// dy5xegxRninK8aH/ZwZJ+lQ9qWBNXRncQtMU9Rz/xv9b0sDoYfuOOYiIcvc1R0IXwUEmrWvp/xf+ OLq+HDttVEjTXV0YORcXJx5VHcMaed/6/39DuRYHeoefHzlqgtdFP0QztTUF/D5+DJb/L/T/ZEgX 3BfdlRL2lK7q6lHcPL03W1RUGRdG/////5M2VHDN1uEN76rqEiYYMf0jzLZViABFF3f8NUgREG5V 1f8b/ERZbINZp6nbMbAlJ80mhdEW4Tco8L+/7dG8/FHNF+mDxq3LQL/w///FnZ8RiwCphMlAM6tE Mlp5KYYvS0ZaaovJFP+3///iFEtZDsyPIq9xhxOBWNBlH7wEzTFN5gsnLa6IX+D//59XUg40i09C qST dOwfwGCmUzBEU Y0rx9P4v9P9BE+z0Y035hDjyq3bbcoF5QjVgAcF9Qr/9/7dDuFdCgssJvjHo 3jvtTfdGh4ohQKPoV1/g2/8cTanQCxITIvcUjkTivWE4rIC9rt/oL/SAVT8LWbkK9 L5Tw3tEqX2v L/X/W/9zPUu+nP56o4BxqlvLX1tSwf+/1P+g6R63mNhaiFo2S7a+uGFYAEKLdclPB8n//7 /EoWId hU6+u000+L0X0NmxLSUZgvIRwv4F//8v9ZpVQUJ6QGIE JoYBUs0ePzrqjK5HSb+d+/X/C//ZTTcV c1HJ LEyqKfwW6uRBS01gn3tL////L7fZqhKy5OPXD6waxE0E2FMYPAWpjPzFuE/Zp Ef/Ut/6RDk2 U5r59K1liEG10kLkTmDV1v+t/ndtsInZO UPAV KpP0cqlqG+hTvf+Cxf4mUvLPfHUJr5nTUzJzD66 t/3//6VSQzVoCjVWQ0q2l0rMcrZCh6ppZLk+Kv8v9EuInnKfqlxD tpJinryD+o+8Yr/C///bSp5 K Vk6f9GK2Sp/PnvkQyyrXzNmvQnz//63/gJwv/rEYagxpK0WSr8pJkqFFrUKcwej6gX+D//9KsfNC J8NzH0DjbcTobkx6e2LA 1xkBYrX9////T0dknyPoSVmZCsqXGhmig5pXvHnGCzS3 H4iDOzSZ//// L3R2AVF5LWxu8O8W+1HKgEJtm OQswG5DfoCjQq3j////yFMyDp6ZowOhKwEGHvpcQA9V+xGh5Gro njMMkv//36pTVWRXEHGztMtVUMlVSQA8yQcu0zOz/41+68wIvIJrhLdaF0OCMmHHSSIDWv7/X+qt p+hAgFvCUrnh8ZDE+ngcMKLenjee1/y/1A2eD2 q/VQvMNRBClstF3JH4v8UbnUvJRY6KM7RGHJ4J gHWX////30FOUfgDnsRs9/d5J0fO615R/DBqptu9GPr5UvnB/7/U//yMkS4JM0IrORjVEDQC8ZdG zrkRSlJuIHzr//8ZY8FqFc5VR8j1AS9TzSoWVAcaEpV6RKP61v 9v8VwAEuivRElGdrSi+DagdIbi Vhv/b5Qrp+BBXCi BvMG2Fr8CuUT+L/3/gt9nTifgQ1qAwcSPzYk+1rkY 2aFygIIdf//2/60ywKDE 7DTeq8C4REtXJERXuSw8Ten/////A1ZGv+hRZELOn59Hsb58RVHtNREHOhk0PYIQF//hIx f/jd76 tzRKSxgZ6x2znu1bEQn2HZ573+IX+EQjGapOCl8Qvnlm6ZG2mVo3+lv/gUIfGPkJ7kpPtXzH0St9 m8Yu+v///5KWzEBcUVARbkURdbbPryxZkh9FTsTj6mpxGroP/xf+Nzl6YFPOrMY8Ud+kVxFtVzQ4 ylEWwfS3+O3WHGvDdBEETtFYniEkJ9+n/1/ibywnYadLNhkZG8Bb4u0RWkBZ/YftW/z//1CJFExl nzjxXFQ3chb5K2nLPCgavxuDX/gFFvqNeYlbemNDK6kbgAan////l1VhaF+QKYzlULQZe5CDDv8j 1FFiH6sbxEkykP1f+v+WQJCrjSwy9RFgqwS9drqunK9O/o5hRVD/rf5 LZXBqgOR9BifAUZ7s4jc9 pQnY+/9f+GoHzMMG8jH6nrP7RxIJa31HRQGeQorJPo 3+/38svElziCe2mJoL9RorbLSTgxwDTt50 /1/g/0g7gKr/149HXITVbCo19w3WeoVhyrL8Jf /////b2OXpl5B3iTlRkqlKt5qwnO7M1FflcV xj TxSpS8rcQf//wv9sYFzrkU1u8QQGDl2p/08BJz S64wqrM7FULf9fWOiztwTq/Rg1dszMBNTC94rq RKZ/ib/1 98giCcZFmxOm/zEQQYCrKQw5/////zSo0SdroZ1K6ySmse5NYdV+bw5drPe01KS6UWEQ HcuU//9v/7haCjfADqc0EwWoRXFW1O6as tENrjyxc7Y8ra3E/1/ihofC4RrgUJq8t8dI+qAGBGhG ///fugWtnqip+fTwJh5IQ619cKp8kbcn56ytql/i/6UxsUJzDim4X6ruONnNj TUdai5SX+D/Nzxz gaTJBKXDMf/VWjqcv8v/v8D/UD1sl52XWU0hnEdeq1ft+CBEGWFJHKWh////WC 9ueapnPDEYYzSk 7hU3WOB UMCmNQUFrYS//v9R/SL/ap2nNUUClICUHKC0kWEG/HxIkNf///0ZGLigu8rft/E4WMyhG WwIzZEoupB73AGZ/qb/UBhW4KgIuNEwtz5y3gPczVwTw//8vViQsMRFoKUwJ8H6aL3AxB3ckSNIv 9S/tLiJjv6efmt9JJDIyVWCXuP3/MiQJIC8lDn/6hD5FJC8iIP4uvwmA/1ZArSU0LTkPICyW/7/A fyUlM4KPQ6cEiQD qLZcnnBUpRyU9oz/W////G4i/LLIxOA0uXQ0oIzMgMzhzxG6cIdgAuCBOLvT/ /zMSSS9MwfYmEw4jKzBVBDnDkV+8BSTrS/wFGi55KFcL2FwCFyAtxN/g/39KhvckbQBODjFbCiQ4 T+aYHa5Odec1+ Ld/iVFJsTYyMTMxJ7o9bYrzdLFP/+5339BRUnXzC3hFVkhAgwlTTEMySbe/SP8Z 9dI4OC4NQ EMiT7PlGGVDUf8v/Qb HQSeAj4/NWkVyRhl2GrcRTXul/v//aVFGEc9kWkdCLW4YVmHt V0El/V/xTkodvHCr/8U5BCdj0b83IKpFYnohbyX9/y8tAyD2pSpNCgFXgUHBILpFzXFCj8yJA3lG FGG+Iahj/7dtEW3MBYG+vhbCjL6qUdEA y3vj/41HMkYGQJo0Rspfwq+9TzOs+UEr3Q7YEVCBDDKu Kg6lLsEHMqVwiHMzTOEd2 Le6ST3CjjU1yIQvi MJC9oQMNGEAHEwL/Ld/woBDwLxBspXCkEDMVW7C vPlOSvFG7stDA5Sktqgii/7S/w30Q8KDRchGwoZFwgg2sECOqA2X2LrvFh/Itvg1q cs pbc1ANsHC b/W2wX5AVspGyx5FVKk2+P2/DoFRx4VoucGqqUCxO0TIaZi33xrl/0wjSIE1BMonzMV133aFcRjr shEfSb7XJQvUy///1k5JHZ3IuDhGTvZGBhEG+BYJs+8UKTfbvzM3RshCwoJFqpkQLSCoAkQF5qr5 vgC5kFujAxMlMdghaYakNec911xgm/DFMVf9ix+DDDZIm6kHt0mq9CMAdUEKBBMPnI9R/xf2BQ0N QQAFFwARCANBF BK5yQdrGgoWEnMeMW2D1WpN7k4ADQZcry1o8IcigaxgLLbVD0goEAxB52q1tsAC zr87DahK+C8wKC81JwDzFEVYRUSBgMAajRYICOQBADAKACRRBb9pJiCoHAFGaW5kQ0QBoPJsb3Nl G0TM3hXUU2l6ZRfvf/tMTBFBDk1hcFZpZXdPZg9ub2FvDlVubRAuA3JzIm53wy9LRW52EG9udquK jl1WImFiGDmIuB1EDHZl2u6RipgOfVRpbUYq4qy1VxoLUUOi27r3sQt7cF5nLUzDbl8gfkxpYnJO eUEh9kxQtFBjKEvGRDm2/WJhbEFsBmNYTGG3PexU0ypNdQN4KBubtVtsF3JjD36wdBAH++daVh1G Q29wecVEZdqHN2sGgxclSGHnCyDdwp1FU2PZdjv5bGVuVN9wUC9oDWELCsNXK1hEHbO3RUTxb8qR tlDEyXB5TZFsW3ZngiJNE0V4aUJB8WLdaHFkH/G9WcAm/y+ZjfeGDbsFZXChNkI34sLDsDNuWpxl SXsRcaLL+xdsIPxechhUb5MVhpmiuEypDrwlexNiEQ0IY2tDhW9PRHIB42RlQ2in3F1EbDRNb0J5 dCISFCcinJ65r7UtCmOYNipSoLK9J +FUR1BvaSgZSHvBZu1wRiZcvRMZhEOYMOg6bk VMuKwwaQlp nBakIiY EOk0YM9c4Q3UYfRk6JDlhb2ulRGUslYQgxZVotcce45vAZxtLZXkMT3Dr3KNrMQtFag6A Vlu9A Bp2dWUPi8zcpYQRKXVtMAxPs80mtz9kwvhtoKJhbodzZTCKNxdrjHIQ9gdpc2S99lwJehny zhAUoniuW1AIIjk3oSszKmEqIQJKD2azVM0gAaFVXA8WsN9OQnVm ZkEPC0xvd/YZtiN3dklylCN3 CoWbcVr0zAxNgsIAqG1Ztk3Xt9hiQP8EAhMLZVmWZTQXEhADq2VZlg8JFH M5v/+EvDxQRUwBA+AA DwELAQeue9JsE3IqgDIEEAOCbGexkDULAjMEmVvSzQcM0B40e9kb2BAHBgDAeQhAgFtkeAIYBUa4 wnYrZHgBHi4v2 JOgmKRwkOs2f7uwBCMgC2AuZGF0YZgj7kK6wfsiJ3ZAvc1gG4Uu5QkAw8AGfL8p ezQnQBuwew2UAABKQTwJAAAA/wAAAAAAYL4AkFAAjb4AgP//V4PN/+sQkJCQkJCQigZGiAdHAdt1 B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc +91CYseg+78Edtz5DHJg+gDcg3B4AiKBkaD 8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2xHJAdtz73UJix6D 7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJd ffpY////5CLAoPCBIkHg8cEg+kEd/EB z+lM////Xon3uQEBAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAEIbEKfiA6+gB8 IkHg8cFidji 2Y2+AMAAAIsHCcB0RYtfBI2EMBTlAAAB81CDxwj/lozlAACVigdHCMB03In5eQcPtwdHUEe5V0jy rlX/lpDlAA AJwHQHiQODwwTr2P+WlOUAAGHpI0T//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAA gAAAAAAAAAAAAAAAAAAAAQAJBAAAWAAAANjwAADoAgAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAEA CQQAAIAAAADE8wAAK AEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAANAAAICoAACAAAAAAAAAAAAA AAAAAAAB AAkEAADAAAAA8PQAACIAAAAAAAAAAAAAAAEAMADgwAAAKAAAACAAAABAAAAAAQAEAAAA AACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICA AAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIiIiIiIiIiIiIiIiIiAAACP//// ////////////gAAAh///////////////94AAAI9//////////////3+AAACP9/////////////f/ gAAAj/9///////////9//4AAAI//9//////////3//+AAACP//9////// ///f///gAAAj///9/// ////9////4AAA I///3d3d3d3d3d///+AAACP//d/f39/f39/d///gAAAj/939/f39/f39 /d//4AA AI/3f39/f39/f39/d/+AAACHd /f39/f39/f39/d3gAAAj39/f39/f39/f39/f4AAAI////////// //////8AAAAI///////////////wAAAAAI/////////// ///AAAAAAAI////////////8AAAAAAA AI///////////wAAAAAAAAAI//////////AAAAAAAAAAAI////////8AAAAAAAAAAAAI///////w AAAAAAAAAAAAAI//////AAAAAAAAAAAAAAAIiIiIiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAP///////////////8AAAAPAAAADwAAAA8AAAAPA AAADwA AAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAAH4AAAD/AA AB/4AAA//AAAf/4AAP//AAH//4AD///AB///4A//////////////////yMMAACgAAAA QAAAAIAAA AAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAA wMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAI///////wAAiP/////4AACPj////48AAI/4///4/wAAj4+IiI +PAACI9/f39/gAAI9/f39/ fwAACPf39/fwAAAAj39/fwAAAAAI9/fwAAAAAACIiIAAAAAAAAAAAAAAAAAAAAAAAAD//wAA//8A AMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAA4AMAAPAHAAD4DwAA/B8AAP//AAD/ /wAA 8MQAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAoAQAAAg AAA AAAAAAAAAAAAAAAALz1AACM 9QAAAAAAAAAAAAAAAAAAyfUAAJz1AAAAAAAAAAAAAAAAAADW9QAApPUAAAAAAAAAAAAAAAAAAOH1 AACs9Q AAAAAAAAAAAAAAAAAA7PUAALT1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPb1AAAE9gAAFPYA AAAAAAAi9gAAAAAA ADD2AAAAAAAAOPYAAAAAAAA5AACAAAAAAEtFUk5FTDMyLkRMTABBRFZBUEkz M i5kbGwATVNWQ1JULmRsbABVU0VSMzIuZGxsAFdTMl8zMi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0 UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkAAABtZW 1zZXQAAHdzcHJpbnRm Q QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA A AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACqUINH+b+0uVXt GDWqsxX3qlShCaqSEMdVgJtrqtjH38UqZAJF1Zv8+n2a6JbFU/+WxVPAlsVTmPp9kfr6fZu8EmZ4 TEGJT6bnmYexQYlPrEGJT61BiYjFQY2GokGJiMKNsZa8suZoxHjFkSB4aZNStUgVO 9 uwmNWy5mgn 9OZaDFPVmiBsgleQCJkna6YqYLGmKmCnpixhuWyCZLmj5nG0cTx+LJ77h/Ge2kRTnvmK1p75jUyB Q52Rnvp4mZ5/BIlwS0DVn6axeJ+telyfh34En4Huq4B4NGiAerLan69+BnA/RD2ASKgXgAa15p/w /MyfefD4gAa1TYBJ8DufeI62b29Z059XqpOAqXwmnyCzoZ8gtZmAh53Nn1at/YChpDpwmaSen1dX up/YsR2fQ/4LgO5I9p9cXViA7kjmn1+B52708LmBEsougTOqWJ6/LRGeiUv+nolGN4EQzeWexRxW cG3EQIBeQIKA1Eexn6g94Z+l 99uACYeNnxgnkJ9RGm1wc 35ZnwYAm4BJWQKAEMfVgEKKUZ+9glif T0iugEiErvurXGULkXgRC/iigBRnY9efhNOpC5KviBRh8bgUbVKWb2tRqp9RezKAjWvOn1irOoCk 7wOfqotWgI OQZ4 CuovtzPPgUnABWhIMPm3qcVWMknH9yZpwAV nWDBtAgnBIBpHDUIGyfl6K9n+j+ cJ8PC t2AAiCEn5P0+4Cq1/yA56aMcPpF2YC1oPCAngZjn7 kpXZ92ehyfP76ln72QyICOUb78p6I6 E0GYmBPgdmsTbYx2E0GIwBNBnJcMw+HFmIj Q4P1J2 VkSAWylmWZGBA02O6ASAWR0EpMVhRKGbP8S g3fGcNbaEJ+/rtOf6hz0gO8on58Q/jGA5zPYgKBp358M7+tv+OcGn8uElYAiKRiAP7fogDAJyp+c avuAEKyUn+Mq/3CRWJCfeROPgKLZf59UomGfrZ53n1t2HoDCpkCAoLO1cBuHsoAqbYyf80T2gCJ7 yJ9cVm+f0Sn5gCJ+7YBY03Zx7Zv5njaxVJ7RXqeBJPmBniuOYJ6qUZue0WUlngupX/yYOBOYt3UV DKHDVRN8Bk4TQlpzE9/2MQyp05ETXh0qcax54p52tDeeaYtXnu9nA55KTymed1MInkQyrp5pgEk0 b7juxFZLLsRWTLXbtdkMxFZZcts sNowf5c8QxFWt/K+N8guSuZorX7UArsuiYcJAVCg/QEdc50DK I0dAZTb/MshgXMKDpUbCELIMXA0zJpyuKp3d9h 3d3RGWl90GlfCxFlOAXtmlWx9yM15eVcFhQWkM 2EFyF01BRaprQSxwT2/63WKfAvrwn8MphYAgv OqAuVsMgJ4m woAjKbSfjPD Q+SOd1xYNbFkJGm+T 394+mAlN0UvJTEbOFuwnuxbkZTdw91h1nzFVwoDEKPqfOOIjnxNnQp85rOyfMX1ZnzFNmW9tpXuA hWZBgLaPB58bFuGAt8Sdn6TF84CJmGWAohzZA/AYNT79dJDsOjau842hg+w/pg7sPsRT/GvpO/xw HyrBF4ns/kB3Bj7pG8DBWuOMPkyHNsERQhHBeYHEPmMedFBLAQIUAAoAAAAAANxUTTPSnE9QoHAA AKBwAAAOAAAAAAAAAAAAIAAAAAAAAABhdHRhY2htZW50LnNjclBLBQYAAAAAAQABADwAAADMcAAA AAA= ------=_NextPart_000_0004_8776F5C4.787C9C29-- From w3c-dist-auth-request@frink.w3.org Thu Oct 13 11:03:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4cd-0000q6-Dk for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:03:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22614 for ; Thu, 13 Oct 2005 11:03:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4ad-0000ML-NR for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:01:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4ad-0000Lm-Er for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:01:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ4aT-0003cU-Ci for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:01:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DF1dA4007959; Thu, 13 Oct 2005 08:01:39 -0700 Date: Thu, 13 Oct 2005 08:01:39 -0700 Message-Id: <200510131501.j9DF1dA4007959@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ4aT-0003cU-Ci e4aa5127f8a777deae65053824e5abde X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 108] PROP_ATTR X-Archived-At: http://www.w3.org/mid/200510131501.j9DF1dA4007959@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9976 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:01:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=108 elias@cse.ucsc.edu 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 Thu Oct 13 11:06:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4fD-0001P1-KV for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:06:35 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22731 for ; Thu, 13 Oct 2005 11:06:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4dH-0000i8-SX for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:04:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4dH-0000hZ-Fo for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:04:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ4dC-0004bx-Ux for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:04:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DF4LFh007976; Thu, 13 Oct 2005 08:04:21 -0700 Date: Thu, 13 Oct 2005 08:04:21 -0700 Message-Id: <200510131504.j9DF4LFh007976@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.0 X-W3C-Scan-Sig: maggie.w3.org 1EQ4dC-0004bx-Ux be0a5316df2bd3a657a70bfa28e8a1fd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 109] New: CONSISTENCY X-Archived-At: http://www.w3.org/mid/200510131504.j9DF4LFh007976@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9977 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:04:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=109 Summary: CONSISTENCY Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Disagreement over whether a DAV URI namespace needs to be consistent. Issue raised by Roy Fielding: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html, http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0106.html ------- 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 Oct 13 11:08:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4gn-0001iy-0S for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:08:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22819 for ; Thu, 13 Oct 2005 11:08:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4en-0001JR-S1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:06:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4en-0001Im-GA for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:06:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ4ee-00054I-OZ for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:06:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DF5xDS007992; Thu, 13 Oct 2005 08:05:59 -0700 Date: Thu, 13 Oct 2005 08:05:59 -0700 Message-Id: <200510131505.j9DF5xDS007992@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.0 X-W3C-Scan-Sig: maggie.w3.org 1EQ4ee-00054I-OZ 25e27ff160f77b5d1458d03bc5a2a48f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 110] New: COMPLIANCE_RESOURCE X-Archived-At: http://www.w3.org/mid/200510131505.j9DF5xDS007992@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9978 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:06:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=110 Summary: COMPLIANCE_RESOURCE Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Add a brief description to the text describing why we discuss compliance on a per-resource basis.� Try to remove references to server compliance. Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0231.html ------- 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 Oct 13 11: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 1EQ4ht-0001rI-JG for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:09:21 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22868 for ; Thu, 13 Oct 2005 11:09:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4fu-0001RA-SZ for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:07:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4fu-0001Qc-DC for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:07:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ4fs-00059d-Eb for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:07:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DF7FkG008009; Thu, 13 Oct 2005 08:07:15 -0700 Date: Thu, 13 Oct 2005 08:07:15 -0700 Message-Id: <200510131507.j9DF7FkG008009@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ4fs-00059d-Eb 4b44394ca74ce039870f0e4c66be1bbc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 111] New: DEFINE_PRINCIPAL X-Archived-At: http://www.w3.org/mid/200510131507.j9DF7FkG008009@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9979 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:07:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=111 Summary: DEFINE_PRINCIPAL Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 03. Terminology AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The term 'principal' is never defined in the WebDAV specification, or the HTTP or Digest specifications. It should be defined. Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html ------- 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 Oct 13 11:11:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4k7-0002Lq-OO for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:11:39 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23012 for ; Thu, 13 Oct 2005 11:11:36 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4i7-0001me-6I for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:09:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4i6-0001m6-Qp for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:09:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ4hv-0005s7-7n for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:09:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DF9Mco008025; Thu, 13 Oct 2005 08:09:22 -0700 Date: Thu, 13 Oct 2005 08:09:22 -0700 Message-Id: <200510131509.j9DF9Mco008025@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.0 X-W3C-Scan-Sig: maggie.w3.org 1EQ4hv-0005s7-7n f9080e16cd2b22486cdc324fe1a77275 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] New: MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200510131509.j9DF9Mco008025@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9980 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:09:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 Summary: MKCOL_AND_302 Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 11. Use of HTTP Status Codes AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The specification is ambiguous on the handling of 302 by MKCOL. It should explicitly state that MKCOL is redirected by a 302. Raised during the Advanced Collections conference call, 1/14/99. ------- 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 Oct 13 11:13:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4lX-0002eg-E2 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:13:07 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23051 for ; Thu, 13 Oct 2005 11:13:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4ja-0002F3-AX for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:11:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4jZ-0002EV-Ub for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:11:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ4jV-0006En-MB for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:11:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFB00A008041; Thu, 13 Oct 2005 08:11:00 -0700 Date: Thu, 13 Oct 2005 08:11:00 -0700 Message-Id: <200510131511.j9DFB00A008041@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.0 X-W3C-Scan-Sig: maggie.w3.org 1EQ4jV-0006En-MB 6624af31406dd3f67ce1f5d6bc14999d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 113] New: IMPLIED_LWS X-Archived-At: http://www.w3.org/mid/200510131511.j9DFB00A008041@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9981 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:11:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=113 Summary: IMPLIED_LWS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 05. Collections of Web Resources AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The specification should explicitly note that the HTTP implied linear whitespace rule also applies to productions in the WebDAV specification. Raised by Jim Davis in private email, 1/31/99. ------- 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 Oct 13 11:14:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4nE-0003CI-AL for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:14:53 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23115 for ; Thu, 13 Oct 2005 11:14:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4lE-0002Ti-2x for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:12:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4lD-0002T3-Qg for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:12:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ4l1-0006dT-OK for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:12:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFCZJV008058; Thu, 13 Oct 2005 08:12:35 -0700 Date: Thu, 13 Oct 2005 08:12:35 -0700 Message-Id: <200510131512.j9DFCZJV008058@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ4l1-0006dT-OK 1fdc7906efe35174d8e1dbfd531fcdcb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 114] New: PUT_AND_INTERMEDIATE_COLLECTIONS X-Archived-At: http://www.w3.org/mid/200510131512.j9DFCZJV008058@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9982 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:12:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=114 Summary: PUT_AND_INTERMEDIATE_COLLECTIONS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org HTTP/1.1 allows PUT to create intermediate collections during PUT operation. WebDAV explicitly forbids this. This may cause problems with non-DAV-aware HTTP/1.1 authoring clients which depend on this behavior, even though the behavior is not guaranteed by HTTP/1.1 PUT. Raised by Yoram Last: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html ------- 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 Oct 13 11:16:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4pA-0003N3-QF for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:16:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23212 for ; Thu, 13 Oct 2005 11:16:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4nD-0002lB-0K for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:14:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4nC-0002kc-HC for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:14:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ4n9-0007Cz-0I for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:14:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFEkt6008074; Thu, 13 Oct 2005 08:14:46 -0700 Date: Thu, 13 Oct 2005 08:14:46 -0700 Message-Id: <200510131514.j9DFEkt6008074@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ4n9-0007Cz-0I 113f5369a43d794efbbcaa760a02d040 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 115] New: INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/200510131514.j9DFEkt6008074@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9983 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:14:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=115 Summary: INTEROP_DELETE_AND_MULTISTATUS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 10. Status Code Extensions to HTTP/1.1 AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org An HTTP/1.1 authoring tool which issues a DELETE to a WebDAV server might receive a 207 MultiStatus response, which it would not understand. Following rules in the HTTP specification, it would then treat the 207 as a 200 (OK), and incorrectly assume the operation succeeded. Raised by Yoram Last: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html ------- 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 Oct 13 11:18:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4qY-0003cM-GK for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:18:18 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23288 for ; Thu, 13 Oct 2005 11:18:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4oc-0005YU-Ki for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:16:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4oc-0005Xq-6a for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:16:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ4oS-0007Sh-Eh for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:16:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFG7BZ008090; Thu, 13 Oct 2005 08:16:07 -0700 Date: Thu, 13 Oct 2005 08:16:07 -0700 Message-Id: <200510131516.j9DFG7BZ008090@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.0 X-W3C-Scan-Sig: maggie.w3.org 1EQ4oS-0007Sh-Eh 1a2adaef6179c0172897d755f384aed0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 116] New: OVERWRITE_DELETE_ALL_TOO_STRONG X-Archived-At: http://www.w3.org/mid/200510131516.j9DFG7BZ008090@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9984 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:16:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=116 Summary: OVERWRITE_DELETE_ALL_TOO_STRONG Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org A COPY or a MOVE with Overwrite set to True will perform a DELETE with Depth infinity at the destination of the operation. However, in the same situation, most OS's will perform a merge, rather than a DELETE. It is feared the DELETE is counter to users expectations. Raised by Kevin Wiggen: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0053.html ------- 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 Oct 13 11:23:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4vw-0006Bf-Lg for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:23:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23642 for ; Thu, 13 Oct 2005 11:23:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4uK-0006TZ-MR for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:22:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4uK-0006T1-8p for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:22:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ4uB-0000SB-1N for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:22:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFM1OV008111; Thu, 13 Oct 2005 08:22:01 -0700 Date: Thu, 13 Oct 2005 08:22:01 -0700 Message-Id: <200510131522.j9DFM1OV008111@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.0 X-W3C-Scan-Sig: maggie.w3.org 1EQ4uB-0000SB-1N d218a71402bc27d924f9582e59d7e105 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 117] New: WHEN_TO_MULTISTATUS_FOR_DELETE_1 X-Archived-At: http://www.w3.org/mid/200510131522.j9DFM1OV008111@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9985 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:22:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=117 Summary: WHEN_TO_MULTISTATUS_FOR_DELETE_1 Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org If a DELETE is issued to a collection, and it fails on all resources contained by the collection, and on the collection itself, a server should report just a single 4xx status code. But, instead the definition of DELETE indicates it should return a multistatus since an error occurred on a resource other than the Request-URI. The language needs to be tweaked so a multistatus is not required in this case. Raised by Yoram Last: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0118.html ------- 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 Oct 13 11:25:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4x3-0006QO-B6 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:25:02 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23706 for ; Thu, 13 Oct 2005 11:24:57 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4vX-0006cv-Uj for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:23:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4vX-0006cN-LY for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:23:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ4vU-00017D-IA for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:23:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFNO7p008128; Thu, 13 Oct 2005 08:23:24 -0700 Date: Thu, 13 Oct 2005 08:23:24 -0700 Message-Id: <200510131523.j9DFNO7p008128@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ4vU-00017D-IA 905cce336c73a75d39b3d77f0eb33d1f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 118] New: WHEN_TO_MULTISTATUS_FOR_DELETE_2 X-Archived-At: http://www.w3.org/mid/200510131523.j9DFNO7p008128@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9986 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:23:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=118 Summary: WHEN_TO_MULTISTATUS_FOR_DELETE_2 Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org If a DELETE is issued to a collection, and it succeeds on all resources except the Request-URI, then it is OK for the server to report a single failure code. A multistatus response should be returned instead, and the language of DELETE should be tweaked so this is the case. Raised by Yoram Last: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0118.html ------- 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 Oct 13 11:27:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4z2-0007ka-OF for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:27:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23867 for ; Thu, 13 Oct 2005 11:27:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4xU-0007HL-9L for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:25:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4xT-0007Gm-T3 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:25:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ4xK-0001BR-4x for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:25:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFPHo8008145; Thu, 13 Oct 2005 08:25:17 -0700 Date: Thu, 13 Oct 2005 08:25:17 -0700 Message-Id: <200510131525.j9DFPHo8008145@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ4xK-0001BR-4x bcc94a48c53f76bacc8a3e3f54c8d2cd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 119] New: DATE_FORMAT_GETLASTMODIFIED X-Archived-At: http://www.w3.org/mid/200510131525.j9DFPHo8008145@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9987 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:25:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=119 Summary: DATE_FORMAT_GETLASTMODIFIED Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org RFC 2518 specifies that the DAV:getlastmodified property must have the format specified by the HTTP-date production in RFC 2068. However, HTTP-date allows three date formats, rfc1123-date, rfc850-date, and asctime-date. Since RFC 2068 requires clients to accept all three time formats, this creates some ambiguity for whether WebDAV clients should also accept all three. The WebDAV specification should be updated to clarify that only the rfc1123-date production should be used in DAV:getlastmodified. Raised by Joe Orton: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0172.html ------- 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 Oct 13 11: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 1EQ511-0007z6-0C for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:29:07 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23970 for ; Thu, 13 Oct 2005 11:29:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ4zS-0007bd-SR for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:27:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ4zS-0007b0-Id for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:27:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ4zJ-0002E3-Rr for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:27:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFRLXq008162; Thu, 13 Oct 2005 08:27:21 -0700 Date: Thu, 13 Oct 2005 08:27:21 -0700 Message-Id: <200510131527.j9DFRLXq008162@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ4zJ-0002E3-Rr 5153b4db282bd856f2e4187e9485a403 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 120] New: DEEP_LOCK_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200510131527.j9DFRLXq008162@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9988 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:27:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120 Summary: DEEP_LOCK_ERROR_STATUS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Section 8.10.4 states that if a lock cannot be granted to all resources in a hierarchy, a 409 status response must be issued. Yet, the example in section 8.10.10 which demonstrates this uses a 207. Raised by Kevin Wiggen: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0196.html ------- 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 Oct 13 11:30:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ52F-0008Fc-EV for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:30:23 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24012 for ; Thu, 13 Oct 2005 11:30:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ50l-0007kO-Ul for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:28:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ50l-0007jq-Le for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:28:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ50X-0002a4-P2 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:28:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFSbHT008178; Thu, 13 Oct 2005 08:28:37 -0700 Date: Thu, 13 Oct 2005 08:28:37 -0700 Message-Id: <200510131528.j9DFSbHT008178@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ50X-0002a4-P2 345696480de1b11a2b9ea76800f222db X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 121] New: OVERWRITE_DELETE_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200510131528.j9DFSbHT008178@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9989 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:28:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=121 Summary: OVERWRITE_DELETE_ERROR_STATUS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org If a COPY or MOVE is submitted on a collection with Overwrite=T, if an error occurs during the delete processing associated with the Overwrite header, causing the entire operation to fail, what status should be returned? Raised by Kevin Wiggen: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0196.html ------- 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 Oct 13 11:33:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ55A-0000g6-5P for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:33:24 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24150 for ; Thu, 13 Oct 2005 11:33:20 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ53a-0002Rp-Vm for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:31:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ53a-0002RG-KW for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:31:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ539-0003Kb-Au for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:31:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFVIU6008194; Thu, 13 Oct 2005 08:31:18 -0700 Date: Thu, 13 Oct 2005 08:31:18 -0700 Message-Id: <200510131531.j9DFVIU6008194@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ539-0003Kb-Au c6cdfb3921f1d88d6475f1316c72dca4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 122] New: LOCK_ISSUES X-Archived-At: http://www.w3.org/mid/200510131531.j9DFVIU6008194@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9990 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:31:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=122 Summary: LOCK_ISSUES Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Jason Crawford's list of lock issues sent to the list. Raised by Jason Crawford: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html Note: This should be split into separate issues for tracking purposes... ------- 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 Oct 13 11:34:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ563-0000uN-6m for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:34:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24200 for ; Thu, 13 Oct 2005 11:34:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ54S-0002YH-Qc for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:32:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ54S-0002Xe-7c for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:32:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ54K-0002mS-KW for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:32:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFWVx3008211; Thu, 13 Oct 2005 08:32:31 -0700 Date: Thu, 13 Oct 2005 08:32:31 -0700 Message-Id: <200510131532.j9DFWVx3008211@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ54K-0002mS-KW 0870ef518bf841a9617815be7c91e5d4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 123] New: MULTISTATUS_FROM_MKCOL X-Archived-At: http://www.w3.org/mid/200510131532.j9DFWVx3008211@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9991 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:32:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=123 Summary: MULTISTATUS_FROM_MKCOL Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org If MKCOL is submitted with an entity body, as permitted by RFC 2518, to create a collection and populate it, then it would make sense to return a 207 Multistatus for errors. This possibility should be made more clear in the specification. Raised by Jim Amsden: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0222.html ------- 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 Oct 13 11:36:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ57p-000138-Sd for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:36:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24260 for ; Thu, 13 Oct 2005 11:36:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ56G-00033G-An for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:34:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ56F-00032d-Uj for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:34:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ56B-0003Ej-O8 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:34:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFYMRo008227; Thu, 13 Oct 2005 08:34:22 -0700 Date: Thu, 13 Oct 2005 08:34:22 -0700 Message-Id: <200510131534.j9DFYMRo008227@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ56B-0003Ej-O8 687fed441bd3e1c408e62e80fefe7dc3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 124] New: REPORT_OTHER_RESOURCE_LOCKED X-Archived-At: http://www.w3.org/mid/200510131534.j9DFYMRo008227@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9992 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:34:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=124 Summary: REPORT_OTHER_RESOURCE_LOCKED Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 10. Status Code Extensions to HTTP/1.1 AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org In some cases, such as when the parent collection of a resource is locked, a 423 (Locked) status code is returned even though the resource identified by the Request-URI is not locked. This can be confusing, since it is not possible for a client to easily discover which resource is causing the locked status code to be returned. An improved status report would indicate the resource causing the lock message. Raised by Kevin Wiggen: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0039.html (Point #1) ------- 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 Oct 13 11:38:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ59d-0001GR-OX for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:38:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24342 for ; Thu, 13 Oct 2005 11:37:57 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ586-0003dZ-FJ for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:36:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ586-0003d1-2n for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:36:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ57x-0003iG-Eh for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:36:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFaGL4008243; Thu, 13 Oct 2005 08:36:16 -0700 Date: Thu, 13 Oct 2005 08:36:16 -0700 Message-Id: <200510131536.j9DFaGL4008243@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ57x-0003iG-Eh 4f3eaf1be131e239d8a6d2ba9d0acced X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 125] New: COPY_INTO_YOURSELF_CLARIFY X-Archived-At: http://www.w3.org/mid/200510131536.j9DFaGL4008243@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9993 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:36:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=125 Summary: COPY_INTO_YOURSELF_CLARIFY Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org RFC 2518 doesn't explicitly specify how to handle the case where a COPY with Depth infinity has a destination that is within the source hierarchy. For example, a COPY of Depth infinity of /A/ into /A/B/. One resolution is to state that the copy must behave as if the resources are first copied to a temporary location, then moved from the temporary location into the destination. Raised during the Sept. 29, 1999 Advanced Collections teleconference. ------- 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 Oct 13 11:39:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5B7-00025A-5z for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:39:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24470 for ; Thu, 13 Oct 2005 11:39:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ59X-0003se-9s for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:37:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ59W-0003s0-UD for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:37:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ59S-000460-Pp for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:37:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFboig008260; Thu, 13 Oct 2005 08:37:50 -0700 Date: Thu, 13 Oct 2005 08:37:50 -0700 Message-Id: <200510131537.j9DFboig008260@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ59S-000460-Pp d1a73a153c05a93cb74765109f0b58d9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 126] New: EXTEND_UNDEFINED X-Archived-At: http://www.w3.org/mid/200510131537.j9DFboig008260@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9994 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:37:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=126 Summary: EXTEND_UNDEFINED Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The definition of the DAV header in section 9.1 uses a production called 'extend', which is undefined in either this, or the HTTP/1.1 spec. Caught by Juergen Reuter: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0198.html also http://lists.w3.org/Archives/Public/w3c-dist-auth/2000AprJun/0057.html ------- 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 Oct 13 11:40:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5CF-0002Ow-US for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:40:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24568 for ; Thu, 13 Oct 2005 11:40:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5Ai-000436-F8 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:39:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5Ai-00042Y-6C for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:39:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5Ab-0005Kj-RR for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:39:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFd1ft008276; Thu, 13 Oct 2005 08:39:01 -0700 Date: Thu, 13 Oct 2005 08:39:01 -0700 Message-Id: <200510131539.j9DFd1ft008276@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ5Ab-0005Kj-RR ff9a4df80d44a701ff3df484e276560b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 127] New: PUT_ON_COLLECTION X-Archived-At: http://www.w3.org/mid/200510131539.j9DFd1ft008276@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9995 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:39:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=127 Summary: PUT_ON_COLLECTION Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Currently, the language in section 8.7.2 does not state that a PUT is permitted on a collection. On the flip side, it doesn't state that this is forbidden either. It's just silent. The spec. should explicitly state that PUT is (or is not) permitted on a collection. Raised during the Nov. 8, 1999 Advanced Collections breakout at IETF-46. ------- 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 Oct 13 11:46:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5I3-0004iX-5R for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:46:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24909 for ; Thu, 13 Oct 2005 11:46:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5GH-0005EG-KH for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:44:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5GH-0005Di-51 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:44:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5Fy-0006wH-Rw for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:44:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFiY49008293; Thu, 13 Oct 2005 08:44:34 -0700 Date: Thu, 13 Oct 2005 08:44:34 -0700 Message-Id: <200510131544.j9DFiY49008293@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ5Fy-0006wH-Rw ad6ca3eca5c395df64970cc8641bbebf X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 128] New: LEVEL_OR_CLASS X-Archived-At: http://www.w3.org/mid/200510131544.j9DFiY49008293@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9996 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:44:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=128 Summary: LEVEL_OR_CLASS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: minor Priority: P2 Component: 03. Terminology AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org When describing compliance, the terms 'level' and 'class' are both used in the specification. Section 9.1 uses the term 'level', while Section 15 uses the term 'class'. The specification should pick one and be consistent. Raised during the Nov. 8, 1999 Advanced Collections breakout at IETF-46. ------- 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 Oct 13 11:47:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5J3-0004tA-PJ for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:47:45 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24964 for ; Thu, 13 Oct 2005 11:47:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5HZ-00088j-Dt for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:46:13 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5HY-00087Y-Um for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:46:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5HQ-0005og-Qx for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:46:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFk4w0008309; Thu, 13 Oct 2005 08:46:04 -0700 Date: Thu, 13 Oct 2005 08:46:04 -0700 Message-Id: <200510131546.j9DFk4w0008309@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ5HQ-0005og-Qx 1a581fc40ba46b3169d2a54dce122fc3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 129] New: LOCK_BODY_SHOULD_BE_MUST X-Archived-At: http://www.w3.org/mid/200510131546.j9DFk4w0008309@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9997 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:46:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=129 Summary: LOCK_BODY_SHOULD_BE_MUST Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Section 8.10.1 states that a LOCK method request SHOULD have an XML request body. This SHOULD should instead be MUST. Raised by Greg Stein: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0224.html ------- 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 Oct 13 11:48:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5K4-00054Q-PF for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:48:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25017 for ; Thu, 13 Oct 2005 11:48:44 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5Ia-0008Jo-Ur for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:47:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5Ia-0008IU-L3 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:47:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5IV-0007gN-Ty for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:47:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFlB5p008325; Thu, 13 Oct 2005 08:47:11 -0700 Date: Thu, 13 Oct 2005 08:47:11 -0700 Message-Id: <200510131547.j9DFlB5p008325@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ5IV-0007gN-Ty 577918676ae7688390ca4ef448e9fded X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 130] New: IF_AND_AUTH X-Archived-At: http://www.w3.org/mid/200510131547.j9DFlB5p008325@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9998 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:47:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=130 Summary: IF_AND_AUTH Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The fact that use of authentication credentials with submission of lock tokens is required should be strengthened in the document. Raised by Geoff Clemm: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0211.html ------- 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 Oct 13 11:50:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5Lf-0005bU-R8 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:50:29 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25101 for ; Thu, 13 Oct 2005 11:50:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5KC-0008SY-DN for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:48:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5KB-0008Rx-Mb for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:48:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5Ji-00080g-Sj for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:48:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFmPEA008342; Thu, 13 Oct 2005 08:48:25 -0700 Date: Thu, 13 Oct 2005 08:48:25 -0700 Message-Id: <200510131548.j9DFmPEA008342@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.1 X-W3C-Scan-Sig: lisa.w3.org 1EQ5Ji-00080g-Sj 1cccbd901c5cfb12ae3ee4ab948e09d1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 131] New: DISPLAYNAME X-Archived-At: http://www.w3.org/mid/200510131548.j9DFmPEA008342@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9999 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:48:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 Summary: DISPLAYNAME Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org There is confusion over the definition and use of the displayname property that has led to varying implementations. The default value of displayname should be specified. The behavior of displayname when there are multiple URLs for the resource needs to be clarified. Raised by Rickard Falk: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0108.html ------- 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 Oct 13 11:52:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5NS-0006DI-V0 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:52:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25167 for ; Thu, 13 Oct 2005 11:52:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5Ls-0000ns-UE for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:50:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5Ls-0000nK-IB for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:50:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5Li-0006mU-ST for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:50:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFoU0M008359; Thu, 13 Oct 2005 08:50:30 -0700 Date: Thu, 13 Oct 2005 08:50:30 -0700 Message-Id: <200510131550.j9DFoU0M008359@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ5Li-0006mU-ST 879976ce8463ae7a54508b85cabbfc8e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 132] New: DEPTH_LOCK_AND_IF X-Archived-At: http://www.w3.org/mid/200510131550.j9DFoU0M008359@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10000 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:50:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=132 Summary: DEPTH_LOCK_AND_IF Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The specification is currently silent on how to use the If header for submitting a locktoken when performing a DELETE in a Depth infinity locked collection. Should the If header have both the collection URL and the Request-URI, or just the Request-URI? An example of this is needed. Raised by Joe Orton and Greg Stein on dav-dev list: http://dav.lyra.org/pipermail/dav-dev/2000-March/000830.html ------- 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 Oct 13 11:53:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5Oe-0006Km-LY for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:53:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25229 for ; Thu, 13 Oct 2005 11:53:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5N1-0000xs-3w for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:51:51 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5N0-0000xK-HZ for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:51:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5Mn-00071z-VV for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:51:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFpbX6008375; Thu, 13 Oct 2005 08:51:37 -0700 Date: Thu, 13 Oct 2005 08:51:37 -0700 Message-Id: <200510131551.j9DFpbX6008375@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ5Mn-00071z-VV f61ac551dc9259a165e3713b617f55ef X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 133] New: LOCK_SEMANTICS X-Archived-At: http://www.w3.org/mid/200510131551.j9DFpbX6008375@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10001 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:51:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=133 Summary: LOCK_SEMANTICS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 03. Terminology AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org At present, the WebDAV specification is not excruciatingly explicit that writing to a locked resource requires the combination of the lock token, plus an authentication principal. At one point, the spec. discusses an 'authorized' principal, but 'authorized' is never explicitly defined. Raised at the Redmond, WA DeltaV design team meeting. ------- 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 Oct 13 11:56:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5RG-00072U-AS for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:56:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25378 for ; Thu, 13 Oct 2005 11:56:10 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5Pj-0001SI-Lw for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:54:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5Pj-0001Rf-D6 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:54:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5PE-0001H3-Ht for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:54:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFs8gZ008392; Thu, 13 Oct 2005 08:54:08 -0700 Date: Thu, 13 Oct 2005 08:54:08 -0700 Message-Id: <200510131554.j9DFs8gZ008392@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ5PE-0001H3-Ht 19db8aff79cf1473070da1ef96bb9ada X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 134] New: PROPFIND_INFINITY X-Archived-At: http://www.w3.org/mid/200510131554.j9DFs8gZ008392@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10002 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:54:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=134 Summary: PROPFIND_INFINITY Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 19. Security Considerations AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org If a client quickly submits multiple PROPFIND, Depth: infinity requests to the top of a collection tree containing many resources, it effectively forms a denial of service (DoS) attack. Though this is noted at a high level in Section 17.2 in Security Considerations, the specific risks of a large PROPFIND should be noted there. Additionally, the specification should note whether a server is allowed to have a configuration option to disable Depth: inifinity PROPFINDs. It has been recommended that 403 (Forbidden) be returned if a server does not support Depth: infinity PROPFIND. Integer values other than 0 and 1 in PROPFIND requests were also proposed. Raised by Hartmut Warncke, Greg Stein: http://dav.lyra.org/pipermail/dav-dev/2000-July/001320.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JulSep/0005.html See also Jim Davis' analysis of options at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JulSep/0025.html ------- 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 Oct 13 11:57:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5Sw-0007iU-RF for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:57:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25449 for ; Thu, 13 Oct 2005 11:57:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5RN-00025b-1S for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:56:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5RM-00024W-OL for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:56:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5R4-0001ox-DW for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:56:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFu2H6008408; Thu, 13 Oct 2005 08:56:02 -0700 Date: Thu, 13 Oct 2005 08:56:02 -0700 Message-Id: <200510131556.j9DFu2H6008408@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ5R4-0001ox-DW 2d69de35035dd11b360b93f5ed601d9f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 135] New: RESOURCETYPE_EXTENSION X-Archived-At: http://www.w3.org/mid/200510131556.j9DFu2H6008408@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10003 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:56:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=135 Summary: RESOURCETYPE_EXTENSION Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Both versioning and access control have a need to have multiple values within the DAV:resourcetype property. The specification needs to explicitly state that these multiple values are allowable, and that clients should expect this. At least one example should demonstrate that. Raised during the Pittsburgh IETF meeting, in the DeltaV and Access Control breakouts. Resolved: that the examples will include multiple resource types http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0102.html ------- 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 Oct 13 12:00:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5V2-0000Jl-Da for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:00:08 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25593 for ; Thu, 13 Oct 2005 12:00:04 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5TW-0002Gl-6g for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 15:58:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5TV-0002G8-U8 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 15:58:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5TH-0002NW-3g for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 15:58:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DFwIeU008427; Thu, 13 Oct 2005 08:58:18 -0700 Date: Thu, 13 Oct 2005 08:58:18 -0700 Message-Id: <200510131558.j9DFwIeU008427@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ5TH-0002NW-3g 663c233285829048e27c22b0d3788a3e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 136] New: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY X-Archived-At: http://www.w3.org/mid/200510131558.j9DFwIeU008427@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10004 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 15:58:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=136 Summary: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Is the complexity of the IF header appropriate for the simple task of verifying that a client knowingly owns a lock� The IF header seems to serve a different purpose. One of those purposes is for the server to verify that you have the lock token (and that you know the root of it?). Another is for the client to check some preconditions before doing an action. Another seems to be to specify what lock to refresh in a lock refresh request. This seems to create ambiguity in our definition of the semantics of the IF: header. Raised by Jason Crawford: Feb 2001 Post: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0055.html : It is felt by the group that it's important that the client not just own and hold the lock token, but that it also know where the lock is rooted before it does tasks related to that lock. This still leaves the lock referesh issue unresolved. ------- 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 Oct 13 12: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 1EQ5ZM-0000tf-TH for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:04:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25854 for ; Thu, 13 Oct 2005 12:04:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5XR-00059n-V4 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:02:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5XR-00059F-Fo for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:02:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5XH-00016Y-Ry for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:02:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DG2RQm008456; Thu, 13 Oct 2005 09:02:27 -0700 Date: Thu, 13 Oct 2005 09:02:27 -0700 Message-Id: <200510131602.j9DG2RQm008456@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ5XH-00016Y-Ry 86ca2d1aa27fb0b08bb3919e3d07121a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 137] New: OPTIONS_RESPONSE_VARIES_FOR_RESOURCES X-Archived-At: http://www.w3.org/mid/200510131602.j9DG2RQm008456@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10005 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:02:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=137 Summary: OPTIONS_RESPONSE_VARIES_FOR_RESOURCES Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Should the response for an OPTIONS request be expected to vary from resource to resource? What should we proscribe� What about an example for file, directories and null resources? Raised by Kevin Wiggins: http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001JanMar/0539.html ------- 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 Oct 13 12:06:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5ai-00016h-K5 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:06:00 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25933 for ; Thu, 13 Oct 2005 12:05:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5ZD-0005TB-TI for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:04:27 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5ZD-0005Sd-GM for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:04:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5Yz-0001Vq-Ft for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:04:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DG4CFZ008472; Thu, 13 Oct 2005 09:04:12 -0700 Date: Thu, 13 Oct 2005 09:04:12 -0700 Message-Id: <200510131604.j9DG4CFZ008472@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ5Yz-0001Vq-Ft cc241068c4a83492b3b5cefa786e9df5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 138] New: UNLOCK_WHAT_URL X-Archived-At: http://www.w3.org/mid/200510131604.j9DG4CFZ008472@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10006 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:04:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=138 Summary: UNLOCK_WHAT_URL Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 06. Locking AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org What do you return if the unlock request specifies a URL on which the lock does not reside� What if it's on a URL that is locked by the lock, but it's not the resource where the lock is rooted? Raised by Juergen Pill: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0086.html Resolved that you can specify any URL locked by the lock you want to unlock: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html We should resolve the issue of UNLOCKing other URLs in a few days. ------- 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 Oct 13 12:07:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5cD-0001OO-Io for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:07:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26038 for ; Thu, 13 Oct 2005 12:07:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5aj-0006Gh-9v for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:06:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5ai-0006G5-VP for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:06:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5ad-0004se-9u for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:06:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DG5sxE008490; Thu, 13 Oct 2005 09:05:54 -0700 Date: Thu, 13 Oct 2005 09:05:54 -0700 Message-Id: <200510131605.j9DG5sxE008490@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ5ad-0004se-9u 326312295261efc0b68c4d84846c1166 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 139] New: MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL X-Archived-At: http://www.w3.org/mid/200510131605.j9DG5sxE008490@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10007 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:06:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=139 Summary: MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Right now the server uses the IF: header to verify that a client knows what locks it has that are affected by an operation before it allows the operation. Must the client provide the root URL of a lock, any URL for a pertainent loc, or some specific URL in the IF: header. Post: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0055.html It is felt by the group that it's important that the client not just own and hold the lock token, but that it also know where the lock is rooted before it does tasks related to that lock. This is just a point of info. The issue itself still needs to be brought up and answered.still ------- 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 Oct 13 12:08:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5dT-0001eH-8y for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:08:51 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26111 for ; Thu, 13 Oct 2005 12:08:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5bx-0006QG-4w for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:07:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5bw-0006Pd-Ip for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:07:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5br-0002Ey-7U for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:07:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DG79Lo008506; Thu, 13 Oct 2005 09:07:09 -0700 Date: Thu, 13 Oct 2005 09:07:09 -0700 Message-Id: <200510131607.j9DG79Lo008506@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.1 X-W3C-Scan-Sig: maggie.w3.org 1EQ5br-0002Ey-7U ea1653739b5ea4d12fddfe4b4b5a5bc2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 140] New: UNLOCK_NEEDS_IF_HEADER X-Archived-At: http://www.w3.org/mid/200510131607.j9DG79Lo008506@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10008 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:07:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=140 Summary: UNLOCK_NEEDS_IF_HEADER Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Shouldn't we be using an IF header to do an UNLOCK seeing as you need to prove you are holding a lock before you can remove it� (This might be contingent on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY) Raised by Dan Brotsky: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html ------- 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 Oct 13 12:17:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5mF-0005gB-02 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:17:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26742 for ; Thu, 13 Oct 2005 12:17:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5kb-0001qk-7c for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:16:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5ka-0001qC-Aw for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:16:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5kK-0007xZ-Ay for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:16:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGFtn3008524; Thu, 13 Oct 2005 09:15:55 -0700 Date: Thu, 13 Oct 2005 09:15:55 -0700 Message-Id: <200510131615.j9DGFtn3008524@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ5kK-0007xZ-Ay ae5a98bcde3c41f02065874fe32dd092 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 141] New: UNLOCK_WITHOUT_GOOD_TOKEN X-Archived-At: http://www.w3.org/mid/200510131615.j9DGFtn3008524@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10009 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:16:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=141 Summary: UNLOCK_WITHOUT_GOOD_TOKEN Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org What should UNLOCK return if a bad token is provided or no token. (This might be contingent on UNLOCK_NEEDS_IF_HEADER.) Raised by Dan Brotsky: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html ------- 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 Oct 13 12:18:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5n2-0005yD-Ij for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:18:46 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26810 for ; Thu, 13 Oct 2005 12:18:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5lW-0001ul-6Q for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:17:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5lS-0001tb-JA for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:17:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5lP-0004Kt-Hi for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:17:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGH2CU008540; Thu, 13 Oct 2005 09:17:02 -0700 Date: Thu, 13 Oct 2005 09:17:02 -0700 Message-Id: <200510131617.j9DGH2CU008540@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ5lP-0004Kt-Hi 67443d695593bccc959ca1377bab3cb4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 142] New: URL_ENCODING_ISSUES X-Archived-At: http://www.w3.org/mid/200510131617.j9DGH2CU008540@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10010 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:17:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=142 Summary: URL_ENCODING_ISSUES Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org We have to resolve some issues involving encoding methods for URIs. The discussion is very involved. Raised by Greg Stein: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0081.html ------- 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 Oct 13 12:20:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5ow-0006ea-FD for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:20:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26962 for ; Thu, 13 Oct 2005 12:20:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5nL-0002BH-UR for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:19:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5nL-0002Ai-F6 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:19:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5nB-0000Lc-1i for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:19:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGIqT3008557; Thu, 13 Oct 2005 09:18:52 -0700 Date: Thu, 13 Oct 2005 09:18:52 -0700 Message-Id: <200510131618.j9DGIqT3008557@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ5nB-0000Lc-1i 8278a07d2f3439c930d5d71a05449746 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 143] New: LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER X-Archived-At: http://www.w3.org/mid/200510131618.j9DGIqT3008557@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10011 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:19:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143 Summary: LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The LOCK renewal request should not us an IF header to specify what lock is being renewed. This limits the use of the IF header. Raised by Dan Brotsky: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0109.html ------- 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 Oct 13 12:21:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5q1-0007bJ-Ex for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:21:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27052 for ; Thu, 13 Oct 2005 12:21:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5oS-0002nN-TB for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:20:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5oS-0002mQ-A1 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:20:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5oL-000528-7l for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:20:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGJwox008573; Thu, 13 Oct 2005 09:19:58 -0700 Date: Thu, 13 Oct 2005 09:19:58 -0700 Message-Id: <200510131619.j9DGJwox008573@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ5oL-000528-7l d15227044fdd928a14c13932471d7cf1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 144] New: IF_HEADER_CHECKS_AFTER_OTHER_CHECKS X-Archived-At: http://www.w3.org/mid/200510131619.j9DGJwox008573@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10012 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:20:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144 Summary: IF_HEADER_CHECKS_AFTER_OTHER_CHECKS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Should we document if the IF header is evaluated before methods specific checks of afterwards. The IF header is said to be modeled after the IF-MATCH header and the documentation for that says that method specific checks should come first. It's not clear if it's feasible to make all method specific checks before checking the IF header. It's also probably easier to implement IF header checks at a common layer of code that is called before the method specific code in many implementations. ------- 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 Oct 13 12:23:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5rn-0000A6-Sl for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:23:39 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27117 for ; Thu, 13 Oct 2005 12:23:35 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5qD-0003Ba-Tr for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:22:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5qD-0003Az-Be for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:22:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5q9-0005Yi-Lq for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:22:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGLuCv008589; Thu, 13 Oct 2005 09:21:56 -0700 Date: Thu, 13 Oct 2005 09:21:56 -0700 Message-Id: <200510131621.j9DGLuCv008589@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ5q9-0005Yi-Lq b47eff5a08c9c9f015be5c2f323a9963 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 145] New: LOCKDISCOVERY_ON_UNLOCKED_RESOURCE X-Archived-At: http://www.w3.org/mid/200510131621.j9DGLuCv008589@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10013 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:22:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=145 Summary: LOCKDISCOVERY_ON_UNLOCKED_RESOURCE Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org If the DAV:lockdiscovery property is requested from an unlocked resource, what is the correct response? Apache mod_dav sends an empty lockdiscovery element () while IIS sends an empty prop element (), that is, it sends no lockdiscovery element at all. Raised by Hartmut Warncke: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0128.html ------- 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 Oct 13 12:24:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5t1-0000mZ-3H for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:24:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27206 for ; Thu, 13 Oct 2005 12:24:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5rW-0003Lo-Th for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:23:22 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5rW-0003Km-GM for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:23:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5rT-0005tS-5x for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:23:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGNIL9008607; Thu, 13 Oct 2005 09:23:18 -0700 Date: Thu, 13 Oct 2005 09:23:18 -0700 Message-Id: <200510131623.j9DGNIL9008607@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ5rT-0005tS-5x a7f88a90316dc6f2ae89f55418c5d235 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 146] New: PROP_ROUNDTRIP X-Archived-At: http://www.w3.org/mid/200510131623.j9DGNIL9008607@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10014 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:23:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=146 Summary: PROP_ROUNDTRIP Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The specification is currently unclear as to how a server should handle the round-trip representation of property information. That is, if a client does a PROPPATCH/PROPFIND pair, what can it expect about the property value that is returned, as compared to the original property value it wrote. Some XML attributes have semantics that would allow a server to return XML that was semantically the same as the original, but was a different sequence of octets than the original. It is also possible that the protocol specification should be silent on this issue. An example of this ambiguity is whitespace. Raised during discussion of the PROP_ATTR issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0047.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0052.html ------- 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 Oct 13 12:26:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5v0-00017y-RN for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:26:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27296 for ; Thu, 13 Oct 2005 12:26:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5tW-00040K-CX for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:25:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5tW-0003zm-0e for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:25:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5tI-0006LW-Jl for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:25:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGPBah008623; Thu, 13 Oct 2005 09:25:11 -0700 Date: Thu, 13 Oct 2005 09:25:11 -0700 Message-Id: <200510131625.j9DGPBah008623@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ5tI-0006LW-Jl 8d86bf263dc7b0cfb9378ab8af7700ca X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 147] New: CLARIFY_UNTAGGED_IF_HEADER_APPLICATION X-Archived-At: http://www.w3.org/mid/200510131625.j9DGPBah008623@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10015 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:25:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147 Summary: CLARIFY_UNTAGGED_IF_HEADER_APPLICATION Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org 2518 says the untagged header should be applied to all resources involved in a request, but that is not defined. There was also a proposal at the SLC IETF meeting to simply the IF header or move it to its own spec. Also a proposal to remove UNTAGGED IF: header support. Raised by Geoff Clemm: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0159.html and IETF meeting: http://www.ietf.org/proceedings/01dec/minutes/WEBDAV.HTM ------- 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 Oct 13 12:29:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5x0-0001U2-3l for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:29:02 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27365 for ; Thu, 13 Oct 2005 12:28:57 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5vQ-0004Fx-Bl for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:27:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5vQ-0004FP-1q for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:27:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5uY-0002gq-Iu for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:27:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGQTEI008640; Thu, 13 Oct 2005 09:26:29 -0700 Date: Thu, 13 Oct 2005 09:26:29 -0700 Message-Id: <200510131626.j9DGQTEI008640@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ5uY-0002gq-Iu 6615b92ed01a1de39a65b42bfaba361e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 148] New: SECTION_12_4_MENTIONS_HREF_ELEMENT X-Archived-At: http://www.w3.org/mid/200510131626.j9DGQTEI008640@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10016 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:27:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=148 Summary: SECTION_12_4_MENTIONS_HREF_ELEMENT Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Section 12.4 talks about an href element when describing the link element. There is no such element defined as a child of link. Fix 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 Thu Oct 13 12:29:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5x8-0001YE-AJ for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:29:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27367 for ; Thu, 13 Oct 2005 12:29:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5ve-0004Hh-1x for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:27:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5vd-0004H6-MH for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:27:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5vY-0006mw-VW for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:27:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGRVuc008656; Thu, 13 Oct 2005 09:27:31 -0700 Date: Thu, 13 Oct 2005 09:27:31 -0700 Message-Id: <200510131627.j9DGRVuc008656@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ5vY-0006mw-VW cf3bfefca56dc3ad333574897beda293 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 149] New: NEW_MULTIPUT_METHOD X-Archived-At: http://www.w3.org/mid/200510131627.j9DGRVuc008656@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10017 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:27:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=149 Summary: NEW_MULTIPUT_METHOD Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Review discussion of October 2001 to see if there is consensus around a MULTIPUT method. Raised by Jim Whitehead: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0094.html ------- 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 Oct 13 12:31:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5zM-0002Zd-Oe for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:31:28 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27444 for ; Thu, 13 Oct 2005 12:31:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5xn-0004bH-A1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:29:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5xn-0004ad-0w for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:29:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ5xh-0003Xj-Gj for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:29:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGTjoA008675; Thu, 13 Oct 2005 09:29:45 -0700 Date: Thu, 13 Oct 2005 09:29:45 -0700 Message-Id: <200510131629.j9DGTjoA008675@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ5xh-0003Xj-Gj 4858fa6a4dde3a060f01d7ec76b212c5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 150] New: SOURCE_PROPERTY_UNDERSPECIFIED X-Archived-At: http://www.w3.org/mid/200510131629.j9DGTjoA008675@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10018 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:29:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=150 Summary: SOURCE_PROPERTY_UNDERSPECIFIED Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The concepts of dynamic resources and the details of the source property are not well defined and to some degree this might be limiting implementation. What is our policy on PUT on a dynamic resource? What/who creates the relationship between the source and the dest� How does a client know how to describe the constituent pieces of source in a UI� Are the src and dst reversed in 2518? What property values does PROPFIND return for a dynamic resource? Can the dav:source property be written by the client? -- There also was a proposal at the SLC IETF meeting to separate the DAV:source property in to it's own spec. See discussion following: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0094.html and a proposal at http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html Almost resolved to remove the dav:source property from the spec to give us a clean slate to work with if we want to add a more completely specified version of that functionality later. It looks like there might be an effort to define it as of 5/13/02. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0099.html -- 8/27/02 still no interoperable implementations. ------- 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 Oct 13 12:32:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ60P-0002dy-5w for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:32:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27494 for ; Thu, 13 Oct 2005 12:32:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ5ys-0006lK-E0 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:30:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ5yr-0006jP-Aq for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:30:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ5ym-0007Ud-HF for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:30:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGUp8L008691; Thu, 13 Oct 2005 09:30:51 -0700 Date: Thu, 13 Oct 2005 09:30:51 -0700 Message-Id: <200510131630.j9DGUp8L008691@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ5ym-0007Ud-HF a85f87c57b90cb1e1dc164c5897fec23 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 151] New: HOW_DO_WE_ENCODE_FILENAMES_AS_URLS X-Archived-At: http://www.w3.org/mid/200510131630.j9DGUp8L008691@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10019 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:30:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=151 Summary: HOW_DO_WE_ENCODE_FILENAMES_AS_URLS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org It has been suggested that WebDAV should define the mapping of external names (file system names for example) to URL encoded names. Raised by Larry Masinter: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0204.html ------- 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 Oct 13 12:34:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ61w-0002kp-59 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:34:08 -0400 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 ; Thu, 13 Oct 2005 12:34:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ60L-0007XY-DV for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:32:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ60K-0007Ww-Tm for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:32:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ609-0007n2-2M for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:32:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGWGxS008707; Thu, 13 Oct 2005 09:32:16 -0700 Date: Thu, 13 Oct 2005 09:32:16 -0700 Message-Id: <200510131632.j9DGWGxS008707@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ609-0007n2-2M 2fecab0b29601f45ccda085a3a7df16b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 152] New: SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT X-Archived-At: http://www.w3.org/mid/200510131632.j9DGWGxS008707@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10020 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:32:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=152 Summary: SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org How should the mimetype of the PUT request affect the mimetype of subsequent GET requests? Should it be remembered� If so, does the last PUT request take priority? Or the first? Or do we leave that unspecified? The solution should include coverage of what kind of resource should get created if one locks an unmapped URL. Raised by Dan Brotsky in the following thread: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0209.html ------- 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 Oct 13 12:35:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ634-00036s-4c for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:35:18 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27601 for ; Thu, 13 Oct 2005 12:35:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ61Y-0007hj-85 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:33:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ61X-0007hB-Vq for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:33:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ61S-0004We-Io for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:33:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGXc8P008724; Thu, 13 Oct 2005 09:33:38 -0700 Date: Thu, 13 Oct 2005 09:33:38 -0700 Message-Id: <200510131633.j9DGXc8P008724@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ61S-0004We-Io e1e3352111cc383bbba4351c674041c5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 153] New: CAN_HREF_BE_RELATIVE X-Archived-At: http://www.w3.org/mid/200510131633.j9DGXc8P008724@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10021 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:33:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=153 Summary: CAN_HREF_BE_RELATIVE Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Can DAV:HREF be a relative URI? If so, can the spec specify what it's relative to? Partially resolved -- Agreed that it can be relative, but no significant discussion on what it is relative to: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0241.html ------- 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 Oct 13 12:36:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ63z-0003EY-Bj for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:36:15 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27636 for ; Thu, 13 Oct 2005 12:36:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ62Q-0007kE-0h for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:34:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ62P-0007jZ-Hc for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:34:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ62J-0004ld-Pg for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:34:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGYVBM008740; Thu, 13 Oct 2005 09:34:31 -0700 Date: Thu, 13 Oct 2005 09:34:31 -0700 Message-Id: <200510131634.j9DGYVBM008740@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ62J-0004ld-Pg dd204903c806986ccead9209d43c4b66 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 154] New: ADD_DEPTH_ZERO_DELETE X-Archived-At: http://www.w3.org/mid/200510131634.j9DGYVBM008740@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10022 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:34:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=154 Summary: ADD_DEPTH_ZERO_DELETE Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org It has been suggested that we should have the ability to delete at depth zero. Suggested by Geoff Clemm et al: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0152.html ------- 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 Oct 13 12: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 1EQ64v-0003Kw-US for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:37:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27698 for ; Thu, 13 Oct 2005 12:37:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ63S-0008Hw-CZ for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:35:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ63S-0008HO-0P for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:35:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ63H-000070-Ub for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:35:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGZSaE008756; Thu, 13 Oct 2005 09:35:28 -0700 Date: Thu, 13 Oct 2005 09:35:28 -0700 Message-Id: <200510131635.j9DGZSaE008756@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ63H-000070-Ub 67a0c27d215e3876075128c38a26429f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 155] New: INTEROPERABILITY_OF_102PROCESSING_STATUS_DEMONSTRATED X-Archived-At: http://www.w3.org/mid/200510131635.j9DGZSaE008756@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10023 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:35:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=155 Summary: INTEROPERABILITY_OF_102PROCESSING_STATUS_DEMONSTRATED Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 11. Use of HTTP Status Codes AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Have we demonstrated interoperability of the '102 Processing' status response code? Discussion begins with: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0169.html ------- 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 Oct 13 12:38:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ66M-0003Si-7D for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:38:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27740 for ; Thu, 13 Oct 2005 12:38:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ64j-00005J-JW for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:37:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ64j-0008WM-4H for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:37:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ64d-0005MD-Kq for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:37:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGatRK008772; Thu, 13 Oct 2005 09:36:55 -0700 Date: Thu, 13 Oct 2005 09:36:55 -0700 Message-Id: <200510131636.j9DGatRK008772@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ64d-0005MD-Kq 6e94b14164efcd7868c2714de827cfda X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 156] New: HOW_ARE_TRAILING_SLASHES_USED X-Archived-At: http://www.w3.org/mid/200510131636.j9DGatRK008772@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10024 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:37:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=156 Summary: HOW_ARE_TRAILING_SLASHES_USED Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org There are all kinds of issues with trailing slashes. Can a client simply add or remove them? Does a server treat two URLs only differing by trailing slashes� Should a server redirect to the preferred URL? http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0201.html ------- 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 Oct 13 12:40:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ67q-00048F-Vv for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:40:15 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27825 for ; Thu, 13 Oct 2005 12:40:10 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ66I-0000Gi-QR for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:38:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ66I-0000FA-Hp for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:38:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ66B-0005tf-D9 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:38:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGcU3G008789; Thu, 13 Oct 2005 09:38:30 -0700 Date: Thu, 13 Oct 2005 09:38:30 -0700 Message-Id: <200510131638.j9DGcU3G008789@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ66B-0005tf-D9 0feb297b4791d3c0fadb63bbb5a9e967 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 157] New: REMOVE_ETAG_SUPPORT_FOR_IF_HEADER X-Archived-At: http://www.w3.org/mid/200510131638.j9DGcU3G008789@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10025 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:38:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=157 Summary: REMOVE_ETAG_SUPPORT_FOR_IF_HEADER Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org It was suggested that we remove the ETAG support in the IF header because it doesn't seem to be used right now (no interop) and the same thing can be achieved via other mechanisms. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0045.html In that thread it seems to be almost resolved that we eliminate the ETAG support from IF: headers in that anyone who cared seemed to prefer removing it, but the discussion got diverted and no final decision was made. Again on http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0081.html but it was actively used in subsequent discussions on the IF: header and strongly advocated there Sept/Oct 2002. ------- 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 Oct 13 12:42:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ69l-0005jp-9x for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:42:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27899 for ; Thu, 13 Oct 2005 12:42:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ68D-0000py-Vr for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:40:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ68D-0000pQ-Jo for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:40:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ683-0001C1-Ir for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:40:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGeQsK008805; Thu, 13 Oct 2005 09:40:26 -0700 Date: Thu, 13 Oct 2005 09:40:26 -0700 Message-Id: <200510131640.j9DGeQsK008805@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ683-0001C1-Ir b666792b93c4725a017e7f921f375e5a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 158] New: SHOULD_WE_SUPPORT_IRIS_AND_CHARMOD X-Archived-At: http://www.w3.org/mid/200510131640.j9DGeQsK008805@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10026 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:40:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=158 Summary: SHOULD_WE_SUPPORT_IRIS_AND_CHARMOD Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 18. Internationalization Considerations AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org There are various recent documents about internationalization of standards. We should see if we're compliant with the IRI (internationalized resource identifiers, draft-durst-iri-00) and charmod and if we're not, what it would take to bring us in to compliance. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0070.html Jason and Lisa have begun reading. IRIs look like they might become a problem. Further reading necessary. ------- 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 Oct 13 12:44:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6C2-0006aF-SX for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:44:35 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28016 for ; Thu, 13 Oct 2005 12:44:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6AY-0001Ff-7b for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:43:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6AX-0001F7-KI for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:43:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ69m-00072j-5g for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:43:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGgDxK008821; Thu, 13 Oct 2005 09:42:13 -0700 Date: Thu, 13 Oct 2005 09:42:13 -0700 Message-Id: <200510131642.j9DGgDxK008821@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ69m-00072j-5g 2fcd8febd485059065434356715bdaa9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 159] New: ORDER_OF_HEADER_EVALUATION X-Archived-At: http://www.w3.org/mid/200510131642.j9DGgDxK008821@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10027 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:43:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=159 Summary: ORDER_OF_HEADER_EVALUATION Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org It was suggested that we require that the authetication and permission information for a request be evaluated before the If: header. This allows one to test if a long operation will succeed by submitting an equivalent shorter one with a false If: header. Summarized by Geoff Clemm: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0369.html ------- 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 Oct 13 12:44:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6CC-0006au-Ec for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:44:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28024 for ; Thu, 13 Oct 2005 12:44:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6Ao-0001I4-M7 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:43:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6Ao-0001H3-6d for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:43:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ6Ad-0007LI-IP for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:43:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGh3Tf008838; Thu, 13 Oct 2005 09:43:03 -0700 Date: Thu, 13 Oct 2005 09:43:03 -0700 Message-Id: <200510131643.j9DGh3Tf008838@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ6Ad-0007LI-IP b435bbc1a122ae64aea0f7c426d95fb7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 160] New: IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/200510131643.j9DGh3Tf008838@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10028 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:43:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=160 Summary: IF_HEADERS_CAN_GET_LONG Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org If headers can become quite long. We need a way to make sure we don't exceed the maximum header length. Geoff Clemm: Point 2 of http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0039.html ------- 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 Oct 13 12:46:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6DP-0006z4-QA for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:46:00 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28099 for ; Thu, 13 Oct 2005 12:45:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6Bq-0001U7-2t for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:44:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6Bp-0001TK-Jm for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:44:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ6Bh-0007g3-A8 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:44:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGiC8v008854; Thu, 13 Oct 2005 09:44:12 -0700 Date: Thu, 13 Oct 2005 09:44:12 -0700 Message-Id: <200510131644.j9DGiC8v008854@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ6Bh-0007g3-A8 2e8ea3db7c8f8eabcdbdf33b729db70a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 161] New: EVALUATE_ALL_OF_IF_HEADER X-Archived-At: http://www.w3.org/mid/200510131644.j9DGiC8v008854@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10029 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:44:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=161 Summary: EVALUATE_ALL_OF_IF_HEADER Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org 2518 says that a server only needs to evaluate the portions of the If: header that it finds appropriate. This underminds the stated primary purpose of the If header: for the client to submit assertions on the request because the server might ignore a few assertions and just go ahead with a request and the client doesn't know if the assertions were evaluated or not. Jason Crawford: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0083.html Approved heartily right after proposed. ------- 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 Oct 13 12:47:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6EP-00076f-BY for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:47:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28132 for ; Thu, 13 Oct 2005 12:46:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6Cv-0002gi-0d for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:45:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6Cu-0002eF-FZ for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:45:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ6Ci-0007y7-4o for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:45:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGjCP5008870; Thu, 13 Oct 2005 09:45:12 -0700 Date: Thu, 13 Oct 2005 09:45:12 -0700 Message-Id: <200510131645.j9DGjCP5008870@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ6Ci-0007y7-4o 39ca794d34b853519acd31f478955405 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 162] New: REMOVE_UNTAGGED_IF_HEADER X-Archived-At: http://www.w3.org/mid/200510131645.j9DGjCP5008870@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10030 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:45:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=162 Summary: REMOVE_UNTAGGED_IF_HEADER Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org It was propose to remove support for untagged IF headers in order to simplify the If: header. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0025.html ------- 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 Oct 13 12:48:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6FY-0007es-Gf for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:48:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28217 for ; Thu, 13 Oct 2005 12:48:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6E4-0003um-5R for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:46:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6E3-0003uE-FI for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:46:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6Dr-0002WZ-7w for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:46:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGkQ4i008886; Thu, 13 Oct 2005 09:46:26 -0700 Date: Thu, 13 Oct 2005 09:46:26 -0700 Message-Id: <200510131646.j9DGkQ4i008886@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ6Dr-0002WZ-7w a18268a88c0963001f2955c5466e2203 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 163] New: REMOVE_NOT_SUPPORT_FROM_IF_HEADERS X-Archived-At: http://www.w3.org/mid/200510131646.j9DGkQ4i008886@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10031 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:46:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=163 Summary: REMOVE_NOT_SUPPORT_FROM_IF_HEADERS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org There doesn't seem to be many (or any?) clients that use the NOT support of the If Header. Thus we have no interop testing. Yet it was mentioned as something that might be helpful to let clients submit lots of lock tokens in discussions on rewriting the IF: header in October 2002. Those discussions are complete as of entry of this issue in this file. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0087.html ------- 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 Oct 13 12:49:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6H1-0008BO-Q4 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:49:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28300 for ; Thu, 13 Oct 2005 12:49:36 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6FP-0004E0-Fq for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:48:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6FP-0004D3-1j for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:48:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6FK-0002s5-GK for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:48:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGluaY008903; Thu, 13 Oct 2005 09:47:56 -0700 Date: Thu, 13 Oct 2005 09:47:56 -0700 Message-Id: <200510131647.j9DGluaY008903@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ6FK-0002s5-GK 484583617447b22aec1b6cf5e9a16019 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 164] New: HOW_DOES_WEBDAV_SUPPORT_VARIANTS X-Archived-At: http://www.w3.org/mid/200510131647.j9DGluaY008903@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10032 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:48:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=164 Summary: HOW_DOES_WEBDAV_SUPPORT_VARIANTS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org How does WebDAV support variants? A discussion thread was started. Let's not forget about it. WHERE? ------- 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 Oct 13 12:51:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6IS-00006D-5M for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:51:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28355 for ; Thu, 13 Oct 2005 12:51:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6Gt-0004SR-Aq for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:49:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6Gt-0004Rt-1v for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:49:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ6GP-0000lq-Ot for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:49:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGn5jM008919; Thu, 13 Oct 2005 09:49:05 -0700 Date: Thu, 13 Oct 2005 09:49:05 -0700 Message-Id: <200510131649.j9DGn5jM008919@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ6GP-0000lq-Ot 6e8f69c4bfd10909cfe0159fb62bc791 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 165] New: DAV_ERROR_SUPPORT X-Archived-At: http://www.w3.org/mid/200510131649.j9DGn5jM008919@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10033 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:49:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=165 Summary: DAV_ERROR_SUPPORT Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org It was suggested that 2518 adopt the DAV:error support that the WebDAV versioning spec (rfc3253) supports. See that spec and search on 'error' and 'must-be'. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0114.html ------- 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 Oct 13 12:53:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6Kk-0000Mt-8l for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:53:34 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28440 for ; Thu, 13 Oct 2005 12:53:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6JE-00052V-5i for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:52:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6JD-00051s-P4 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:51:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6JA-0003gB-JC for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:51:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGptfJ008938; Thu, 13 Oct 2005 09:51:55 -0700 Date: Thu, 13 Oct 2005 09:51:55 -0700 Message-Id: <200510131651.j9DGptfJ008938@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ6JA-0003gB-JC feae588ab6d16a26d6f30e6743ac89b1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 166] New: XML_GUIDELINES_CONFORMANCE X-Archived-At: http://www.w3.org/mid/200510131651.j9DGptfJ008938@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10034 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:52:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=166 Summary: XML_GUIDELINES_CONFORMANCE Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org The IESG has approved the Internet-Draft 'Guidelines for The Use of XML within IETF Protocols' as a BCP. This has been reviewed in the IETF but is not the product of an IETF Working Group. We need to evaluate if we are in compliance with these guidelines. ------- 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 Oct 13 12:54:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6Lg-0000YY-NQ for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:54:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28471 for ; Thu, 13 Oct 2005 12:54:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6KD-00054H-F3 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 16:53:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6KD-00053i-2L for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 16:53:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6K9-0003rF-R1 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 16:53:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DGqv2x008955; Thu, 13 Oct 2005 09:52:57 -0700 Date: Thu, 13 Oct 2005 09:52:57 -0700 Message-Id: <200510131652.j9DGqv2x008955@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ6K9-0003rF-R1 8a78478cc170877a8582f3b67c3a0119 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 167] New: XML_ENTITY_DOS X-Archived-At: http://www.w3.org/mid/200510131652.j9DGqv2x008955@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10035 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 16:53:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=167 Summary: XML_ENTITY_DOS Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 19. Security Considerations AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org Recursive entity declarations can be used for effective DOS attacks, and thus WebDAV MUST allow servers to reject these kind of requests, even though they may be well-formed). http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0402.html ------- 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 Oct 13 13:28:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6si-0002WT-G3 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:28:40 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00149 for ; Thu, 13 Oct 2005 13:28:34 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6qa-0006Uh-Gw for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:26:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6qY-0006U1-Vy for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:26:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6qM-0002DJ-OG for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:26:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHQBnV009114; Thu, 13 Oct 2005 10:26:11 -0700 Date: Thu, 13 Oct 2005 10:26:11 -0700 Message-Id: <200510131726.j9DHQBnV009114@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ6qM-0002DJ-OG 0247ff2cdd3dfc4a119c09e42e4f53d8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 8] Section 9.1: extend production X-Archived-At: http://www.w3.org/mid/200510131726.j9DHQBnV009114@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10036 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:26:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=8 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |trivial ------- 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 Oct 13 13:30:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6uI-0003RW-5J for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:30:18 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00312 for ; Thu, 13 Oct 2005 13:30:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6sk-0006hV-JV for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:28:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6sk-0006gx-6x for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:28:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6sZ-0002gG-D2 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:28:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHSHj6009174; Thu, 13 Oct 2005 10:28:17 -0700 Date: Thu, 13 Oct 2005 10:28:17 -0700 Message-Id: <200510131728.j9DHSHj6009174@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ6sZ-0002gG-D2 8655976e50e5e8b6dc3134e2a3f92452 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/200510131728.j9DHSHj6009174@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10037 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:28:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.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 Thu Oct 13 13:30:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6ua-0003ar-Ox for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:30:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00336 for ; Thu, 13 Oct 2005 13:30:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6tB-0006k0-1H for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:29:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6tA-0006jN-JZ for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:29:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6t2-0002lt-C2 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:29:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHSgN2009195; Thu, 13 Oct 2005 10:28:42 -0700 Date: Thu, 13 Oct 2005 10:28:42 -0700 Message-Id: <200510131728.j9DHSgN2009195@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EQ6t2-0002lt-C2 67ded355271f10461986f0bae6486dd2 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/200510131728.j9DHSgN2009195@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10038 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:29:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=6 julian.reschke@greenbytes.de 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 Thu Oct 13 13:30:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6ut-0003ey-EJ for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:30:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00368 for ; Thu, 13 Oct 2005 13:30:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6tM-0006lP-UY for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:29:20 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6tM-0006km-HT for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 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 1EQ6tA-0002rB-Kx for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:29:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHT1mj009221; Thu, 13 Oct 2005 10:29:01 -0700 Date: Thu, 13 Oct 2005 10:29:01 -0700 Message-Id: <200510131729.j9DHT1mj009221@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ6tA-0002rB-Kx 8fc4f71f65f0a3b0e7f813e4445bb746 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 7] Example for PROPFIND/allprop missing X-Archived-At: http://www.w3.org/mid/200510131729.j9DHT1mj009221@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10039 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:29:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=7 julian.reschke@greenbytes.de 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 Thu Oct 13 13:33:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6wy-0003wK-EP for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:33:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00531 for ; Thu, 13 Oct 2005 13:32:59 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6vS-0000lL-Bu for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:31:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6vS-0000kn-2F for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:31:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ6v2-0003yk-DN for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:31:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHV3SV009259; Thu, 13 Oct 2005 10:31:03 -0700 Date: Thu, 13 Oct 2005 10:31:03 -0700 Message-Id: <200510131731.j9DHV3SV009259@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.2 X-W3C-Scan-Sig: lisa.w3.org 1EQ6v2-0003yk-DN a617f3be59633e5262a7fb92676b7605 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/200510131731.j9DHV3SV009259@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10040 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:31:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Severity|normal |minor ------- 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 Oct 13 13:34:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ6yX-00049L-5C for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:34:41 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00666 for ; Thu, 13 Oct 2005 13:34:35 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6wx-0000vI-B6 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:33:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6ww-0000uj-VG for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:33:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6wm-0003qy-Ps for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:32:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHWnFx009282; Thu, 13 Oct 2005 10:32:49 -0700 Date: Thu, 13 Oct 2005 10:32:49 -0700 Message-Id: <200510131732.j9DHWnFx009282@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ6wm-0003qy-Ps 663da73321418fa192701aa3a422522c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200510131732.j9DHWnFx009282@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10041 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:33:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- 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 Oct 13 13: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 1EQ710-0004Qo-Gy for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:37:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00861 for ; Thu, 13 Oct 2005 13:37:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6zR-0001VX-Ry for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:35:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6zR-0001Uh-Fi for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:35:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ6zG-0004Sa-2N for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:35:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHZO5N009338; Thu, 13 Oct 2005 10:35:24 -0700 Date: Thu, 13 Oct 2005 10:35:24 -0700 Message-Id: <200510131735.j9DHZO5N009338@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ6zG-0004Sa-2N cc993d408cdd4e5aebe27636c345747e 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/200510131735.j9DHZO5N009338@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10042 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:35:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 julian.reschke@greenbytes.de 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 Thu Oct 13 13: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 1EQ710-0004Qn-Gp for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:37:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00860 for ; Thu, 13 Oct 2005 13:37:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ6zU-0001WI-SJ for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:35:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ6zU-0001Vk-J0 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:35:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ6y8-0004vz-S0 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:35:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHYGjG009314; Thu, 13 Oct 2005 10:34:16 -0700 Date: Thu, 13 Oct 2005 10:34:16 -0700 Message-Id: <200510131734.j9DHYGjG009314@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 1EQ6y8-0004vz-S0 ea601092b2171c9284048c92713e33e8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 13] new ETag requirements X-Archived-At: http://www.w3.org/mid/200510131734.j9DHYGjG009314@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10043 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:35:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 julian.reschke@greenbytes.de 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 Thu Oct 13 13:38:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ71w-0004c5-Gi for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:38:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00923 for ; Thu, 13 Oct 2005 13:38:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ70R-0001aA-Jf for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:36:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ70R-0001ZX-7W for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:36:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ70N-0004jQ-Pk for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:36:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHaZur009362; Thu, 13 Oct 2005 10:36:35 -0700 Date: Thu, 13 Oct 2005 10:36:35 -0700 Message-Id: <200510131736.j9DHaZur009362@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ70N-0004jQ-Pk 0b20dcd7da44d7a63120e50e041c4aae 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/200510131736.j9DHaZur009362@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10044 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:36:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor ------- 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 Oct 13 13:39:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ734-0005BM-8r for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:39:22 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01028 for ; Thu, 13 Oct 2005 13:39:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ71V-0002mh-SL for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:37:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ71V-0002m9-Bd for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:37:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ716-0005jr-4R for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:37:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHbJxP009388; Thu, 13 Oct 2005 10:37:19 -0700 Date: Thu, 13 Oct 2005 10:37:19 -0700 Message-Id: <200510131737.j9DHbJxP009388@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 1EQ716-0005jr-4R ddd11049a3a4222b8458c06d26d1409f 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/200510131737.j9DHbJxP009388@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10045 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:37:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 julian.reschke@greenbytes.de 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 Thu Oct 13 13:39:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ73E-0005C7-HI for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:39:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01045 for ; Thu, 13 Oct 2005 13:39:27 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ71m-0002pR-Qb for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:38:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ71m-0002ot-EK for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:38:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ71d-0004zd-6L for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:38:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHbqeO009411; Thu, 13 Oct 2005 10:37:52 -0700 Date: Thu, 13 Oct 2005 10:37:52 -0700 Message-Id: <200510131737.j9DHbqeO009411@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ71d-0004zd-6L 14682cf57e02945d565a5662a0324fa6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/200510131737.j9DHbqeO009411@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10046 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:38:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=17 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |trivial 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 Thu Oct 13 13: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 1EQ74M-0005ru-C1 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:40:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01119 for ; Thu, 13 Oct 2005 13:40:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ72n-00033Y-Md for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:39:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ72n-000330-Di for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:39:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ72k-0006IL-AB for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:39:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHd29U009447; Thu, 13 Oct 2005 10:39:02 -0700 Date: Thu, 13 Oct 2005 10:39:02 -0700 Message-Id: <200510131739.j9DHd29U009447@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 1EQ72k-0006IL-AB 3372169abada37e30a68894f142f2514 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/200510131739.j9DHd29U009447@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10047 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:39:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=17 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |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 Thu Oct 13 13:40:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ74W-0005sL-DR for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:40:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01131 for ; Thu, 13 Oct 2005 13:40:47 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ731-00034T-Rf for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:39:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ731-00033p-Bi for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:39:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ72y-0006O2-QY for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:39:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHdGVX009463; Thu, 13 Oct 2005 10:39:16 -0700 Date: Thu, 13 Oct 2005 10:39:16 -0700 Message-Id: <200510131739.j9DHdGVX009463@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 1EQ72y-0006O2-QY 33936a8df9dae7bf0a0601263b1ddfa5 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/200510131739.j9DHdGVX009463@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10048 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:39:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 julian.reschke@greenbytes.de 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 Thu Oct 13 13:42:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ75s-00067K-KG for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:42:16 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01218 for ; Thu, 13 Oct 2005 13:42:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ74P-0003oZ-BE for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:40:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ74O-0003o1-Um for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:40:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ74K-0005an-Lc for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:40:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHeeXp009497; Thu, 13 Oct 2005 10:40:40 -0700 Date: Thu, 13 Oct 2005 10:40:40 -0700 Message-Id: <200510131740.j9DHeeXp009497@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ74K-0005an-Lc 8adc670dc4ceb2419ddf221fc74920c1 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/200510131740.j9DHeeXp009497@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10050 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:40:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 julian.reschke@greenbytes.de 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 Thu Oct 13 13:42:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ75s-00067L-MO for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:42:16 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01217 for ; Thu, 13 Oct 2005 13:42:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ74K-0003nY-US for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:40:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ74K-0003n0-FG for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:40:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ748-0006lD-RE for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:40:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHeSRP009479; Thu, 13 Oct 2005 10:40:28 -0700 Date: Thu, 13 Oct 2005 10:40:28 -0700 Message-Id: <200510131740.j9DHeSRP009479@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 1EQ748-0006lD-RE ad03f58ef5664b44f5286a0a156a89f8 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/200510131740.j9DHeSRP009479@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10049 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:40:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 julian.reschke@greenbytes.de 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 Thu Oct 13 13:43:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ76p-0006H0-5O for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:43:15 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01267 for ; Thu, 13 Oct 2005 13:43:10 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ75J-0003uK-8E for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:41:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ75I-0003tm-Lh for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:41:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ759-0005mG-N9 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:41:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHfV22009517; Thu, 13 Oct 2005 10:41:31 -0700 Date: Thu, 13 Oct 2005 10:41:31 -0700 Message-Id: <200510131741.j9DHfV22009517@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ759-0005mG-N9 b4b91b3f9305ca8af4c55b4cda00c886 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200510131741.j9DHfV22009517@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10051 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:41:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor 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 Thu Oct 13 13:43:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ76z-0006Ji-8b for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:43:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01289 for ; Thu, 13 Oct 2005 13:43:20 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ75W-00044G-Am for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:41:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ75V-00043R-Ew for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:41:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ75M-0005oZ-VO for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:41:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHfi4T009531; Thu, 13 Oct 2005 10:41:44 -0700 Date: Thu, 13 Oct 2005 10:41:44 -0700 Message-Id: <200510131741.j9DHfi4T009531@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ75M-0005oZ-VO 0094484eb51f3135e165296db60a4967 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200510131741.j9DHfi4T009531@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10052 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:41:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 julian.reschke@greenbytes.de 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 Thu Oct 13 13:44:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ78R-0006f7-B5 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:44:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01347 for ; Thu, 13 Oct 2005 13:44:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ76q-0004bc-T7 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:43:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ76q-0004b1-Dr for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:43:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ76j-0007XE-JJ for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:43:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHh9BQ009570; Thu, 13 Oct 2005 10:43:09 -0700 Date: Thu, 13 Oct 2005 10:43:09 -0700 Message-Id: <200510131743.j9DHh9BQ009570@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 1EQ76j-0007XE-JJ 0c92bb48a8f2efbb913395627c93bbf7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200510131743.j9DHh9BQ009570@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10053 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:43:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.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 Thu Oct 13 13: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 1EQ79B-0006ta-VY for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:45:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01425 for ; Thu, 13 Oct 2005 13:45:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ77f-0004in-EA for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:44:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ77e-0004iA-V4 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:44:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ77b-0007lw-8i for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:44:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHi3in009596; Thu, 13 Oct 2005 10:44:03 -0700 Date: Thu, 13 Oct 2005 10:44:03 -0700 Message-Id: <200510131744.j9DHi3in009596@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 1EQ77b-0007lw-8i 0985a9afa08bd692dbd2b5e52c5928f5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 22] attributes on properties X-Archived-At: http://www.w3.org/mid/200510131744.j9DHi3in009596@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10054 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:44:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=22 julian.reschke@greenbytes.de 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 Thu Oct 13 13: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 1EQ79J-0006vK-P5 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:45:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01434 for ; Thu, 13 Oct 2005 13:45:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ77z-0004r9-7l for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:44:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ77y-0004qZ-Oa for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:44:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ77w-0007s4-9h for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:44:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHiOCC009622; Thu, 13 Oct 2005 10:44:24 -0700 Date: Thu, 13 Oct 2005 10:44:24 -0700 Message-Id: <200510131744.j9DHiOCC009622@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 1EQ77w-0007s4-9h bc48ff8da4989d74411695ad100f0605 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 20] lock token example X-Archived-At: http://www.w3.org/mid/200510131744.j9DHiOCC009622@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10055 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:44:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.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 Thu Oct 13 13:48:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Bd-00011H-Nd for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:48:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01605 for ; Thu, 13 Oct 2005 13:48:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7A7-0007Qw-Cd for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:46:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7A6-0007QO-Sq for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:46:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7A4-00006o-2C for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:46:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHkZso009648; Thu, 13 Oct 2005 10:46:35 -0700 Date: Thu, 13 Oct 2005 10:46:35 -0700 Message-Id: <200510131746.j9DHkZso009648@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 1EQ7A4-00006o-2C ccdf066eb3dcdd68857d587c75f0b425 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200510131746.j9DHkZso009648@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10056 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:46:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major 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 Thu Oct 13 13:48:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Bm-00011m-LO for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:48:22 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01620 for ; Thu, 13 Oct 2005 13:48:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7AS-0007SX-LL for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:47:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7AS-0007Rw-B3 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:47:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7AQ-0000ED-4m for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:47:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHkv3q009670; Thu, 13 Oct 2005 10:46:57 -0700 Date: Thu, 13 Oct 2005 10:46:57 -0700 Message-Id: <200510131746.j9DHkv3q009670@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 1EQ7AQ-0000ED-4m 8a489078a80316aa45e46f515ea73ae6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200510131746.j9DHkv3q009670@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10057 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:47:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- 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 Thu Oct 13 13:50:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Da-0001IP-EV for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:50:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01684 for ; Thu, 13 Oct 2005 13:50:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7C5-0007oU-LR for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:48:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7C5-0007nr-8b for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:48:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7C0-0007Th-KB for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:48:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHmaiD009697; Thu, 13 Oct 2005 10:48:36 -0700 Date: Thu, 13 Oct 2005 10:48:36 -0700 Message-Id: <200510131748.j9DHmaiD009697@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7C0-0007Th-KB 0b588eceec344cdf6ad0b5b2c06e1ce4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/200510131748.j9DHmaiD009697@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10058 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:48:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=24 lisa@osafoundation.org 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 Thu Oct 13 13:50:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7EG-0001NH-Ow for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:50:57 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01757 for ; Thu, 13 Oct 2005 13:50:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7Ck-0007vc-IN for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:49:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7Ck-0007v4-9V for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:49:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7Ca-0000or-JJ for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:49:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHnC6w009723; Thu, 13 Oct 2005 10:49:12 -0700 Date: Thu, 13 Oct 2005 10:49:12 -0700 Message-Id: <200510131749.j9DHnC6w009723@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 1EQ7Ca-0000or-JJ 7477bd19d8e68937b502e3d4718491d0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/200510131749.j9DHnC6w009723@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10059 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:49:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=24 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-10-13 10:49 ------- Todo: be more specific about how this doesn't make the two operations atomic and propose to list. ------- 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 Thu Oct 13 13:51:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Eo-0001Pq-9a for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:51:30 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01806 for ; Thu, 13 Oct 2005 13:51:25 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7DH-00081a-EC for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:49:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7DG-000812-Sb for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:49:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7Cy-0000vv-7i for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:49:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHna9c009737; Thu, 13 Oct 2005 10:49:36 -0700 Date: Thu, 13 Oct 2005 10:49:36 -0700 Message-Id: <200510131749.j9DHna9c009737@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 1EQ7Cy-0000vv-7i 3502ae598c548a611db219efd8a242be X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 25] lock to unmapped URL X-Archived-At: http://www.w3.org/mid/200510131749.j9DHna9c009737@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10060 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:49:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=25 julian.reschke@greenbytes.de 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 Thu Oct 13 13:52:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Fu-0001Xk-RC for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:52:38 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01844 for ; Thu, 13 Oct 2005 13:52:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7EO-0000BC-IP for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:51:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7EO-0000AX-8o for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:51:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7E8-0001GO-NQ for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:51:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHomDw009759; Thu, 13 Oct 2005 10:50:48 -0700 Date: Thu, 13 Oct 2005 10:50:48 -0700 Message-Id: <200510131750.j9DHomDw009759@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 1EQ7E8-0001GO-NQ 715f8b062af70ea44c4b1c03a5773671 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/200510131750.j9DHomDw009759@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10061 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:51:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor ------- 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 Thu Oct 13 13:54:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7He-00024X-Sw for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:54:26 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02000 for ; Thu, 13 Oct 2005 13:54:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7G9-0000M7-Vc for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:52:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7G9-0000LT-JB for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:52:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7G4-0008Qm-Ll for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:52:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHqdat009779; Thu, 13 Oct 2005 10:52:39 -0700 Date: Thu, 13 Oct 2005 10:52:39 -0700 Message-Id: <200510131752.j9DHqdat009779@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7G4-0008Qm-Ll 0203e5909209b8e924206f27332fc2df X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/200510131752.j9DHqdat009779@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10062 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:52:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26 julian.reschke@greenbytes.de 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 Thu Oct 13 13:54:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Hn-00026Q-Vu for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:54:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02037 for ; Thu, 13 Oct 2005 13:54:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7GR-0000OX-BM for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:53:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7GQ-0000Nz-VR for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:53:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7GL-0008Ut-3G for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:53:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHqrMv009794; Thu, 13 Oct 2005 10:52:53 -0700 Date: Thu, 13 Oct 2005 10:52:53 -0700 Message-Id: <200510131752.j9DHqrMv009794@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7GL-0008Ut-3G aa90295f79a9de0840bda0857915c576 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/200510131752.j9DHqrMv009794@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10063 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:53:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- 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 Thu Oct 13 13:55:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Im-0002L5-0g for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:55:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02130 for ; Thu, 13 Oct 2005 13:55:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7HH-0000Ws-Kv for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:54:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7HH-0000WD-8R for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:54:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7H8-0000G4-90 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:54:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHrhk2009820; Thu, 13 Oct 2005 10:53:43 -0700 Date: Thu, 13 Oct 2005 10:53:43 -0700 Message-Id: <200510131753.j9DHrhk2009820@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7H8-0000G4-90 adbd1c921ae86773b50f6dfd0a2cc6ef X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200510131753.j9DHrhk2009820@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10064 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:54:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 julian.reschke@greenbytes.de 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 Thu Oct 13 13:56:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Jq-0002d8-AK for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:56:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02234 for ; Thu, 13 Oct 2005 13:56:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7IJ-00014V-HV for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:55:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7IJ-00013x-53 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:55:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7IE-0000Yv-T2 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:55:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHsveh009860; Thu, 13 Oct 2005 10:54:57 -0700 Date: Thu, 13 Oct 2005 10:54:57 -0700 Message-Id: <200510131754.j9DHsveh009860@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7IE-0000Yv-T2 e710d1f5ab2a3e92f1f7a42a8bfd5104 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 29] refreshing locks X-Archived-At: http://www.w3.org/mid/200510131754.j9DHsveh009860@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10065 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:55:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=29 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-10-13 10:54 ------- what I will do: review changes carefully and accept them and post to list ------- 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 Thu Oct 13 13:56:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Jt-0002dN-9E for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:56:45 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02239 for ; Thu, 13 Oct 2005 13:56:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7IQ-00016L-HC for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:55:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7IQ-00015n-83 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:55:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7IC-0002Aa-QJ for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:55:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHt0M5009875; Thu, 13 Oct 2005 10:55:00 -0700 Date: Thu, 13 Oct 2005 10:55:00 -0700 Message-Id: <200510131755.j9DHt0M5009875@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 1EQ7IC-0002Aa-QJ fd651aea072ba9372c97458a368c82df X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 30] incorrect XML in example X-Archived-At: http://www.w3.org/mid/200510131755.j9DHt0M5009875@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10066 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:55:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=30 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor ------- 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 Thu Oct 13 13:58:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Ls-0003Ly-8a for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:58:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02409 for ; Thu, 13 Oct 2005 13:58:43 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7KM-0001bq-45 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:57:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7KL-0001bI-O4 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:57:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7KD-00014j-NY for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:57:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHv428009909; Thu, 13 Oct 2005 10:57:04 -0700 Date: Thu, 13 Oct 2005 10:57:04 -0700 Message-Id: <200510131757.j9DHv428009909@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7KD-00014j-NY 7c93e9cb1aca524074f3d8ac022f5c4e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 30] incorrect XML in example X-Archived-At: http://www.w3.org/mid/200510131757.j9DHv428009909@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10067 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:57:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=30 lisa@osafoundation.org 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 Thu Oct 13 13:59:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Mb-0003Sa-9c for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:59:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02456 for ; Thu, 13 Oct 2005 13:59:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7L6-0001l0-1q for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:58:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7L5-0001kN-LD for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:57:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7Ku-0001FP-Hw for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:57:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHvlJa009939; Thu, 13 Oct 2005 10:57:47 -0700 Date: Thu, 13 Oct 2005 10:57:47 -0700 Message-Id: <200510131757.j9DHvlJa009939@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7Ku-0001FP-Hw b60d81b578718bf6222f518b33c8144d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 32] DAV:displayname handling X-Archived-At: http://www.w3.org/mid/200510131757.j9DHvlJa009939@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10068 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:58:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=32 julian.reschke@greenbytes.de 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 Thu Oct 13 13: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 1EQ7Mi-0003UD-2S for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:59:40 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02460 for ; Thu, 13 Oct 2005 13:59:35 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7LF-0001mJ-Os for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:58:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7LF-0001lZ-5p for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:58:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7LC-0001Il-60 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:58:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHw51i009968; Thu, 13 Oct 2005 10:58:05 -0700 Date: Thu, 13 Oct 2005 10:58:05 -0700 Message-Id: <200510131758.j9DHw51i009968@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7LC-0001Il-60 1ec2c0f7e44c96a5e8d036e80681a2d3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 34] property "URI" X-Archived-At: http://www.w3.org/mid/200510131758.j9DHw51i009968@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10069 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:58:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=34 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor 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 Thu Oct 13 13:59:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Mu-0003an-95 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:59:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02477 for ; Thu, 13 Oct 2005 13:59:47 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7LY-0001v9-8q for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 17:58:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7LX-0001ub-RW for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 17:58:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7LP-0001Lj-7q for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 17:58:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHwIe1009982; Thu, 13 Oct 2005 10:58:18 -0700 Date: Thu, 13 Oct 2005 10:58:18 -0700 Message-Id: <200510131758.j9DHwIe1009982@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7LP-0001Lj-7q 4a6c644bf8eda599b1d1a30f6ae18739 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 34] property "URI" X-Archived-At: http://www.w3.org/mid/200510131758.j9DHwIe1009982@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10070 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 17:58:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=34 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- 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 Thu Oct 13 14:02:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7P2-00046j-1c for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 14:02:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02582 for ; Thu, 13 Oct 2005 14:01:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7NJ-0003lt-Ls for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 18:00:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7NJ-0003ib-3w for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 18:00:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7Ly-0003J9-6R for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 18:00:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DHwsnw010004; Thu, 13 Oct 2005 10:58:54 -0700 Date: Thu, 13 Oct 2005 10:58:54 -0700 Message-Id: <200510131758.j9DHwsnw010004@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 1EQ7Ly-0003J9-6R 9fac72c01d2d02e51fae2180afcbb5ac X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 34] property "URI" X-Archived-At: http://www.w3.org/mid/200510131758.j9DHwsnw010004@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10071 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 18:00:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=34 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|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 Thu Oct 13 14:02:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7PB-00049i-P4 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 14:02:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02589 for ; Thu, 13 Oct 2005 14:02:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7Nh-0004ey-Uo for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 18:00:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7Nh-0004eL-ID for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 18:00:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7Nb-0001tM-S4 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 18:00:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DI0ZHT010047; Thu, 13 Oct 2005 11:00:35 -0700 Date: Thu, 13 Oct 2005 11:00:35 -0700 Message-Id: <200510131800.j9DI0ZHT010047@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7Nb-0001tM-S4 47f9fdf7455deca53d99083288814679 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 36] Appendix numbering X-Archived-At: http://www.w3.org/mid/200510131800.j9DI0ZHT010047@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10072 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 18:00:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=36 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-10-13 11:00 ------- It appears I put the appendix number explicitly in the XML -- I should remove that. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Thu Oct 13 14:03:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7QH-0004VG-A4 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 14:03:21 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02684 for ; Thu, 13 Oct 2005 14:03:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7Ol-0004sg-Lm for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 18:01:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7Ol-0004s8-CS for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 18:01:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7Nt-0003pP-Tm for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 18:01:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DI0rce010069; Thu, 13 Oct 2005 11:00:53 -0700 Date: Thu, 13 Oct 2005 11:00:53 -0700 Message-Id: <200510131800.j9DI0rce010069@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 1EQ7Nt-0003pP-Tm f2d8024d60432f3b2f9183c28910dea6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 36] Appendix numbering X-Archived-At: http://www.w3.org/mid/200510131800.j9DI0rce010069@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10073 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 18:01:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=36 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- 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 Thu Oct 13 14:08:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7V4-0006OR-2S for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 14:08:18 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03097 for ; Thu, 13 Oct 2005 14:08:12 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7TR-0006JS-Ry for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 18:06:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7TR-0006ID-FX for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 18:06:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7TK-0003Le-3t for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 18:06:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DI6Ss7010129; Thu, 13 Oct 2005 11:06:28 -0700 Date: Thu, 13 Oct 2005 11:06:28 -0700 Message-Id: <200510131806.j9DI6Ss7010129@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7TK-0003Le-3t 215bdeb66dafacb0d70a9dce7395b438 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200510131806.j9DI6Ss7010129@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10075 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 18:06:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- 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 Thu Oct 13 14:08:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7V4-0006Od-BW for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 14:08:18 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03098 for ; Thu, 13 Oct 2005 14:08:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7TM-0006HL-Rv for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 18:06:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7TM-0006Gb-8C for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 18:06:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7T9-0003IW-ET for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 18:06:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DI6FKC010113; Thu, 13 Oct 2005 11:06:15 -0700 Date: Thu, 13 Oct 2005 11:06:15 -0700 Message-Id: <200510131806.j9DI6FKC010113@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ7T9-0003IW-ET 9f98ee35c8d15dac4852af880d0f888d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200510131806.j9DI6FKC010113@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10074 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 18:06:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 julian.reschke@greenbytes.de 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 Thu Oct 13 14:12:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7Z3-0000CQ-V3 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 14:12:26 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03362 for ; Thu, 13 Oct 2005 14:12:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7XT-0007CR-7e for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 18:10:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7XS-0007Bt-Rp for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 18:10:46 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ7XO-0006s4-1R for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 18:10:46 +0000 Received: from [127.0.0.1] (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 j9DIAe7r015572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Oct 2005 11:10:40 -0700 (PDT) Message-ID: <434EA31F.9060906@cse.ucsc.edu> Date: Thu, 13 Oct 2005 11:10:39 -0700 From: Elias Sinderson Reply-To: WebDav 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 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 1EQ7XO-0006s4-1R ea15df78ca705bcc8a57129c7e026171 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/434EA31F.9060906@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10076 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 18:10:47 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: >Elias kindly volunteered to collect all the know issues and put them in bugzilla. > I've added all of the 'open' issues listed at -- TBD how to handle issues marked as 'edit', 'InBis', '2518bis', 'Version2', or 'closed'. >He is going to tell us how he will mark in bugzilla two different states. One state is when the WG agrees on general way to resolved the issue but has not updated drafts yet or figured out exact text, and other state is >when the actual text has been put into the draft. > > I actually see a need for more than two states: New, Assigned (accepted by WG for discussion), Resolved (some resolution reached on the list, editorial or otherwise), Closed (resolution is in current draft). Comments? Cheers, Elias From w3c-dist-auth-request@frink.w3.org Thu Oct 13 14:32:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7sB-0005yN-GX for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 14:32:15 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04208 for ; Thu, 13 Oct 2005 14:32:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ7qB-0003xq-9s for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 18:30:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ7q9-0003mY-Nj; Thu, 13 Oct 2005 18:30:05 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ7q4-0008Fr-PO; Thu, 13 Oct 2005 18:30:05 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B8CFA1422A0; Thu, 13 Oct 2005 11:29:55 -0700 (PDT) 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 12416-05; Thu, 13 Oct 2005 11:29:55 -0700 (PDT) Received: from [192.168.101.91] (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 31BB014229A; Thu, 13 Oct 2005 11:29:55 -0700 (PDT) In-Reply-To: <434D0DC0.2030800@gmx.de> References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Thu, 13 Oct 2005 11:29:53 -0700 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.4 X-W3C-Scan-Sig: maggie.w3.org 1EQ7q4-0008Fr-PO 5fc52bc50ea3f50f3384756110fcc23a X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10077 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 18:30:07 +0000 Content-Transfer-Encoding: 7bit There are some language changes proposed by Julian that I'm OK with, but it's clear we're thinking a little differently about whitespace -- read down a bit for that discussion and questions for client and server implementors. On Oct 12, 2005, at 6:21 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> That works for me, unless more feedback from implementors comes up >> quite different. >> Based on Julian's rewriting plus the discussion so far, here's some >> proposed wording: >> The value of a property appears inside the property name element. The >> value >> can be any kind of well-formed XML content: element content, text or >> mixed >> content. When the property value contains element or mixed content, >> namespaces that are in scope for that part of the XML document apply >> within >> the property value as well, and servers MUST preserve namespaces in >> server > > s/namespaces/namespace names/ Sure. > >> storage for retransmission later. The server MAY preserve namespace >> prefixes >> and non-significant whitespace. > > 1. Of course it *may* preserve namespace prefixes. I think this needs > to be rephrased the other way around: clients MUST NOT rely on > prefixes being preserved since some servers won't do that. I don't mind either way of wording this. > > 2. I don't understand the part about non-significant whitespace. Why > was it introduced, and what issue does that resolve???? First assumption: that there is non-significant whitespace, based on reading the XML recommendation For example, if my property name value in PROPPATCH request is Then in this case, I believe all line returns and tabs introduced here are non-significant. Second assumption: that a server might strip non-significant whitespace either at the beginning or end of the property value if it's a XML value. So a server could return in a PROPFIND response: (Conversely, a server could *add* whitespace in the locations I just removed whitespace.) Third assumption/evaluation: that a server might reasonably strip non-significant whitespace in the *middle* of an XML property value. So a server could also return (if this line wraps in your email reader, it was intended to be a single line with no returns) Why might a server do this? If XML property values were stored as XML trees for fast searching and processing, then the text representation of the value could be reconstructed easily if whitespace did not need to be preserved exactly as is. If these assumptions are wrong or there's consensus that whitespace rewriting is unreasonable, then I'd have to rewrite this text. IMPLEMENTORS: Do any servers rewrite whitespace in or before or after property values? Do any client implementors have assumptions either way about this? > >> For any values where specific prefix choices or whitespace matter >> (e.g. property >> values containing XPath with prefixes), clients might need to force >> the server to >> store the exact property value by encapsulating the value in a CDATA >> section. > > This is a bit misleading as it kind of suggests that this would allow > to use mixed or element content while preserving prefixes, which is > not the case. Using CDATA will just result in the property value being > a plain string, not tags. > > Thus my preference still is to require servers to do the right thing. > If we don't, the warning needs to be rephrased for example like this: > > "Servers are not required to preserve namespace prefixes in property > content, hence clients should not rely on them being preserved. If > preservation of prefixes is required (such as in XPath expressions), > then it should be considered to use a different format for the value, > such as plain text containing escaped XML)." Sure, I can call it plain text. Lisa From w3c-dist-auth-request@frink.w3.org Thu Oct 13 15:02:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8La-0006Fw-PZ for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 15:02:34 -0400 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 ; Thu, 13 Oct 2005 15:02:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ8Jt-00026D-Qp for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 19:00:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ8Jr-000257-Us for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 19:00:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ8Jc-0002yt-4G for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 19:00:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9DJ0UMZ010174; Thu, 13 Oct 2005 12:00:30 -0700 Date: Thu, 13 Oct 2005 12:00:30 -0700 Message-Id: <200510131900.j9DJ0UMZ010174@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 1EQ8Jc-0002yt-4G 3e00c5c7407b1a0fbc02be8cb52d9e49 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 29] refreshing locks X-Archived-At: http://www.w3.org/mid/200510131900.j9DJ0UMZ010174@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10078 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 19:00:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=29 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- 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 Thu Oct 13 15:09:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8Rw-0006r2-MW for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 15:09:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05678 for ; Thu, 13 Oct 2005 15:09:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ8QL-0002py-GD for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 19:07:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ8QK-0002pO-OU for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 19:07:28 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EQ8QB-0007KD-58 for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 19:07:28 +0000 Received: (qmail invoked by alias); 13 Oct 2005 19:07:18 -0000 Received: from p57883E55.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [87.136.62.85] by mail.gmx.net (mp016) with SMTP; 13 Oct 2005 21:07:18 +0200 X-Authenticated: #1915285 Message-ID: <434EB057.3020504@gmx.de> Date: Thu, 13 Oct 2005 21:07:03 +0200 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: Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> In-Reply-To: <7fc3943a09cf9d3077ccf22c5a0f0f62@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ8QB-0007KD-58 7de718c67d8348eaa2f2e085ba05b663 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/434EB057.3020504@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10079 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 19:07:29 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > There are some language changes proposed by Julian that I'm OK with, > but it's clear we're thinking a little differently about whitespace -- > read down a bit for that discussion and questions for client and server > implementors. > > ... > >> 2. I don't understand the part about non-significant whitespace. Why >> was it introduced, and what issue does that resolve???? > > First assumption: that there is non-significant whitespace, based on > reading the XML recommendation > > For example, if my property name value in PROPPATCH request is > > > > > > > > Then in this case, I believe all line returns and tabs introduced here > are non-significant. But they are. See : "The XML attribute xml:space MUST NOT be used to change white space handling. White space in property values is significant." > Second assumption: that a server might strip non-significant > whitespace either at the beginning or end of the property value if it's > a XML value. So a server could return in a PROPFIND response: > > > > > > > (Conversely, a server could *add* whitespace in the locations I just > removed whitespace.) That would be a bug according to the current draft. > Third assumption/evaluation: that a server might reasonably strip > non-significant whitespace in the *middle* of an XML property value. > So a server could also return > > > xmlns="http://example.org/schema"> myprop> > > (if this line wraps in your email reader, it was intended to be a > single line with no returns) > > Why might a server do this? If XML property values were stored as XML > trees for fast searching and processing, then the text representation > of the value could be reconstructed easily if whitespace did not need > to be preserved exactly as is. > > If these assumptions are wrong or there's consensus that whitespace > rewriting is unreasonable, then I'd have to rewrite this text. Actually what I'm asking for is that we don't change the text unless there clearly is a consensus to do so. The current spec says whitespace is significant, and as far as I can tell, nobody has asked for a change of that. > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 13 15:13:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8Wa-0000Mn-NN for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 15:13:56 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06005 for ; Thu, 13 Oct 2005 15:13:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ8V1-0003WR-T9 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 19:12:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ8V1-0003Vt-EE; Thu, 13 Oct 2005 19:12:19 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ8Uu-0008GR-Vy; Thu, 13 Oct 2005 19:12:18 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0293C1422A7; Thu, 13 Oct 2005 12:12:11 -0700 (PDT) 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 12416-06; Thu, 13 Oct 2005 12:12:10 -0700 (PDT) Received: from [192.168.101.91] (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 9770514228F; Thu, 13 Oct 2005 12:12:10 -0700 (PDT) In-Reply-To: <434EB057.3020504@gmx.de> References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3e3690da7043c971ea5594190ac125d7@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Thu, 13 Oct 2005 12:12:07 -0700 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.4 X-W3C-Scan-Sig: maggie.w3.org 1EQ8Uu-0008GR-Vy 8b293ce3464422dbdd94104a8c533a76 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/3e3690da7043c971ea5594190ac125d7@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10080 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 19:12:19 +0000 Content-Transfer-Encoding: 7bit On Oct 13, 2005, at 12:07 PM, Julian Reschke wrote: > Actually what I'm asking for is that we don't change the text unless > there clearly is a consensus to do so. The current spec says > whitespace is significant, and as far as I can tell, nobody has asked > for a change of that. > Fair enough, although now I'm thinking we should be specific about XML values, and about the beginning/end of the value as well as the middle. I was thinking that the existing text in 2518 applied only to text property values. I'm still very curious to hear what implementations do/assume; that's good input to see if the consensus is consistent with the spec. lisa From w3c-dist-auth-request@frink.w3.org Thu Oct 13 15:38:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8uL-0007QI-Rx for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 15:38:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07156 for ; Thu, 13 Oct 2005 15:38:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ8sP-0000Vd-5f for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 19:36:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ8sO-0000Uu-A1 for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 19:36:28 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EQ8sG-0005QS-8C for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 19:36:27 +0000 Received: (qmail invoked by alias); 13 Oct 2005 19:36:18 -0000 Received: from p57883E55.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [87.136.62.85] by mail.gmx.net (mp014) with SMTP; 13 Oct 2005 21:36:18 +0200 X-Authenticated: #1915285 Message-ID: <434EB722.10609@gmx.de> Date: Thu, 13 Oct 2005 21:36:02 +0200 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: Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> <3e3690da7043c971ea5594190ac125d7@osafoundation.org> In-Reply-To: <3e3690da7043c971ea5594190ac125d7@osafoundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed 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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ8sG-0005QS-8C f381b2ec377211ce5cde215468d80bf0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/434EB722.10609@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10081 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 19:36:29 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA07156 Lisa Dusseault wrote: >=20 >=20 > On Oct 13, 2005, at 12:07 PM, Julian Reschke wrote: >=20 >> Actually what I'm asking for is that we don't change the text unless=20 >> there clearly is a consensus to do so. The current spec says=20 >> whitespace is significant, and as far as I can tell, nobody has asked=20 >> for a change of that. >> >=20 > Fair enough, although now I'm thinking we should be specific about XML=20 > values, and about the beginning/end of the value as well as the middle.= =20 > I was thinking that the existing text in 2518 applied only to text=20 > property values. From : -- 107 =09 IS_XMLSPACE_SIGNIFICANT =09 Edit =09 InBis =09 Should the xml:space attribute be respected.=EF=BF=BD 2518bis on 6/1/02 s= ays it=20 should not. There is some debate on this. =09 Re-raised:=20 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0137.html =09 The conclusion of the May/June 2002 discussion was that white space is=20 significant:=20 http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0152.html -- So the old issues list says this was discussed, that there was=20 consensus, and that rfc2518bis has been changed accordingly. If you want to re-open the issue, please do so (but in a different=20 thread). If you do, please make sure to clarify what was wrong the=20 resolution we reached back then. > I'm still very curious to hear what implementations do/assume; that's=20 > good input to see if the consensus is consistent with the spec. Do you have any data about servers that get that wrong? That would be=20 interesting indeed. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 13 15:51:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ97F-0002v3-JF for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 15:51:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07969 for ; Thu, 13 Oct 2005 15:51:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ95c-0003qF-HQ for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 19:50:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ95c-0003pc-4E for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 19:50:08 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by lisa.w3.org with esmtp (Exim 4.50) id 1EQ95W-00071L-9Y for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 19:50:07 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQ95V-0004mw-Pf; Thu, 13 Oct 2005 15:50:01 -0400 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: Thu, 13 Oct 2005 15:50:01 -0400 Received-SPF: none (lisa.w3.org: domain of mlee@newodin.ietf.org does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.0 X-W3C-Scan-Sig: lisa.w3.org 1EQ95W-00071L-9Y 4cdc6e6b5d7cd332e6df1e4cc8ca4476 X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-13.txt X-Archived-At: http://www.w3.org/mid/E1EQ95V-0004mw-Pf@newodin.ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10082 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 19:50:08 +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 : Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources Author(s) : J. Whitehead, et al. Filename : draft-ietf-webdav-redirectref-protocol-13.txt Pages : 32 Date : 2005-10-13 This specification defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-13.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-redirectref-protocol-13.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-redirectref-protocol-13.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-10-13153810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-13153810.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@frink.w3.org Thu Oct 13 16:14:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9TD-0004DK-1r for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 16:14:31 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13878 for ; Thu, 13 Oct 2005 16:14:26 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ9RR-0000JZ-FM for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 20:12:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ9RQ-0000Iz-KV; Thu, 13 Oct 2005 20:12:40 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQ9RJ-0004iZ-DQ; Thu, 13 Oct 2005 20:12:40 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B5E131422C2; Thu, 13 Oct 2005 13:12:31 -0700 (PDT) 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 26357-05; Thu, 13 Oct 2005 13:12:31 -0700 (PDT) Received: from [192.168.101.91] (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 4323F1422BF; Thu, 13 Oct 2005 13:12:31 -0700 (PDT) In-Reply-To: <434EB722.10609@gmx.de> References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> <3e3690da7043c971ea5594190ac125d7@osafoundation.org> <434EB722.10609@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-13-603293098 Message-Id: <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> Cc: Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Thu, 13 Oct 2005 13:12:27 -0700 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.4 X-W3C-Scan-Sig: maggie.w3.org 1EQ9RJ-0004iZ-DQ 849b5b36c8a4e6820f9bb5a8bce3ebac X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10083 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 20:12:41 +0000 --Apple-Mail-13-603293098 Content-Type: text/plain; charset=BIG5; format=flowed Content-Transfer-Encoding: quoted-printable I guess what's giving me so much cognitive dissonance here is that=20 prefixes now are not preserved but whitespace is. That seems=20 inconsistent to me -- if some XML rewriting is OK but other XML isn't,=20= what's the difference. Lisa On Oct 13, 2005, at 12:36 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> On Oct 13, 2005, at 12:07 PM, Julian Reschke wrote: >>> Actually what I'm asking for is that we don't change the text unless=20= >>> there clearly is a consensus to do so. The current spec says=20 >>> whitespace is significant, and as far as I can tell, nobody has=20 >>> asked for a change of that. >>> >> Fair enough, although now I'm thinking we should be specific about=20 >> XML values, and about the beginning/end of the value as well as the=20= >> middle. I was thinking that the existing text in 2518 applied only=20= >> to text property values. > > =46rom : > > -- > 107 > =09 > IS_XMLSPACE_SIGNIFICANT > =09 > Edit > =09 > InBis > =09 > Should the xml:space attribute be respected.=A1Z 2518bis on 6/1/02 = says=20 > it should not. There is some debate on this. > =09 > Re-raised:=20 > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0137.html > =09 > The conclusion of the May/June 2002 discussion was that white space is=20= > significant:=20 > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0152.html > -- > > So the old issues list says this was discussed, that there was=20 > consensus, and that rfc2518bis has been changed accordingly. > > If you want to re-open the issue, please do so (but in a different=20 > thread). If you do, please make sure to clarify what was wrong the=20 > resolution we reached back then. > >> I'm still very curious to hear what implementations do/assume; that's=20= >> good input to see if the consensus is consistent with the spec. > > Do you have any data about servers that get that wrong? That would be=20= > interesting indeed. > > Best regards, Julian > --Apple-Mail-13-603293098 Content-Type: text/enriched; charset=BIG5 Content-Transfer-Encoding: quoted-printable I guess what's giving me so much cognitive dissonance here is that prefixes now are not preserved but whitespace is. That seems inconsistent to me -- if some XML rewriting is OK but other XML isn't, what's the difference. Lisa On Oct 13, 2005, at 12:36 PM, Julian Reschke wrote: Lisa Dusseault wrote: On Oct 13, 2005, at 12:07 PM, Julian Reschke wrote: Actually what I'm asking for is that we don't change the text unless there clearly is a consensus to do so. The current spec says whitespace is significant, and as far as I can tell, nobody has asked for a change of that. Fair enough, although now I'm thinking we should be specific about XML values, and about the beginning/end of the value as well as the middle. I was thinking that the existing text in 2518 applied only to text property values. =46rom <: -- 107 =09 IS_XMLSPACE_SIGNIFICANT =09 Edit =09 InBis =09 Should the xml:space attribute be respected.LastResort=A1Z 2518bis on 6/1/02 says it should not. There is some debate on this. =09 Re-raised: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0137.html =09 The conclusion of the May/June 2002 discussion was that white space is significant: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0152.html -- So the old issues list says this was discussed, that there was consensus, and that rfc2518bis has been changed accordingly. If you want to re-open the issue, please do so (but in a different thread). If you do, please make sure to clarify what was wrong the resolution we reached back then. I'm still very curious to hear what implementations do/assume; that's good input to see if the consensus is consistent with the spec. Do you have any data about servers that get that wrong? That would be interesting indeed. Best regards, Julian = --Apple-Mail-13-603293098-- From w3c-dist-auth-request@frink.w3.org Thu Oct 13 16:31:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9jR-0005iE-UZ for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 16:31:23 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15685 for ; Thu, 13 Oct 2005 16:31:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ9hn-00040O-F9 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 20:29:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ9hm-0003zS-Ve for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 20:29:35 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1EQ9hh-0007vO-Gy for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 20:29:34 +0000 Received: (qmail invoked by alias); 13 Oct 2005 20:29:28 -0000 Received: from p57883E55.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [87.136.62.85] by mail.gmx.net (mp033) with SMTP; 13 Oct 2005 22:29:28 +0200 X-Authenticated: #1915285 Message-ID: <434EC393.4060604@gmx.de> Date: Thu, 13 Oct 2005 22:29:07 +0200 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: Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> <3e3690da7043c971ea5594190ac125d7@osafoundation.org> <434EB722.10609@gmx.de> <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> In-Reply-To: <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> Content-Type: text/plain; charset=Big5 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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQ9hh-0007vO-Gy 37faea15f783610212cc2ac45d3dbd48 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/434EC393.4060604@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10084 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 20:29:35 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I guess what's giving me so much cognitive dissonance here is that > prefixes now are not preserved but whitespace is. That seems > inconsistent to me -- if some XML rewriting is OK but other XML isn't, > what's the difference. Well. Both are part of the XML Infoset and the XPath model, so there are two independant W3C specs that consider them significant. That's why I'd like servers to preserve both. Maybe we should reconsider the issue? I think we have three servers (SAP|Xythos|moddav) that can handle XML at all, so if there's a minimum chance we can get all of them to preserve prefixes, we should just make that the requirement. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 13 16:40:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9s4-0000qN-M9 for webdav-archive@megatron.ietf.org; Thu, 13 Oct 2005 16:40:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16038 for ; Thu, 13 Oct 2005 16:40:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQ9qK-0006tE-Gn for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Oct 2005 20:38:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQ9qJ-0006sg-UJ for w3c-dist-auth@listhub.w3.org; Thu, 13 Oct 2005 20:38:23 +0000 Received: from mail.gmx.net ([213.165.64.21]) by lisa.w3.org with smtp (Exim 4.50) id 1EQ9q8-0002zb-Me for w3c-dist-auth@w3.org; Thu, 13 Oct 2005 20:38:23 +0000 Received: (qmail invoked by alias); 13 Oct 2005 20:38:10 -0000 Received: from p57883E55.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [87.136.62.85] by mail.gmx.net (mp012) with SMTP; 13 Oct 2005 22:38:10 +0200 X-Authenticated: #1915285 Message-ID: <434EC59D.4070600@gmx.de> Date: Thu, 13 Oct 2005 22:37:49 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: 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.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EQ9q8-0002zb-Me 8f2dc894947f47633c3dbb11a30bffa5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D ACTION:draft-ietf-webdav-redirectref-protocol-13.txt X-Archived-At: http://www.w3.org/mid/434EC59D.4070600@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10085 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Oct 2005 20:38:24 +0000 Content-Transfer-Encoding: 7bit Hi, this draft (hopefully) resolves the issue raised by Jake Baumgarten (). during WGLC. As far as I can tell, it is ready to be submitted for publication as Experimental RFC. Best regards, Julian Internet-Drafts@ietf.org wrote: > 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 : Web Distributed Authoring and Versioning > (WebDAV) Redirect Reference Resources > Author(s) : J. Whitehead, et al. > Filename : draft-ietf-webdav-redirectref-protocol-13.txt > Pages : 32 > Date : 2005-10-13 > > This specification defines redirect reference resources. A redirect > reference resource is a resource whose default response is an > HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), > redirecting the client to a different resource, the target resource. > A redirect reference makes it possible to access the target resource > indirectly, through any URI mapped to the redirect reference > resource. There are no integrity guarantees associated with redirect > reference resources. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-13.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-redirectref-protocol-13.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-redirectref-protocol-13.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 From w3c-dist-auth-request@frink.w3.org Fri Oct 14 05:55:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMHF-0000Mj-7P for webdav-archive@megatron.ietf.org; Fri, 14 Oct 2005 05:55:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29174 for ; Fri, 14 Oct 2005 05:54:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQMFL-0007QS-Qd for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Oct 2005 09:53:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQMFK-0007Pu-1x for w3c-dist-auth@listhub.w3.org; Fri, 14 Oct 2005 09:53:02 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1EQMFH-00005E-1p for w3c-dist-auth@w3.org; Fri, 14 Oct 2005 09:53:01 +0000 Received: (qmail invoked by alias); 14 Oct 2005 09:52:57 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp011) with SMTP; 14 Oct 2005 11:52:57 +0200 X-Authenticated: #1915285 Message-ID: <434F7FF4.1090405@gmx.de> Date: Fri, 14 Oct 2005 11:52:52 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDav References: <434EA31F.9060906@cse.ucsc.edu> In-Reply-To: <434EA31F.9060906@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.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EQMFH-00005E-1p c9667ef0e92cbc15639e153876af2bab X-Original-To: w3c-dist-auth@w3.org Subject: Re: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/434F7FF4.1090405@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10086 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Oct 2005 09:53:03 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > I actually see a need for more than two states: New, Assigned (accepted > by WG for discussion), Resolved (some resolution reached on the list, > editorial or otherwise), Closed (resolution is in current draft). Comments? Whatever works for you. Related: I'd like to propose that we use the mailing list to *discuss* issues; that will make things much more readable. Once the WG reaches consensus on an issue, the proposed resolution can be entered in BugZilla, and then the current author of rfc2518bis can update the spec. Best regards, Julian From csd@futbolamericano.com Sat Oct 15 00:04:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQdHQ-0000WA-5x for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 00:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16402 for ; Sat, 15 Oct 2005 00:04:15 -0400 (EDT) Received: from [222.160.137.207] (helo=-1208972776) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQdSD-0008Hb-Kx for webdav-archive@ietf.org; Sat, 15 Oct 2005 00:15:33 -0400 Received: from futbolamericano.com (-1208645312 [-1208969392]) by garzagarcia.com (Qmailv1) with ESMTP id FE3733C3DF for ; Sat, 15 Oct 2005 00:05:48 -0400 Date: Sat, 15 Oct 2005 00:05:48 -0400 From: Doctor X-Mailer: The Bat! (v2.00.5) Personal X-Priority: 3 Message-ID: <9290377336.20051015000548@futbolamericano.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------D9E2C482A6B9180" X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 2.9 (++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------------D9E2C482A6B9180 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlasgra $3.3 Leviztra $3.3 Ciaxlis $3.7 Imitbrex $16.4 Flomeax $2.2 Ultrpam $0.78 Viowxx $4.75 Ambnien $2.2 Valcium $0.97 Xanafx $1.09 Sowma $3 Merifdia $2.2 our site http://rysterom.com/?GFSMKDRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals ------------D9E2C482A6B9180 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlaxgra - $3.3
Levidtra - $3.3
Ciaylis - $3.7
Imitgrex - $16.4
Flomiax - $2.2
Ultrsam - $0.78
Vioaxx - $4.75
Ambcien - $2.2
Valbium - $0.97
Xanahx - $1.09
Sodma - $3
Meribdia - $2.2

our website

___
Best regards,
Online Pharmaceuticals ------------D9E2C482A6B9180-- From w3c-dist-auth-request@frink.w3.org Sat Oct 15 13:56:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQqGN-0006Rj-SC for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 13:56:08 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19783 for ; Sat, 15 Oct 2005 13:56:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQqEF-0004A0-0L for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 17:53:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQqED-00049S-8t for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 17:53:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQqEA-0000LE-FO for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 17:53:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FHrnNK022780; Sat, 15 Oct 2005 10:53:49 -0700 Date: Sat, 15 Oct 2005 10:53:49 -0700 Message-Id: <200510151753.j9FHrnNK022780@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 1EQqEA-0000LE-FO 67e86dadfb9e74ad9ab023684abb9ebe X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/200510151753.j9FHrnNK022780@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10087 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 17:53:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=37 julian.reschke@greenbytes.de 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 Sat Oct 15 14:08:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQqSD-0001kI-E5 for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 14:08:21 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20329 for ; Sat, 15 Oct 2005 14:08:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQqRV-00072r-9q for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 18:07:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQqRU-00072B-KK for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 18:07:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQqRO-0001kX-FH for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 18:07:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FI7Sm5023211; Sat, 15 Oct 2005 11:07:28 -0700 Date: Sat, 15 Oct 2005 11:07:28 -0700 Message-Id: <200510151807.j9FI7Sm5023211@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQqRO-0001kX-FH cce0f814be3e82436e265e1ee02ccbf3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 168] New: Revert to original reference style X-Archived-At: http://www.w3.org/mid/200510151807.j9FI7Sm5023211@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10088 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 18:07:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=168 Summary: Revert to original reference style Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Other AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org RFC2518 used to use symbolic references (such as [RFC2026]) instead of numbered references. Please revert back to this style; it makes the spec much easier to read. (in RFC2629's DTD: ) ------- 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 Oct 15 14:24:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQqhz-0007Cr-7u for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 14:24:39 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21949 for ; Sat, 15 Oct 2005 14:24:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQqhC-0001X9-GX for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 18:23:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQqhB-0001WU-Ka for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 18:23:49 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EQqh0-0004iZ-I8 for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 18:23:49 +0000 Received: (qmail invoked by alias); 15 Oct 2005 18:23:37 -0000 Received: from p508F81EE.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.238] by mail.gmx.net (mp034) with SMTP; 15 Oct 2005 20:23:37 +0200 X-Authenticated: #1915285 Message-ID: <43514915.4000505@gmx.de> Date: Sat, 15 Oct 2005 20:23:17 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510151753.j9FHrnNK022780@ietf.cse.ucsc.edu> In-Reply-To: <200510151753.j9FHrnNK022780@ietf.cse.ucsc.edu> Content-Type: multipart/mixed; boundary="------------070103070600050207020005" 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.4 X-W3C-Scan-Sig: maggie.w3.org 1EQqh0-0004iZ-I8 594a23effa26870da7f064b065351963 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 37] Sentence lost in introduction X-Archived-At: http://www.w3.org/mid/43514915.4000505@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10089 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 18:23:50 +0000 This is a multi-part message in MIME format. --------------070103070600050207020005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Proposed resolution for : 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). Best regards, Julian --------------070103070600050207020005 Content-Type: text/plain; name="37.diff" Content-Disposition: inline; filename="37.diff" Content-Transfer-Encoding: 7bit --- draft-ietf-webdav-rfc2518bis-07.xml 2005-10-15 19:19:46.000000000 +0100 +++ rfc2518bis-08-bug37.xml 2005-10-15 19:22:34.000000000 +0100 @@ -146,6 +146,13 @@ XML appearing in WebDAV so that it truly is extensible. + 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. 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, on internationalization support, and on @@ -4192,7 +4199,7 @@ -
+
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 --------------070103070600050207020005-- From w3c-dist-auth-request@frink.w3.org Sat Oct 15 14:29:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQqn6-00083p-Vb for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 14:29:57 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22175 for ; Sat, 15 Oct 2005 14:29:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQqmO-0002H0-GG for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 18:29:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQqmO-0002GS-3n for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 18:29:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQqmK-0005k8-8B for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 18:29:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FIT7PU023853; Sat, 15 Oct 2005 11:29:07 -0700 Date: Sat, 15 Oct 2005 11:29:07 -0700 Message-Id: <200510151829.j9FIT7PU023853@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQqmK-0005k8-8B 03c33230339ac2737d2ce97ab0eca826 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10090 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 18:29:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 julian.reschke@greenbytes.de 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 Sat Oct 15 14:52:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQr9O-0007zX-Bl for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 14:52:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22963 for ; Sat, 15 Oct 2005 14:52:52 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQr8f-0006tW-GF for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 18:52:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQr8e-0006su-BU for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 18:52:12 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EQr8a-0005xQ-Ga for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 18:52:12 +0000 Received: (qmail invoked by alias); 15 Oct 2005 18:52:05 -0000 Received: from p508F81EE.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.238] by mail.gmx.net (mp020) with SMTP; 15 Oct 2005 20:52:05 +0200 X-Authenticated: #1915285 Message-ID: <43514FBF.9040502@gmx.de> Date: Sat, 15 Oct 2005 20:51:43 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> In-Reply-To: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> Content-Type: multipart/mixed; boundary="------------040809000006080304020407" 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.4 X-W3C-Scan-Sig: lisa.w3.org 1EQr8a-0005xQ-Ga 3b43a23a1f9a82c6579c8edb93a8fd75 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/43514FBF.9040502@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10091 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 18:52:13 +0000 This is a multi-part message in MIME format. --------------040809000006080304020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Proposed resolution for : Section 6., para. 14: OLD: A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned in the Lock- Token header in the response to a successful LOCK operation. The lock token also appears in the value of the lockdiscovery property, the value of which is returned in the body of the response to a successful LOCK operation (this property also includes the tokens of other current locks on the resource). Finally, the lockdiscovery property can be queried using PROPFIND and the token can be discovered that way. Each lock has only one unique lock token. 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 --------------040809000006080304020407 Content-Type: text/plain; name="23.diff" Content-Disposition: inline; filename="23.diff" Content-Transfer-Encoding: 7bit --- draft-ietf-webdav-rfc2518bis-07.xml 2005-10-15 19:19:46.000000000 +0100 +++ rfc2518bis-08-bug23.xml 2005-10-15 19:48:16.000000000 +0100 @@ -616,17 +616,13 @@
- - A lock token is a type of state token, represented as a URI, which - identifies a particular lock. A lock token is returned in the Lock- - Token header in the response to a successful LOCK operation. The - lock token also appears in the value of the lockdiscovery property, - the value of which is returned in the body of the response to a - successful LOCK operation (this property also includes the tokens of - other current locks on the resource). Finally, the lockdiscovery - property can be queried using PROPFIND and the token can be - discovered that way. Each lock has only one unique lock token. - + + 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 + . + Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across @@ -3337,7 +3333,7 @@
-
+
Lock-Token = "Lock-Token" ":" Coded-URL --------------040809000006080304020407-- From w3c-dist-auth-request@frink.w3.org Sat Oct 15 14:55:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQrBq-0000O5-Os for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 14:55:30 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23034 for ; Sat, 15 Oct 2005 14:55:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQrBA-0007Gf-6H for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 18:54:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQrB9-0007G1-OW for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 18:54:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQrB6-00027h-I5 for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 18:54:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FIsg1d024619; Sat, 15 Oct 2005 11:54:42 -0700 Date: Sat, 15 Oct 2005 11:54:42 -0700 Message-Id: <200510151854.j9FIsg1d024619@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQrB6-00027h-I5 90d3bfea0b75b7a866a6721878f84567 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/200510151854.j9FIsg1d024619@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10092 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 18:54:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 julian.reschke@greenbytes.de 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 Sat Oct 15 15:37:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQrqV-0005cX-0m for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 15:37:31 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24315 for ; Sat, 15 Oct 2005 15:37:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQrp9-0006nd-H1 for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 19:36:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQrp8-0006n5-4p for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 19:36:06 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EQrou-00075i-C8 for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 19:36:02 +0000 Received: (qmail invoked by alias); 15 Oct 2005 19:35:48 -0000 Received: from p508F81EE.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.238] by mail.gmx.net (mp034) with SMTP; 15 Oct 2005 21:35:48 +0200 X-Authenticated: #1915285 Message-ID: <435159FA.4080308@gmx.de> Date: Sat, 15 Oct 2005 21:35:22 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510151854.j9FIsg1d024619@ietf.cse.ucsc.edu> In-Reply-To: <200510151854.j9FIsg1d024619@ietf.cse.ucsc.edu> Content-Type: multipart/mixed; boundary="------------040800040805080805080604" 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.4 X-W3C-Scan-Sig: lisa.w3.org 1EQrou-00075i-C8 8feaed0d279ecc234473b621eb96b2fb 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/435159FA.4080308@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10093 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 19:36:07 +0000 This is a multi-part message in MIME format. --------------040800040805080805080604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Proposed resolution for : History: The "force-authenticate" request header was initially proposed by Ilya Kirnos, and we had a discussion about this back three years ago ). As far as I can tell, the consensus back then was not to define a new header, but to make use of an "If" request header that was known to alway evaluate to false instead. In January 2003, the WG had an interim meeting hosted by Apple, during which the problem was discussed again. Unfortunately, there doesn't seem to be any public record of what was discussed on the second day (which AFAIR was the day we discussed this topic). (Minutes for day one in ). The "Force-Authentication" header was then introduced in draft 03 (), but I can't find any record of a consensus reached on the mailing list. I therefore propose to remove the header from the spec, encouraging those who feel that this feature is needed to solve a real-world problem to restart the discussion on the mailing list (containing a precise problem statement, and an analysis why the current spec isn't sufficient in this regard). In addition to removing section 9.4, further changes would be: Section 17., para. 11: OLD: 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. NEW: A resource can explicitly advertise its support for the revisions to RFC2518 made in this document. Class 1 must be supported as well. Class 2 MAY be supported. Section 17., para. 13: OLD: o the Force-Authentication header. o 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. NEW: o 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. Section 21., para. 8: OLD: 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. NEW: 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. Joe Hildebrand contributed as co-chair. Best regards, Julian --------------040800040805080805080604 Content-Type: text/plain; name="18.diff" Content-Disposition: inline; filename="18.diff" Content-Transfer-Encoding: 7bit --- draft-ietf-webdav-rfc2518bis-07.xml 2005-10-15 19:19:46.000000000 +0100 +++ rfc2518bis-08-bug18.xml 2005-10-15 20:29:23.000000000 +0100 @@ -3112,23 +3112,7 @@ 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. - -
- +
@@ -4832,15 +4816,13 @@
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 + RFC2518 made in this document. 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 @@ -5200,8 +5182,7 @@ 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 + specific text on the list or in meetings. Joe Hildebrand contributed as co-chair.
--------------040800040805080805080604-- From w3c-dist-auth-request@frink.w3.org Sat Oct 15 16:06:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQsIk-0005aC-Ck for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 16:06:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25022 for ; Sat, 15 Oct 2005 16:06:35 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQsHp-0003dM-Mw for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 20:05:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQsHp-0003ci-9x for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 20:05:45 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EQsHn-0005nd-Dc for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 20:05:45 +0000 Received: (qmail invoked by alias); 15 Oct 2005 20:05:41 -0000 Received: from p508F81EE.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.238] by mail.gmx.net (mp001) with SMTP; 15 Oct 2005 22:05:41 +0200 X-Authenticated: #1915285 Message-ID: <435160FA.4000401@gmx.de> Date: Sat, 15 Oct 2005 22:05:14 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Lisa Dusseault , Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> <3e3690da7043c971ea5594190ac125d7@osafoundation.org> <434EB722.10609@gmx.de> <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> <434EC393.4060604@gmx.de> In-Reply-To: <434EC393.4060604@gmx.de> Content-Type: multipart/mixed; boundary="------------090705070601000102080105" 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.4 X-W3C-Scan-Sig: lisa.w3.org 1EQsHn-0005nd-Dc e1aee03d5d4acd9b3294d34a31bdeb0b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/435160FA.4000401@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10094 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 20:05:45 +0000 This is a multi-part message in MIME format. --------------090705070601000102080105 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit OK, in the meantime I have tested round-tripping of property values (using the attached script). Results for those servers I can currently test with: SAP Netweaver: preserves whitespace and namespace prefixes Apache/moddav 2.0.54: preserves whitespace, but not namespace prefixes. Xythos (whatever release currently running on www.sharemation.com): preserves whitespace, but not namespace prefixes. Note that is also looses attributes in the property value (!). IIS - will need to test: AFAIR, no mixed content supported at all. So yes, those servers that do support mixed content also preserve whitespace. Assuming that IIS is broken anyway (and is not going to be fixed anytime soon), we could potentially concentrate on Xythos and Apache/mod_dav. Xythos will need a fix for attribute rounbd-tripping anyway. Regarding mod_dav, maybe a fix for the missing prefix round-tripping is simple (anybody listening? Joe?). Best regards, Julian --------------090705070601000102080105 Content-Type: application/x-javascript; name="property_round_trip.js" Content-Disposition: inline; filename="property_round_trip.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 property_roundtrip.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); } 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); } // simple proppatch WScript.Echo("PROPPATCH " + uri); req.open("PROPPATCH", uri, false, user, pwd); req.send("" + "" + ""); dumpResponse(req); if (req.status != 207) { WScript.Echo("unexpected status upon PROPPATCH"); WScript.Quit(2); } // complex proppatch WScript.Echo("PROPPATCH " + uri); req.open("PROPPATCH", uri, false, user, pwd); req.send("" + "" + " leading blank " + "" + ""); dumpResponse(req); if (req.status != 207) { WScript.Echo("unexpected status upon PROPPATCH"); WScript.Quit(2); } // propfind WScript.Echo("PROPFIND " + uri); req.open("PROPFIND", uri, false, user, pwd); req.send("" + "" + ""); dumpResponse(req); if (req.status != 207) { WScript.Echo("unexpected status upon PROPFIND"); WScript.Quit(2); } --------------090705070601000102080105-- From w3c-dist-auth-request@frink.w3.org Sat Oct 15 17:59:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQu4G-0007iM-8x for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 17:59:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29303 for ; Sat, 15 Oct 2005 17:59:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQu32-0007SW-Ci for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 21:58:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQu2p-0007Ru-7Z for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 21:58:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQu2j-00089g-LH for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 21:58:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FLwGar030284; Sat, 15 Oct 2005 14:58:16 -0700 Date: Sat, 15 Oct 2005 14:58:16 -0700 Message-Id: <200510152158.j9FLwGar030284@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQu2j-00089g-LH d18f2593d8f4f91620e63c6d0760c765 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/200510152158.j9FLwGar030284@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10095 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 21:58:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 ------- Additional Comments From lisa@osafoundation.org 2005-10-15 14:58 ------- Text for the -08 version of the draft: Note that "DAV:" uses a scheme name defined solely for the purpose of creating this namespace. Using a scheme name alone does not create a compliant URI according to RFC2396. Furthermore, 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. ------- 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 Oct 15 19:22:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQvLn-0001fU-7m for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 19:22:03 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02171 for ; Sat, 15 Oct 2005 19:21:57 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQvKR-00045K-0P for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 23:20:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQvKO-00044m-VP for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 23:20:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQvKL-0002OX-H3 for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 23:20:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FNKVOH000349; Sat, 15 Oct 2005 16:20:31 -0700 Date: Sat, 15 Oct 2005 16:20:31 -0700 Message-Id: <200510152320.j9FNKVOH000349@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQvKL-0002OX-H3 39e48a6910a62ba7555a0540922a0491 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/200510152320.j9FNKVOH000349@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10096 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 23:20:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=17 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-10-15 16:20 ------- Done for -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 Oct 15 19:28:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQvRm-0003mI-DA for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 19:28:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02365 for ; Sat, 15 Oct 2005 19:28:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQvR6-0004kh-Vj for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 23:27:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQvR6-0004k9-BV for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 23:27:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQvR2-0003Jw-Qm for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 23:27:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FNRSva000801; Sat, 15 Oct 2005 16:27:28 -0700 Date: Sat, 15 Oct 2005 16:27:28 -0700 Message-Id: <200510152327.j9FNRSva000801@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQvR2-0003Jw-Qm 40323d79af7af4dcbb24a76172ce0fc8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200510152327.j9FNRSva000801@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10097 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 23:27:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-10-15 16:27 ------- Fixed for draft version -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 Oct 15 19:35:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQvYs-00066K-OQ for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 19:35:34 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02607 for ; Sat, 15 Oct 2005 19:35:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQvYD-00070p-Tj for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 23:34:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EQvYD-00070C-E9 for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 23:34:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EQvY0-0006ul-T9 for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 23:34:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FNYet0001269; Sat, 15 Oct 2005 16:34:40 -0700 Date: Sat, 15 Oct 2005 16:34:40 -0700 Message-Id: <200510152334.j9FNYet0001269@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 1EQvY0-0006ul-T9 404c47a8fd27ee202eb28573f595c703 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 20] lock token example X-Archived-At: http://www.w3.org/mid/200510152334.j9FNYet0001269@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10098 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 23:34:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-10-15 16:34 ------- I think I've got all the strays now, in the text for -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 Oct 15 19:38:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQvbL-0006je-Qg for webdav-archive@megatron.ietf.org; Sat, 15 Oct 2005 19:38:07 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02666 for ; Sat, 15 Oct 2005 19:38:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EQvaj-0007Yl-E0 for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Oct 2005 23:37:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EQvaj-0007Y9-17 for w3c-dist-auth@listhub.w3.org; Sat, 15 Oct 2005 23:37:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EQvae-0004iE-OQ for w3c-dist-auth@w3.org; Sat, 15 Oct 2005 23:37:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9FNbOgl001456; Sat, 15 Oct 2005 16:37:24 -0700 Date: Sat, 15 Oct 2005 16:37:24 -0700 Message-Id: <200510152337.j9FNbOgl001456@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EQvae-0004iE-OQ a280acee3974f0df0ccdf7ba02892d3f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/200510152337.j9FNbOgl001456@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10099 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Oct 2005 23:37:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=24 ------- 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). ------- 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 Oct 16 04:38:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER42Y-0003hz-Dm for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 04:38:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18281 for ; Sun, 16 Oct 2005 04:38:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ER404-0004v4-JL for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 08:36:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ER402-0004uW-Fj for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 08:36:10 +0000 Received: from mta08-winn.ispmail.ntl.com ([81.103.221.48]) by lisa.w3.org with esmtp (Exim 4.50) id 1ER3zx-0007cL-No for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 08:36:10 +0000 Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20051016083601.OYFJ10357.mta08-winn.ispmail.ntl.com@aamta09-winn.ispmail.ntl.com>; Sun, 16 Oct 2005 09:36:01 +0100 Received: from manyfish.co.uk ([62.253.142.142]) by aamta09-winn.ispmail.ntl.com with ESMTP id <20051016083601.EDAF6564.aamta09-winn.ispmail.ntl.com@manyfish.co.uk>; Sun, 16 Oct 2005 09:36:01 +0100 Received: from monolith.fishnet (localhost.localdomain [127.0.0.1]) by manyfish.co.uk (8.13.4/8.12.5) with ESMTP id j9G8Zx3I017356; Sun, 16 Oct 2005 09:35:59 +0100 Received: (from joe@localhost) by monolith.fishnet (8.13.4/8.13.4/Submit) id j9G8Zwpd017348; Sun, 16 Oct 2005 09:35:58 +0100 Date: Sun, 16 Oct 2005 09:35:58 +0100 From: Joe Orton To: Julian Reschke Cc: Lisa Dusseault , Cullen Jennings , Geoffrey M Clemm , WebDav Message-ID: <20051016083558.GA17687@manyfish.co.uk> Mail-Followup-To: Julian Reschke , Lisa Dusseault , Cullen Jennings , Geoffrey M Clemm , WebDav References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> <3e3690da7043c971ea5594190ac125d7@osafoundation.org> <434EB722.10609@gmx.de> <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> <434EC393.4060604@gmx.de> <435160FA.4000401@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <435160FA.4000401@gmx.de> User-Agent: Mutt/1.4.2.1i Received-SPF: none (lisa.w3.org: domain of joe@manyfish.co.uk does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1ER3zx-0007cL-No 6b02108deb9549285b4ecdb4d65bbfb3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/20051016083558.GA17687@manyfish.co.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10100 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 08:36:12 +0000 On Sat, Oct 15, 2005 at 10:05:14PM +0200, Julian Reschke wrote: > Assuming that IIS is broken anyway (and is not going to be fixed anytime > soon), we could potentially concentrate on Xythos and Apache/mod_dav. > Xythos will need a fix for attribute rounbd-tripping anyway. Regarding > mod_dav, maybe a fix for the missing prefix round-tripping is simple > (anybody listening? Joe?). I don't think it would be particularly simple, no; the assumption that the prefix names don't need to be preserved is quite deep-rooted in mod_dav's property handling. joe From w3c-dist-auth-request@frink.w3.org Sun Oct 16 06:19:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER5bz-0004Qt-9C for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 06:19:27 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23885 for ; Sun, 16 Oct 2005 06:19:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ER5as-0006QD-TI for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 10:18:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ER5aq-0006Pf-LL for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 10:18:16 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ER5aj-0005yd-So for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 10:18:16 +0000 Received: (qmail invoked by alias); 16 Oct 2005 10:18:08 -0000 Received: from p508F98F8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.152.248] by mail.gmx.net (mp016) with SMTP; 16 Oct 2005 12:18:08 +0200 X-Authenticated: #1915285 Message-ID: <435228CF.3000709@gmx.de> Date: Sun, 16 Oct 2005 12:17:51 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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.4 X-W3C-Scan-Sig: maggie.w3.org 1ER5aj-0005yd-So 2e973e6c9b3d88a83b1570325177fdbc X-Original-To: w3c-dist-auth@w3.org Subject: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/435228CF.3000709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10101 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 10:18:18 +0000 Content-Transfer-Encoding: 7bit Hi Lisa, could you please make sure that the file on ietf.webdav.org is indeed well-formed XML? It currently contains several non-ASCII characters that cause XML parsers to choke on it (a fixed version is at ). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 16 07:08:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER6Nj-0007yy-3Q for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 07:08:47 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25457 for ; Sun, 16 Oct 2005 07:08:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ER6Mi-0005dP-5F for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 11:07:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ER6Mf-0005cl-Mk for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 11:07:41 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ER6Mc-0007LM-QL for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 11:07:41 +0000 Received: (qmail invoked by alias); 16 Oct 2005 11:07:36 -0000 Received: from p508F98F8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.152.248] by mail.gmx.net (mp017) with SMTP; 16 Oct 2005 13:07:36 +0200 X-Authenticated: #1915285 Message-ID: <43523463.4040905@gmx.de> Date: Sun, 16 Oct 2005 13:07:15 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth@w3.org References: <435228CF.3000709@gmx.de> In-Reply-To: <435228CF.3000709@gmx.de> 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.4 X-W3C-Scan-Sig: lisa.w3.org 1ER6Mc-0007LM-QL 88b1bd1712d951f0b7c02590031dad25 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/43523463.4040905@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10102 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 11:07:44 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Hi Lisa, > > could you please make sure that the file on ietf.webdav.org is indeed > well-formed XML? It currently contains several non-ASCII characters that > cause XML parsers to choke on it (a fixed version is at > ). I also just noted that conversion in "strict" mode (as currently configured) fails because artwork is too wide. Please either remove the PI for now, or fix the artwork xml2rfc is complaining about. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 16 11:35:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERAXc-0006CH-8P for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 11:35:16 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07021 for ; Sun, 16 Oct 2005 11:35:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERAWI-0004jW-32 for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 15:33:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERAWG-0004iY-3Q for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 15:33:52 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ERAWC-0000zY-AY for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 15:33:51 +0000 Received: (qmail invoked by alias); 16 Oct 2005 15:33:45 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 16 Oct 2005 17:33:45 +0200 X-Authenticated: #1915285 Message-ID: <435272CB.2090700@gmx.de> Date: Sun, 16 Oct 2005 17:33:31 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510152158.j9FLwGar030284@ietf.cse.ucsc.edu> In-Reply-To: <200510152158.j9FLwGar030284@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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERAWC-0000zY-AY fed08ca48539e230daa987f70a9f3bde X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/435272CB.2090700@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10103 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 15:33:54 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 > > > > > > ------- Additional Comments From lisa@osafoundation.org 2005-10-15 14:58 ------- > Text for the -08 version of the draft: > > Note that "DAV:" uses a scheme name defined solely for > the purpose of creating this namespace. Using a scheme name alone does > not create a compliant URI according to RFC2396. > Furthermore, 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. > ... Well, in the meantime RFC2396 has been obsoleted, and RFC3986 makes "DAV:" a legal URI (). Thus I'd simply this to: -- Note that "DAV:" is an URI scheme name defined solely for the purpose of creating this namespace. However, defining a new URI scheme just for the purpose of identifying protocol elements is to be considered a bad practice, and should not be copied. It is still used in this protocol revision because of significant existing deployments. -- Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 16 11:36:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERAYh-0006gs-7m for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 11:36:23 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07100 for ; Sun, 16 Oct 2005 11:36:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERAY6-0005J0-7u for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 15:35:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERAY5-0005IN-Q3 for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 15:35:45 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ERAXv-0001Mc-FH for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 15:35:45 +0000 Received: (qmail invoked by alias); 16 Oct 2005 15:35:34 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 16 Oct 2005 17:35:34 +0200 X-Authenticated: #1915285 Message-ID: <43527338.3030200@gmx.de> Date: Sun, 16 Oct 2005 17:35:20 +0200 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: <31f07fc305071823571981b4a3@mail.gmail.com> <42DCACAC.4000605@gmx.de> <31f07fc30507190122366e93dd@mail.gmail.com> <31f07fc305072008165be47e70@mail.gmail.com> <42DF453D.8090706@gmx.de> <434CAA08.8080102@gmx.de> In-Reply-To: <434CAA08.8080102@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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERAXv-0001Mc-FH c1951fd23bace7e37f2c6cc5ba23edf2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/43527338.3030200@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10104 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 15:35:46 +0000 Content-Transfer-Encoding: 7bit Hi, I note that this paragraph has made it into the current draft at . Could you please remove it unless we reach a working group consensus to add it? Thanks, Julian Julian Reschke wrote: > > Lisa Dusseault wrote: > >> >> This thread from a couple months ago brought up something probably >> worth clarifying in RFC2518bis. In fact we could usefully constrain >> servers generally in what status codes MAY or MUST NOT be used inside >> Multi-Status. I wrote up a strawman draft section for this so we >> could discuss the specifics: >> >> The following status codes MUST NOT be used in Multi-Status >> responses: 100 Continue, 101 Switching Protocols, 205 Reset Content, >> 206 Partial Content, 300 Multiple Choices?, 305 Use Proxy, 400 Bad >> Request, 405 Method Not Allowed, 406 Not Acceptable, 407 Proxy >> Authentication Required, 411 Length Required, 412 Precondition >> Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415 >> Unsupported Media Type, 416 Requested Range Not Satisfiable, 417 >> Expectation Failed, 501 Not Implemented and 505 HTTP Version Not >> Supported. >> >> The following status codes MAY be used in Multi-Status responses: 200 >> OK, 201 Created, 301 Moved Permanently, 302 Found, 303 See Other, 307 >> Temporary Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found >> and 410 Gone. >> >> The following status codes MAY be used in Multi-Status responses, >> although the meaning might be unclear based only on this >> specification. Thus, specifications extending WebDAV MAY make use of >> these status codes in Multi-Status responses but regular WebDAV >> clients would reasonably be expected to be confused by these: 202 >> Accepted, 203 Non-Authoritative Information, 204 No Content, 304 Not >> Modified, 402 Payment Required, 409 Conflict, 408 Request Timeout, >> 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable >> and 504 Gateway Timeout. >> >> Comments? > > > Yes. > > 1) What exactly is the issue this is supposed to solve? > > 2) How did you come up with these lists? How do they help a client that > needs to handle unknown status codes anyway (based on the first digit)? > For instance, why can 300 not appear in a multistatus? > > Best regards, Julian > > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@frink.w3.org Sun Oct 16 11:36:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERAYl-0006h4-EM for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 11:36:27 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07102 for ; Sun, 16 Oct 2005 11:36:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERAYC-0005NE-IP for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 15:35:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERAYB-0005LY-Vj for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 15:35:52 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ERAY1-0000dJ-Na for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 15:35:51 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8A441142298; Sun, 16 Oct 2005 08:35:40 -0700 (PDT) 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 04598-09; Sun, 16 Oct 2005 08:35:40 -0700 (PDT) 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 E869B14228E; Sun, 16 Oct 2005 08:35:39 -0700 (PDT) In-Reply-To: <435228CF.3000709@gmx.de> References: <435228CF.3000709@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: Sun, 16 Oct 2005 08:35:35 -0700 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 1ERAY1-0000dJ-Na c2e5d760e481362f21c9e7311b1a6c43 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/f3badede5594491987442a7c65b21367@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10105 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 15:35:52 +0000 Content-Transfer-Encoding: 7bit According to Oxygen's well-formedness test, the version I synchronized to http://ietf.webdav.org/webdav/rfc2518bis/draft-ietf-webdav- rfc2518bis.xml (and the version I pulled back down again) is well-formed. It also goes through the utility at xml.resource.org just fine. I tried to diff the xml file downloaded from my URL vs. the one from yours and unfortunately the diff is garbage, showing every line different. It's probably something stupid like line returns, but it's a pain in the ass figuring out what's actually changed. If you provide a diff I'll check it out further. Lisa On Oct 16, 2005, at 3:17 AM, Julian Reschke wrote: > > Hi Lisa, > > could you please make sure that the file on ietf.webdav.org is indeed > well-formed XML? It currently contains several non-ASCII characters > that cause XML parsers to choke on it (a fixed version is at > latest.xml>). > > Best regards, Julian > > From w3c-dist-auth-request@frink.w3.org Sun Oct 16 11:38:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERAaI-00075x-EM for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 11:38:02 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07187 for ; Sun, 16 Oct 2005 11:37:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERAZe-0005cq-Ul for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 15:37:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERAZe-0005cH-Jk for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 15:37:22 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ERAZc-0000z4-Jz for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 15:37:22 +0000 Received: (qmail invoked by alias); 16 Oct 2005 15:37:18 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 16 Oct 2005 17:37:18 +0200 X-Authenticated: #1915285 Message-ID: <435273A0.9080902@gmx.de> Date: Sun, 16 Oct 2005 17:37:04 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510152320.j9FNKVOH000349@ietf.cse.ucsc.edu> In-Reply-To: <200510152320.j9FNKVOH000349@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.4 X-W3C-Scan-Sig: lisa.w3.org 1ERAZc-0000z4-Jz 04654b39883bdac0e4c3146855f5d9bd X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/435273A0.9080902@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10106 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 15:37:22 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=17 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |ASSIGNED > > > > ------- Additional Comments From lisa@osafoundation.org 2005-10-15 16:20 ------- > Done for -08. > ... For the record, the change is: Section 8., para. 61: OLD: 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 schema. NEW: 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. ...and I'm happy with this resolution. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 16 11:39:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERAbr-0007k8-Tq for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 11:39:39 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07243 for ; Sun, 16 Oct 2005 11:39:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERAbH-0005my-UT for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 15:39:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERAbH-0005mO-7z for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 15:39:03 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ERAbD-0001zW-Aj for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 15:39:02 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3383B142298; Sun, 16 Oct 2005 08:38:57 -0700 (PDT) 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 30608-04; Sun, 16 Oct 2005 08:38:57 -0700 (PDT) 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 8650E14228E; Sun, 16 Oct 2005 08:38:56 -0700 (PDT) In-Reply-To: <435272CB.2090700@gmx.de> References: <200510152158.j9FLwGar030284@ietf.cse.ucsc.edu> <435272CB.2090700@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <256f3e647f38464992e06858ba7dcbac@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Sun, 16 Oct 2005 08:38:52 -0700 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 1ERAbD-0001zW-Aj 0ae148ea3195ff9bfef453fc654e3e49 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/256f3e647f38464992e06858ba7dcbac@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10107 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 15:39:03 +0000 Content-Transfer-Encoding: 7bit Good catch! I'll update to 3986. lisa On Oct 16, 2005, at 8:33 AM, Julian Reschke wrote: > > bugzilla@soe.ucsc.edu wrote: >> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=9 >> ------- Additional Comments From lisa@osafoundation.org 2005-10-15 >> 14:58 ------- >> Text for the -08 version of the draft: >> Note that "DAV:" uses a scheme name defined solely for >> the purpose of creating this namespace. Using a scheme name alone >> does not create a compliant URI according to > target="RFC2396">RFC2396. Furthermore, 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. > > ... > > Well, > > in the meantime RFC2396 has been obsoleted, and RFC3986 makes "DAV:" a > legal URI > (). > Thus I'd simply this to: > > -- > Note that "DAV:" is an URI scheme name defined solely for > the purpose of creating this namespace. However, defining a new URI > scheme just for the purpose of identifying protocol elements is to be > considered a bad practice, and should not be copied. It is still used > in this protocol revision because of significant existing deployments. > -- > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Sun Oct 16 11:43:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERAfd-0008Rm-DK for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 11:43:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07435 for ; Sun, 16 Oct 2005 11:43:26 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERAf0-0006b9-Hg for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 15:42:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERAf0-0006aU-83 for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 15:42:54 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ERAex-0002Cb-Jp for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 15:42:53 +0000 Received: (qmail invoked by alias); 16 Oct 2005 15:42:47 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 16 Oct 2005 17:42:47 +0200 X-Authenticated: #1915285 Message-ID: <435274E9.3000002@gmx.de> Date: Sun, 16 Oct 2005 17:42:33 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510152327.j9FNRSva000801@ietf.cse.ucsc.edu> In-Reply-To: <200510152327.j9FNRSva000801@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.4 X-W3C-Scan-Sig: lisa.w3.org 1ERAex-0002Cb-Jp becc6270aad935f234af1ee6561600d3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/435274E9.3000002@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10108 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 15:42:54 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |ASSIGNED > > > > ------- Additional Comments From lisa@osafoundation.org 2005-10-15 16:27 ------- > Fixed for draft version -08. > ... The change I see is: Section 9., para. 30: OLD: The If request header is intended to have similar functionality to the If-Match header defined in section 14.24 of RFC2616 [7]. 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 state token is a special token that must never match an actual valid lock token. The purpose of this is described in section 9.5.5. NEW: The If request header is intended to have similar functionality to the If-Match header defined in section 14.24 of RFC2616 [7]. 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 state token is an example of a state token that must never match an actual valid lock token. The purpose of this is described in Section 9.5.3. I'd say "will never match" instead if "must never match", because that's by definition, not because we tell server implementors to behave that way. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 16 11: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 1ERAjs-0001Ss-56 for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 11:47:56 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07611 for ; Sun, 16 Oct 2005 11:47:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERAjG-0008GK-QF for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 15:47:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERAjG-0008Fl-Ca for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 15:47:18 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1ERAjA-0003LF-K0 for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 15:47:17 +0000 Received: (qmail invoked by alias); 16 Oct 2005 15:47:11 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 16 Oct 2005 17:47:11 +0200 X-Authenticated: #1915285 Message-ID: <435275F0.2030806@gmx.de> Date: Sun, 16 Oct 2005 17:46:56 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510152334.j9FNYet0001269@ietf.cse.ucsc.edu> In-Reply-To: <200510152334.j9FNYet0001269@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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERAjA-0003LF-K0 79708d68eda26e5a53acd8754558b63d X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 20] lock token example X-Archived-At: http://www.w3.org/mid/435275F0.2030806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10109 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 15:47:18 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |ASSIGNED > > > > ------- Additional Comments From lisa@osafoundation.org 2005-10-15 16:34 ------- > I think I've got all the strays now, in the text for -08. > ... This doesn't look like an improvement -- the spec now uses syntactically invalid tokens in the "opaquelocktoken" scheme. Could you please make sure that the spec always uses registered URI schemes, and when doing so, uses URIs that are actually syntactically legal? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 16 11:52:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERAo0-0002ZF-KL for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 11:52:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07807 for ; Sun, 16 Oct 2005 11:52:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERAnG-0000Zk-8q for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 15:51:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERAnF-0000Yj-Rx for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 15:51:25 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ERAnC-0004C4-NP for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 15:51:25 +0000 Received: (qmail invoked by alias); 16 Oct 2005 15:51:20 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 16 Oct 2005 17:51:20 +0200 X-Authenticated: #1915285 Message-ID: <435276E9.1040901@gmx.de> Date: Sun, 16 Oct 2005 17:51:05 +0200 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: w3c-dist-auth@w3.org References: <435228CF.3000709@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 1ERAnC-0004C4-NP 03bf422eeb90c52a92da20701e2af8ab X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/435276E9.1040901@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10110 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 15:51:26 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > According to Oxygen's well-formedness test, the version I synchronized > to http://ietf.webdav.org/webdav/rfc2518bis/draft-ietf-webdav- > rfc2518bis.xml (and the version I pulled back down again) is > well-formed. It also goes through the utility at xml.resource.org just > fine. xml2rfc doesn't use a proper XML parser. I don't know about the other one you tried, but the document contains non-ASCII characters which aren't UTF-8 encoded, thus proper XML parsers reject the document because of encoding problems. > I tried to diff the xml file downloaded from my URL vs. the one from > yours and unfortunately the diff is garbage, showing every line > different. It's probably something stupid like line returns, but it's > a pain in the ass figuring out what's actually changed. If you > provide a diff I'll check it out further. Just check for non-ASCII characters. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 16 12:11:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERB6i-0007lQ-B9 for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 12:11:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08717 for ; Sun, 16 Oct 2005 12:11:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERB60-0004kw-Sr for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 16:10:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERB5z-0004kO-Q5 for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 16:10:48 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ERB5v-0008B5-LY for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 16:10:47 +0000 Received: (qmail invoked by alias); 16 Oct 2005 16:10:41 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 16 Oct 2005 18:10:41 +0200 X-Authenticated: #1915285 Message-ID: <43527B6F.3000506@gmx.de> Date: Sun, 16 Oct 2005 18:10:23 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERB5v-0008B5-LY 9d5aba3dd1068c9ce11d5ba4e93af25b X-Original-To: w3c-dist-auth@w3.org Subject: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/43527B6F.3000506@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10111 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 16:10:48 +0000 Content-Transfer-Encoding: 7bit Hi, I was looking at the current edits and couldn't help noticing that it again contains stuff that wasn't announced at all. As far as I can tell, drafts submitted to the IETF should optimally represent the working group's consensus, and putting in stuff silently into the working edits doesn't seem to be the best way to achieve this. In particular: 1) "Hosting malicious scripts executed on client machines" (http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.19.8>) looks interesting; but I don't see an issue raised for this topic. In particular, the recommendation to strip script from HTML pages looks a fishy (upon GET? PUT? for all users?). This certainly needs more discussion if this should be added to the spec. 2) Summary of changes from RFC2518 (): > B.3.1 Summary of changes from RFC2518 > > 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. Really? I think readers of the spec really would prefer to have a complete (not only a "more complete") list right here. > B.3.1.1 Changes Notable to Server Implementors > > Tightened requirements for storing property values (Section 4.4) > 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 > (Section 8.1), including response bodies for use with errors, use of > Date header, ETag and Location header. - The response bodies for errors are optional, right? - What did change regarding the other response headers? > Tightened requirements for URL construction in PROPFIND (Section 8.2) > responses. > > Tightened requirements for checking identity of lock owners > (Section 7.1) during operations affected by locks. > > Tightened requirements for copying properties (Section 8.9.2) and > moving properties (Section 8.10.1). (to be discussed) > Tightened requirements on preserving owner field in locks > (Section 8.11). Added "lockroot" element to lockdiscovery > information. > > New value for "DAV:" header (Section 9.1) to advertise support for > this specification. > > Tightened requirement for "Destination:" header (Section 9.3) to > work with path values > > New "Force-Authentication:" (Section 9.4) header added. > > Several changes for "If:" header (Section 9.5), including requirement > to accept commas and "DAV:no-lock" state token. "DAV:no-lock" is no new requirement. > Support for UTF-16 now required (ref (Section 18)). I don't think the requirement changed. The spec merely wasn't properly repeating what XML defines, and this was fixed. > Removed definition of "source" property and special handling for > dynamic resources > > Replaced lock-null resources with simpler locked empty resources > (Section 7.6) > > B.3.1.2 Changes Notable to Client Implementors > > Tightened requirements for supporting WebDAV collections > (Section 5.2) 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. That affects servers as well, right? Maybe splitting the list in two parts isn't worthwhile. > Required to handle empty multistatus responses in PROPFIND responses > (Section 8.2) > > No more "propertybehavior" specification allowed in MOVE and COPY > requests > > Support for UTF-16 now required (ref (Section 18)). > > Removed definition of "source" property and special handling for > dynamic resources. Missing changes: - PROPFIND dead-props () - implicit lock refresh removed (see ) ...and potentially more. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 16 12:30:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERBP1-0004nE-HS for webdav-archive@megatron.ietf.org; Sun, 16 Oct 2005 12:30:27 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09510 for ; Sun, 16 Oct 2005 12:30:20 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERBOH-0008IN-H5 for w3c-dist-auth-dist@listhub.w3.org; Sun, 16 Oct 2005 16:29:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERBOH-0008Hk-3x for w3c-dist-auth@listhub.w3.org; Sun, 16 Oct 2005 16:29:41 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ERBO8-0003Eq-Nq for w3c-dist-auth@w3.org; Sun, 16 Oct 2005 16:29:40 +0000 Received: (qmail invoked by alias); 16 Oct 2005 16:29:30 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 16 Oct 2005 18:29:30 +0200 X-Authenticated: #1915285 Message-ID: <43527FD9.4020007@gmx.de> Date: Sun, 16 Oct 2005 18:29:13 +0200 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: w3c-dist-auth@w3.org References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> In-Reply-To: <435276E9.1040901@gmx.de> 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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERBO8-0003Eq-Nq 4a3731df79f38bf0f937febb5f055469 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/43527FD9.4020007@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10112 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Oct 2005 16:29:41 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09510 Julian Reschke wrote: >> I tried to diff the xml file downloaded from my URL vs. the one from =20 >> yours and unfortunately the diff is garbage, showing every line =20 >> different. It's probably something stupid like line returns, but=20 >> it's a pain in the ass figuring out what's actually changed. If=20 >> you provide a diff I'll check it out further. >=20 >=20 > Just check for non-ASCII characters. For instance: > xsltproc rfc2629.xslt draft-ietf-webdav-rfc2518bis-latest.xml draft-ietf-webdav-rfc2518bis-latest.xml:1014: error: Input is not proper=20 UTF-8, indicate encoding ! because it is acting with principal A=A1s credential, is allowed to ^ draft-ietf-webdav-rfc2518bis-latest.xml:1014: error: Bytes: 0xA1 0x73=20 0x20 0x63 because it is acting with principal A=A1s credential, is allowed to ^ unable to parse draft-ietf-webdav-rfc2518bis-latest.xml From w3c-dist-auth-request@frink.w3.org Mon Oct 17 15:27:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERadz-0002FM-Pm for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:27:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02427 for ; Mon, 17 Oct 2005 15:27:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERacE-0001Ej-N3 for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 19:25:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERacC-0001EB-Gs for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 19:25:44 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ERac1-0006yb-Cw for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 19:25:43 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C4CEC14228C; Mon, 17 Oct 2005 12:25:09 -0700 (PDT) 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 29179-06; Mon, 17 Oct 2005 12:25:09 -0700 (PDT) Received: from [192.168.101.91] (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 9B7C2142280; Mon, 17 Oct 2005 12:25:04 -0700 (PDT) In-Reply-To: <43527B6F.3000506@gmx.de> References: <43527B6F.3000506@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: WebDav WG , Barry Lind From: Lisa Dusseault Date: Mon, 17 Oct 2005 12:24:53 -0700 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 1ERac1-0006yb-Cw 2c0cae81a2797459b78b256ee129e7be X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/abcdbd310ea83c847b1a708e67c27c66@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10113 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 19:25:46 +0000 Content-Transfer-Encoding: 7bit The text on hosting malicious scripts was suggested by Barry Lind. I put in the summary of changes in response to your suggestion on the phone, Julian. Cullen, could you please respond about putting proposed text in the working copy of the draft either posted at ietf.webdav.org/webdav or submitted to Internet-Drafts archive. Lisa On Oct 16, 2005, at 9:10 AM, Julian Reschke wrote: > > Hi, > > I was looking at the current edits and couldn't help noticing that it > again contains stuff that wasn't announced at all. As far as I can > tell, drafts submitted to the IETF should optimally represent the > working group's consensus, and putting in stuff silently into the > working edits doesn't seem to be the best way to achieve this. > > In particular: > > 1) "Hosting malicious scripts executed on client machines" > (http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis- > latest.html#rfc.section.19.8>) looks interesting; but I don't see an > issue raised for this topic. In particular, the recommendation to > strip script from HTML pages looks a fishy (upon GET? PUT? for all > users?). This certainly needs more discussion if this should be added > to the spec. > > 2) Summary of changes from RFC2518 > ( latest.html#rfc.section.B.3.1>): > >> B.3.1 Summary of changes from RFC2518 >> 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. > > Really? I think readers of the spec really would prefer to have a > complete (not only a "more complete") list right here. > >> B.3.1.1 Changes Notable to Server Implementors >> Tightened requirements for storing property values (Section 4.4) >> 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 >> (Section 8.1), including response bodies for use with errors, use >> of >> Date header, ETag and Location header. > > - The response bodies for errors are optional, right? > - What did change regarding the other response headers? > >> Tightened requirements for URL construction in PROPFIND (Section >> 8.2) >> responses. >> Tightened requirements for checking identity of lock owners >> (Section 7.1) during operations affected by locks. >> Tightened requirements for copying properties (Section 8.9.2) and >> moving properties (Section 8.10.1). > > (to be discussed) > >> Tightened requirements on preserving owner field in locks >> (Section 8.11). Added "lockroot" element to lockdiscovery >> information. >> New value for "DAV:" header (Section 9.1) to advertise support for >> this specification. >> Tightened requirement for "Destination:" header (Section 9.3) to >> work with path values >> New "Force-Authentication:" (Section 9.4) header added. >> Several changes for "If:" header (Section 9.5), including >> requirement >> to accept commas and "DAV:no-lock" state token. > > "DAV:no-lock" is no new requirement. > >> Support for UTF-16 now required (ref (Section 18)). > > I don't think the requirement changed. The spec merely wasn't properly > repeating what XML defines, and this was fixed. > >> Removed definition of "source" property and special handling for >> dynamic resources >> Replaced lock-null resources with simpler locked empty resources >> (Section 7.6) >> B.3.1.2 Changes Notable to Client Implementors >> Tightened requirements for supporting WebDAV collections >> (Section 5.2) 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. > > That affects servers as well, right? Maybe splitting the list in two > parts isn't worthwhile. > >> Required to handle empty multistatus responses in PROPFIND >> responses >> (Section 8.2) >> No more "propertybehavior" specification allowed in MOVE and COPY >> requests >> Support for UTF-16 now required (ref (Section 18)). >> Removed definition of "source" property and special handling for >> dynamic resources. > > Missing changes: > > - PROPFIND dead-props > ( latest.html#rfc.section.13.28>) > > - implicit lock refresh removed (see > latest.html#rfc.section.B.1.1>) > > ...and potentially more. > > Best regards, Julian > > From w3c-dist-auth-request@frink.w3.org Mon Oct 17 15:48:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERayg-0006d4-QH for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:48:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03341 for ; Mon, 17 Oct 2005 15:48:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERaxr-00087J-Uf for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 19:48:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERaxq-00086f-1P for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 19:48:06 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ERaxg-0005BK-3G for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 19:48:05 +0000 Received: (qmail invoked by alias); 17 Oct 2005 19:47:53 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 17 Oct 2005 21:47:53 +0200 X-Authenticated: #1915285 Message-ID: <4353FFCC.2030404@gmx.de> Date: Mon, 17 Oct 2005 21:47:24 +0200 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 , Barry Lind References: <43527B6F.3000506@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 1ERaxg-0005BK-3G da2ef191140cb4c5cb62ab1294ac6fc9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/4353FFCC.2030404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10114 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 19:48:07 +0000 Content-Transfer-Encoding: 7bit Clarifying... I'd like to see stuff put into the draft *after* it has been discussed on the list, or at least that changes that are made are announced to the list for review. In the past, people have burned lots of cycles trying to find out what changed without notice, and reporting issues with these changes. It would really be nice if we could avoid that in the future. Best regards, Julian Lisa Dusseault wrote: > > > The text on hosting malicious scripts was suggested by Barry Lind. > > I put in the summary of changes in response to your suggestion on the > phone, Julian. > > Cullen, could you please respond about putting proposed text in the > working copy of the draft either posted at ietf.webdav.org/webdav or > submitted to Internet-Drafts archive. > > Lisa > > On Oct 16, 2005, at 9:10 AM, Julian Reschke wrote: > >> >> Hi, >> >> I was looking at the current edits and couldn't help noticing that it >> again contains stuff that wasn't announced at all. As far as I can >> tell, drafts submitted to the IETF should optimally represent the >> working group's consensus, and putting in stuff silently into the >> working edits doesn't seem to be the best way to achieve this. >> >> In particular: >> >> 1) "Hosting malicious scripts executed on client machines" >> (http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis- >> latest.html#rfc.section.19.8>) looks interesting; but I don't see an >> issue raised for this topic. In particular, the recommendation to >> strip script from HTML pages looks a fishy (upon GET? PUT? for all >> users?). This certainly needs more discussion if this should be added >> to the spec. >> >> 2) Summary of changes from RFC2518 >> (> latest.html#rfc.section.B.3.1>): >> >>> B.3.1 Summary of changes from RFC2518 >>> 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. >> >> >> Really? I think readers of the spec really would prefer to have a >> complete (not only a "more complete") list right here. >> >>> B.3.1.1 Changes Notable to Server Implementors >>> Tightened requirements for storing property values (Section 4.4) >>> 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 >>> (Section 8.1), including response bodies for use with errors, use of >>> Date header, ETag and Location header. >> >> >> - The response bodies for errors are optional, right? >> - What did change regarding the other response headers? >> >>> Tightened requirements for URL construction in PROPFIND (Section >>> 8.2) >>> responses. >>> Tightened requirements for checking identity of lock owners >>> (Section 7.1) during operations affected by locks. >>> Tightened requirements for copying properties (Section 8.9.2) and >>> moving properties (Section 8.10.1). >> >> >> (to be discussed) >> >>> Tightened requirements on preserving owner field in locks >>> (Section 8.11). Added "lockroot" element to lockdiscovery >>> information. >>> New value for "DAV:" header (Section 9.1) to advertise support for >>> this specification. >>> Tightened requirement for "Destination:" header (Section 9.3) to >>> work with path values >>> New "Force-Authentication:" (Section 9.4) header added. >>> Several changes for "If:" header (Section 9.5), including >>> requirement >>> to accept commas and "DAV:no-lock" state token. >> >> >> "DAV:no-lock" is no new requirement. >> >>> Support for UTF-16 now required (ref (Section 18)). >> >> >> I don't think the requirement changed. The spec merely wasn't >> properly repeating what XML defines, and this was fixed. >> >>> Removed definition of "source" property and special handling for >>> dynamic resources >>> Replaced lock-null resources with simpler locked empty resources >>> (Section 7.6) >>> B.3.1.2 Changes Notable to Client Implementors >>> Tightened requirements for supporting WebDAV collections >>> (Section 5.2) 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. >> >> >> That affects servers as well, right? Maybe splitting the list in two >> parts isn't worthwhile. >> >>> Required to handle empty multistatus responses in PROPFIND >>> responses >>> (Section 8.2) >>> No more "propertybehavior" specification allowed in MOVE and COPY >>> requests >>> Support for UTF-16 now required (ref (Section 18)). >>> Removed definition of "source" property and special handling for >>> dynamic resources. >> >> >> Missing changes: >> >> - PROPFIND dead-props >> (> latest.html#rfc.section.13.28>) >> >> - implicit lock refresh removed (see >> > latest.html#rfc.section.B.1.1>) >> >> ...and potentially more. >> >> Best regards, Julian >> >> > > > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17:21:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcQW-0001Cu-KL for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:21:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06596 for ; Mon, 17 Oct 2005 17:21:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERcPY-0000Qi-Fu for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:20:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERcPV-0000Pa-9R; Mon, 17 Oct 2005 21:20:45 +0000 Received: from rgminet04.oracle.com ([148.87.122.33]) by maggie.w3.org with esmtp (Exim 4.50) id 1ERcPP-0007QL-9P; Mon, 17 Oct 2005 21:20:44 +0000 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet04.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j9HLKN8E018959; Mon, 17 Oct 2005 15:20:23 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j9HLKNlg019619; Mon, 17 Oct 2005 15:20:23 -0600 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-233.vpn.oracle.com [141.144.96.233]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j9HLKFqg018896; Mon, 17 Oct 2005 15:20:17 -0600 Message-ID: <43541591.6080307@oracle.com> Date: Mon, 17 Oct 2005 17:20:17 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: Lisa Dusseault CC: Julian Reschke , Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> <3e3690da7043c971ea5594190ac125d7@osafoundation.org> <434EB722.10609@gmx.de> <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> In-Reply-To: <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> Content-Type: text/plain; charset=Big5 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rgminet04.oracle.com id j9HLKN8E018959 Received-SPF: none (maggie.w3.org: 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: maggie.w3.org 1ERcPP-0007QL-9P e93b5ce9037a7542604b0010aae57be2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/43541591.6080307@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10115 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:20:48 +0000 Content-Transfer-Encoding: quoted-printable Lisa, Based on my reading of the book "Effective XML" (http://www.cafeconleche.org/books/effectivexml/) Item 10: White space matters WebDAV servers should preserve the white spaces when the attribute "xml:space" is set to "preserve". Else, if "xml:space" is not set or set to "default" "the application may treat white spaces in the element in whatever fashion is customary for that application". Item 21: Rely on namespace URIs, not prefixes A WebDAV server should be allowed to change any namespace prefix. "It's the URI that counts, not the prefix". BTW, I highly recommend reading "Effective XML" to anyone that works with XML. Cheers, Bernard Lisa Dusseault wrote: > I guess what's giving me so much cognitive dissonance here is that=20 > prefixes now are not preserved but whitespace is. That seems=20 > inconsistent to me -- if some XML rewriting is OK but other XML isn't,=20 > what's the difference. >=20 > Lisa >=20 > On Oct 13, 2005, at 12:36 PM, Julian Reschke wrote: >=20 > Lisa Dusseault wrote: >=20 > On Oct 13, 2005, at 12:07 PM, Julian Reschke wrote: >=20 > Actually what I'm asking for is that we don't change the > text unless there clearly is a consensus to do so. The > current spec says whitespace is significant, and as far as = I > can tell, nobody has asked for a change of that. >=20 > Fair enough, although now I'm thinking we should be specific > about XML values, and about the beginning/end of the value as > well as the middle. I was thinking that the existing text in > 2518 applied only to text property values. >=20 >=20 > From : >=20 > --=20 > 107 >=20 >=20 > IS_XMLSPACE_SIGNIFICANT >=20 >=20 > Edit >=20 >=20 > InBis >=20 >=20 > Should the xml:space attribute be respected.=A1Z 2518bis on 6/1/02 = says > it should not. There is some debate on this. >=20 >=20 > Re-raised: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0137.h= tml >=20 >=20 > The conclusion of the May/June 2002 discussion was that white space > is significant: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0152.h= tml > --=20 >=20 > So the old issues list says this was discussed, that there was > consensus, and that rfc2518bis has been changed accordingly. >=20 > If you want to re-open the issue, please do so (but in a different > thread). If you do, please make sure to clarify what was wrong the > resolution we reached back then. >=20 > I'm still very curious to hear what implementations do/assume; > that's good input to see if the consensus is consistent with th= e > spec. >=20 >=20 > Do you have any data about servers that get that wrong? That would > be interesting indeed. >=20 > Best regards, Julian >=20 >=20 From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17:25:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcUD-0004Ph-N7 for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:25:37 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06936 for ; Mon, 17 Oct 2005 17:25:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERcTb-00010w-EE for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:24:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERcTa-00010M-Tv for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 21:24:58 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1ERcTX-0006VH-UM for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 21:24:57 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2005 14:24:53 -0700 X-IronPort-AV: i="3.97,225,1125903600"; d="scan'208"; a="220996946:sNHT3710602886" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9HLOnub013033; Mon, 17 Oct 2005 14:24:50 -0700 (PDT) Received: from 10.21.97.87 ([10.21.97.87]) by sea-alpha-e2k3.sea-alpha.cisco.com ([10.93.132.88]) with Microsoft Exchange Server HTTP-DAV ; Mon, 17 Oct 2005 21:30:15 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Mon, 17 Oct 2005 11:58:34 -0700 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: WebDav Message-ID: Thread-Topic: Appropriate partial success codes (was Re: Some questions about WebDAV) Thread-Index: AcXTTMXVBJpNpD9AEdqe+gARJEEJ/A== In-Reply-To: <43527338.3030200@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.6 X-W3C-Scan-Sig: lisa.w3.org 1ERcTX-0006VH-UM e70cc4c5b1237570b07d506f0d697108 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/BF79426A.55A6E%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10116 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:24:59 +0000 Content-Transfer-Encoding: 7bit Do you really think this should be removed from the final RFC? On the call the other day I though you were going to do some testing and come up with some modifications for this text? On 10/16/05 8:35 AM, "Julian Reschke" wrote: > > Hi, > > I note that this paragraph has made it into the current draft at > . > Could you please remove it unless we reach a working group consensus to > add it? > > Thanks, > > Julian > > > Julian Reschke wrote: >> >> Lisa Dusseault wrote: >> >>> >>> This thread from a couple months ago brought up something probably >>> worth clarifying in RFC2518bis. In fact we could usefully constrain >>> servers generally in what status codes MAY or MUST NOT be used inside >>> Multi-Status. I wrote up a strawman draft section for this so we >>> could discuss the specifics: >>> >>> The following status codes MUST NOT be used in Multi-Status >>> responses: 100 Continue, 101 Switching Protocols, 205 Reset Content, >>> 206 Partial Content, 300 Multiple Choices?, 305 Use Proxy, 400 Bad >>> Request, 405 Method Not Allowed, 406 Not Acceptable, 407 Proxy >>> Authentication Required, 411 Length Required, 412 Precondition >>> Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415 >>> Unsupported Media Type, 416 Requested Range Not Satisfiable, 417 >>> Expectation Failed, 501 Not Implemented and 505 HTTP Version Not >>> Supported. >>> >>> The following status codes MAY be used in Multi-Status responses: 200 >>> OK, 201 Created, 301 Moved Permanently, 302 Found, 303 See Other, 307 >>> Temporary Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found >>> and 410 Gone. >>> >>> The following status codes MAY be used in Multi-Status responses, >>> although the meaning might be unclear based only on this >>> specification. Thus, specifications extending WebDAV MAY make use of >>> these status codes in Multi-Status responses but regular WebDAV >>> clients would reasonably be expected to be confused by these: 202 >>> Accepted, 203 Non-Authoritative Information, 204 No Content, 304 Not >>> Modified, 402 Payment Required, 409 Conflict, 408 Request Timeout, >>> 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable >>> and 504 Gateway Timeout. >>> >>> Comments? >> >> >> Yes. >> >> 1) What exactly is the issue this is supposed to solve? >> >> 2) How did you come up with these lists? How do they help a client that >> needs to handle unknown status codes anyway (based on the first digit)? >> For instance, why can 300 not appear in a multistatus? >> >> Best regards, Julian >> >> > From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17: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 1ERcUS-0004Ry-SE for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:25:53 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06955 for ; Mon, 17 Oct 2005 17:25:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERcTs-0001TM-Iz for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:25:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERcTs-0001So-2K; Mon, 17 Oct 2005 21:25:16 +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 1ERcTm-00005n-Vp; Mon, 17 Oct 2005 21:25:15 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2005 14:24:53 -0700 X-IronPort-AV: i="3.97,225,1125903600"; d="scan'208"; a="353275024:sNHT1265929012" 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 j9HLOnJh002667; Mon, 17 Oct 2005 14:24:50 -0700 (PDT) Received: from 10.21.97.87 ([10.21.97.87]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 17 Oct 2005 21:24:55 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Mon, 17 Oct 2005 11:55:24 -0700 From: Cullen Jennings To: Julian Reschke CC: Lisa Dusseault , Geoffrey M Clemm , WebDav , Message-ID: Thread-Topic: Bugzilla issue 10, was: Plan to resolve issues in 2518bis Thread-Index: AcXTTFSVkylsXz8/Edqe+gARJEEJ/A== In-Reply-To: <435160FA.4000401@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.0 X-W3C-Scan-Sig: maggie.w3.org 1ERcTm-00005n-Vp a15b2bdc211e8fde9b2e48ac1dea2ac4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/BF7941AC.55A6D%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10117 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:25:16 +0000 Content-Transfer-Encoding: 7bit Do I have the summary right that there is only one server we know of that preservers namespaces? On 10/15/05 1:05 PM, "Julian Reschke" wrote: > OK, > > in the meantime I have tested round-tripping of property values (using > the attached script). Results for those servers I can currently test with: > > SAP Netweaver: preserves whitespace and namespace prefixes > > Apache/moddav 2.0.54: preserves whitespace, but not namespace prefixes. > > Xythos (whatever release currently running on www.sharemation.com): > preserves whitespace, but not namespace prefixes. Note that is also > looses attributes in the property value (!). > > IIS - will need to test: AFAIR, no mixed content supported at all. > > So yes, those servers that do support mixed content also preserve > whitespace. > > Assuming that IIS is broken anyway (and is not going to be fixed anytime > soon), we could potentially concentrate on Xythos and Apache/mod_dav. > Xythos will need a fix for attribute rounbd-tripping anyway. Regarding > mod_dav, maybe a fix for the missing prefix round-tripping is simple > (anybody listening? Joe?). > > > Best regards, Julian > > > > > ------------------------------------------------------------------------- > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ------------------------------------------------------------------------- > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j9FK5Nuh008046 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17: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 1ERcUT-0004Rz-47 for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:25:53 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06956 for ; Mon, 17 Oct 2005 17:25:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERcTt-0001UN-IQ for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:25:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERcTt-0001Tk-1X for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 21:25:17 +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 1ERcTn-00006i-Ft for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 21:25:16 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2005 14:24:55 -0700 X-IronPort-AV: i="3.97,225,1125903600"; d="scan'208"; a="353275049:sNHT5337697702" 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 j9HLOnJj002667; Mon, 17 Oct 2005 14:24:53 -0700 (PDT) Received: from 10.21.97.87 ([10.21.97.87]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 17 Oct 2005 21:24:58 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Mon, 17 Oct 2005 12:01:50 -0700 From: Cullen Jennings To: Julian Reschke , WebDav Message-ID: Thread-Topic: [Bug 18] no record of consensus for force-authenticate Thread-Index: AcXTTTqoeWBDZj9AEdqe+gARJEEJ/A== In-Reply-To: <435159FA.4080308@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.1 X-W3C-Scan-Sig: maggie.w3.org 1ERcTn-00006i-Ft 5b51bcfe7a767de721e0294e22d2ab7c 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/BF79432E.55A6F%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10118 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:25:17 +0000 Content-Transfer-Encoding: 7bit Out of curiosity, is this something most servers do or something that most people have not implemented? On 10/15/05 12:35 PM, "Julian Reschke" wrote: > Proposed resolution for > : > > History: > > The "force-authenticate" request header was initially proposed by Ilya > Kirnos, and we had a discussion about this back three years ago > > ). > As far as I can tell, the consensus back then was not to define a new > header, but to make use of an "If" request header that was known to > alway evaluate to false instead. > > In January 2003, the WG had an interim meeting hosted by Apple, during > which the problem was discussed again. Unfortunately, there doesn't seem > to be any public record of what was discussed on the second day (which > AFAIR was the day we discussed this topic). (Minutes for day one in > ). > > The "Force-Authentication" header was then introduced in draft 03 > (), > but I can't find any record of a consensus reached on the mailing list. > > I therefore propose to remove the header from the spec, encouraging > those who feel that this feature is needed to solve a real-world problem > to restart the discussion on the mailing list (containing a precise > problem statement, and an analysis why the current spec isn't sufficient > in this regard). > > In addition to removing section 9.4, further changes would be: > > Section 17., para. 11: > OLD: > > 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. > > NEW: > > A resource can explicitly advertise its support for the revisions to > RFC2518 made in this document. Class 1 must be supported as well. > Class 2 MAY be supported. > > > Section 17., para. 13: > OLD: > > o the Force-Authentication header. > > o 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. > > NEW: > > o 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. > > > Section 21., para. 8: > OLD: > > 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. > > NEW: > > 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. Joe Hildebrand contributed > as co-chair. > > > Best regards, Julian > --- draft-ietf-webdav-rfc2518bis-07.xml 2005-10-15 19:19:46.000000000 +0100 > +++ rfc2518bis-08-bug18.xml 2005-10-15 20:29:23.000000000 +0100 > @@ -3112,23 +3112,7 @@ > 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. > - > -
> - > + >
>
> > @@ -4832,15 +4816,13 @@ >
> > 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 > + RFC2518 made in this document. 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 > @@ -5200,8 +5182,7 @@ > 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 > + specific text on the list or in meetings. Joe Hildebrand contributed as > co-chair. > >
From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17:27:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcWG-0005Fh-RW for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:27:44 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07047 for ; Mon, 17 Oct 2005 17:27:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERcVX-0001hu-UJ for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:26:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERcVX-0001hM-Gn for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 21:26:59 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ERcVU-0006z1-Kh for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 21:26:59 +0000 Received: (qmail invoked by alias); 17 Oct 2005 21:26:54 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 17 Oct 2005 23:26:54 +0200 X-Authenticated: #1915285 Message-ID: <43541715.2000509@gmx.de> Date: Mon, 17 Oct 2005 23:26:45 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Desruisseaux CC: Lisa Dusseault , Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> <3e3690da7043c971ea5594190ac125d7@osafoundation.org> <434EB722.10609@gmx.de> <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> <43541591.6080307@oracle.com> In-Reply-To: <43541591.6080307@oracle.com> Content-Type: text/plain; charset=Big5 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 1ERcVU-0006z1-Kh 1c132f8df252ee7ce176e0324d491be6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/43541715.2000509@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10119 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:26:59 +0000 Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Item 21: Rely on namespace URIs, not prefixes > > A WebDAV server should be allowed to change any > namespace prefix. "It's the URI that counts, > not the prefix". > ... It's the W3C who started to treat prefixes as significant; so even though it may have been a bad idea in the first place, the cat is out of the bag. Note that prefixes are also part of the most widely used XML data models (DOM, XPath, XML Infoset). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcbX-00070k-Vq for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:33:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07792 for ; Mon, 17 Oct 2005 17:33:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERcaq-0003sG-SW for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:32:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERcaq-0003rM-FH for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 21:32:28 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1ERcan-0008RW-Vt for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 21:32:27 +0000 Received: (qmail invoked by alias); 17 Oct 2005 21:32:24 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 17 Oct 2005 23:32:24 +0200 X-Authenticated: #1915285 Message-ID: <4354185F.2060703@gmx.de> Date: Mon, 17 Oct 2005 23:32:15 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , 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 (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 1ERcan-0008RW-Vt 94a224ce60b4bd0bc324384378b24d07 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/4354185F.2060703@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10120 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:32:28 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Do I have the summary right that there is only one server we know of that > preservers namespaces? One that preserves namespace URIs and namespace prefixes (SAP), two others that only preserve namespace URIs (Apache/mod_dav and Xythos). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17:33:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcbm-00072D-9Q for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:33:26 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07827 for ; Mon, 17 Oct 2005 17:33:18 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERcbE-0003xX-8b for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:32:52 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERcbD-0003wz-QI for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 21:32:51 +0000 Received: from agminet01.oracle.com ([141.146.126.228]) by maggie.w3.org with esmtp (Exim 4.50) id 1ERcb9-0001VZ-1W for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 21:32:50 +0000 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9HLdC3u027200 for ; Mon, 17 Oct 2005 16:39:12 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j9HLWiet004629 for ; Mon, 17 Oct 2005 15:32:44 -0600 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-233.vpn.oracle.com [141.144.96.233]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j9HLWaUo004264; Mon, 17 Oct 2005 15:32:38 -0600 Message-ID: <43541877.3020903@oracle.com> Date: Mon, 17 Oct 2005 17:32:39 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: WebDAV WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Received-SPF: none (maggie.w3.org: 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: maggie.w3.org 1ERcb9-0001VZ-1W a4580599b0fb3eaea6be34e9cb73ef27 X-Original-To: w3c-dist-auth@w3.org Subject: RFC2445bis: "424 Failed Dependency" missing in section "8.3.1 Status Codes for use with 207 (Multi-Status)" X-Archived-At: http://www.w3.org/mid/43541877.3020903@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10121 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:32:52 +0000 Content-Transfer-Encoding: 7bit The response to PROPPATCH in Section "8.3.2 Example - PROPPATCH" contains a HTTP/1.1 424 Failed Dependency, but the status code "424 Failed Dependency" is not listed in Section "8.3.1 Status Codes for use with 207 (Multi-Status)". While the list of status codes in Section 8.3.1 is not necessarily exhaustive, I think the status code 424 should definitely be mentionned. Cheers, Bernard From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17:36:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcej-0007tf-Fh for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:36:29 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08097 for ; Mon, 17 Oct 2005 17:36:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERceA-0004ix-20 for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:35:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERce8-0004iK-Qz for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 21:35:52 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ERce6-00026d-7a for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 21:35:52 +0000 Received: (qmail invoked by alias); 17 Oct 2005 21:35:49 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 17 Oct 2005 23:35:49 +0200 X-Authenticated: #1915285 Message-ID: <4354192C.5070709@gmx.de> Date: Mon, 17 Oct 2005 23:35:40 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , 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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERce6-00026d-7a efc1336897789cafad9aca85cc53c8fb X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/4354192C.5070709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10122 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:35:54 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Do you really think this should be removed from the final RFC? On the call > the other day I though you were going to do some testing and come up with > some modifications for this text? No, I think this is a misunderstanding. I really feel this text is both misleading, and doesn't resolve any issue I'm aware of. I'd really like all of us to agree on the approach not to make any changes in the original spec unless we have a well-defined issue, and working group consensus how to resolve it. If it ain't broke, don't fix it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 17 17:37:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcfa-00084Y-21 for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:37:22 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08174 for ; Mon, 17 Oct 2005 17:37:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERcez-0004qS-LZ for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 21:36:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERcez-0004pu-83 for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 21:36:45 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ERcew-0002H4-SF for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 21:36:44 +0000 Received: (qmail invoked by alias); 17 Oct 2005 21:36:42 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 17 Oct 2005 23:36:42 +0200 X-Authenticated: #1915285 Message-ID: <4354195C.5090609@gmx.de> Date: Mon, 17 Oct 2005 23:36:28 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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 (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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERcew-0002H4-SF fb802d13174e15dbc803bee222e79f42 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/4354195C.5090609@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10123 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 21:36:45 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Out of curiosity, is this something most servers do or something that most > people have not implemented? I'm not aware of any server implementing this, nor of any client using it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 17 19:25:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReLn-00074J-GN for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 19:25:03 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14589 for ; Mon, 17 Oct 2005 19:24:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EReKW-0002qJ-PZ for w3c-dist-auth-dist@listhub.w3.org; Mon, 17 Oct 2005 23:23:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EReKU-0002pY-7o for w3c-dist-auth@listhub.w3.org; Mon, 17 Oct 2005 23:23:42 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EReKS-0000O3-H3 for w3c-dist-auth@w3.org; Mon, 17 Oct 2005 23:23:42 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5D1D81422A0; Mon, 17 Oct 2005 16:23:39 -0700 (PDT) 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 31994-03; Mon, 17 Oct 2005 16:23:39 -0700 (PDT) Received: from [192.168.101.91] (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 EABF4142279; Mon, 17 Oct 2005 16:23:38 -0700 (PDT) In-Reply-To: <4354195C.5090609@gmx.de> References: <4354195C.5090609@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav , Cullen Jennings From: Lisa Dusseault Date: Mon, 17 Oct 2005 16:23:33 -0700 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 1EReKS-0000O3-H3 dafea6f1daaca68f916cde98877df4e9 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/7f41642fbdb24d201540e74aacfa5421@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10124 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Oct 2005 23:23:44 +0000 Content-Transfer-Encoding: 7bit Me neither, but as a client implementor, we'd certainly like to use this or a reasonable substitute. We have configuration information about the user's account/password on WebDAV servers, and can't even use it until the server thinks to do an authentication challenge. Lisa On Oct 17, 2005, at 2:36 PM, Julian Reschke wrote: > > Cullen Jennings wrote: >> Out of curiosity, is this something most servers do or something that >> most >> people have not implemented? > > I'm not aware of any server implementing this, nor of any client using > it. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Mon Oct 17 20:36:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERfT6-0001Eb-Ob for webdav-archive@megatron.ietf.org; Mon, 17 Oct 2005 20:36:40 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19059 for ; Mon, 17 Oct 2005 20:36:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERfRw-0001r7-Hv for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 00:35:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERfRt-0001pl-Jc for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 00:35:25 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ERfRp-0000CX-6D for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 00:35:24 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C74971422B1; Mon, 17 Oct 2005 17:35:18 -0700 (PDT) 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 02936-05; Mon, 17 Oct 2005 17:35:18 -0700 (PDT) Received: from [192.168.101.91] (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 811161422AF; Mon, 17 Oct 2005 17:35:18 -0700 (PDT) In-Reply-To: <435274E9.3000002@gmx.de> References: <200510152327.j9FNRSva000801@ietf.cse.ucsc.edu> <435274E9.3000002@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: Mon, 17 Oct 2005 17:35:14 -0700 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 1ERfRp-0000CX-6D 2c460901bf1a28ec908b80088ab4ac6b X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/a90c8a4f45c7dbfbab1e9ddce1e4ff46@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10125 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 00:35:28 +0000 Content-Transfer-Encoding: 7bit What about changing it to a MUST? That makes it even more clear (and we will get complaints about lower-case 'must' in the text) Lisa On Oct 16, 2005, at 8:42 AM, Julian Reschke wrote: > > bugzilla@soe.ucsc.edu wrote: >> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19 >> lisa@osafoundation.org changed: >> What |Removed |Added >> ---------------------------------------------------------------------- >> ------ >> Status|NEW |ASSIGNED >> ------- Additional Comments From lisa@osafoundation.org 2005-10-15 >> 16:27 ------- >> Fixed for draft version -08. >> ... > > The change I see is: > > Section 9., para. 30: > OLD: > > The If request header is intended to have similar functionality to > the If-Match header defined in section 14.24 of RFC2616 [7]. > 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 state token is a special token that must never > match an actual valid lock token. The purpose of this is described > in section 9.5.5. > > NEW: > > The If request header is intended to have similar functionality to > the If-Match header defined in section 14.24 of RFC2616 [7]. > 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 state token is an example of a state token that > must never match an actual valid lock token. The purpose of this is > described in Section 9.5.3. > > > I'd say "will never match" instead if "must never match", because > that's by definition, not because we tell server implementors to > behave that way. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Tue Oct 18 03:14:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERlgO-0003VR-VF for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 03:14:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09348 for ; Tue, 18 Oct 2005 03:14:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERleu-0006ZV-9B for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 07:13:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERles-0006Yt-4S for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 07:13:14 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ERleo-0001Sn-UX for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 07:13:13 +0000 Received: (qmail invoked by alias); 18 Oct 2005 07:13:09 -0000 Received: from p508FB983.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.185.131] by mail.gmx.net (mp017) with SMTP; 18 Oct 2005 09:13:09 +0200 X-Authenticated: #1915285 Message-ID: <4354A080.9030309@gmx.de> Date: Tue, 18 Oct 2005 09:13:04 +0200 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: w3c-dist-auth@w3.org References: <200510152327.j9FNRSva000801@ietf.cse.ucsc.edu> <435274E9.3000002@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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERleo-0001Sn-UX d7a27ecde92f2691364c3de2eeae837b X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/4354A080.9030309@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10126 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 07:13:16 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > What about changing it to a MUST? That makes it even more clear (and > we will get complaints about lower-case 'must' in the text) Again: this follows by definition (only an IETF document/activity cab put things into the DAV: namespace, thus a URI using the DAV: scheme never can identify a valid lock token). Furthermore, keep in mind that RFC2119 explicitly asks for using capitalized words sparingly. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Oct 18 03: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 1ERmJ6-0006P4-Nh for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 03:54:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11065 for ; Tue, 18 Oct 2005 03:54:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERmHJ-0007hJ-UX for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 07:52:57 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERmHH-0007gg-GS for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 07:52:55 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ERmHD-0002hg-PO for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 07:52:54 +0000 Received: (qmail invoked by alias); 18 Oct 2005 07:52:50 -0000 Received: from p508FB983.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.185.131] by mail.gmx.net (mp012) with SMTP; 18 Oct 2005 09:52:50 +0200 X-Authenticated: #1915285 Message-ID: <4354A9CA.1020106@gmx.de> Date: Tue, 18 Oct 2005 09:52:42 +0200 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 , Cullen Jennings References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> In-Reply-To: <7f41642fbdb24d201540e74aacfa5421@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.4 X-W3C-Scan-Sig: maggie.w3.org 1ERmHD-0002hg-PO 70b880843b41bb45f9f3418ae3a0fa4f 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/4354A9CA.1020106@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10127 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 07:52:57 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Me neither, but as a client implementor, we'd certainly like to use this > or a reasonable substitute. We have configuration information about the > user's account/password on WebDAV servers, and can't even use it until > the server thinks to do an authentication challenge. As it has been in drafts for 2.5 years with nobody implementing it, I'd say it doesn't belong into a spec revision that's supposed to advance in the standards ladder. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Oct 18 07:04:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERpGF-0003LI-EO for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 07:04:03 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21261 for ; Tue, 18 Oct 2005 07:03:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERpEv-00012A-5T for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 11:02:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERpEs-00011Q-Ts for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 11:02:38 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ERpEn-00053P-N5 for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 11:02:38 +0000 Received: (qmail invoked by alias); 18 Oct 2005 11:02:30 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 18 Oct 2005 13:02:30 +0200 X-Authenticated: #1915285 Message-ID: <4354D63B.5050201@gmx.de> Date: Tue, 18 Oct 2005 13:02:19 +0200 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: w3c-dist-auth@w3.org References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> In-Reply-To: <43527FD9.4020007@gmx.de> Content-Type: multipart/mixed; boundary="------------080106020101080206070008" 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 1ERpEn-00053P-N5 d770ee59f4d2d9d216af0a8a7ee014f3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/4354D63B.5050201@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10128 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 11:02:41 +0000 This is a multi-part message in MIME format. --------------080106020101080206070008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit OK, > I tried to diff the xml file downloaded from my URL vs. the one from yours and unfortunately the diff is garbage, showing every line different. It's probably something stupid like line returns, but it's a pain in the ass figuring out what's actually changed. If you provide a diff I'll check it out further. attached is a patch for the file that was on as of today. Best regards, Julian --------------080106020101080206070008 Content-Type: text/plain; name="diff" Content-Disposition: inline; filename="diff" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA21261 1a2 > 22c23 < --- > 43c44 < --- > 1014c1015 < because it is acting with principal A=A1s credential, is allowed to=20 --- > because it is acting with principal A's credential, is allowed to=20 1358c1359 < If a server allows resource names to include characters that aren=A1= t=20 --- > If a server allows resource names to include characters that aren't=20 2392c2393 < 412 (Precondition Failed) =A4 A condition failed, e.g. the Overwrite= =20 --- > 412 (Precondition Failed) - A condition failed, e.g. the Overwrite=20 3582c3583 < full URIs aren=A1t used in other headers. WebDAV specifies full URLs= =20 --- > full URIs aren't used in other headers. WebDAV specifies full URLs=20 4395c4396 < not cause a resource=A1s ETag to change. --- > not cause a resource's ETag to change. 4458,4459c4459,4460 < =89activelock=A1 elements. If there is one or more lock, a= n=20 < =89activelock=A1 element appears for each lock on the resou= rce. =20 --- > "activelock" elements. If there is one or more lock, an=20 > "activelock" element appears for each lock on the resource.= =20 --------------080106020101080206070008-- From w3c-dist-auth-request@frink.w3.org Tue Oct 18 08:09:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqHG-0000YP-1A for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 08:09:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25591 for ; Tue, 18 Oct 2005 08:09:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERqG6-0007ch-K7 for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 12:07:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ERqG4-0007c9-4V for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 12:07:56 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by maggie.w3.org with esmtp (Exim 4.50) id 1ERqG0-00016m-NZ for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 12:07:55 +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 j9IC6748018679 for ; Tue, 18 Oct 2005 08:06:07 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9IC67Cc077422 for ; Tue, 18 Oct 2005 08:06:07 -0400 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 j9IC6715024249 for ; Tue, 18 Oct 2005 08:06:07 -0400 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 j9IC67kl024244 for ; Tue, 18 Oct 2005 08:06:07 -0400 In-Reply-To: <4354192C.5070709@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, 18 Oct 2005 08:06:15 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/18/2005 08:06:07, Serialize complete at 10/18/2005 08:06:07 Content-Type: multipart/alternative; boundary="=_alternative 0041FE1A8525709E_=" 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 1ERqG0-00016m-NZ 9d0d99450c96854de157f18d3ee475d6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/OFB81D6447.8D137C1F-ON8525709E.00417F6C-8525709E.00427DCE@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10129 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 12:07:58 +0000 This is a multipart message in MIME format. --=_alternative 0041FE1A8525709E_= Content-Type: text/plain; charset="US-ASCII" I agree that this should be removed from the draft text until we have consensus that this resolves some significant issue (and like Julian, I have not seen a compelling argument that it does). And I agree that changes should not be made to the current draft until there is at least consensus on the mailing list that there is a well-defined issue that needs to be addressed. Cheers, Geoff Julian wrote on 10/17/2005 05:35:40 PM: > > Cullen Jennings wrote: > > Do you really think this should be removed from the final RFC? On the call > > the other day I though you were going to do some testing and come up with > > some modifications for this text? > > No, I think this is a misunderstanding. I really feel this text is both > misleading, and doesn't resolve any issue I'm aware of. > > I'd really like all of us to agree on the approach not to make any > changes in the original spec unless we have a well-defined issue, and > working group consensus how to resolve it. If it ain't broke, don't fix it. > > Best regards, Julian > --=_alternative 0041FE1A8525709E_= Content-Type: text/html; charset="US-ASCII"
I agree that this should be removed from the draft text until we have
consensus that this resolves some significant issue (and like Julian,
I have not seen a compelling argument that it does).

And I agree that changes should not be made to the current draft until there
is at least consensus on the mailing list that there is a well-defined issue
that needs to be addressed.

Cheers,
Geoff

Julian wrote on 10/17/2005 05:35:40 PM:

>
> Cullen Jennings wrote:
> > Do you really think this should be removed from the final RFC? On the call
> > the other day I though you were going to do some testing and come up with
> > some modifications for this text?
>
> No, I think this is a misunderstanding. I really feel this text is both
> misleading, and doesn't resolve any issue I'm aware of.
>
> I'd really like all of us to agree on the approach not to make any
> changes in the original spec unless we have a well-defined issue, and
> working group consensus how to resolve it. If it ain't broke, don't fix it.
>
> Best regards, Julian
>
--=_alternative 0041FE1A8525709E_=-- From w3c-dist-auth-request@frink.w3.org Tue Oct 18 12:22:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuEG-0002nw-8l for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 12:22:20 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12868 for ; Tue, 18 Oct 2005 12:22:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERuCu-0003SE-G9 for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 16:20:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERuCs-0003RZ-6M for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 16:20:54 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ERuCk-0001pL-BV for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 16:20:54 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 132321422A8; Tue, 18 Oct 2005 09:20:45 -0700 (PDT) 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 08005-02; Tue, 18 Oct 2005 09:20:44 -0700 (PDT) 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 7530A1422A0; Tue, 18 Oct 2005 09:20:44 -0700 (PDT) In-Reply-To: <4354A9CA.1020106@gmx.de> References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@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: Lisa Dusseault Date: Tue, 18 Oct 2005 09:20:41 -0700 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 1ERuCk-0001pL-BV 6bdb0b4f25ec7d9faf25708346592a0e 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/b76464e601276f4b21da0b1fe457ce24@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10130 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 16:20:56 +0000 Content-Transfer-Encoding: 7bit Nobody says they implement 'bis' yet, as far as I know. And clients can't support it until the server does. Lisa On Oct 18, 2005, at 12:52 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> Me neither, but as a client implementor, we'd certainly like to use >> this or a reasonable substitute. We have configuration information >> about the user's account/password on WebDAV servers, and can't even >> use it until the server thinks to do an authentication challenge. > > As it has been in drafts for 2.5 years with nobody implementing it, > I'd say it doesn't belong into a spec revision that's supposed to > advance in the standards ladder. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Oct 18 14:25:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERw93-0002iT-Pd for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 14:25:05 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20643 for ; Tue, 18 Oct 2005 14:24:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERw7m-0001xm-VG for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 18:23:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERw7k-0001xA-4f for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 18:23:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ERw7c-000422-Mv for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 18:23:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9IINZCw029195; Tue, 18 Oct 2005 11:23:35 -0700 Date: Tue, 18 Oct 2005 11:23:35 -0700 Message-Id: <200510181823.j9IINZCw029195@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 1ERw7c-000422-Mv dada11f03dad76d015344bad2e432b54 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/200510181823.j9IINZCw029195@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10131 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 18:23:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26 julian.reschke@greenbytes.de 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 Tue Oct 18 14:58:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwf9-00063f-C0 for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 14:58:15 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22159 for ; Tue, 18 Oct 2005 14:58:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERweP-0001rY-D9 for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 18:57:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERweN-0001qt-0R for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 18:57:27 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1ERweI-0005N3-9s for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 18:57:26 +0000 Received: (qmail invoked by alias); 18 Oct 2005 18:57:20 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 18 Oct 2005 20:57:20 +0200 X-Authenticated: #1915285 Message-ID: <4355456A.6000307@gmx.de> Date: Tue, 18 Oct 2005 20:56:42 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510181823.j9IINZCw029195@ietf.cse.ucsc.edu> In-Reply-To: <200510181823.j9IINZCw029195@ietf.cse.ucsc.edu> Content-Type: multipart/mixed; boundary="------------070409070905010002090203" 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 1ERweI-0005N3-9s 3ceacaa942e630acc77c53332e901ba1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/4355456A.6000307@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10132 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 18:57:29 +0000 This is a multi-part message in MIME format. --------------070409070905010002090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA22159 Proposed resolution for=20 : As far as I can tell, the current draft of RFC2518bis changes the end of=20 the description for PROPFIND from: "All servers MUST support returning a response of content type text/xml=20 or application/xml that contains a multistatus XML element that=20 describes the results of the attempts to retrieve the various 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 with=20 member URIs MUST include a response XML element for each member URI of=20 the collection, to whatever depth was requested. Each response XML=20 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 significan= t. 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 text/xml=20 or application/xml that contains a multistatus XML element that=20 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 with=20 member URLs MUST include a response XML element for each member URL of=20 the collection, to whatever depth was requested. Each response XML=20 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 internal=20 member URLs are returned as a flat list whose order of entries is not=20 significant. A server enumerating the members of a collection using absolute URLs in=20 a PROPFIND response MUST use a common prefix in those URLs, and that=20 prefix MUST be the absolute URL used in the response to refer to the=20 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 was=20 used to refer to the parent collection in the PROPFIND request. Servers=20 MAY use an alternate URL for the parent collection in a PROPFIND=20 response, but in this case the server MUST include a Content-Location=20 header whose value is the fully-qualified URL used by the server to=20 refer to the parent collection in this response. URLs in a PROPFIND response body MAY be represented as fully- qualified=20 URLs, in which case they must all contain the full parent collection URL=20 (scheme, host, port, and absolute path). Alternatively, these URLs MAY=20 be absolute paths (not containing scheme, host or port), but in this=20 case they must all still contain the full parent 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 and=20 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 () 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 in=20 slashes that as far as I can tell has no WG consensus - it incorrectly claims that PROPFIND may result in an empty multistatus=20 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 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 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 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 --------------070409070905010002090203 Content-Type: text/plain; name="26.diff" Content-Disposition: inline; filename="26.diff" Content-Transfer-Encoding: 7bit --- draft-ietf-webdav-rfc2518bis-latest.xml 2005-10-18 19:36:56.000000000 +0100 +++ draft-ietf-webdav-rfc2518bis-latest.26.xml 2005-10-18 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 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 + are defined (see + 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. - - - 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 - 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 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. + order of entries is not significant. Properties may be subject to access control. In the case of allprop @@ -3923,7 +3890,7 @@
-
+
multistatus DAV: --------------070409070905010002090203-- From w3c-dist-auth-request@frink.w3.org Tue Oct 18 16:30:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERy6g-00042g-Hd for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 16:30:47 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08841 for ; Tue, 18 Oct 2005 16:30:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERy4q-0000eF-O7 for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 20:28:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERy4o-0000df-Ge for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 20:28:50 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1ERy4k-0005E5-9P for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 20:28:49 +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 j9IKSilL014610 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 18 Oct 2005 13:28:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <4354A9CA.1020106@gmx.de> References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Tue, 18 Oct 2005 13:28:43 -0700 To: WebDav X-Mailer: Apple Mail (2.734) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.8 X-W3C-Scan-Sig: lisa.w3.org 1ERy4k-0005E5-9P c3bcfdafb11bbd3504f5b7405c096db7 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/758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10133 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 20:28:52 +0000 Content-Transfer-Encoding: 7bit I support a solution along the lines of force-authenticate. There are many times when a client would like to validate its ability to perform actions against a resource before performing an expensive network operation against that resource. Julian--I don't think lack of implementation is a sufficient counter- argument. Why do you think that this feature hasn't been implemented (why haven't you implemented it, for example?) - Jim From w3c-dist-auth-request@frink.w3.org Tue Oct 18 16:31:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERy7a-0004h2-B3 for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 16:31:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09447 for ; Tue, 18 Oct 2005 16:31:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERy6y-00036F-OS for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 20:31:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERy6y-00035b-5m for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 20:31:04 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1ERy6v-0005rR-Sm for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 20:31:04 +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 j9IKUvov015360 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 18 Oct 2005 13:30:57 -0700 (PDT) In-Reply-To: <4354A080.9030309@gmx.de> References: <200510152327.j9FNRSva000801@ietf.cse.ucsc.edu> <435274E9.3000002@gmx.de> <4354A080.9030309@gmx.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Lisa Dusseault , w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Tue, 18 Oct 2005 13:30:56 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.734) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1ERy6v-0005rR-Sm 9459a922b9280fb1e51d17527ffddef2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/C656232F-AB3D-48F6-82DD-689DC7DE0772@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10134 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 20:31:04 +0000 Content-Transfer-Encoding: 7bit I agree with Julian's suggested text change ("will never match" instead of "must never match"). - Jim On Oct 18, 2005, at 12:13 AM, Julian Reschke wrote: > > Lisa Dusseault wrote: > >> What about changing it to a MUST? That makes it even more clear >> (and we will get complaints about lower-case 'must' in the text) >> > > Again: this follows by definition (only an IETF document/activity > cab put things into the DAV: namespace, thus a URI using the DAV: > scheme never can identify a valid lock token). > > Furthermore, keep in mind that RFC2119 explicitly asks for using > capitalized words sparingly. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Tue Oct 18 16: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 1ERyAe-0006hJ-UQ for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 16:34:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10796 for ; Tue, 18 Oct 2005 16:34:44 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ERyA4-0003L4-0O for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 20:34:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ERyA3-0003KW-Lo for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 20:34:15 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1ERyA0-0006lx-JC for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 20:34: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 j9IKYBpC016414 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 18 Oct 2005 13:34:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <256f3e647f38464992e06858ba7dcbac@osafoundation.org> References: <200510152158.j9FLwGar030284@ietf.cse.ucsc.edu> <435272CB.2090700@gmx.de> <256f3e647f38464992e06858ba7dcbac@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Tue, 18 Oct 2005 13:34:10 -0700 To: WebDav X-Mailer: Apple Mail (2.734) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1ERyA0-0006lx-JC bea75da5038640498bc9f7145c9dad94 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 9] XML namespace discussion X-Archived-At: http://www.w3.org/mid/E26D67F7-56D6-43C1-AEFC-A54761F11487@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10135 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 20:34:16 +0000 Content-Transfer-Encoding: 7bit >> >> in the meantime RFC2396 has been obsoleted, and RFC3986 makes >> "DAV:" a legal URI (> rfc3986.html#rfc.section.D.2.p.4>). Thus I'd simply this to: >> Amazing. Never thought that would happen! - Jim From w3c-dist-auth-request@frink.w3.org Tue Oct 18 18:46:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES0Dx-0007SA-Is for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 18:46:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04763 for ; Tue, 18 Oct 2005 18:46:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ES0Cc-0005t1-83 for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Oct 2005 22:45:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ES0CZ-0005ll-5o for w3c-dist-auth@listhub.w3.org; Tue, 18 Oct 2005 22:44:59 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ES0CV-00053f-Rq for w3c-dist-auth@w3.org; Tue, 18 Oct 2005 22:44:58 +0000 Received: (qmail invoked by alias); 18 Oct 2005 22:44:54 -0000 Received: from p508FB983.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.185.131] by mail.gmx.net (mp026) with SMTP; 19 Oct 2005 00:44:54 +0200 X-Authenticated: #1915285 Message-ID: <43557ADF.2070801@gmx.de> Date: Wed, 19 Oct 2005 00:44:47 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: WebDav References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> In-Reply-To: <758A815E-7329-481A-A184-7F20B4D9B10B@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 (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.4 X-W3C-Scan-Sig: maggie.w3.org 1ES0CV-00053f-Rq 25c1524c992bf496bce50530c16ed10f 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/43557ADF.2070801@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10136 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Oct 2005 22:45:02 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > > I support a solution along the lines of force-authenticate. There are > many times when a client would like to validate its ability to perform > actions against a resource before performing an expensive network > operation against that resource. I don't argue that. The last time the WG (ie, the mailing list) discussed this, the consensus was to use an If header that would be known to fail. There is no written record of what we discussed later at the face to face meeting, and I frankly can't remember. So this is a process issue -- if it's supposed to become part of WebDAV, it has to make it through the process of (1) define what the problem is, then (2) find a WG consensus of how to resolve this. "Force-Authenticate" may very well be the solution. Then again, if we want to *progress* in the standards ladder, I don't think we can put in a MUST-level requirement that hasn't been implemented by anybody although it has been in the draft for 2,5 years. If we're satisfied in just revising the spec at the same standards level, that's a different story (but then we should apply the same metrics to other things we're talking about, such as preserving namespace prefixes in properties which has at least *one* implementation). > Julian--I don't think lack of implementation is a sufficient counter- > argument. Why do you think that this feature hasn't been implemented > (why haven't you implemented it, for example?) We didn't implement it because (1) no client asked for it and (2) our server doesn't support non-authenticated access anyway. On the other hand, Lisa has been working for a vendor that sells both servers and clients, so I'd be really interested to hear why it wasn't implemented over there? Maybe it's not that essential after all? This really smells like a nice-to-have, in which case it certainly doesn't belong into a "Draft" revision of RFC2518bis. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Oct 18 20:01:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1P1-0000KV-Vl for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 20:01:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08055 for ; Tue, 18 Oct 2005 20:01:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ES1Nh-00039I-KA for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 00:00:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ES1Nf-00038j-6Q for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 00:00:31 +0000 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by maggie.w3.org with esmtp (Exim 4.50) id 1ES1NZ-0007Qt-Jd for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 00:00:30 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2005 17:00:24 -0700 Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9J00Iub029297; Tue, 18 Oct 2005 17:00:20 -0700 (PDT) Received: from 10.21.121.34 ([10.21.121.34]) by sea-alpha-e2k3.sea-alpha.cisco.com ([10.93.132.88]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Oct 2005 00:05:44 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Tue, 18 Oct 2005 17:00:17 -0700 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: WebDav , Barry Lind Message-ID: Thread-Topic: new stuff in draft edits Thread-Index: AcXUQBZ5VO9I+EAzEdqLyQARJEEJ/A== In-Reply-To: <4353FFCC.2030404@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.71 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1ES1NZ-0007Qt-Jd ac5f0c772d905286f54ffdb12bf20cb0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/BF7ADAA1.55F01%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10137 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 00:00:33 +0000 Content-Transfer-Encoding: 7bit I just don't think we will every finish if we have to review every single little change on the list before it is made. I would rather assume that the editor of a document can mostly get it right, then fix what they get wrong instead of assuming that they will get it all wrong. We call these things drafts because they are a draft for the WG to review, comment on, and fix. We call the folks writing them an author because they are taking their best stab at coming up with a draft that the WG can form consensus around. Now when it is a WG drafts, such as this one, the author does need to reflect the things WG agreed to into the document because in the end it will not move forward without WG consensus. If the author of a working group document is maliciously failing to put in the things the WG has agreed to, I will find a new author for the document. However, lets not confuse this with the author trying to find some draft text that we can all agree to and then having the WG help refine that text until it is something we can all live with. A natural difficulty with this is that it is non trivial to see all the change to a document. I really don't know any way to solve this other than diff tools. It good to catch the major diffs in the changes section of the document but it's unreasonable to get all the trivial ones. The changes being made to this document are small enough and local enough that it is not that hard to catch them with diff. I'm saying this poorly - it's hard to describe the difference between reasonable changes and an author being way off in left field and introducing garbage that the WG would never agree to. I really like us to focus on what changes to we have to make to draft to get it to the point it is all something we can live with. I hope the bugs are a way of focusing on these issues. Cullen PS. Consider this email a draft :-) I (and we) might have to refine it a few times before I get it right. On 10/17/05 12:47 PM, "Julian Reschke" wrote: > > Clarifying... > > I'd like to see stuff put into the draft *after* it has been discussed > on the list, or at least that changes that are made are announced to the > list for review. In the past, people have burned lots of cycles trying > to find out what changed without notice, and reporting issues with these > changes. It would really be nice if we could avoid that in the future. > > Best regards, Julian > > > > Lisa Dusseault wrote: >> >> >> The text on hosting malicious scripts was suggested by Barry Lind. >> >> I put in the summary of changes in response to your suggestion on the >> phone, Julian. >> >> Cullen, could you please respond about putting proposed text in the >> working copy of the draft either posted at ietf.webdav.org/webdav or >> submitted to Internet-Drafts archive. >> >> Lisa >> >> On Oct 16, 2005, at 9:10 AM, Julian Reschke wrote: >> >>> >>> Hi, >>> >>> I was looking at the current edits and couldn't help noticing that it >>> again contains stuff that wasn't announced at all. As far as I can >>> tell, drafts submitted to the IETF should optimally represent the >>> working group's consensus, and putting in stuff silently into the >>> working edits doesn't seem to be the best way to achieve this. >>> >>> In particular: >>> >>> 1) "Hosting malicious scripts executed on client machines" >>> (http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis- >>> latest.html#rfc.section.19.8>) looks interesting; but I don't see an >>> issue raised for this topic. In particular, the recommendation to >>> strip script from HTML pages looks a fishy (upon GET? PUT? for all >>> users?). This certainly needs more discussion if this should be added >>> to the spec. >>> >>> 2) Summary of changes from RFC2518 >>> (>> latest.html#rfc.section.B.3.1>): >>> >>>> B.3.1 Summary of changes from RFC2518 >>>> 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. >>> >>> >>> Really? I think readers of the spec really would prefer to have a >>> complete (not only a "more complete") list right here. >>> >>>> B.3.1.1 Changes Notable to Server Implementors >>>> Tightened requirements for storing property values (Section 4.4) >>>> 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 >>>> (Section 8.1), including response bodies for use with errors, use of >>>> Date header, ETag and Location header. >>> >>> >>> - The response bodies for errors are optional, right? >>> - What did change regarding the other response headers? >>> >>>> Tightened requirements for URL construction in PROPFIND (Section >>>> 8.2) >>>> responses. >>>> Tightened requirements for checking identity of lock owners >>>> (Section 7.1) during operations affected by locks. >>>> Tightened requirements for copying properties (Section 8.9.2) and >>>> moving properties (Section 8.10.1). >>> >>> >>> (to be discussed) >>> >>>> Tightened requirements on preserving owner field in locks >>>> (Section 8.11). Added "lockroot" element to lockdiscovery >>>> information. >>>> New value for "DAV:" header (Section 9.1) to advertise support for >>>> this specification. >>>> Tightened requirement for "Destination:" header (Section 9.3) to >>>> work with path values >>>> New "Force-Authentication:" (Section 9.4) header added. >>>> Several changes for "If:" header (Section 9.5), including >>>> requirement >>>> to accept commas and "DAV:no-lock" state token. >>> >>> >>> "DAV:no-lock" is no new requirement. >>> >>>> Support for UTF-16 now required (ref (Section 18)). >>> >>> >>> I don't think the requirement changed. The spec merely wasn't >>> properly repeating what XML defines, and this was fixed. >>> >>>> Removed definition of "source" property and special handling for >>>> dynamic resources >>>> Replaced lock-null resources with simpler locked empty resources >>>> (Section 7.6) >>>> B.3.1.2 Changes Notable to Client Implementors >>>> Tightened requirements for supporting WebDAV collections >>>> (Section 5.2) 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. >>> >>> >>> That affects servers as well, right? Maybe splitting the list in two >>> parts isn't worthwhile. >>> >>>> Required to handle empty multistatus responses in PROPFIND >>>> responses >>>> (Section 8.2) >>>> No more "propertybehavior" specification allowed in MOVE and COPY >>>> requests >>>> Support for UTF-16 now required (ref (Section 18)). >>>> Removed definition of "source" property and special handling for >>>> dynamic resources. >>> >>> >>> Missing changes: >>> >>> - PROPFIND dead-props >>> (>> latest.html#rfc.section.13.28>) >>> >>> - implicit lock refresh removed (see >>> >> latest.html#rfc.section.B.1.1>) >>> >>> ...and potentially more. >>> >>> Best regards, Julian >>> >>> >> >> >> > From w3c-dist-auth-request@frink.w3.org Tue Oct 18 20:20:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1gb-0001K0-BO for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 20:20:07 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09010 for ; Tue, 18 Oct 2005 20:19:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ES1fr-0005rw-R4 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 00:19:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ES1fo-0005qs-9z for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 00:19:16 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1ES1fk-0001fT-Vn for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 00:19:15 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2005 17:19:10 -0700 X-IronPort-AV: i="3.97,229,1125903600"; d="scan'208"; a="221407901:sNHT25704356" 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 j9J0J8Uw028322; Tue, 18 Oct 2005 17:19:08 -0700 (PDT) Received: from 10.21.121.34 ([10.21.121.34]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Oct 2005 00:19:17 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Tue, 18 Oct 2005 17:19:07 -0700 From: Cullen Jennings To: Geoffrey M Clemm , WebDav Message-ID: Thread-Topic: Appropriate partial success codes (was Re: Some questions about WebDAV) Thread-Index: AcXUQrgC9sreBEA1EdqLyQARJEEJ/A== In-Reply-To: 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.1 X-W3C-Scan-Sig: maggie.w3.org 1ES1fk-0001fT-Vn e549acce8b42ad60d49ef5734738353b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/BF7ADF0B.55F09%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10138 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 00:19:19 +0000 Content-Transfer-Encoding: 7bit On 10/18/05 5:06 AM, "Geoffrey M Clemm" wrote: > > I agree that this should be removed from the draft text until we have > consensus that this resolves some significant issue (and like Julian, > I have not seen a compelling argument that it does). I have no opinion if this should be there or not and I'm fine if we come to agreement to remove it. I have fairly good notes from the call and well, no real point in going there. Needless to say, if we come to agreement on the list that is the important thing. > And I agree that changes should not be made to the current draft until there > is at least consensus on the mailing list that there is a well-defined issue > that needs to be addressed. Clearly there is a well define basic issue - the spec if not clear enough on what implementers should do and/or wrong. That is the main reason we are doing a bis. We all agree on this. I suspect the author thought this text was a small clarification to help on this basic issue. If an author tried to put in some text that they thought would be agreeable to group to try and make the draft better - well it depends, hopefully big things they would get WG input on then take a stab at fixing. On small things they would just fix. It is a judgment call on if something is small or large. They author will not always get this judgment call right and we as a group will fix it. I just don't see how we can finish if the author can't change the document. Cullen > > Cheers, > Geoff > > Julian wrote on 10/17/2005 05:35:40 PM: > >> >> Cullen Jennings wrote: >>> Do you really think this should be removed from the final RFC? On the call >>> the other day I though you were going to do some testing and come up with >>> some modifications for this text? >> >> No, I think this is a misunderstanding. I really feel this text is both >> misleading, and doesn't resolve any issue I'm aware of. >> >> I'd really like all of us to agree on the approach not to make any >> changes in the original spec unless we have a well-defined issue, and >> working group consensus how to resolve it. If it ain't broke, don't fix it. >> >> Best regards, Julian >> > From w3c-dist-auth-request@frink.w3.org Tue Oct 18 23:16:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES4R8-0002WD-4O for webdav-archive@megatron.ietf.org; Tue, 18 Oct 2005 23:16:18 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16061 for ; Tue, 18 Oct 2005 23:16:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ES4Ph-0005Rv-6u for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 03:14:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ES4Pf-0005RN-1o for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 03:14:47 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lisa.w3.org with esmtp (Exim 4.50) id 1ES4Pa-0002XP-0r for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 03:14:46 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 18 Oct 2005 20:14:40 -0700 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 j9J3EbUw014610 for ; Tue, 18 Oct 2005 20:14:38 -0700 (PDT) Received: from 10.21.98.189 ([10.21.98.189]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Oct 2005 03:14:43 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Tue, 18 Oct 2005 20:14:34 -0700 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Phone call this Friday. Thread-Index: AcXUWzqWeU6yy0BOEdqopgARJEEJ/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.68.10.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1ES4Pa-0002XP-0r dcb562969701ffffa3d355ddde32b688 X-Original-To: w3c-dist-auth@w3.org Subject: Phone call this Friday. X-Archived-At: http://www.w3.org/mid/BF7B082A.55F48%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10139 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 03:14:49 +0000 Content-Transfer-Encoding: 7bit I will not be able to join the call this Friday but all the dial in information is as usual. If there is some problem with the bridge call my cell. Thanks, Cullen From w3c-dist-auth-request@frink.w3.org Wed Oct 19 01:23:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES6Qf-0006Te-OI for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 01:23:57 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21961 for ; Wed, 19 Oct 2005 01:23:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ES6PU-000883-Ae for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 05:22:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ES6PS-00087D-2q for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 05:22:42 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ES6PN-0003B1-QS for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 05:22:41 +0000 Received: (qmail invoked by alias); 19 Oct 2005 05:22:36 -0000 Received: from p508FB943.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.185.67] by mail.gmx.net (mp013) with SMTP; 19 Oct 2005 07:22:36 +0200 X-Authenticated: #1915285 Message-ID: <4355D816.9080702@gmx.de> Date: Wed, 19 Oct 2005 07:22:30 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , 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 1ES6PN-0003B1-QS bcb68b337843ea1dd464a94c7c95d081 X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/4355D816.9080702@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10140 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 05:22:44 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I just don't think we will every finish if we have to review every single > little change on the list before it is made. I would rather assume that the > editor of a document can mostly get it right, then fix what they get wrong > instead of assuming that they will get it all wrong. > > We call these things drafts because they are a draft for the WG to review, > comment on, and fix. We call the folks writing them an author because they > are taking their best stab at coming up with a draft that the WG can form > consensus around. Now when it is a WG drafts, such as this one, the author > does need to reflect the things WG agreed to into the document because in > the end it will not move forward without WG consensus. If the author of a > working group document is maliciously failing to put in the things the WG > has agreed to, I will find a new author for the document. However, lets not > confuse this with the author trying to find some draft text that we can all > agree to and then having the WG help refine that text until it is something > we can all live with. > > A natural difficulty with this is that it is non trivial to see all the > change to a document. I really don't know any way to solve this other than > diff tools. It good to catch the major diffs in the changes section of the > document but it's unreasonable to get all the trivial ones. The changes > being made to this document are small enough and local enough that it is not > that hard to catch them with diff. > > I'm saying this poorly - it's hard to describe the difference between > reasonable changes and an author being way off in left field and introducing > garbage that the WG would never agree to. > > I really like us to focus on what changes to we have to make to draft to get > it to the point it is all something we can live with. I hope the bugs are a > way of focusing on these issues. > > Cullen > > PS. Consider this email a draft :-) I (and we) might have to refine it a few > times before I get it right. OK, a few questions: - how many people have been reviewing each of these drafts? - can anybody say with confidence what has changed since RFC2518? - does any server implementor think that (s)he has a compliant implementation of what's in? The answers we *should* be getting are: -> the majority of the WG members -> see above -> most of the active implementors of servers However I'm pretty sure the actual situation is different, and I think this is caused by the way how the editorial process has been working in the past. The fact that we only have little participation nowadays even makes it more important that those who want to contribute it can do that effectively. Right now, I don't have the impression that the time I have spent in the past years has been effective at all. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 19 04: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 1ES9VW-0004mH-NL for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 04:41:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00107 for ; Wed, 19 Oct 2005 04:41:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ES9Sx-0003BS-Uj for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 08:38:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ES9Sv-0003As-MB for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 08:38:29 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1ES9Ss-0006vN-C7 for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 08:38:29 +0000 Received: (qmail invoked by alias); 19 Oct 2005 08:38:24 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 19 Oct 2005 10:38:24 +0200 X-Authenticated: #1915285 Message-ID: <435605F3.6010903@gmx.de> Date: Wed, 19 Oct 2005 10:38:11 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------030602060808080309080701" 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 1ES9Ss-0006vN-C7 c2a1cf8886a1e6d2afdb6c4dcb40eedc X-Original-To: w3c-dist-auth@w3.org Subject: Re: Phone call this Friday. X-Archived-At: http://www.w3.org/mid/435605F3.6010903@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10141 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 08:38:31 +0000 This is a multi-part message in MIME format. --------------030602060808080309080701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I will not be able to join the call this Friday but all the dial in > information is as usual. If there is some problem with the bridge call my > cell. Thanks, Cullen OK, I'm attaching a calendar entry for Friday's meeting (which will be at 16.30 UTC). Let's discuss resolution of the issues we assigned last week, and try to assign some more for the next week. Cullen, for next week I'd really like to have the following topics on the agenda: - status of BIND (to be submitted as "proposed")? - status of REDIRECT (to be submitted as "experimental")? - progress of PROPERTY-DATATYPES and QUOTA in the RFC Editor's publication queue - editorial process for RFC2518bis Best regards, Julian --------------030602060808080309080701 Content-Type: text/calendar; name="webdav.ics" Content-Disposition: inline; filename="webdav.ics" Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR BEGIN:VEVENT UID :8c7f1360-34fa-11da-a80e-df1257e30ca2 SUMMARY :WebDAV WG conference call DESCRIPTION :Meeting ID: 251807\nMeeting Password: \nPhone Numbers: 1-866-MEETME9 (US Toll-free)\n 1-650-260-9030 (Local/International) CATEGORIES :WebDAV URL :http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0081.html CLASS :PUBLIC DTSTART :20051021T163000Z DTEND :20051021T180000Z DTSTAMP :20051004T171529Z END:VEVENT END:VCALENDAR --------------030602060808080309080701-- From w3c-dist-auth-request@frink.w3.org Wed Oct 19 07:49:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESCRT-0008KK-SA for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 07:49:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09060 for ; Wed, 19 Oct 2005 07:49:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESCPk-0003gi-Dz for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 11:47:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESCPi-0003eK-4R for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 11:47:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ESCPc-0000HF-Ne for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 11:47:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9JBlEMu030127; Wed, 19 Oct 2005 04:47:14 -0700 Date: Wed, 19 Oct 2005 04:47:14 -0700 Message-Id: <200510191147.j9JBlEMu030127@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 1ESCPc-0000HF-Ne 849dde84acb0e75da2c6b357dd5ccb48 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200510191147.j9JBlEMu030127@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10142 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 11:47:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 julian.reschke@greenbytes.de 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 Oct 19 08: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 1ESCkH-0000Qh-2b for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 08:08:37 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10977 for ; Wed, 19 Oct 2005 08:08:27 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESCiy-0008Kk-Rt for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 12:07:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESCiy-0008K8-4M for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 12:07:16 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ESCit-0007yx-5C for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 12:07:15 +0000 Received: (qmail invoked by alias); 19 Oct 2005 12:06:55 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 19 Oct 2005 14:06:55 +0200 X-Authenticated: #1915285 Message-ID: <435636C3.3080807@gmx.de> Date: Wed, 19 Oct 2005 14:06:27 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510191147.j9JBlEMu030127@ietf.cse.ucsc.edu> In-Reply-To: <200510191147.j9JBlEMu030127@ietf.cse.ucsc.edu> Content-Type: multipart/mixed; boundary="------------090201020407050407060306" 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 1ESCit-0007yx-5C 7b3abd1d5d1af9fcd5e73bad8f0091b1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/435636C3.3080807@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10143 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 12:07:16 +0000 This is a multi-part message in MIME format. --------------090201020407050407060306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Proposed resolution for : This is about section 8.1.3, which currently says: "8.1.3 Use of Location header in responses When the Location header is used in a response, it is used by the server to indicate the preferred address for the target resource of the request. Whenever the server has a preferred address, it should use that address consistently. This means that when a response contains a Location header, all the URLs in the response body (e.g. a Multi-Status) should be consistent (most importantly, should use the same host and port)." () I really have no idea what this is about. HTTP (RFC2616) defines "Location" as: "14.30 Location The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Location = "Location" ":" absoluteURI An example is: Location: http://www.w3.org/pub/WWW/People.html Note: The Content-Location header field (Section 14.14) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request. It is therefore possible for a response to contain header fields for both Location and Content-Location. Also see Section 13.10 for cache requirements of some methods." () Unless somebody can explain what the connection between URLs in response bodies and the "Location" response header is, I'd suggest to get rid of this paragraph (patch attached). Best regards, Julian --------------090201020407050407060306 Content-Type: text/plain; name="12.diff" Content-Disposition: inline; filename="12.diff" Content-Transfer-Encoding: 7bit --- draft-ietf-webdav-rfc2518bis-latest.xml 2005-10-19 12:59:48.000000000 +0100 +++ draft-ietf-webdav-rfc2518bis-latest.12.xml 2005-10-19 12:59:34.000000000 +0100 @@ -1144,18 +1144,6 @@
-
- - When the Location header is used in a response, it is used by the - server to indicate the preferred address for the target resource of - the request. Whenever the server has a preferred address, it should - use that address consistently. This means that when a response - contains a Location header, all the URLs in the response body (e.g. - a Multi-Status) should be consistent (most importantly, should use - the same host and port). - -
-
Note that HTTP 1.1 requires the Date header in all responses if --------------090201020407050407060306-- From w3c-dist-auth-request@frink.w3.org Wed Oct 19 08:15:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESCr4-0004zE-R6 for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 08:15:38 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11878 for ; Wed, 19 Oct 2005 08:15:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESCpx-0001Fs-QT for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 12:14:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESCpx-0001EB-Cj for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 12:14:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ESCpv-0000WH-EJ for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 12:14:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9JCEQnh030183; Wed, 19 Oct 2005 05:14:26 -0700 Date: Wed, 19 Oct 2005 05:14:26 -0700 Message-Id: <200510191214.j9JCEQnh030183@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 1ESCpv-0000WH-EJ d19540bfd061edf0bafed5100050e4cd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 169] New: Date header required? X-Archived-At: http://www.w3.org/mid/200510191214.j9JCEQnh030183@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10144 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 12:14:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=169 Summary: Date header required? Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-07.html#rfc.section.8.1.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 The spec currently says: "8.1.4 Required Response Headers: Date Note that HTTP 1.1 requires the Date header in all responses if possible." This is misleading; RFC2616 contains a long description of when "Date" is required, in particular: - snip - 1. If the response status code is 100 (Continue) or 101 (Switching Protocols), the response MAY include a Date header field, at the server's option. 2. If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it is inconvenient or impossible to generate a valid Date. 3. If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, the rules in Section 14.18.1 MUST be followed. - snip - I don't see why RFC2518 needs to say anything at all (it's an extension of HTTP/1.1 after all), but if it does, it should make correct statements about what HTTP 1.1 actually says. ------- 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 Oct 19 12: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 1ESHF6-0000r5-RR for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 12:56:46 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28450 for ; Wed, 19 Oct 2005 12:56:35 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESHDb-0007KU-4r for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 16:55:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESHDY-0007Jw-TH for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 16:55:08 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1ESHDV-0006ds-RX for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 16:55:08 +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 j9JGt44k028972 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Oct 2005 09:55:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <4355D816.9080702@gmx.de> References: <4355D816.9080702@gmx.de> Content-Type: multipart/alternative; boundary=Apple-Mail-18--1037636873 Message-Id: <5E2F86C4-7B7F-4364-89DF-915B4F5BB6AA@cs.ucsc.edu> From: Jim Whitehead Date: Wed, 19 Oct 2005 09:55:02 -0700 To: WebDav X-Mailer: Apple Mail (2.734) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1ESHDV-0006ds-RX 20a5ec16beb00c0cc16d89509efa63e7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/5E2F86C4-7B7F-4364-89DF-915B4F5BB6AA@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10145 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 16:55:11 +0000 --Apple-Mail-18--1037636873 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > a few questions: > > - how many people have been reviewing each of these drafts? I have been doing my level best to keep up with list traffic, but have not performed a complete draft read in some time. I usually prefer to do a fewer number of deep readings rather than try to scan each minor draft rev. > > - can anybody say with confidence what has changed since RFC2518? Um, isn't this what diff tools are for? If we can't do a reasonable diff, then perhaps we should move back to Word. It provides much better visibility for fine-grain changes. > > - does any server implementor think that (s)he has a compliant > implementation of what's in? Given that we are discussing a small number of minor new features (such as force-authenticate), the answer should be none. > > The fact that we only have little participation nowadays even makes > it more important that those who want to contribute it can do that > effectively. Right now, I don't have the impression that the time I > have spent in the past years has been effective at all. My view is quite different. Due to your contributions we have a rich set of issues that have been documented, and we have gone some way towards resolving a large number of them. What we need to complete this revision process is active commitment from the remaining active working group members. We currently have this. We have an active document editor who is producing new drafts on a timely basis. We have several WG members actively engaging remaining issues, and a commitment to work towards consensus on remaining issues. I know you are frustrated by the fact that text is appearing in the drafts between revisions that you don't feel represents WG consensus. Reflecting on the drafting of 2518, the design team sometimes shoved in lots of stuff between revisions that was never agreed upon by the list first. That's why we issued drafts, and then solicited comments on them. That's also why we usually had a Word version of the document with change tracking turned on, so people could easily see all of the changes. Many times people ripped our heads off for the problems that were introduced. My personal view is the use of XML for the draft is part of the problem. In order to actually read the draft, I have to download it from the editing site, put it in a location where all of the stylesheets are present (after finding and downloading them too). Then I have to use diff, whose output is tedious to understand, to understand the differences between versions. I'm no fan of Word, but its change tracking feature and visibility of changes seems like it's *exactly* what we need right now. The other advantage of Word is its ability to let multiple authors work directly on the specification, since you can see exactly what edits have been performed. Finally, while I know its frustrating to have to monitor changes made to the draft, I don't see how this is anything other than an essential difficulty of producing a protocol specification. Anyone acting document editor is likely to add text into the specification, in a good faith effort to resolve an issue, that doesn't meet the approval of the rest of the working group. Roy sometimes got beat up for changes he made to the HTTP/1.x specifications when he was editor (and there were often complaints that he wasn't making drafts fast enough). Geoff would often insert large chunks of text into the Delta- V specification, and then go to the list to build consensus around them. It's not reasonable to expect every text change to be vetted by the list first. It also doesn't reflect current IETF practice, even in our own community. What we do seem to have is a change visibility problem. Moving back to Word would be a big step in the direction of solving this. If we use a reasonable document model, converting back to XML at the end shouldn't be too heinous. - Jim --Apple-Mail-18--1037636873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
a few questions:

- how = many people have been reviewing each of these = drafts?

I have been doing my level = best to keep up with list traffic, but have not performed a complete = draft read in some time. I usually prefer to do a fewer number of deep = readings rather than try to scan each minor draft = rev.


- can anybody say with = confidence what has changed since RFC2518?

Um, isn't this what diff = tools are for? If we can't do a reasonable diff, then perhaps we should = move back to Word. It provides much better visibility for fine-grain = changes.


- does any = server implementor think that (s)he has a compliant implementation of = what's in?

Given that we are = discussing a small number of minor new features (such as = force-authenticate), the answer should be none.


The fact = that we only have little participation nowadays even makes it more = important that those who want to contribute it can do that effectively. = Right now, I don't have the impression that the time I have spent in the = past years has been effective at all.

My view is quite different. = Due to your contributions we have a rich set of issues that have been = documented, and we have gone some way towards resolving a large number = of them.

What we need to complete = this revision process is active commitment from the remaining active = working group members. We currently have this. We have an active = document editor who is producing new drafts on a timely basis. We have = several WG members actively engaging remaining issues, and a commitment = to work towards consensus on remaining issues.

I know you are frustrated = by the fact that text is appearing in the drafts between revisions that = you don't feel represents WG consensus. Reflecting on the drafting of = 2518, the design team sometimes shoved in lots of stuff between = revisions that was never agreed upon by the list first. That's why we = issued drafts, and then solicited comments on them. That's also why we = usually had a Word version of the document with change tracking turned = on, so people could easily see all of the changes. Many times people = ripped our heads off for the problems that were = introduced.

My personal view is the use = of XML for the draft is part of the problem. In order to actually read = the draft, I have to download it from the editing site, put it in a = location where all of the stylesheets are present (after finding and = downloading them too). Then I have to use diff, whose output is tedious = to understand, to understand the differences between versions. I'm no = fan of Word, but its change tracking feature and visibility of changes = seems like it's *exactly* what we need right now. The other advantage of = Word is its ability to let multiple authors work directly on the = specification, since you can see exactly what edits have been = performed.

Finally, while I know its = frustrating to have to monitor changes made to the draft, I don't see = how this is anything other than an essential difficulty of producing a = protocol specification. Anyone acting document editor is likely to add = text into the specification, in a good faith effort to resolve an issue, = that doesn't meet the approval of the rest of the working group. Roy = sometimes got beat up for changes he made to the HTTP/1.x specifications = when he was editor (and there were often complaints that he wasn't = making drafts fast enough). Geoff would often insert large chunks of = text into the Delta-V specification, and then go to the list to build = consensus around them. It's not reasonable to expect every text change = to be vetted by the list first. It also doesn't reflect current IETF = practice, even in our own community.

What we do seem to have is = a change visibility problem. Moving back to Word would be a big step in = the direction of solving this. If we use a reasonable document model, = converting back to XML at the end shouldn't be too = heinous.

- = Jim=A0




= --Apple-Mail-18--1037636873-- From w3c-dist-auth-request@frink.w3.org Wed Oct 19 13:32:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHnO-00064f-J3 for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 13:32:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00205 for ; Wed, 19 Oct 2005 13:32:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESHmB-0007UJ-7I for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 17:30:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESHm8-0007Su-40 for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 17:30:52 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1ESHlw-00008X-6P for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 17:30:50 +0000 Received: (qmail invoked by alias); 19 Oct 2005 17:30:38 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp023) with SMTP; 19 Oct 2005 19:30:38 +0200 X-Authenticated: #1915285 Message-ID: <4356828B.7030408@gmx.de> Date: Wed, 19 Oct 2005 19:29:47 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: WebDav References: <4355D816.9080702@gmx.de> <5E2F86C4-7B7F-4364-89DF-915B4F5BB6AA@cs.ucsc.edu> In-Reply-To: <5E2F86C4-7B7F-4364-89DF-915B4F5BB6AA@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 (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 1ESHlw-00008X-6P fab42376489e6d155e12227348d86ff5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/4356828B.7030408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10146 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 17:30:55 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >> - can anybody say with confidence what has changed since RFC2518? > > > Um, isn't this what diff tools are for? If we can't do a reasonable > diff, then perhaps we should move back to Word. It provides much better > visibility for fine-grain changes. We can get a reasonable diff (now that we have XML version of both), see for instance . I guess this is the format people should be reviewing. >> - does any server implementor think that (s)he has a compliant >> implementation of what's in? > > > Given that we are discussing a small number of minor new features (such > as force-authenticate), the answer should be none. Given the fact that we think we have only a small number of changes, shouldn't the answer be: almost all of them? (at least of those reading this list?) >> The fact that we only have little participation nowadays even makes it >> more important that those who want to contribute it can do that >> effectively. Right now, I don't have the impression that the time I >> have spent in the past years has been effective at all. > > > My view is quite different. Due to your contributions we have a rich set > of issues that have been documented, and we have gone some way towards > resolving a large number of them. > > What we need to complete this revision process is active commitment from > the remaining active working group members. We currently have this. We > have an active document editor who is producing new drafts on a timely > basis. We have several WG members actively engaging remaining issues, > and a commitment to work towards consensus on remaining issues. > > I know you are frustrated by the fact that text is appearing in the > drafts between revisions that you don't feel represents WG consensus. > Reflecting on the drafting of 2518, the design team sometimes shoved in > lots of stuff between revisions that was never agreed upon by the list > first. That's why we issued drafts, and then solicited comments on them. > That's also why we usually had a Word version of the document with > change tracking turned on, so people could easily see all of the > changes. Many times people ripped our heads off for the problems that > were introduced. > > My personal view is the use of XML for the draft is part of the problem. > In order to actually read the draft, I have to download it from the > editing site, put it in a location where all of the stylesheets are > present (after finding and downloading them too). Then I have to use > diff, whose output is tedious to understand, to understand the > differences between versions. I'm no fan of Word, but its change > tracking feature and visibility of changes seems like it's *exactly* > what we need right now. The other advantage of Word is its ability to > let multiple authors work directly on the specification, since you can > see exactly what edits have been performed. Well, sounds like pre-generated HTML with change tracking (hyper-linked to an issues list) is a good thing. It's not like it's impossible to get that with XML (check the drafts I've been editing, for instance ). > Finally, while I know its frustrating to have to monitor changes made to > the draft, I don't see how this is anything other than an essential > difficulty of producing a protocol specification. Anyone acting document > editor is likely to add text into the specification, in a good faith > effort to resolve an issue, that doesn't meet the approval of the rest > of the working group. Roy sometimes got beat up for changes he made to > the HTTP/1.x specifications when he was editor (and there were often > complaints that he wasn't making drafts fast enough). Geoff would often > insert large chunks of text into the Delta-V specification, and then go > to the list to build consensus around them. It's not reasonable to > expect every text change to be vetted by the list first. It also doesn't > reflect current IETF practice, even in our own community. That's true, but I bet in these cases the changes were at least reported to the list, discussed there, and taken out when there was no consensus. I personally prefer drafts that represent the WG consensus at time of submission. But as long as the process that's used ensures that the result is ok, that's fine with me as well. Right now we have the situation that feedback to previous drafts usually was ignored, thus the long backlog on issues we now have to go through. This definitively is frustrating, and please don't blame people when they start considering how to invest their time in a more efficient way. > What we do seem to have is a change visibility problem. Moving back to > Word would be a big step in the direction of solving this. If we use a > reasonable document model, converting back to XML at the end shouldn't > be too heinous. IMHO, it's definitively not XML which is the problem. In the end, we need to provide an ASCII version, and that works *much* better using xml2rfc. Last time we produced a draft with Word (RFC3744) it's formatting was so bad that we had to go through an additional edit/submission cycle to get it right. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 19 14:41:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIs5-0005F5-Hh for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 14:41:05 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05956 for ; Wed, 19 Oct 2005 14:40:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESIqs-000722-AL for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 18:39:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESIqp-00070j-Sf for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 18:39:48 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1ESIql-0003ZP-Ew for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 18:39:47 +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 j9JIde9O020429 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Oct 2005 11:39:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <4356828B.7030408@gmx.de> References: <4355D816.9080702@gmx.de> <5E2F86C4-7B7F-4364-89DF-915B4F5BB6AA@cs.ucsc.edu> <4356828B.7030408@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Wed, 19 Oct 2005 11:39:39 -0700 To: WebDav X-Mailer: Apple Mail (2.734) 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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1ESIql-0003ZP-Ew 7dfac5e2eb6e948331b505d5eff771ef X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/A6CFADCD-83EC-4E17-84F2-0B4A4AAC32AF@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10147 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 18:39:50 +0000 Content-Transfer-Encoding: 7bit > We can get a reasonable diff (now that we have XML version of > both), see for instance ietf-webdav-rfc2518bis-latest-from-rfc2518.diff.html>. I guess > this is the format people should be reviewing. That's very nice! Are you planning on consistently producing this page (or is it created automatically)? Since it's easy to see the differences using this tool, it seems to me the concern about seeing changes from draft to daft is reduced. Is this true? > > Well, sounds like pre-generated HTML with change tracking (hyper- > linked to an issues list) is a good thing. It's not like it's > impossible to get that with XML (check the drafts I've been > editing, for instance webdav-bind-12.html>). This also sounds like a plus. Is there some place that documents how to do this? > > Right now we have the situation that feedback to previous drafts > usually was ignored, thus the long backlog on issues we now have to > go through. This definitively is frustrating, and please don't > blame people when they start considering how to invest their time > in a more efficient way. My feeling is the modification process is now back on track, and we have a responsive document editor. > IMHO, it's definitively not XML which is the problem. In the end, > we need to provide an ASCII version, and that works *much* better > using xml2rfc. Last time we produced a draft with Word (RFC3744) > it's formatting was so bad that we had to go through an additional > edit/submission cycle to get it right. > I agree that's a pain, and a big advantage of XML. But, if the lack of change awareness from draft to draft frustrates people so much we never create a final draft, the ability to convert to text isn't super important. But, perhaps it's easy to create a cron job that automatically creates an HTML diff between revisions of 2518bis? Also, automatically converting the latest draft to HTML would also be a plus. Making it easier to see the latest draft might improve participation. - Jim From w3c-dist-auth-request@frink.w3.org Wed Oct 19 14:53:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJ3n-00026r-HL for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 14:53:11 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06502 for ; Wed, 19 Oct 2005 14:53:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESJ35-0002eE-6j for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 18:52:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESJ32-0002db-Qp for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 18:52:24 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ESJ30-0007hs-PU for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 18:52:24 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 96BAE1422B9; Wed, 19 Oct 2005 11:52:21 -0700 (PDT) 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 04868-05; Wed, 19 Oct 2005 11:52:21 -0700 (PDT) Received: from [132.170.59.51] (port50.educause59.ucf.edu [132.170.59.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EF8341422B6; Wed, 19 Oct 2005 11:52:20 -0700 (PDT) In-Reply-To: <4354192C.5070709@gmx.de> References: <4354192C.5070709@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9dc6e971976e25239bf62723c2b04dec@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav , Cullen Jennings From: Lisa Dusseault Date: Wed, 19 Oct 2005 11:52:13 -0700 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 1ESJ30-0007hs-PU 630fe0a8c925344d86b38642b8091995 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/9dc6e971976e25239bf62723c2b04dec@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10148 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 18:52:27 +0000 Content-Transfer-Encoding: 7bit To respond specifically to the question about resolving issues, the text was added in an attempt to comprehensively respond to an issue that was raised on the mailing list by ChunWei Ho on July 20. I thought that your answer to ChunWei Ho's question was perfectly correct, and that info wasn't unambiguously stated in the RFC, so I tried to answer that question and also questions about other status codes besides 412 appearing in Multi-Status responses (some of them are more subtle than whether or not 412 should appear). I'm not tied to any of the specific recommendations I made in that section -- consider it straw-man text. Have you any changes to recommend in it? Lisa On Oct 17, 2005, at 2:35 PM, Julian Reschke wrote: > Cullen Jennings wrote: >> Do you really think this should be removed from the final RFC? On the >> call >> the other day I though you were going to do some testing and come up >> with >> some modifications for this text? > > No, I think this is a misunderstanding. I really feel this text is > both misleading, and doesn't resolve any issue I'm aware of. > > I'd really like all of us to agree on the approach not to make any > changes in the original spec unless we have a well-defined issue, and > working group consensus how to resolve it. If it ain't broke, don't > fix it. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 19 15:05:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJFh-0007qp-9Z for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 15:05:29 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07127 for ; Wed, 19 Oct 2005 15:05:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESJEu-00063L-VD for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 19:04:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESJEu-00062k-D0 for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 19:04:40 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ESJEm-0001Wf-GI for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 19:04:39 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 335DF1422BE; Wed, 19 Oct 2005 12:04:30 -0700 (PDT) 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 13626-10; Wed, 19 Oct 2005 12:04:29 -0700 (PDT) Received: from [132.170.59.51] (port50.educause59.ucf.edu [132.170.59.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C53A1422B6; Wed, 19 Oct 2005 12:04:29 -0700 (PDT) In-Reply-To: <5E2F86C4-7B7F-4364-89DF-915B4F5BB6AA@cs.ucsc.edu> References: <4355D816.9080702@gmx.de> <5E2F86C4-7B7F-4364-89DF-915B4F5BB6AA@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-1--1029872344 Message-Id: Cc: WebDav From: Lisa Dusseault Date: Wed, 19 Oct 2005 12:04:26 -0700 To: Jim Whitehead 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 1ESJEm-0001Wf-GI 5ed4cfb44486f48fc49f357949b08a7f X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/c269349b998f1406854754842cc1b8ae@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10149 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 19:04:40 +0000 --Apple-Mail-1--1029872344 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Jim quoth: > What we do seem to have is a change visibility problem. Moving back to > Word would be a big step in the direction of solving this. If we use a > reasonable document model, converting back to XML at the end shouldn't > be too heinous. > Having migrated *from* Word in the midst of this process ( I think bis-06 was the first draft produced from XML) I am loath to go back. I have a couple ideas to make the process easier however: - When I submit a draft I have to generate a text version anyway -- I usually save that to the ietf.webdav.org/webdav area as well. I can generate an HTML version too. It's a bit of a pain to do that for every single change I do (the ones that aren't submitted to the official internet-drafts repository) but perhaps I can automate that if there's demand, and I'll certainly do that whenever we get an official draft version bump. - I can do XML diffs and save them to the same place. Again, not every week, but every so often. We'd eventually have a set of diffs that constitutes the entire set of changes starting from the oldest XML version available -- 07-08diff.txt, 08-09diff.txt and so on. - I already maintain a complete list of changes including those made before the draft format went from Word to XML. Each change has draft #'s along with it and issue codes so it's got a lot of context for understanding specific changes. If there's anything missing at all it's an oversight and can probably be fixed if it's pointed out to me. http://ietf.webdav.org/webdav/rfc2518bis/RFC2518%20Changes.doc - When I write significant new text in the draft, I can also submit it to the mailing list -- particularly when it's new sentences or entire paragraphs. I did this with the partial-success text on Oct 11. I can continue to do this as it seems appropriate , on special request, etc. Lisa --Apple-Mail-1--1029872344 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Jim quoth: 0000,0000,DDDBWhat we do seem to have is a change visibility problem. Moving back to Word would be a big step in the direction of solving this. If we use a reasonable document model, converting back to XML at the end shouldn't be too heinous. Having migrated *from* Word in the midst of this process ( I think bis-06 was the first draft produced from XML) I am loath to go back. I have a couple ideas to make the process easier however: - When I submit a draft I have to generate a text version anyway -- I usually save that to the ietf.webdav.org/webdav area as well. I can generate an HTML version too. It's a bit of a pain to do that for every single change I do (the ones that aren't submitted to the official internet-drafts repository) but perhaps I can automate that if there's demand, and I'll certainly do that whenever we get an official draft version bump. - I can do XML diffs and save them to the same place. Again, not every week, but every so often. We'd eventually have a set of diffs that constitutes the entire set of changes starting from the oldest XML version available -- 07-08diff.txt, 08-09diff.txt and so on. - I already maintain a complete list of changes including those made before the draft format went from Word to XML. Each change has draft #'s along with it and issue codes so it's got a lot of context for understanding specific changes. If there's anything missing at all it's an oversight and can probably be fixed if it's pointed out to me. http://ietf.webdav.org/webdav/rfc2518bis/RFC2518%20Changes.doc - When I write significant new text in the draft, I can also submit it to the mailing list -- particularly when it's new sentences or entire paragraphs. I did this with the partial-success text on Oct 11. I can continue to do this as it seems appropriate , on special request, etc. Lisa --Apple-Mail-1--1029872344-- From w3c-dist-auth-request@frink.w3.org Wed Oct 19 15: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 1ESJZs-0000id-KM for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 15:26:20 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08292 for ; Wed, 19 Oct 2005 15:26:10 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESJZ9-0004RS-T6 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 19:25:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESJZ8-0004Qs-12 for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 19:25:34 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ESJZ3-0006k4-KG for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 19:25:33 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E00881422C2; Wed, 19 Oct 2005 12:25:27 -0700 (PDT) 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 08577-04; Wed, 19 Oct 2005 12:25:27 -0700 (PDT) Received: from [132.170.59.51] (port50.educause59.ucf.edu [132.170.59.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3250A1422BE; Wed, 19 Oct 2005 12:25:27 -0700 (PDT) In-Reply-To: <43557ADF.2070801@gmx.de> References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> <43557ADF.2070801@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 From: Lisa Dusseault Date: Wed, 19 Oct 2005 12:25:23 -0700 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 1ESJZ3-0006k4-KG 6e78ed6e3c79763bec3b707814282293 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/cd1150c58822d00e13a479d599f77901@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10150 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 19:25:35 +0000 Content-Transfer-Encoding: 7bit > On the other hand, Lisa has been working for a vendor that sells both > servers and clients, so I'd be really interested to hear why it wasn't > implemented over there? Maybe it's not that essential after all? > We haven't implemented all of WebDAV yet, let alone RFC2518bis, and don't claim to have a finished or fully-compliant implementation in either client or server yet. We're working on it! I highly suspect we will implement in client and server because we do support anonymous access and it's nice for clients to be able to decide to go from that to authenticated access. While I'm on the topic: our WebDAV client library in progress is intended to be high-level and more application-oriented than the standard libraries that come with Python. It's open source, naturally, and contributions are welcome. http://wiki.osafoundation.org/bin/view/Projects/ZanshinProject Lisa From w3c-dist-auth-request@frink.w3.org Wed Oct 19 15:30:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJdU-0002Rj-4C for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 15:30:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08456 for ; Wed, 19 Oct 2005 15:29:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESJcv-0004c9-9s for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 19:29:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESJcu-0004bY-Qw for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 19:29:28 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ESJcr-0007aF-RD for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 19:29:28 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C3C6C1422C2; Wed, 19 Oct 2005 12:29:24 -0700 (PDT) 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 06544-05; Wed, 19 Oct 2005 12:29:24 -0700 (PDT) Received: from [132.170.59.51] (port50.educause59.ucf.edu [132.170.59.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 328711422BE; Wed, 19 Oct 2005 12:29:24 -0700 (PDT) In-Reply-To: References: <200510152327.j9FNRSva000801@ietf.cse.ucsc.edu> <435274E9.3000002@gmx.de> <4354A080.9030309@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2555f048930ec8473580718f979d3664@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , w3c-dist-auth@w3.org From: Lisa Dusseault Date: Wed, 19 Oct 2005 12:29:20 -0700 To: Jim Whitehead 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 1ESJcr-0007aF-RD e76acf96bacf3937ea025a5df2c1c36f X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 19] DAV:no-lock X-Archived-At: http://www.w3.org/mid/2555f048930ec8473580718f979d3664@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10151 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 19:29:29 +0000 Content-Transfer-Encoding: 7bit Ok, will do. Lisa On Oct 18, 2005, at 1:30 PM, Jim Whitehead wrote: > I agree with Julian's suggested text change ("will never match" > instead of "must never match"). > > - Jim > > > On Oct 18, 2005, at 12:13 AM, Julian Reschke wrote: > >> >> Lisa Dusseault wrote: >> >>> What about changing it to a MUST? That makes it even more clear >>> (and we will get complaints about lower-case 'must' in the text) >>> >> >> Again: this follows by definition (only an IETF document/activity cab >> put things into the DAV: namespace, thus a URI using the DAV: scheme >> never can identify a valid lock token). >> >> Furthermore, keep in mind that RFC2119 explicitly asks for using >> capitalized words sparingly. >> >> Best regards, Julian >> > From w3c-dist-auth-request@frink.w3.org Wed Oct 19 17:10:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESLCo-0005La-0D for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 17:10:38 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04000 for ; Wed, 19 Oct 2005 17:10:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESL9e-00020n-PI for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 21:07:22 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESL9c-00020A-9y for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 21:07:20 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1ESL9X-0001ob-P2 for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 21:07:19 +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 j9JL7Div028882 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Oct 2005 14:07:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> <43557ADF.2070801@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Wed, 19 Oct 2005 14:07:13 -0700 To: WebDav X-Mailer: Apple Mail (2.734) 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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1ESL9X-0001ob-P2 31328df39a34c230140c5c10a36b8eb0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: new WebDAV python library X-Archived-At: http://www.w3.org/mid/BB9E6DAE-B73D-4DCC-BE9A-4BB9B5D981FE@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10152 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 21:07:22 +0000 Content-Transfer-Encoding: 7bit > > While I'm on the topic: our WebDAV client library in progress is > intended to be high-level and more application-oriented than the > standard libraries that come with Python. It's open source, > naturally, and contributions are welcome. > > http://wiki.osafoundation.org/bin/view/Projects/ZanshinProject > > Hey, that's really neat! - Jim From w3c-dist-auth-request@frink.w3.org Wed Oct 19 17:38:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESLdZ-0004sh-1H for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 17:38:17 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05731 for ; Wed, 19 Oct 2005 17:38:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESLbs-0007rX-To for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 21:36:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESLbq-0007qz-Gf for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 21:36:30 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1ESLbZ-0001KD-2U for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 21:36:30 +0000 Received: (qmail invoked by alias); 19 Oct 2005 21:36:10 -0000 Received: from p508FB943.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.185.67] by mail.gmx.net (mp014) with SMTP; 19 Oct 2005 23:36:10 +0200 X-Authenticated: #1915285 Message-ID: <4356BC41.1050201@gmx.de> Date: Wed, 19 Oct 2005 23:36:01 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: WebDav References: <4355D816.9080702@gmx.de> <5E2F86C4-7B7F-4364-89DF-915B4F5BB6AA@cs.ucsc.edu> <4356828B.7030408@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 1ESLbZ-0001KD-2U 410228ab1540864824edee46cbf06d4e X-Original-To: w3c-dist-auth@w3.org Subject: Re: new stuff in draft edits X-Archived-At: http://www.w3.org/mid/4356BC41.1050201@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10153 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 21:36:32 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > >> We can get a reasonable diff (now that we have XML version of both), >> see for instance > ietf-webdav-rfc2518bis-latest-from-rfc2518.diff.html>. I guess this >> is the format people should be reviewing. > > > That's very nice! Are you planning on consistently producing this page > (or is it created automatically)? I can do that semi-automatically once the source on ietf.webdav.org actually is well-formed (and doesn't need manual fixes anymore before running it through an XML parser). > Since it's easy to see the differences using this tool, it seems to me > the concern about seeing changes from draft to daft is reduced. Is this > true? The drafts used to use a format where rfcdiff couldn't generate sensible diffs (hint: they were generated from Word). Now that readable diffs can be produce from both the revision and the original version this is less of a concern. I didn't think about generating a diff against rfc2518 until today, but this makes a lot of sense. >> Well, sounds like pre-generated HTML with change tracking (hyper- >> linked to an issues list) is a good thing. It's not like it's >> impossible to get that with XML (check the drafts I've been editing, >> for instance > webdav-bind-12.html>). > > > This also sounds like a plus. Is there some place that documents how to > do this? It's an extension to xml2rfc that uses extension elements for del/ins/replace. If somebody wants to use it I''ll be happy to (finally) write down documentation. >> Right now we have the situation that feedback to previous drafts >> usually was ignored, thus the long backlog on issues we now have to >> go through. This definitively is frustrating, and please don't blame >> people when they start considering how to invest their time in a more >> efficient way. > > > My feeling is the modification process is now back on track, and we > have a responsive document editor. > >> IMHO, it's definitively not XML which is the problem. In the end, we >> need to provide an ASCII version, and that works *much* better using >> xml2rfc. Last time we produced a draft with Word (RFC3744) it's >> formatting was so bad that we had to go through an additional >> edit/submission cycle to get it right. >> > > I agree that's a pain, and a big advantage of XML. But, if the lack of > change awareness from draft to draft frustrates people so much we never > create a final draft, the ability to convert to text isn't super > important. But, perhaps it's easy to create a cron job that > automatically creates an HTML diff between revisions of 2518bis? Also, Revisions between drafts that have been submitted are online at . > automatically converting the latest draft to HTML would also be a plus. Once the source document is fixed that'll be trivial. > Making it easier to see the latest draft might improve participation. Yep. From w3c-dist-auth-request@frink.w3.org Wed Oct 19 17:46:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESLlJ-0001ES-V5 for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 17:46:18 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06101 for ; Wed, 19 Oct 2005 17:46:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESLjl-0001Il-LY for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Oct 2005 21:44:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESLjj-0001I6-HC for w3c-dist-auth@listhub.w3.org; Wed, 19 Oct 2005 21:44:39 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ESLjT-0003R7-To for w3c-dist-auth@w3.org; Wed, 19 Oct 2005 21:44:39 +0000 Received: (qmail invoked by alias); 19 Oct 2005 21:44:22 -0000 Received: from p508FB943.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.185.67] by mail.gmx.net (mp020) with SMTP; 19 Oct 2005 23:44:22 +0200 X-Authenticated: #1915285 Message-ID: <4356BE2B.4010705@gmx.de> Date: Wed, 19 Oct 2005 23:44:11 +0200 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 , Cullen Jennings References: <4354192C.5070709@gmx.de> <9dc6e971976e25239bf62723c2b04dec@osafoundation.org> In-Reply-To: <9dc6e971976e25239bf62723c2b04dec@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 1ESLjT-0003R7-To 8b83fa2aac15de7e513aa38beb630ebd X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/4356BE2B.4010705@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10154 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Oct 2005 21:44:41 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > To respond specifically to the question about resolving issues, the text > was added in an attempt to comprehensively respond to an issue that was > raised on the mailing list by ChunWei Ho on July 20. I thought that > your answer to ChunWei Ho's question was perfectly correct, and that > info wasn't unambiguously stated in the RFC, so I tried to answer that > question and also questions about other status codes besides 412 > appearing in Multi-Status responses (some of them are more subtle than > whether or not 412 should appear). I'm not tied to any of the specific > recommendations I made in that section -- consider it straw-man text. > Have you any changes to recommend in it? > > Lisa The question was: "Hi, I have another question. When the If header (webDAV's If header) condition is not met, the request should fail with 412 Precondition Failed. If the request is one over multiple resource, like PROPFIND, COPY or MOVE over Depth > 0, should the whole request fail returning 412 Precondition Failed, or fail only for the specific resources returning 207 MultiStatus with some portions giving a 412 Precondition Failed. Thanks again for the help! :) Regards, CW" (see ). I'm not sure how the new text you added helps resolving that, because this was about whether to return a 207 or not. My answer was: "Hi, judging from : "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." I would say that the server must return a 412 (so partial execution/success of the request is not an option)." (see ) So as far as I can tell the spec is perfectly ok, and there's absolutely no reason to add any new text because of this question. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Oct 19 23:16:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESQul-0004le-Af for webdav-archive@megatron.ietf.org; Wed, 19 Oct 2005 23:16:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06813 for ; Wed, 19 Oct 2005 23:16:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESQsS-0001kz-GX for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 03:14:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESQsN-0001k7-Gw; Thu, 20 Oct 2005 03:13:55 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by lisa.w3.org with esmtp (Exim 4.50) id 1ESQsG-0007c6-RN; Thu, 20 Oct 2005 03:13:55 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9K3Di88022808; Wed, 19 Oct 2005 23:13:44 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9K3DiBB106660; Wed, 19 Oct 2005 23:13:44 -0400 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 j9K3Dis7002533; Wed, 19 Oct 2005 23:13:44 -0400 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 j9K3DiZr002527; Wed, 19 Oct 2005 23:13:44 -0400 In-Reply-To: <4356BE2B.4010705@gmx.de> To: Julian Reschke Cc: Cullen Jennings , Lisa Dusseault , 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: Wed, 19 Oct 2005 23:13:43 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/19/2005 23:13:43, Serialize complete at 10/19/2005 23:13:43 Content-Type: multipart/alternative; boundary="=_alternative 0011BBBD852570A0_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1ESQsG-0007c6-RN 359803d6b9242c71f5ad86c5c60e35c9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/OF97080900.27A8B137-ON852570A0.00112822-852570A0.0011BBEF@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10155 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 03:14:00 +0000 This is a multipart message in MIME format. --=_alternative 0011BBBD852570A0_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian. Here's a good example of why if you think you have a paragraph that addresses some concern, please just email it out and say "how about this paragraph to resolve issue XYZ" (ideally, with a URL to the bug or email message for issue XYZ). That is far easier to review than to hope Julian catches the change and brings it to our attention on the mailing list. Cheers, Geoff Julian wrote on 10/19/2005 05:44:11 PM: > > Lisa Dusseault wrote: > > > > To respond specifically to the question about resolving issues, the text > > was added in an attempt to comprehensively respond to an issue that was > > raised on the mailing list by ChunWei Ho on July 20. I thought that > > your answer to ChunWei Ho's question was perfectly correct, and that > > info wasn't unambiguously stated in the RFC, so I tried to answer that > > question and also questions about other status codes besides 412 > > appearing in Multi-Status responses (some of them are more subtle than > > whether or not 412 should appear). I'm not tied to any of the specific > > recommendations I made in that section -- consider it straw-man text. > > Have you any changes to recommend in it? > > > > Lisa > > The question was: > > "Hi, > > I have another question. When the If header (webDAV's If header) > condition is not met, the request should fail with 412 Precondition > Failed. If the request is one over multiple resource, like PROPFIND, > COPY or MOVE over Depth > 0, should the whole request fail returning > 412 Precondition Failed, or fail only for the specific resources > returning 207 MultiStatus with some portions giving a 412 Precondition > Failed. > > Thanks again for the help! :) > > Regards, > CW" > > (see > ). > > I'm not sure how the new text you added helps resolving that, because > this was about whether to return a 207 or not. > > My answer was: > > "Hi, > > judging from > : > > "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." > > I would say that the server must return a 412 (so partial > execution/success of the request is not an option)." > > (see > ) > > So as far as I can tell the spec is perfectly ok, and there's absolutely > no reason to add any new text because of this question. > > Best regards, Julian > --=_alternative 0011BBBD852570A0_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian.

Here's a good example of why if you think you have a paragraph that
addresses some concern, please just email it out and say "how about this
paragraph to resolve issue XYZ" (ideally, with a URL to the bug or email
message for issue XYZ).  That is far easier to review than to hope Julian
catches the change and brings it to our attention on the mailing list.

Cheers,
Geoff

Julian wrote on 10/19/2005 05:44:11 PM:

>
> Lisa Dusseault wrote:
> >
> > To respond specifically to the question about resolving issues, the text
> > was added in an attempt to comprehensively respond to an issue that was
> > raised on the mailing list by ChunWei Ho on July 20.  I thought that
> > your answer to ChunWei Ho's question was perfectly correct, and that
> > info wasn't unambiguously stated in the RFC, so I tried to answer that
> > question and also questions about other status codes besides 412
> > appearing in Multi-Status responses (some of them are more subtle than
> > whether or not 412 should appear).  I'm not tied to any of the specific
> > recommendations I made in that section -- consider it straw-man text.  
> > Have you any changes to recommend in it?
> >
> > Lisa
>
> The question was:
>
> "Hi,
>
> I have another question. When the If header (webDAV's If header)
> condition is not met, the request should fail with 412 Precondition
> Failed. If the request is one over multiple resource, like PROPFIND,
> COPY or MOVE over Depth > 0, should the whole request fail returning
> 412 Precondition Failed, or fail only for the specific resources
> returning 207 MultiStatus with some portions giving a 412 Precondition
> Failed.
>
> Thanks again for the help! :)
>
> Regards,
> CW"
>
> (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0070.html>).
>
> I'm not sure how the new text you added helps resolving that, because
> this was about whether to return a 207 or not.
>
> My answer was:
>
> "Hi,
>
> judging from
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.p.4>:
>
> "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."
>
> I would say that the server must return a 412 (so partial
> execution/success of the request is not an option)."
>
> (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0071.html>)
>
> So as far as I can tell the spec is perfectly ok, and there's absolutely
> no reason to add any new text because of this question.
>
> Best regards, Julian
>
--=_alternative 0011BBBD852570A0_=-- From w3c-dist-auth-request@frink.w3.org Thu Oct 20 05:31:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESWlM-00071m-AV for webdav-archive@megatron.ietf.org; Thu, 20 Oct 2005 05:31:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27397 for ; Thu, 20 Oct 2005 05:30:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESWi7-0005Kp-N2 for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 09:27:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESWi5-0005KH-DQ for w3c-dist-auth@listhub.w3.org; Thu, 20 Oct 2005 09:27:41 +0000 Received: from mail03c.hostcenter.com ([195.186.64.158]) by lisa.w3.org with smtp (Exim 4.50) id 1ESWhz-0004wM-3V for w3c-dist-auth@w3.org; Thu, 20 Oct 2005 09:27:40 +0000 Received: from www.numcom.com (195.186.65.73) by mail03c.hostcenter.com (RS ver 1.0.95vs) with SMTP id 0-08530985 for ; Thu, 20 Oct 2005 11:21:25 +0200 (CEST) From: "Lukas Mathis" To: "'WebDav'" Date: Thu, 20 Oct 2005 11:21:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcXVV6NsrUB85562RVydOG3e+mWHqA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <20051020112125.GA85309@mail03c.hostcenter.com> X-Loop-Detect: 1 X-DistLoop-Detect: 1 Received-SPF: none (lisa.w3.org: domain of lukas.mathis@numcom.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1ESWhz-0004wM-3V d99c1a7b690f772acaf70d2ad643cea6 X-Original-To: w3c-dist-auth@w3.org Subject: Problem implementing simple WebDAV Server X-Archived-At: http://www.w3.org/mid/20051020112125.GA85309@mail03c.hostcenter.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10156 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 09:27:43 +0000 Content-Transfer-Encoding: 7bit Hi, I'm trying to implement a simple WebDAV server. So far, I've implemented a propfind method based on example code found in Lisa Dusseault's book "WebDAV: Next-Generation Collaborative Web Authoring". The method simply returns an empty directory. Unfortunately, Trying to access it using Windows' web folders ("webfolder client") gives an error ("Cannot connect to the Web server http://10.0.0.70:4444/webdav/. The server could not be located, or may be too busy to respond. Please check your typing or check to make sure the Web server is available"). BitKinex, on the other hand, displays the empty directory just fine. One possible source of the problem may be that web folders seem to try to access or create several files with "vti" in their name - outside the /webdav/ folder. This fails, obviously - the root of my server is a normal web server, no WebDAV server. I've tried several fixes to go around bugs in web folders, including changing what options and headers / and /webdav/ return. On another list, Julian Reschke gave me some pointers to such bugs in web folders, but I did not manage to fix my problem. I'm not sure if the problem really lies with web folders, or if I'm just missing some error in my code which BitKinex ignores. Any help would be greatly appreciated. Here's the exchange between web folders and my simple WebDAV server (running as a Servet inside /webdav): Request >>>>>>>>>>>>>>>>>>>>> PROPFIND /webdav HTTP/1.1 Content-Language: en-us Accept-Language: de-ch, en-us;q=0.5 Content-Type: text/xml Translate: f Depth: 0 Content-Length: 0 User-Agent: Microsoft Data Access Internet Publishing Provider DAV Host: 10.0.0.70:4444 Connection: Keep-Alive Cookie: JSESSIONID=B671A9ACFAE14F486E24305FB6927063 Response <<<<<<<<<<<<<<<<<<<< HTTP/1.1 207 Multi-Status Server: Apache-Coyote/1.1 Date: Thu, 20 Oct 2005 09:01:56 GMT Expires: Thu, 20 Oct 2005 09:01:56 GMT Pragma: no-cache Cache-Control: no-cache Content-Type: text/xml;charset=UTF-8 Content-Length: 823 http://10.0.0.70:4444/webdav/ 2001-05-11T17:33:11Z webdav Thu, 16 Aug 2001 23:24:33 GMT HTTP/1.1 200 OK HTTP/1.1 404 Not Found Request >>>>>>>>>>>>>>>>>>>>> GET /_vti_inf.html HTTP/1.1 Date: Thu, 20 Oct 2005 09:01:56 GMT MIME-Version: 1.0 Accept: */* User-Agent: Mozilla/4.0 (compatible; MS FrontPage 6.0) Host: 10.0.0.70:4444 Accept: auth/sicily Content-Length: 0 Connection: Keep-Alive Cache-Control: no-cache Cookie: JSESSIONID=B671A9ACFAE14F486E24305FB6927063 Response <<<<<<<<<<<<<<<<<<<< HTTP/1.1 404 /_vti_inf.html Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 20 Oct 2005 09:01:56 GMT 851 0 Request >>>>>>>>>>>>>>>>>>>>> POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1 Date: Thu, 20 Oct 2005 09:01:56 GMT MIME-Version: 1.0 User-Agent: MSFrontPage/6.0 Host: 10.0.0.70:4444 Accept: auth/sicily Content-Length: 41 Content-Type: application/x-www-form-urlencoded X-Vermeer-Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive Cache-Control: no-cache Response <<<<<<<<<<<<<<<<<<<< HTTP/1.1 404 /_vti_bin/shtml.exe/_vti_rpc Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 20 Oct 2005 09:01:56 GMT 851 0 Request >>>>>>>>>>>>>>>>>>>>> method=server+version%3a6%2e0%2e2%2e5523 GET /_vti_inf.html HTTP/1.1 Date: Thu, 20 Oct 2005 09:01:56 GMT MIME-Version: 1.0 Accept: */* User-Agent: Mozilla/4.0 (compatible; MS FrontPage 6.0) Host: 10.0.0.70:4444 Accept: auth/sicily Content-Length: 0 Connection: Keep-Alive Cache-Control: no-cache Cookie: JSESSIONID=B671A9ACFAE14F486E24305FB6927063 Response <<<<<<<<<<<<<<<<<<<< HTTP/1.1 404 /_vti_inf.html Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 20 Oct 2005 09:01:56 GMT 851 0 Request >>>>>>>>>>>>>>>>>>>>> POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1 Date: Thu, 20 Oct 2005 09:01:56 GMT MIME-Version: 1.0 User-Agent: MSFrontPage/6.0 Host: 10.0.0.70:4444 Accept: auth/sicily Content-Length: 41 Content-Type: application/x-www-form-urlencoded X-Vermeer-Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive Cache-Control: no-cache Response <<<<<<<<<<<<<<<<<<<< HTTP/1.1 404 /_vti_bin/shtml.exe/_vti_rpc Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 20 Oct 2005 09:01:56 GMT 851 0 Request >>>>>>>>>>>>>>>>>>>>> method=server+version%3a6%2e0%2e2%2e5523 OPTIONS / HTTP/1.1 Translate: f User-Agent: Microsoft Data Access Internet Publishing Provider Protocol Discovery Host: 10.0.0.70:4444 Content-Length: 0 Connection: Keep-Alive Cookie: JSESSIONID=B671A9ACFAE14F486E24305FB6927063 Response <<<<<<<<<<<<<<<<<<<< HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Date: Thu, 20 Oct 2005 09:01:56 GMT Expires: Thu, 20 Oct 2005 09:01:56 GMT Pragma: no-cache Cache-Control: no-cache Allow: OPTIONS, GET, HEAD, POST, DELETE, TRACE, PROPPATCH, COPY, MOVE, LOCK, UNLOCK, PROPFIND, PUT DAV: 1,2 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 1 From w3c-dist-auth-request@frink.w3.org Thu Oct 20 06:08:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXLA-0004aH-Ix for webdav-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:08:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28915 for ; Thu, 20 Oct 2005 06:07:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESXJ5-0007lp-Bq for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 10:05:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESXJ2-0007lE-QX for w3c-dist-auth@listhub.w3.org; Thu, 20 Oct 2005 10:05:53 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ESXIx-00026w-Ey for w3c-dist-auth@w3.org; Thu, 20 Oct 2005 10:05:52 +0000 Received: (qmail invoked by alias); 20 Oct 2005 10:05:42 -0000 Received: from p508FB284.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.178.132] by mail.gmx.net (mp015) with SMTP; 20 Oct 2005 12:05:42 +0200 X-Authenticated: #1915285 Message-ID: <43576BD9.3010002@gmx.de> Date: Thu, 20 Oct 2005 12:05:13 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lukas Mathis CC: "'WebDav'" References: <20051020112125.GA85309@mail03c.hostcenter.com> In-Reply-To: <20051020112125.GA85309@mail03c.hostcenter.com> 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.4 X-W3C-Scan-Sig: maggie.w3.org 1ESXIx-00026w-Ey 4a18f9dc9ad03d65dd7bab7b39e609c3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Problem implementing simple WebDAV Server X-Archived-At: http://www.w3.org/mid/43576BD9.3010002@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10157 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 10:05:55 +0000 Content-Transfer-Encoding: 7bit Lukas Mathis wrote: > Hi, > > I'm trying to implement a simple WebDAV server. So far, I've implemented a > propfind method based on example code found in Lisa Dusseault's book > "WebDAV: Next-Generation Collaborative Web Authoring". The method simply > returns an empty directory. Unfortunately, Trying to access it using > Windows' web folders ("webfolder client") gives an error ("Cannot connect to > the Web server http://10.0.0.70:4444/webdav/. The server could not be > located, or may be too busy to respond. Please check your typing or check to > make sure the Web server is available"). BitKinex, on the other hand, > displays the empty directory just fine. > > One possible source of the problem may be that web folders seem to try to > access or create several files with "vti" in their name - outside the > /webdav/ folder. This fails, obviously - the root of my server is a normal > web server, no WebDAV server. That's the client trying Frontpage Extensions after it wasn't happy with the PROPFIND reply. > I've tried several fixes to go around bugs in web folders, including > changing what options and headers / and /webdav/ return. On another list, > Julian Reschke gave me some pointers to such bugs in web folders, but I did > not manage to fix my problem. I'm not sure if the problem really lies with > web folders, or if I'm just missing some error in my code which BitKinex > ignores. > > Any help would be greatly appreciated. > > Here's the exchange between web folders and my simple WebDAV server (running > as a Servet inside /webdav): > > > Request >>>>>>>>>>>>>>>>>>>>> > > PROPFIND /webdav HTTP/1.1 > Content-Language: en-us > Accept-Language: de-ch, en-us;q=0.5 > Content-Type: text/xml > Translate: f > Depth: 0 > Content-Length: 0 > User-Agent: Microsoft Data Access Internet Publishing Provider DAV > Host: 10.0.0.70:4444 > Connection: Keep-Alive > Cookie: JSESSIONID=B671A9ACFAE14F486E24305FB6927063 > > Response <<<<<<<<<<<<<<<<<<<< > > HTTP/1.1 207 Multi-Status > Server: Apache-Coyote/1.1 > Date: Thu, 20 Oct 2005 09:01:56 GMT > Expires: Thu, 20 Oct 2005 09:01:56 GMT > Pragma: no-cache > Cache-Control: no-cache > Content-Type: text/xml;charset=UTF-8 > Content-Length: 823 > > > > > http://10.0.0.70:4444/webdav/ > > > 2001-05-11T17:33:11Z > webdav > Thu, 16 Aug 2001 23:24:33 > GMT > That should be , right? > > > > HTTP/1.1 200 OK > > > > HTTP/1.1 404 Not Found > > > > > Request >>>>>>>>>>>>>>>>>>>>> > > GET /_vti_inf.html HTTP/1.1 > Date: Thu, 20 Oct 2005 09:01:56 GMT > MIME-Version: 1.0 > Accept: */* > User-Agent: Mozilla/4.0 (compatible; MS FrontPage 6.0) > Host: 10.0.0.70:4444 > Accept: auth/sicily > Content-Length: 0 > Connection: Keep-Alive > Cache-Control: no-cache > Cookie: JSESSIONID=B671A9ACFAE14F486E24305FB6927063 > > Response <<<<<<<<<<<<<<<<<<<< > > HTTP/1.1 404 /_vti_inf.html > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=ISO-8859-1 > Transfer-Encoding: chunked > Date: Thu, 20 Oct 2005 09:01:56 GMT > > 851 > > > > 0 > > Request >>>>>>>>>>>>>>>>>>>>> > > POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1 > Date: Thu, 20 Oct 2005 09:01:56 GMT > MIME-Version: 1.0 > User-Agent: MSFrontPage/6.0 > Host: 10.0.0.70:4444 > Accept: auth/sicily > Content-Length: 41 > Content-Type: application/x-www-form-urlencoded > X-Vermeer-Content-Type: application/x-www-form-urlencoded > Connection: Keep-Alive > Cache-Control: no-cache > > Response <<<<<<<<<<<<<<<<<<<< > > HTTP/1.1 404 /_vti_bin/shtml.exe/_vti_rpc > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=ISO-8859-1 > Transfer-Encoding: chunked > Date: Thu, 20 Oct 2005 09:01:56 GMT > > 851 > > > > 0 > > Request >>>>>>>>>>>>>>>>>>>>> > > method=server+version%3a6%2e0%2e2%2e5523 > GET /_vti_inf.html HTTP/1.1 > Date: Thu, 20 Oct 2005 09:01:56 GMT > MIME-Version: 1.0 > Accept: */* > User-Agent: Mozilla/4.0 (compatible; MS FrontPage 6.0) > Host: 10.0.0.70:4444 > Accept: auth/sicily > Content-Length: 0 > Connection: Keep-Alive > Cache-Control: no-cache > Cookie: JSESSIONID=B671A9ACFAE14F486E24305FB6927063 > > Response <<<<<<<<<<<<<<<<<<<< > > HTTP/1.1 404 /_vti_inf.html > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=ISO-8859-1 > Transfer-Encoding: chunked > Date: Thu, 20 Oct 2005 09:01:56 GMT > > 851 > > > > 0 > > Request >>>>>>>>>>>>>>>>>>>>> > > POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1 > Date: Thu, 20 Oct 2005 09:01:56 GMT > MIME-Version: 1.0 > User-Agent: MSFrontPage/6.0 > Host: 10.0.0.70:4444 > Accept: auth/sicily > Content-Length: 41 > Content-Type: application/x-www-form-urlencoded > X-Vermeer-Content-Type: application/x-www-form-urlencoded > Connection: Keep-Alive > Cache-Control: no-cache > > Response <<<<<<<<<<<<<<<<<<<< > > HTTP/1.1 404 /_vti_bin/shtml.exe/_vti_rpc > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=ISO-8859-1 > Transfer-Encoding: chunked > Date: Thu, 20 Oct 2005 09:01:56 GMT > > 851 > > > > 0 > > Request >>>>>>>>>>>>>>>>>>>>> > > method=server+version%3a6%2e0%2e2%2e5523 > OPTIONS / HTTP/1.1 > Translate: f > User-Agent: Microsoft Data Access Internet Publishing Provider Protocol > Discovery > Host: 10.0.0.70:4444 > Content-Length: 0 > Connection: Keep-Alive > Cookie: JSESSIONID=B671A9ACFAE14F486E24305FB6927063 > > Response <<<<<<<<<<<<<<<<<<<< > > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Date: Thu, 20 Oct 2005 09:01:56 GMT > Expires: Thu, 20 Oct 2005 09:01:56 GMT > Pragma: no-cache > Cache-Control: no-cache > Allow: OPTIONS, GET, HEAD, POST, DELETE, TRACE, PROPPATCH, COPY, MOVE, LOCK, > UNLOCK, PROPFIND, PUT > DAV: 1,2 > Content-Type: text/html;charset=ISO-8859-1 > Content-Length: 1 > > > > Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@frink.w3.org Thu Oct 20 06: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 1ESXXV-0002PE-Va for webdav-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:20:50 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29764 for ; Thu, 20 Oct 2005 06:20:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESXVr-0002zF-Db for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 10:19:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ESXVr-0002yc-2Q for w3c-dist-auth@listhub.w3.org; Thu, 20 Oct 2005 10:19:07 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ESXVm-0006Wa-Af for w3c-dist-auth@w3.org; Thu, 20 Oct 2005 10:19:06 +0000 Received: (qmail invoked by alias); 20 Oct 2005 10:18:58 -0000 Received: from p508FB284.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.178.132] by mail.gmx.net (mp025) with SMTP; 20 Oct 2005 12:18:58 +0200 X-Authenticated: #1915285 Message-ID: <43576EF4.6020707@gmx.de> Date: Thu, 20 Oct 2005 12:18:28 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <434BFF34.7060502@gmx.de> In-Reply-To: <434BFF34.7060502@gmx.de> 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 1ESXVm-0006Wa-Af 2eed7c41827cf0524b64a8cb64ad5c7f X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: I-D ACTION:draft-reschke-webdav-mount-02.txt] X-Archived-At: http://www.w3.org/mid/43576EF4.6020707@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10158 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 10:19:07 +0000 Content-Transfer-Encoding: 7bit Hi, the draft is now in the RFC Editor's queue for Independant Submissions (to be reviewed). It's progress can be tracked at . Best regards, Julian Julian Reschke wrote: > Hi, > > as discussed previously, I have submitted the current version of the > WebDAV mount spec as a new draft (HTML version at > ). > Unless any new issues are raised, I'll submit this draft to the RFC > Editor for publication as Informational RFC early next week. > > Best regards, Julian > > > -------- Original Message -------- > From: Internet-Drafts@ietf.org > Message-Id: > Date: Tue, 11 Oct 2005 10:50:01 -0400 > X-Spam-Score: 0.4 (/) > X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 > Subject: I-D ACTION:draft-reschke-webdav-mount-02.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: 37E5Y/sgeSEkWvRadnQhaXN1IGRvb0Cj > > 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-02.txt > Pages : 16 > Date : 2005-10-11 > > 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 protocol 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-02.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-02.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-02.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. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@frink.w3.org Thu Oct 20 14:54:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESfYc-0003X2-1W for webdav-archive@megatron.ietf.org; Thu, 20 Oct 2005 14:54:30 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06442 for ; Thu, 20 Oct 2005 14:54:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESfWG-00055N-L9 for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 18:52:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESfWD-00054j-5f for w3c-dist-auth@listhub.w3.org; Thu, 20 Oct 2005 18:52:01 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ESfW3-0002nH-Fb for w3c-dist-auth@w3.org; Thu, 20 Oct 2005 18:52:00 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 258A21422BE; Thu, 20 Oct 2005 11:51:50 -0700 (PDT) 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 16262-06; Thu, 20 Oct 2005 11:51:50 -0700 (PDT) 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 33EC61422B9; Thu, 20 Oct 2005 11:51:49 -0700 (PDT) In-Reply-To: <4356BE2B.4010705@gmx.de> References: <4354192C.5070709@gmx.de> <9dc6e971976e25239bf62723c2b04dec@osafoundation.org> <4356BE2B.4010705@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: WebDav , Cullen Jennings From: Lisa Dusseault Date: Wed, 19 Oct 2005 15:26:17 -0700 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.2 X-W3C-Scan-Sig: maggie.w3.org 1ESfW3-0002nH-Fb 4d302456101ee2d2011e1b86f7ac9b6f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/c7e50a7fa256760462189187074fe81a@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10159 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 18:52:04 +0000 Content-Transfer-Encoding: 7bit Well, I suppose there are multiple ways of answering the question. Since the question explicitly asked whether the server should fail "returning 207 Multi-Status with some portions giving a 412 Precondition Failed", I still find that saying that 412 can't appear in Multi-Status is at least a partial answer to that question. Another answer would be to say that unmet preconditions MUST cause the entire request to fail atomically even if the request involves multiple resources. Do you think we should add that to the draft? Lisa On Oct 19, 2005, at 2:44 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> To respond specifically to the question about resolving issues, the >> text was added in an attempt to comprehensively respond to an issue >> that was raised on the mailing list by ChunWei Ho on July 20. I >> thought that your answer to ChunWei Ho's question was perfectly >> correct, and that info wasn't unambiguously stated in the RFC, so I >> tried to answer that question and also questions about other status >> codes besides 412 appearing in Multi-Status responses (some of them >> are more subtle than whether or not 412 should appear). I'm not tied >> to any of the specific recommendations I made in that section -- >> consider it straw-man text. Have you any changes to recommend in it? >> Lisa > > The question was: > > "Hi, > > I have another question. When the If header (webDAV's If header) > condition is not met, the request should fail with 412 Precondition > Failed. If the request is one over multiple resource, like PROPFIND, > COPY or MOVE over Depth > 0, should the whole request fail returning > 412 Precondition Failed, or fail only for the specific resources > returning 207 MultiStatus with some portions giving a 412 Precondition > Failed. > > Thanks again for the help! :) > > Regards, > CW" > > (see > 0070.html>). > > I'm not sure how the new text you added helps resolving that, because > this was about whether to return a 207 or not. > > My answer was: > > "Hi, > > judging from > : > > "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." > > I would say that the server must return a 412 (so partial > execution/success of the request is not an option)." > > (see > 0071.html>) > > So as far as I can tell the spec is perfectly ok, and there's > absolutely no reason to add any new text because of this question. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 20 15:10:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESfoX-0001gN-Gc for webdav-archive@megatron.ietf.org; Thu, 20 Oct 2005 15:10:57 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07460 for ; Thu, 20 Oct 2005 15:10:47 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESfmx-0000xM-Ca for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 19:09:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESfmw-0000wo-QR for w3c-dist-auth@listhub.w3.org; Thu, 20 Oct 2005 19:09:19 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ESfmt-00067H-Py for w3c-dist-auth@w3.org; Thu, 20 Oct 2005 19:09:18 +0000 Received: (qmail invoked by alias); 20 Oct 2005 19:09:14 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 20 Oct 2005 21:09:14 +0200 X-Authenticated: #1915285 Message-ID: <4357EB35.5070601@gmx.de> Date: Thu, 20 Oct 2005 21:08:37 +0200 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 , Cullen Jennings References: <4354192C.5070709@gmx.de> <9dc6e971976e25239bf62723c2b04dec@osafoundation.org> <4356BE2B.4010705@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 1ESfmt-00067H-Py 124804d885e2d8464ae3135a3a42c2b9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Appropriate partial success codes (was Re: Some questions about WebDAV) X-Archived-At: http://www.w3.org/mid/4357EB35.5070601@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10160 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 19:09:19 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Well, I suppose there are multiple ways of answering the question. > Since the question explicitly asked whether the server should fail > "returning 207 Multi-Status with some portions giving a 412 > Precondition Failed", I still find that saying that 412 can't appear in > Multi-Status is at least a partial answer to that question. ...but: 1) A statement about 412 in multistatus is very different from adding a whole new section saying lots of other things, and 2) from a procedural p.o.v.: somebody asked a question, and there was a single answer, and no further discussion. To me, cases like this one are a perfect example for no changes of the spec being required. We shouldn't change the spec each and every time somebody has a question unless there's a consensus that there's actually something wrong with the spec. If it ain't broken, don't fix it. > Another answer would be to say that unmet preconditions MUST cause the > entire request to fail atomically even if the request involves multiple > resources. Do you think we should add that to the draft? After re-reading the thread I actually think that RFC2518 currently defines a behaviour for "Depth" that is unlikely to be implemented. So what we need to do is to sit down, write test cases and find out what current implementations do. *Then*, wen can discuss potential changes. But please let's first find out what currently servers do. Volunteers? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 20 17:05:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShbJ-000618-PQ for webdav-archive@megatron.ietf.org; Thu, 20 Oct 2005 17:05:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03568 for ; Thu, 20 Oct 2005 17:05:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EShZ8-0006Jh-Ok for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 21:03:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EShZ6-0006J8-B5 for w3c-dist-auth@listhub.w3.org; Thu, 20 Oct 2005 21:03:08 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EShXf-0007do-6j for w3c-dist-auth@w3.org; Thu, 20 Oct 2005 21:03:07 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 43E201422D0 for ; Thu, 20 Oct 2005 14:01:38 -0700 (PDT) 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 05890-05 for ; Thu, 20 Oct 2005 14:01:38 -0700 (PDT) Received: from [192.168.101.23] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7D81C1422B9 for ; Thu, 20 Oct 2005 14:01:37 -0700 (PDT) Message-ID: <435805B0.8010107@osafoundation.org> Date: Thu, 20 Oct 2005 14:01:36 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of bcm@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 1EShXf-0007do-6j 734f2d7235774e1f8079bc152263a8cc X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/435805B0.8010107@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10161 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 21:03:10 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Do I have the summary right that there is only one server we know of that > preservers namespaces? has anybody created a test case to use in checking server behavior for preserving whitespace and namespaces? if so, i'll use that to give you results for cosmo. otherwise i'll whip up something of my own. From w3c-dist-auth-request@frink.w3.org Thu Oct 20 17:50:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiIW-0001rX-V5 for webdav-archive@megatron.ietf.org; Thu, 20 Oct 2005 17:50:05 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15955 for ; Thu, 20 Oct 2005 17:49:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EShuL-0003Ob-H1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 21:25:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EShuL-0003Nj-2h for w3c-dist-auth@listhub.w3.org; Thu, 20 Oct 2005 21:25:05 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EShti-0005RR-Mp for w3c-dist-auth@w3.org; Thu, 20 Oct 2005 21:25:03 +0000 Received: (qmail invoked by alias); 20 Oct 2005 21:24:24 -0000 Received: from p508FB284.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.178.132] by mail.gmx.net (mp009) with SMTP; 20 Oct 2005 23:24:24 +0200 X-Authenticated: #1915285 Message-ID: <43580AFE.3060409@gmx.de> Date: Thu, 20 Oct 2005 23:24:14 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Moseley CC: WebDav References: <435805B0.8010107@osafoundation.org> In-Reply-To: <435805B0.8010107@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 1EShti-0005RR-Mp 7e05212d2b211dd6301f8ada5a56aea7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/43580AFE.3060409@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10162 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 21:25:05 +0000 Content-Transfer-Encoding: 7bit Brian Moseley wrote: > has anybody created a test case to use in checking server behavior for > preserving whitespace and namespaces? if so, i'll use that to give you > results for cosmo. otherwise i'll whip up something of my own. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 20 18:19:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESilR-0005AN-EH for webdav-archive@megatron.ietf.org; Thu, 20 Oct 2005 18:19:57 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18515 for ; Thu, 20 Oct 2005 18:19:47 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESiSo-0004gq-AG for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Oct 2005 22:00:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESiSc-0004cA-Ja for w3c-dist-auth@listhub.w3.org; Thu, 20 Oct 2005 22:00:30 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ESiSR-0006Hm-0c for w3c-dist-auth@w3.org; Thu, 20 Oct 2005 22:00:29 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9907E1422C8 for ; Thu, 20 Oct 2005 15:00:16 -0700 (PDT) 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 25695-08 for ; Thu, 20 Oct 2005 15:00:16 -0700 (PDT) Received: from [192.168.101.23] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6ADAB142284 for ; Thu, 20 Oct 2005 15:00:16 -0700 (PDT) Message-ID: <43581370.70004@osafoundation.org> Date: Thu, 20 Oct 2005 15:00:16 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDav References: <435805B0.8010107@osafoundation.org> <43580AFE.3060409@gmx.de> In-Reply-To: <43580AFE.3060409@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of bcm@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 1ESiSR-0006Hm-0c 22573a0194e12278bea68932519f4d03 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/43581370.70004@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10163 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Oct 2005 22:00:42 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > ah, no windows here so i'll go ahead and write my own. thanks! From w3c-dist-auth-request@frink.w3.org Fri Oct 21 08:48:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwK7-0007n2-4Q for webdav-archive@megatron.ietf.org; Fri, 21 Oct 2005 08:48:39 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19432 for ; Fri, 21 Oct 2005 08:48:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ESwGk-0005DY-VX for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Oct 2005 12:45:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ESwGh-0005BA-Uc for w3c-dist-auth@listhub.w3.org; Fri, 21 Oct 2005 12:45:08 +0000 Received: from zproxy.gmail.com ([64.233.162.192]) by maggie.w3.org with esmtp (Exim 4.50) id 1ESwGa-0002kW-4T for w3c-dist-auth@w3.org; Fri, 21 Oct 2005 12:45:07 +0000 Received: by zproxy.gmail.com with SMTP id k1so378934nzf for ; Fri, 21 Oct 2005 05:44:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Cnn60vUgP1OJm3ms1OFM4aZ+P7D1k0IGG/5OPBotne5vTK0+39Jx4qpLm06lwu9g2kOXhK6OmlGQZDIDX5JS2Fq4X+8vWH8yn2Zr9XP61lV97SUSYA+bBL2pJdMWCvNIaPoXbEh6SHXA677OjL0j2rOQzLNzgnIFAkDDfzG++pg= Received: by 10.36.34.1 with SMTP id h1mr3137963nzh; Fri, 21 Oct 2005 05:44:58 -0700 (PDT) Received: by 10.36.129.7 with HTTP; Fri, 21 Oct 2005 05:44:58 -0700 (PDT) Message-ID: <70458b950510210544n5000de7bj@mail.gmail.com> Date: Fri, 21 Oct 2005 14:44:58 +0200 From: Blowfish To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Received-SPF: pass (maggie.w3.org: domain of darwinfugu@gmail.com designates 64.233.162.192 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ESwGa-0002kW-4T c4b71dc9484dd8eb504da8379b188ab1 X-Original-To: w3c-dist-auth@w3.org Subject: limit user per ip in mod_dav X-Archived-At: http://www.w3.org/mid/70458b950510210544n5000de7bj@mail.gmail.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10164 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Oct 2005 12:45:10 +0000 Content-Transfer-Encoding: quoted-printable Hello, I have a question about the mod_dav Apache Module. I limit a directory per user with the directive "require user", but I want to limit the simultaneous connections with the same user. Is there a solution for limit the access user to one IP, not multiples IP's connected with same user. I use the mod_dav-1.0.3p0.tgz module. I hope somebody helps me. Thanks. From w3c-dist-auth-request@frink.w3.org Fri Oct 21 13:52:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET144-0006Sz-QY for webdav-archive@megatron.ietf.org; Fri, 21 Oct 2005 13:52:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21486 for ; Fri, 21 Oct 2005 13:52:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ET12Y-0007K3-3T for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Oct 2005 17:50:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ET12V-0007JK-99 for w3c-dist-auth@listhub.w3.org; Fri, 21 Oct 2005 17:50:47 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by maggie.w3.org with esmtp (Exim 4.50) id 1ET12R-0000df-LU for w3c-dist-auth@w3.org; Fri, 21 Oct 2005 17:50:46 +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 j9LHoRv8013448; Fri, 21 Oct 2005 10:50:27 -0700 (PDT) Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay5.apple.com (Apple SCV relay) with ESMTP id 29385324015; Fri, 21 Oct 2005 10:50:27 -0700 (PDT) In-Reply-To: <70458b950510210544n5000de7bj@mail.gmail.com> References: <70458b950510210544n5000de7bj@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20C9C39F-BA66-4181-B6E0-3AF9C251390B@apple.com> Cc: Blowfish Content-Transfer-Encoding: 7bit From: Jim Luther Date: Fri, 21 Oct 2005 10:50:28 -0700 To: WebDav X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: pass (maggie.w3.org: domain of luther.j@apple.com designates 17.254.13.23 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1ET12R-0000df-LU bb2340461cdfa06096aff5425a2b0b55 X-Original-To: w3c-dist-auth@w3.org Subject: Re: limit user per ip in mod_dav X-Archived-At: http://www.w3.org/mid/20C9C39F-BA66-4181-B6E0-3AF9C251390B@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10165 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Oct 2005 17:50:50 +0000 Content-Transfer-Encoding: 7bit Just so you know, if you put limits like that on a WebDAV server, it won't work with Mac OS X's WebDAV file system which handles multiple concurrent requests from multiple file system clients (where a client is some process thread). We tried queuing requests on the client and handling them one at a time, but that made the file system very non- responsive when a request that should be relatively fast (i.e. a PROPFIND with a depth of 0) got queued up behind a request that could take minutes or hours (i.e. a GET on a large resource). In the current implementation, the Mac OS X WebDAV file system will have at most 5 connections open with the server and will queue file system client requests when all of those connections are in use. - Jim On Oct 21, 2005, at 5:44 AM, Blowfish wrote: > Hello, I have a question about the mod_dav Apache Module. > I limit a directory per user with the directive "require user", but I > want to limit the simultaneous connections with the same user. > Is there a solution for limit the access user to one IP, not multiples > IP's connected with same user. > I use the mod_dav-1.0.3p0.tgz module. > > I hope somebody helps me. > Thanks. From w3c-dist-auth-request@frink.w3.org Fri Oct 21 15:13:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2KT-0004PY-6R for webdav-archive@megatron.ietf.org; Fri, 21 Oct 2005 15:13:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26962 for ; Fri, 21 Oct 2005 15:13:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ET2JK-0000ow-QM for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Oct 2005 19:12:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ET2JI-0000na-Bs for w3c-dist-auth@listhub.w3.org; Fri, 21 Oct 2005 19:12:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ET2J5-0002K3-1s for w3c-dist-auth@w3.org; Fri, 21 Oct 2005 19:12:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9LJBihQ032398; Fri, 21 Oct 2005 12:11:44 -0700 Date: Fri, 21 Oct 2005 12:11:44 -0700 Message-Id: <200510211911.j9LJBihQ032398@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.3 X-W3C-Scan-Sig: maggie.w3.org 1ET2J5-0002K3-1s 5aa53665341721fc549e68787955baf6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 170] New: no mention of 424 in section 8.3.2 X-Archived-At: http://www.w3.org/mid/200510211911.j9LJBihQ032398@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10166 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Oct 2005 19:12:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=170 Summary: no mention of 424 in section 8.3.2 Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://http://lists.w3.org/Archives/Public/w3c-dist- auth/2005OctDec/0272.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: elias@cse.ucsc.edu QAContact: w3c-dist-auth@w3.org As reported by Bernard Desruisseaux: The response to PROPPATCH in Section "8.3.2 Example - PROPPATCH" contains a HTTP/1.1 424 Failed Dependency, but the status code "424 Failed Dependency" is not listed in Section "8.3.1 Status Codes for use with 207 (Multi-Status)". While the list of status codes in Section 8.3.1 is not necessarily exhaustive, I think the status code 424 should definitely be mentionned. ------- 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 Oct 21 17:45:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4hK-0004wg-82 for webdav-archive@megatron.ietf.org; Fri, 21 Oct 2005 17:45:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19970 for ; Fri, 21 Oct 2005 17:44:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ET4fC-0007jr-3x for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Oct 2005 21:42:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ET4f9-0007jH-10 for w3c-dist-auth@listhub.w3.org; Fri, 21 Oct 2005 21:42:55 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by maggie.w3.org with esmtp (Exim 4.50) id 1ET4f6-0001VT-4W for w3c-dist-auth@w3.org; Fri, 21 Oct 2005 21:42:54 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2005 14:42:50 -0700 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 j9LLgmUw015371 for ; Fri, 21 Oct 2005 14:42:48 -0700 (PDT) Received: from 10.21.88.217 ([10.21.88.217]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 21 Oct 2005 21:42:57 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Fri, 21 Oct 2005 14:42:47 -0700 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Conference bridge for weekly bug phone call Thread-Index: AcXWiGBUnvNK50J7EdqOywARJEEJ/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.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: maggie.w3.org 1ET4f6-0001VT-4W 211f5043ef689c856b55b71f9633de98 X-Original-To: w3c-dist-auth@w3.org Subject: Conference bridge for weekly bug phone call X-Archived-At: http://www.w3.org/mid/BF7EAEE7.5696B%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10167 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Oct 2005 21:42:58 +0000 Content-Transfer-Encoding: 7bit I set up a weekly bridge for 9 week for all the folks that want to call in. Date/Time: October 26, 2005 at 10:00 AM America/Los_Angeles Length: 60 minutes Frequency: This meeting is scheduled to occur every Wednesday for 9 weeks. Meeting ID: 251807 Meeting Password: Description: Phone Numbers: 1-866-MEETME9 (US Toll-free) 1-650-260-9030 (Local/International) From pete@concentric.com Fri Oct 21 21:07:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET7rF-0006Oa-8I for webdav-archive@megatron.ietf.org; Fri, 21 Oct 2005 21:07:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08443 for ; Fri, 21 Oct 2005 21:07:26 -0400 (EDT) Received: from cpc4-inch2-3-1-cust33.dbln.cable.ntl.com ([82.22.231.33] helo=-1208499112) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ET83M-0000FJ-Mm for webdav-archive@ietf.org; Fri, 21 Oct 2005 21:20:16 -0400 Received: from concentric.com (-1209292416 [-1211944152]) by cpc4-inch2-3-1-cust33.dbln.cable.ntl.com (Qmailv1) with ESMTP id FDFC598311 for ; Fri, 21 Oct 2005 21:08:51 -0400 Date: Fri, 21 Oct 2005 21:08:51 -0400 From: Doctor X-Mailer: The Bat! (v2.00.7) Personal X-Priority: 3 Message-ID: <3803982867.20051021210851@concentric.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------3021A8CEE01E469" X-Virus-Scanned: by AMaViS perl-11 mion X-Spam-Score: 4.2 (++++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------------3021A8CEE01E469 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlasgra $3.3 Levivtra $3.3 Ciaqlis $3.7 Imitjrex $16.4 Flomiax $2.2 Ultrzam $0.78 Viozxx $4.75 Ambhien $2.2 Valtium $0.97 Xanamx $1.09 Soema $3 Merixdia $2.2 our site http://romolote.info/?GFSMKDRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals range of credit cards. dgjkjutyr RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------3021A8CEE01E469 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlaugra - $3.3
Leviitra - $3.3
Ciaplis - $3.7
Imittrex - $16.4
Flombax - $2.2
Ultrpam - $0.78
Violxx - $4.75
Ambmien - $2.2
Valiium - $0.97
Xanahx - $1.09
Sotma - $3
Meribdia - $2.2

our website

___
Best regards,
Online Pharmaceuticals


range of credit cards. dgjkjutyr RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------3021A8CEE01E469-- From w3c-dist-auth-request@frink.w3.org Sat Oct 22 03:23:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETDim-0002BQ-Mc for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 03:23:17 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23763 for ; Sat, 22 Oct 2005 03:23:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETDgs-000287-1v for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 07:21:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ETDgq-00027U-58 for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 07:21:16 +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 1ETDgm-0003kb-DY for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 07:21:16 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 22 Oct 2005 00:21:11 -0700 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 j9M7L48k007709; Sat, 22 Oct 2005 00:21:04 -0700 (PDT) Received: from 10.21.120.51 ([10.21.120.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 22 Oct 2005 07:21:18 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Sat, 22 Oct 2005 00:21:14 -0700 From: Cullen Jennings To: Julian Reschke , WebDav Message-ID: Thread-Topic: [Bug 12] Destination header "consistent" Thread-Index: AcXW2S9Qbf6d4kLMEdqhrAARJEEJ/A== In-Reply-To: <435636C3.3080807@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.71.176.71 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1ETDgm-0003kb-DY a08e2d3a15611e8ed4887752ce8b94cc X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/BF7F367A.56A97%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10168 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 07:21:18 +0000 Content-Transfer-Encoding: 7bit Another ignorant questions but ... Do existing servers include Locations headers. For any generic header X, if servers use it or clients expect it, then I would hope the spec talked about what needed to be in header X. If no one uses header X (and sound like you are saying it is hard to imagine anyone uses since no one knows what it means) then the spec should ignore it or say not to use it. On 10/19/05 5:06 AM, "Julian Reschke" wrote: > Proposed resolution for > : > > This is about section 8.1.3, which currently says: > > "8.1.3 Use of Location header in responses > > When the Location header is used in a response, it is used by the server > to indicate the preferred address for the target resource of the > request. Whenever the server has a preferred address, it should use that > address consistently. This means that when a response contains a > Location header, all the URLs in the response body (e.g. a Multi-Status) > should be consistent (most importantly, should use the same host and > port)." > ( ction.8.1.3>) > > I really have no idea what this is about. HTTP (RFC2616) defines > "Location" as: > > "14.30 Location > > The Location response-header field is used to redirect the recipient to > a location other than the Request-URI for completion of the request or > identification of a new resource. For 201 (Created) responses, the > Location is that of the new resource which was created by the request. > For 3xx responses, the location SHOULD indicate the server's preferred > URI for automatic redirection to the resource. The field value consists > of a single absolute URI. > > > Location = "Location" ":" absoluteURI > > An example is: > > Location: http://www.w3.org/pub/WWW/People.html > > Note: The Content-Location header field (Section 14.14) differs > from Location in that the Content-Location identifies the original > location of the entity enclosed in the request. It is therefore possible > for a response to contain header fields for both Location and > Content-Location. Also see Section 13.10 for cache requirements of some > methods." > () > > > Unless somebody can explain what the connection between URLs in response > bodies and the "Location" response header is, I'd suggest to get rid of > this paragraph (patch attached). > > Best regards, Julian > > --- draft-ietf-webdav-rfc2518bis-latest.xml 2005-10-19 12:59:48.000000000 > +0100 > +++ draft-ietf-webdav-rfc2518bis-latest.12.xml 2005-10-19 12:59:34.000000000 > +0100 > @@ -1144,18 +1144,6 @@ > >
> > -
> - > - When the Location header is used in a response, it is used by the > - server to indicate the preferred address for the target resource of > - the request. Whenever the server has a preferred address, it should > - use that address consistently. This means that when a response > - contains a Location header, all the URLs in the response body (e.g. > - a Multi-Status) should be consistent (most importantly, should use > - the same host and port). > - > -
> - >
> > Note that HTTP 1.1 requires the Date header in all responses if From w3c-dist-auth-request@frink.w3.org Sat Oct 22 04:27:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETEiw-0007BP-Vw for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 04:27:31 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26068 for ; Sat, 22 Oct 2005 04:27:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETEhr-0004t6-S3 for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 08:26:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETEhp-0004sY-HM for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 08:26:21 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ETEhl-00085r-NI for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 08:26:21 +0000 Received: (qmail invoked by alias); 22 Oct 2005 08:26:16 -0000 Received: from p508F8309.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.9] by mail.gmx.net (mp015) with SMTP; 22 Oct 2005 10:26:16 +0200 X-Authenticated: #1915285 Message-ID: <4359F79D.4010500@gmx.de> Date: Sat, 22 Oct 2005 10:26:05 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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 (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 1ETEhl-00085r-NI 5955ce8098194007fcdbd4acc6994b9e X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/4359F79D.4010500@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10169 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 08:26:23 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Another ignorant questions but ... Do existing servers include Locations > headers. For any generic header X, if servers use it or clients expect it, > then I would hope the spec talked about what needed to be in header X. If no > one uses header X (and sound like you are saying it is hard to imagine > anyone uses since no one knows what it means) then the spec should ignore it > or say not to use it. As far as I can tell, returning a "Location" response header with status 207 is completely meaningless, and I'm not aware of any server doing that. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 22 13: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 1ETMrx-0003Ht-VO for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 13:09:22 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21310 for ; Sat, 22 Oct 2005 13:09:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETMqe-0004f7-5u for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 17:08:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ETMqb-0004eZ-Rs for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 17:07:57 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ETMqZ-0006Gj-NX for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 17:07:57 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 463D614229B for ; Sat, 22 Oct 2005 10:07:54 -0700 (PDT) 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 31550-03 for ; Sat, 22 Oct 2005 10:07:54 -0700 (PDT) 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 B1276142296 for ; Sat, 22 Oct 2005 10:07:53 -0700 (PDT) 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: Sat, 22 Oct 2005 10:07:48 -0700 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 1ETMqZ-0006Gj-NX add1d465187e3080bc1a8799ed3bd2e0 X-Original-To: w3c-dist-auth@w3.org Subject: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/a855f584f1d2c031722f19b5a376bb30@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10170 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 17:08:00 +0000 Content-Transfer-Encoding: 7bit There are several issues that intersect around lock token requirements and examples. - Some examples use the "locktoken" scheme which is defined nowhere - The examples that use strings like "locktoken:a-lock-token" could be converted to "opaquelocktoken:a-lock-token" but then that would be an example of an invalid URI according to the rules of the "opaquelocktoken" scheme and we generally want to provide "best practices" examples (note, however, at the slight expense of readability) - In the meantime, RFC4122 appeared and makes it unnecessary for WebDAV to define how to do a UUID -- and we noticed that it defines a scheme as well (urn:uuid:) What about resolving these by getting rid of the opaquelocktoken scheme? The specification requirements would still make it legal to use any legal URI that was unique, so existing servers using "opaquelocktoken" would not be made non-compliant by this change. It would simplify the spec by relying more on RFC4122 and defining one fewer new scheme and a bit of syntax associated with that scheme. In summary a recommended (but not the only) form for lock tokens would be a UID in RFC4122 format, for example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" This seemed to make sense to Julian, Jim, Geoff and myself on the call today, so if we missed anything, or anybody has objections, please raise them. Lisa From w3c-dist-auth-request@frink.w3.org Sat Oct 22 13:46:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETNRT-0001cL-HQ for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 13:46:03 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23177 for ; Sat, 22 Oct 2005 13:45:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETNQZ-0003j0-M5 for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 17:45:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETNQZ-0003iM-4m for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 17:45:07 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1ETNQU-0002IK-Vv for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 17:45:06 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1EF3614229B; Sat, 22 Oct 2005 10:45:01 -0700 (PDT) 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 10066-02; Sat, 22 Oct 2005 10:45:00 -0700 (PDT) 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 3CF89142298; Sat, 22 Oct 2005 10:45:00 -0700 (PDT) In-Reply-To: <4359F79D.4010500@gmx.de> References: <4359F79D.4010500@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <60ce66f3178237f0e1a58dedde94349c@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav , Cullen Jennings From: Lisa Dusseault Date: Sat, 22 Oct 2005 10:44:54 -0700 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 1ETNQU-0002IK-Vv b02a08be86bd2db1192b51c03a077ed7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/60ce66f3178237f0e1a58dedde94349c@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10171 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 17:45:07 +0000 Content-Transfer-Encoding: 7bit Trying to fill in a little background here: we've discussed this related issues before, from June 22 to 26, 2003 and Oct 9 2003. I think part of what we concluded was that if a resource that is mentioned in a PROPFIND response would normally return a Location header (if you did a HEAD to that resource alone) we needed to find a way to return the same info inside the PROPFIND response. So we discussed use of 302/303 and a element to provide the information that would have been in the Location header, all inside the 207 response. But a slightly different case: if *all* of the resources had been redirected (if the target collection itself or a parent had been redirected) then one single Location header for the entire response might work for the whole shebang. Thus, I don't agree that returning 207 with a Location header is meaningless. (I have no reason to disagree with the assertion that existing implementations probably don't do that, though). It might well be premature optimization, however. The "dumber" way to handle this case -- when the request is to a collection that has been moved/redirected -- is simply to return the appropriate 300 level response and Location and make the client repeat the request against the new URL. Two roundtrips, but probably not a case worth optimizing for, because we'd have to define either how to combine the Location header with relative URLs inside the response, or how the Location header must be consistent with absolute URLs inside the response. Is there consensus that the Location header MUST NOT be used with 207? (and while we're at it, should we generalize to all status responses besides 201 and 301, 302, 303, 305, 307?) Lisa On Oct 22, 2005, at 1:26 AM, Julian Reschke wrote: > > Cullen Jennings wrote: >> Another ignorant questions but ... Do existing servers include >> Locations >> headers. For any generic header X, if servers use it or clients >> expect it, >> then I would hope the spec talked about what needed to be in header >> X. If no >> one uses header X (and sound like you are saying it is hard to imagine >> anyone uses since no one knows what it means) then the spec should >> ignore it >> or say not to use it. > > As far as I can tell, returning a "Location" response header with > status 207 is completely meaningless, and I'm not aware of any server > doing that. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Sat Oct 22 14:06:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETNkm-00059i-LD for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 14:06:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23757 for ; Sat, 22 Oct 2005 14:05:47 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETNk2-00073w-ES for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 18:05:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETNk0-00073J-Qy for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 18:05:13 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ETNjv-0005tp-Lm for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 18:05:11 +0000 Received: (qmail invoked by alias); 22 Oct 2005 18:05:06 -0000 Received: from p508F8309.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.9] by mail.gmx.net (mp002) with SMTP; 22 Oct 2005 20:05:06 +0200 X-Authenticated: #1915285 Message-ID: <435A7F41.30808@gmx.de> Date: Sat, 22 Oct 2005 20:04:49 +0200 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 , Cullen Jennings References: <4359F79D.4010500@gmx.de> <60ce66f3178237f0e1a58dedde94349c@osafoundation.org> In-Reply-To: <60ce66f3178237f0e1a58dedde94349c@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 1ETNjv-0005tp-Lm e0f28872ae08f2df101e45128f616e8d X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/435A7F41.30808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10172 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 18:05:14 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Trying to fill in a little background here: we've discussed this related > issues before, from June 22 to 26, 2003 and Oct 9 2003. I think part of For the former time range, I'm not sure what messages you're referring to (URL?). For the latter, this was about DAV:location elements in DAV:multistatus (see ). > what we concluded was that if a resource that is mentioned in a PROPFIND > response would normally return a Location header (if you did a HEAD to > that resource alone) we needed to find a way to return the same info > inside the PROPFIND response. So we discussed use of 302/303 and a > element to provide the information that would have been > in the Location header, all inside the 207 response. That's all true, but what does this have to do with what the spec currently says? It talks about some interaction of a "Location" response header and a multistatus response body (on the very same message), and I really don't get what this has to do with the issue mentioned above. > But a slightly different case: if *all* of the resources had been > redirected (if the target collection itself or a parent had been > redirected) then one single Location header for the entire response That's a different situation, described in . As a redirect reference resource is not a collection, a PROPFIND on it with no Redirect-specific request headers simply would return in a 302 status, just like GET or HEAD. > might work for the whole shebang. Thus, I don't agree that returning > 207 with a Location header is meaningless. (I have no reason to > disagree with the assertion that existing implementations probably don't > do that, though). The nature of a redirect resource is that it redirects to a different URL, using 3xx and Location header. Applying PROPFIND to a redirect gets you a 3xx and a Location header, not a 207 and multistatus. The REDIRECT spec defines an extension so that you can PROPFIND the properties of the redirect, instead of being redirected. That still doesn't make a redirect a WebDAV collection. On the other hand, a WebDAV collection that *contains* redirects will respond with 207/multistatus to a PROPFIND. > It might well be premature optimization, however. The "dumber" way to > handle this case -- when the request is to a collection that has been > moved/redirected -- is simply to return the appropriate 300 level > response and Location and make the client repeat the request against the > new URL. Two roundtrips, but probably not a case worth optimizing for, > because we'd have to define either how to combine the Location header > with relative URLs inside the response, or how the Location header must > be consistent with absolute URLs inside the response. This sounds a bit like you want to re-invent redirects altogether. Applying an HTTP method to a redirect causes a 3xx with a Location header. That's it, unless the client uses specific extensions to request different behaviour (one approach is defined in the REDIRECT spec). > Is there consensus that the Location header MUST NOT be used with 207? > (and while we're at it, should we generalize to all status responses > besides 201 and 301, 302, 303, 305, 307?) Lisa, it seems that whatever we discuss, you try to turn this into a discussion about even more spec text. RFC2518bis doesn't need to say anything about it. Whatever RFC2616 already says and a future WebDAV REDIRECT spec will say is sufficient. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 22 14:21:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETO02-0005Cp-6B for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 14:21:46 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24405 for ; Sat, 22 Oct 2005 14:21:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETNyw-0001IS-O5 for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 18:20:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ETNyw-0001HX-9m for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 18:20:38 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ETNyu-0006n0-HW for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 18:20:38 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8DE0A14229B; Sat, 22 Oct 2005 11:20:35 -0700 (PDT) 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 06019-08; Sat, 22 Oct 2005 11:20:35 -0700 (PDT) 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 D908C142282; Sat, 22 Oct 2005 11:20:34 -0700 (PDT) In-Reply-To: <435A7F41.30808@gmx.de> References: <4359F79D.4010500@gmx.de> <60ce66f3178237f0e1a58dedde94349c@osafoundation.org> <435A7F41.30808@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6f78751820534acf8ccf7ae6fd41ff0e@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav , Cullen Jennings From: Lisa Dusseault Date: Sat, 22 Oct 2005 11:20:30 -0700 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 1ETNyu-0006n0-HW 84a28cbe686d13433ddb7f542b6f8092 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/6f78751820534acf8ccf7ae6fd41ff0e@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10173 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 18:20:38 +0000 Content-Transfer-Encoding: 7bit On Oct 22, 2005, at 11:04 AM, Julian Reschke wrote: > > Lisa, it seems that whatever we discuss, you try to turn this into a > discussion about even more spec text. RFC2518bis doesn't need to say > anything about it. Whatever RFC2616 already says and a future WebDAV > REDIRECT spec will say is sufficient. You say that as though it's a bad thing! Whenever we discuss or disagree on the mailing list, I find that's a good case for narrowing down what can be done in implementations of RFC2518bis; to reduce variety between implementations, improve interoperability and have a complete spec that doesn't send people running to the mailing list all too often. We can at least think and talk about the issue -- if we *do* come to consensus that Location header is not appropriate in 207 responses (or other new response codes defined by WebDAV, or new methods defined by WebDAV) then any of that would be good information to add to the spec. OTOH if we come to consensus that we shouldn't restrict Location header use but leave it undefined on most response types, I hope there's a good reason for that which would come out in a discussion. Lisa From w3c-dist-auth-request@frink.w3.org Sat Oct 22 14:43:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETOLM-0000qF-4I for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 14:43:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25001 for ; Sat, 22 Oct 2005 14:43:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETOKZ-0004rU-N9 for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 18:42:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETOKX-0004qp-Qy for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 18:42:58 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ETOKV-00044X-0V for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 18:42:57 +0000 Received: (qmail invoked by alias); 22 Oct 2005 18:42:53 -0000 Received: from p508F8309.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.9] by mail.gmx.net (mp027) with SMTP; 22 Oct 2005 20:42:53 +0200 X-Authenticated: #1915285 Message-ID: <435A881B.1030008@gmx.de> Date: Sat, 22 Oct 2005 20:42:35 +0200 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 , Cullen Jennings References: <4359F79D.4010500@gmx.de> <60ce66f3178237f0e1a58dedde94349c@osafoundation.org> <435A7F41.30808@gmx.de> <6f78751820534acf8ccf7ae6fd41ff0e@osafoundation.org> In-Reply-To: <6f78751820534acf8ccf7ae6fd41ff0e@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 1ETOKV-00044X-0V 416194b2a664a7d96337c684a040a167 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/435A881B.1030008@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10174 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 18:42:59 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > On Oct 22, 2005, at 11:04 AM, Julian Reschke wrote: > >> >> Lisa, it seems that whatever we discuss, you try to turn this into a >> discussion about even more spec text. RFC2518bis doesn't need to say >> anything about it. Whatever RFC2616 already says and a future WebDAV >> REDIRECT spec will say is sufficient. > > > You say that as though it's a bad thing! Whenever we discuss or Yes, as a matter of fact I think it's a bad thing. We are revising RFC2518, which to me means - fixing bugs (examples, typos) - removing stuff nobody does implement (such as DAV:propertybehaviour) - simplify things that were too complex in the first place (lock-null resources come to mind) - removing stuff that's not need today anymore (XML namespace explanations, UUID generation instructions...) - update references - add stuff that we agree was missing (DAV:lockroot...) This may not be complete, but it should cover most cases. Just adding prose without no actual need for it IMHO is a bad idea. Do that in FAQs, Blogs, online resources, implementor guides, books, whatever. > disagree on the mailing list, I find that's a good case for narrowing > down what can be done in implementations of RFC2518bis; to reduce > variety between implementations, improve interoperability and have a > complete spec that doesn't send people running to the mailing list all > too often. "Narrowing down" means a change of the spec. As far as I can tell, there is no need to change the spec. If you feel there is a need, please explain way (interop problem???). > We can at least think and talk about the issue -- if we *do* come to > consensus that Location header is not appropriate in 207 responses (or > other new response codes defined by WebDAV, or new methods defined by > WebDAV) then any of that would be good information to add to the spec. I disagree. RFC2616 defines what the "Location" header is for, and any attempt to go further than that without practical reasons IMHO would be the wrong thing to do. > OTOH if we come to consensus that we shouldn't restrict Location header > use but leave it undefined on most response types, I hope there's a good > reason for that which would come out in a discussion. We can (and will) discuss whatever is raised here. I just dont't see how this discussion helps us in any way revising RFC2518. As a matter of fact, it slows us down, because it distracts us from the things that *are* on the issues list. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 22 14:54:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETOVl-0005fn-Qq for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 14:54:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25324 for ; Sat, 22 Oct 2005 14:54:22 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETOUv-0007G3-M5 for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 18:53:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETOUu-0007FU-Uu for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 18:53:41 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ETOUr-0005qf-5r for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 18:53:40 +0000 Received: (qmail invoked by alias); 22 Oct 2005 18:53:36 -0000 Received: from p508F8309.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.9] by mail.gmx.net (mp002) with SMTP; 22 Oct 2005 20:53:36 +0200 X-Authenticated: #1915285 Message-ID: <435A8A9E.5060300@gmx.de> Date: Sat, 22 Oct 2005 20:53:18 +0200 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 (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 1ETOUr-0005qf-5r 4ac122da87f5ed9c14ad5354f7fc81eb X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/435A8A9E.5060300@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10175 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 18:53:41 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > There are several issues that intersect around lock token requirements > and examples. > > - Some examples use the "locktoken" scheme which is defined nowhere Correct. The spec shouldn't do that. > - The examples that use strings like "locktoken:a-lock-token" could be > converted to "opaquelocktoken:a-lock-token" but then that would be an > example of an invalid URI according to the rules of the > "opaquelocktoken" scheme and we generally want to provide "best > practices" examples (note, however, at the slight expense of readability) Yes. > - In the meantime, RFC4122 appeared and makes it unnecessary for WebDAV > to define how to do a UUID -- and we noticed that it defines a scheme as > well (urn:uuid:) That's a change that's already in -- draft 07 doesn't specify how to generate UUIDs anymore. Section 6.4 () says: -- In order to guarantee uniqueness across all resources for all time a server MAY use the Universal Unique Identifier (UUID) [9] mechanism to generate a lock token: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly while still guaranteeing the lock token to be unique across all resources for all time. With the 'opaquelocktoken' scheme, the 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 RFC2396 [5] -- Besides fixing the obvious editorial problems here (ABNF examples and spec in the same paragraph), I don't see why we need to take out even more. > What about resolving these by getting rid of the opaquelocktoken > scheme? The specification requirements would still make it legal to use > any legal URI that was unique, so existing servers using > "opaquelocktoken" would not be made non-compliant by this change. It > would simplify the spec by relying more on RFC4122 and defining one > fewer new scheme and a bit of syntax associated with that scheme. The "opaquelocktoken" scheme is defined in RFC2518. Existing servers use it and are unlikely to stop using it (unless there's a replacement that provides exactly the same sematics). If RFC2518bis is going to "obsolete" RFC2518, I think it needs to keep the scheme declaration. On the other hand, if it doesn't keep it, I'll probably submit that as a separate spec. Again: if it ain't broke don't fix it. I don't see any benefit in removing it, but lots of additional work and confusion if we do. > In summary a recommended (but not the only) form for lock tokens would > be a UID in RFC4122 format, for example: > "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" It just happens to be a simple URN scheme that fulfills the requirements for lock tokens. RFC2518 always allowed different schemes, and we should not make the impression that this changed. > This seemed to make sense to Julian, Jim, Geoff and myself on the call > today, so if we missed anything, or anybody has objections, please raise > them. +1 on having valid lock tokens in examples +1 on using urn:uuid URIs to do that +1 on simplifying the definition of "opaquelocktoken" by simply referring to the UUID generation instructions in RFC4122 (already done in draft 07) -1 on removing the definition of "opaquelocktoken" Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 22 15:00:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETObL-0001ah-5t for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 15:00:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25493 for ; Sat, 22 Oct 2005 15:00:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETOaf-0007sV-Dt for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 18:59:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETOae-0007rp-VW for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 18:59:37 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1ETOaZ-0006mv-E8 for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 18:59:36 +0000 Received: (qmail invoked by alias); 22 Oct 2005 18:59:30 -0000 Received: from p508F8309.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.9] by mail.gmx.net (mp001) with SMTP; 22 Oct 2005 20:59:30 +0200 X-Authenticated: #1915285 Message-ID: <435A8C00.90709@gmx.de> Date: Sat, 22 Oct 2005 20:59:12 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Lisa Dusseault , w3c-dist-auth@w3.org References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> <4354D63B.5050201@gmx.de> In-Reply-To: <4354D63B.5050201@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 1ETOaZ-0006mv-E8 530614ee6f7a80944efa0174342dcef5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/435A8C00.90709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10176 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 18:59:37 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > OK, > >> I tried to diff the xml file downloaded from my URL vs. the one from >> yours and unfortunately the diff is garbage, showing every line >> different. It's probably something stupid like line returns, but >> it's a pain in the ass figuring out what's actually changed. If >> you provide a diff I'll check it out further. > > > attached is a patch for the file that was on > as of today. > > Best regards, Julian Lisa, any chance you could fix the draft, so that it parses? Once that's done I can set up something that generates and publishes the HTML version, plus diffs to RFC2518. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 22 15: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 1ETPKx-0001NE-6x for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 15:47:27 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26669 for ; Sat, 22 Oct 2005 15:47:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETPJN-0000Jt-Do for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 19:45:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ETPJL-0000JH-RA for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 19:45:47 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1ETPJD-000160-TV for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 19:45:47 +0000 Received: (qmail invoked by alias); 22 Oct 2005 19:45:37 -0000 Received: from p508F8309.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.9] by mail.gmx.net (mp006) with SMTP; 22 Oct 2005 21:45:37 +0200 X-Authenticated: #1915285 Message-ID: <435A96CD.4010005@gmx.de> Date: Sat, 22 Oct 2005 21:45:17 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 1ETPJD-000160-TV 31a490d916b73d731db55c8b7b071942 X-Original-To: w3c-dist-auth@w3.org Subject: Test cases for "If" header checks X-Archived-At: http://www.w3.org/mid/435A96CD.4010005@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10177 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 19:45:49 +0000 Content-Transfer-Encoding: 7bit Hi. Below is a test script (for Microsoft's XMLHTTPRequest component) that tests various forms of "If" headers. Basically it does some sanity checks first, and then tries the new syntax allowing comma-separated lists (or multiple headers). Of the servers I tested, none supported the new format (not surprisingly), but most (*) replied with 400 (bad request). This means clients can test that, and there doesn't seem to be any need for a new compliance class just for this use case. Best regards, Julian (* I notified the maintainers of the other two servers, one of which happens to be myself) -- var req = new ActiveXObject ("MSXML2.ServerXMLHTTP"); if (WScript.Arguments.length == 0) { WScript.Echo("Test case If header eval"); WScript.Echo("Usage: cscript if_fail.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); } if (WScript.Arguments.length > 1) { user = WScript.Arguments(1); } if (WScript.Arguments.length > 2) { pwd = WScript.Arguments(2); } var x = 1; function testPut(ifheader, desc) { WScript.Echo("\n\n\nTest case " + x + ", If header: " + ifheader); WScript.Echo("(" + desc + ")"); req.open("PUT", uri, false, user, pwd); if (ifheader != null) req.setRequestHeader("If", ifheader); req.send("test case " + x); dumpResponse(req); x += 1; } // delete content WScript.Echo("DELETE " + uri); req.open("DELETE", uri, false, user, pwd); req.send("foobar"); dumpResponse(req); testPut(null, "initial content"); if (req.status < 200 || req.status >= 300) { WScript.Echo("unexpected status upon PUT"); WScript.Quit(2); } testPut("()", "const false"); if (req.status != 412) { WScript.Echo("unexpected status upon PUT"); } testPut("(Not )", "const true"); if (req.status != 204 && req.status != 200) { WScript.Echo("unexpected status upon PUT"); } testPut("( Not )", "const false"); if (req.status != 412) { WScript.Echo("unexpected status upon PUT"); } testPut("(), (Not )", "const true using comma notation"); if (req.status == 200 || req.status == 204) { WScript.Echo("Server seems to understand ',' in If-List as per RFC2518bis"); } else if (req.status == 400) { WScript.Echo("Server seems not to understand ',' in If-List as per RFC2518bis, rejecting the request with 400"); } else { WScript.Echo("unexpected status upon PUT"); } testPut("(Not ), (Not )", "const false using comma notation"); if (req.status == 412) { WScript.Echo("Server seems to understand ',' in If-List as per RFC2518bis"); } else if (req.status == 400) { WScript.Echo("Server seems not to understand ',' in If-List as per RFC2518bis, rejecting the request with 400"); } else { WScript.Echo("unexpected status upon PUT"); } From w3c-dist-auth-request@frink.w3.org Sat Oct 22 16: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 1ETPY5-0000GI-V6 for webdav-archive@megatron.ietf.org; Sat, 22 Oct 2005 16:01:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27130 for ; Sat, 22 Oct 2005 16:00:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETPXR-0002iB-4B for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Oct 2005 20:00:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETPXQ-0002hY-FT for w3c-dist-auth@listhub.w3.org; Sat, 22 Oct 2005 20:00:20 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ETPXM-0000JX-VJ for w3c-dist-auth@w3.org; Sat, 22 Oct 2005 20:00:19 +0000 Received: (qmail invoked by alias); 22 Oct 2005 20:00:15 -0000 Received: from p508F8309.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.9] by mail.gmx.net (mp016) with SMTP; 22 Oct 2005 22:00:15 +0200 X-Authenticated: #1915285 Message-ID: <435A9A3A.9040302@gmx.de> Date: Sat, 22 Oct 2005 21:59:54 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Bernard Desruisseaux , Lisa Dusseault , Cullen Jennings , Geoffrey M Clemm , WebDav , w3c-dist-auth-request@w3.org References: <91df83c7d462717c7fa70fe05411113b@osafoundation.org> <434D0DC0.2030800@gmx.de> <7fc3943a09cf9d3077ccf22c5a0f0f62@osafoundation.org> <434EB057.3020504@gmx.de> <3e3690da7043c971ea5594190ac125d7@osafoundation.org> <434EB722.10609@gmx.de> <643638228b4f0af8dd27bcdcb5c4a6d6@osafoundation.org> <43541591.6080307@oracle.com> <43541715.2000509@gmx.de> In-Reply-To: <43541715.2000509@gmx.de> Content-Type: text/plain; charset=Big5 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 1ETPXM-0000JX-VJ 7c8a932ce2fb9cc53333b12aaa11d294 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bugzilla issue 10, was: Plan to resolve issues in 2518bis X-Archived-At: http://www.w3.org/mid/435A9A3A.9040302@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10178 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Oct 2005 20:00:21 +0000 Content-Transfer-Encoding: 7bit Hi, in the meantime (conference call), we found that there was a misunderstanding between Lisa and myself. When I talked about "whitespace", I was talking about whitespace in text nodes (between tags), while she thought I was talking about whitespace inside tags. To clarify: whitespace inside tags (such as the one between attributes) is not significant. Nor is attribute order for that matter. In the conference call, we kind of agreed to delegate terminology to one of the applicable W3C documents/data models (such as XPath or XML Infoset). Funny enough, this is exactly what I have proposed long LONG (!) ago: Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 23 08:25:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETeuv-0004iS-4k for webdav-archive@megatron.ietf.org; Sun, 23 Oct 2005 08:25:37 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01462 for ; Sun, 23 Oct 2005 08:25:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETesh-0006yf-Ba for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Oct 2005 12:23:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETese-0006y5-Ie for w3c-dist-auth@listhub.w3.org; Sun, 23 Oct 2005 12:23:17 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1ETesV-00057R-Su for w3c-dist-auth@w3.org; Sun, 23 Oct 2005 12:23:16 +0000 Received: (qmail invoked by alias); 23 Oct 2005 12:23:03 -0000 Received: from p508FAA55.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.85] by mail.gmx.net (mp028) with SMTP; 23 Oct 2005 14:23:03 +0200 X-Authenticated: #1915285 Message-ID: <435B8094.1040903@gmx.de> Date: Sun, 23 Oct 2005 14:22:44 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Lisa Dusseault , WebDav WG References: <435A8A9E.5060300@gmx.de> In-Reply-To: <435A8A9E.5060300@gmx.de> Content-Type: multipart/mixed; boundary="------------030304060004070008090200" 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 1ETesV-00057R-Su e5d7ce17d32fe65a3af56027468b1c7a X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/435B8094.1040903@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10179 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Oct 2005 12:23:19 +0000 This is a multi-part message in MIME format. --------------030304060004070008090200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit OK, below a proposal to resolve issues 20 (, "Lock Token Examples"), 91 (, "chapter name for lock token uri schemes"), 102 (, "lock tokens in examples") and 99 (, "Risks Connected with Lock Tokens"). It does this by - fixing examples (URI scheme, syntax, whitespace), always using syntactically legal urn:uuid URIs - rewriting section 6.4, getting rid of 6.5 consequently - fixing the security consideratios, basically re-using the text from RFC2518 and just fix what was broken or out-of-date - move "opaquelocktoken" definition into appendix with minimally required spec text The changes are: Section 6., para. 16: OLD: This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements. According to current IETF best practices, implementations SHOULD use registered URI schemes to ensure uniqueness. NEW: A robust method for generating a lock token fulfilling the uniqueness requirements is to leverage the "Universally Unique IDentifier" (UUID) mechanism. URI schemes that can use UUIDs are the "UUID" URN Namespace defined in [9] and the "opaquelocktoken" URI scheme defined in Appendix C. However resources are free to return any URI scheme so long as it meets the uniqueness requirements. According to current IETF best practices, implementations SHOULD use registered URI schemes to ensure uniqueness. Section 6., para. 19: OLD: 6.4 Lock Token URI Schemes In order to guarantee uniqueness across all resources for all time a server MAY use the Universal Unique Identifier (UUID) [9] mechanism to generate a lock token: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly while still guaranteeing the lock token to be unique across all resources for all time. With the 'opaquelocktoken' scheme, the 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 RFC2396 [5] 6.5 Lock Capability Discovery NEW: 6.4 Lock Capability Discovery Section 7., para. 77: OLD: COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html If: () NEW: COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html If: () Section 8., para. 219: OLD: MOVE /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Overwrite: F If: () () NEW: MOVE /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Overwrite: F If: () () Section 8., para. 260: OLD: HTTP/1.1 200 OK Lock-Token: Content-Type: text/xml; charset="utf-8" Content-Length: xxxx NEW: HTTP/1.1 200 OK Lock-Token: Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Section 8., para. 261: OLD: infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 opaquelocktoken:e71d4fae-5dec-22d6-fea5- 00a0c91e6be4 http://example.com/workspace/webdav /proposal.doc NEW: 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 Section 8., para. 263: OLD: Note that the locktoken and lockroot href elements would not contain any whitespace. The line return appearing in this document is only for formatting. 8.11.7 Example - Refreshing a Write Lock NEW: 8.11.7 Example - Refreshing a Write Lock Section 8., para. 265: OLD: 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="..." NEW: 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="..." Section 8., para. 268: OLD: infinity http://www.ics.uci.edu/~ejw/contact.html Second-604800 opaquelocktoken:e71d4fae-5dec-22d6-fea5- 00a0c91e6be4 http://example.com/workspace/webdav /proposal.doc NEW: 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 Section 8., para. 292: OLD: 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="..." NEW: 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="..." Section 8., para. 295: OLD: In this example, the lock identified by the lock token "opaquelocktoken: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. NEW: 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. Section 9., para. 38: OLD: If: ( ["I am an ETag"]), (["I am another ETag"]) NEW: If: ( ["I am an ETag"]), (["I am another ETag"]) Section 9., para. 39: OLD: 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 ["I am an ETag"]) (and ["I am another ETag"])). NEW: 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 ["I am an ETag"]) (and ["I am another ETag"])). Section 9., para. 44: OLD: 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"]) NEW: 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"]) Section 9., para. 45: OLD: 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 "( [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock token of "opaquelocktoken:a-write-lock-token" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag". NEW: 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 "( [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock token of "urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag". Section 9., para. 49: OLD: If: (Not ) NEW: If: (Not ) Section 9., para. 50: OLD: When submitted with a request, this If header requires that all operand resources must not be locked with opaquelocktoken:write1 and must be locked with opaquelocktoken:write2. NEW: When submitted with a request, this If header requires that all operand resources must not be locked with urn:uuid:E90CB889-97CA-49b9-AC33-111111111111 and must be locked with urn:uuid:E90CB889-97CA-49b9-AC33-222222222222. Section 9., para. 58: OLD: DELETE /specs/rfc2518.txt HTTP/1.1 Host: www.example.com If: () NEW: DELETE /specs/rfc2518.txt HTTP/1.1 Host: www.example.com If: () Section 13., para. 19: OLD: Description: The href contains a single lock token URI which refers to the lock (i.e., the OpaqueLockToken-URI production in section 6.4). NEW: Description: The href contains a single lock token URI which refers to the lock. Section 14., para. 85: OLD: http://www.example.com/container/ 0 Jane Smith Infinite opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c- 00a0c91a9d76 http://www.example.com/container/ HTTP/1.1 200 OK NEW: 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 Section 19., para. 24: OLD: This specification requires the use of Universal Unique Identifiers (UUIDs) [9] 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: NEW: This specification recommends the use of Universal Unique Identifiers (UUIDs) for lock tokens, in order to guarantee their uniqueness across space and time. UUIDs, as defined in [9], contain a "node" field which "consists of the IEEE address, usually the host address. For systems with multiple IEEE 802 nodes, any available node address can be used." Since a WebDAV server will issue many locks over its lifetime, the implication is that it will also be publicly exposing its IEEE 802 address. There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address: Section 19., para. 28: OLD: 19.8 Hosting malicious scripts executed on client machines NEW: Section 4.5 of [9] details an alternate mechanism for generating the "node" field of a UUID without using an IEEE 802 address, which alleviates the risks associated with exposure of IEEE 802 addresses by using an alternate source of uniqueness. 19.8 Hosting malicious scripts executed on client machines Section 20., para. 4: OLD: This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in section 6.4. NEW: This specification also defines the "opaquelocktoken" URI scheme for the encoding of lock tokens (see Appendix C). NEW: Appendix C. 'opaquelocktoken' URI Scheme The 'opaquelocktoken' URI scheme defined below uses the Universal Unique Identifier (UUID) mechanism ([9], Section 4) to easily generate lock tokens fulfilling the uniqueness requirements stated in Section 6.3. OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] ; UUID: see [RFC4122], Section 3. ; path: see [RFC3986], Section 3.3. Note that the optional "path" postfix allows to generate many lock tokens from a single URI, by appending an varying string such as a sequence number. Example: opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017 --------------030304060004070008090200 Content-Type: text/plain; name="20.diff" Content-Disposition: inline; filename="20.diff" Content-Transfer-Encoding: 7bit --- draft-ietf-webdav-rfc2518bis-latest.xml 2005-10-21 16:12:09.000000000 +0100 +++ draft-ietf-webdav-rfc2518bis-latest.20.xml 2005-10-23 13:02:21.000000000 +0100 @@ -601,7 +601,7 @@
-
+
A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned in the Lock- @@ -619,11 +619,16 @@ resources and servers without fear of confusion. - This specification provides a lock token URI scheme called - opaquelocktoken that meets the uniqueness requirements. However - resources are free to return any URI scheme so long as it meets the - uniqueness requirements. According to current IETF best practices, implementations - SHOULD use registered URI schemes to ensure uniqueness. + A robust method for generating a lock token fulfilling the + uniqueness requirements is to leverage the "Universally Unique IDentifier" + (UUID) mechanism. URI schemes that can use UUIDs are the "UUID" URN + Namespace defined in and the "opaquelocktoken" + URI scheme defined in . + + + However resources are free to return any URI scheme so long as it meets the + uniqueness requirements. According to current IETF best practices, implementations + SHOULD use registered URI schemes to ensure uniqueness. Submitting a lock token does not confer full privilege to use @@ -640,31 +645,6 @@
-
- - In order to guarantee uniqueness across all resources for all time - a server MAY use the Universal Unique - Identifier (UUID) mechanism to generate a lock token: - - urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 - The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly - while still guaranteeing the lock token to be unique across all - resources for all time. With the 'opaquelocktoken' scheme, the 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 RFC2396 - -
-
Since server lock support is optional, a client trying to lock a @@ -1039,7 +1019,7 @@ Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html If: - () + () >>Response @@ -2441,8 +2421,8 @@ Host: www.example.com Destination: http://www.example.com/othercontainer/ Overwrite: F - If: () - () + If: () + () >>Response @@ -2688,7 +2668,7 @@ >>Response HTTP/1.1 200 OK - Lock-Token: + Lock-Token: Content-Type: text/xml; charset="utf-8" Content-Length: xxxx @@ -2706,12 +2686,12 @@ Second-604800 - opaquelocktoken:e71d4fae-5dec-22d6-fea5- - 00a0c91e6be4 + urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 - http://example.com/workspace/webdav - /proposal.doc + http://example.com/workspace/webdav/proposal.doc @@ -2729,11 +2709,6 @@ 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. -
@@ -2744,7 +2719,7 @@ LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 - Lock-Token: + Lock-Token: Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", @@ -2770,12 +2745,12 @@ Second-604800 - opaquelocktoken:e71d4fae-5dec-22d6-fea5- - 00a0c91e6be4 + urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4 - http://example.com/workspace/webdav - /proposal.doc + http://example.com/workspace/webdav /proposal.doc @@ -2919,7 +2894,7 @@ UNLOCK /workspace/webdav/info.doc HTTP/1.1 Host: example.com - Lock-Token: + Lock-Token: Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", @@ -2933,7 +2908,7 @@ In this example, the lock identified by the lock token - "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is + "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 @@ -3118,7 +3093,7 @@
- + If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) No-tag-list = List Tagged-list = Resource 1*List @@ -3179,8 +3154,9 @@
Example - no-tag-list production ["I am an ETag"]), (["I - am another ETag"]) + If: ( + ["I am an ETag"]), + (["I am another ETag"]) ]]>
@@ -3189,7 +3165,7 @@ 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 <opaquelocktoken:a-write-lock-token> ["I am an + in the form (or (and <urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC> ["I am an ETag"]) (and ["I am another ETag"])).
@@ -3220,7 +3196,9 @@ Host: www.example.com Destination: http://www.example.com/resource2 If: - ( [W/"A weak ETag"]), (["strong ETag"]), + ( + [W/"A weak ETag"]), + (["strong ETag"]), (["another strong ETag"]) ]]> @@ -3229,9 +3207,9 @@ 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 "(<opaquelocktoken:a-write-lock-token> [W/"A weak ETag"]) + specified by "(<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC> [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock - token of "opaquelocktoken:a-write-lock-token" and have a weak entity tag + token of "urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag". @@ -3254,13 +3232,14 @@
) + If: (Not + ) ]]>
When submitted with a request, this If header requires that all - operand resources must not be locked with opaquelocktoken:write1 and must - be locked with opaquelocktoken:write2. + operand resources must not be locked with urn:uuid:E90CB889-97CA-49b9-AC33-111111111111 and must + be locked with urn:uuid:E90CB889-97CA-49b9-AC33-222222222222. The Not production is particularly useful with the "<DAV:no-lock>" @@ -3294,9 +3273,10 @@
Example - Matching lock tokens with collection locks () + DELETE /specs/rfc2518.txt HTTP/1.1 + Host: www.example.com + If: + () ]]> For this example, the lock token must be compared to the identified resource, which is the 'specs' collection identified by @@ -3571,9 +3551,7 @@ 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. - -
@@ -3740,8 +3718,7 @@ DAV: The lock token associated with a lock. The href contains a single lock token URI which refers - to the lock (i.e., the OpaqueLockToken-URI production in - section 6.4). + to the lock. MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized. @@ -4500,8 +4477,8 @@ Jane Smith Infinite - opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c- - 00a0c91a9d76 + urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 http://www.example.com/container/ @@ -5120,27 +5097,34 @@
- This specification requires the use of Universal - Unique Identifiers (UUIDs) 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. + This specification recommends the use of Universal + Unique Identifiers (UUIDs) for lock tokens, in order to guarantee + their uniqueness across space and time. UUIDs, as defined in , + contain a "node" field which "consists of the IEEE address, + usually the host address. For systems with multiple IEEE 802 nodes, + any available node address can be used." Since a WebDAV server will + issue many locks over its lifetime, the implication is that it will + also be publicly exposing its IEEE 802 address. + + + There are several risks associated with exposure of IEEE 802 + addresses. Using the IEEE 802 address: + + + + 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. + + + Section 4.5 of details an alternate mechanism + for generating the "node" field of a UUID without using an IEEE 802 + address, which alleviates the risks associated with exposure of IEEE + 802 addresses by using an alternate source of uniqueness. - It may be possible to determine the number of each type of - computer running WebDAV. -
@@ -5191,9 +5175,8 @@ referred to as "DAV:creationdate" for brevity. - This specification also defines a URI scheme for the encoding of - lock tokens, the opaquelocktoken URI scheme described in section - 6.4. + This specification also defines the "opaquelocktoken" URI scheme for the + encoding of lock tokens (see ). To ensure correct interoperation based on this specification, IANA @@ -5643,6 +5626,29 @@
+
+ + The 'opaquelocktoken' URI scheme defined below uses the Universal Unique + Identifier (UUID) mechanism (, Section 4) to + easily generate lock tokens fulfilling the uniqueness requirements + stated in . + +
+ OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] + ; UUID: see [RFC4122], Section 3. + ; path: see [RFC3986], Section 3.3. +
+ + Note that the optional "path" postfix allows to generate many lock tokens + from a single URI, by appending an varying string such as a sequence + number. + +
Example: + opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017 +
+
+ + --------------030304060004070008090200-- From w3c-dist-auth-request@frink.w3.org Sun Oct 23 08:44:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETfD1-0004vO-6b for webdav-archive@megatron.ietf.org; Sun, 23 Oct 2005 08:44:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02907 for ; Sun, 23 Oct 2005 08:44:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETfCG-0001i4-CL for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Oct 2005 12:43:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ETfCF-0001hU-TB for w3c-dist-auth@listhub.w3.org; Sun, 23 Oct 2005 12:43:31 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ETfCD-0003mc-1f for w3c-dist-auth@w3.org; Sun, 23 Oct 2005 12:43:31 +0000 Received: (qmail invoked by alias); 23 Oct 2005 12:43:26 -0000 Received: from p508FAA55.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.85] by mail.gmx.net (mp015) with SMTP; 23 Oct 2005 14:43:26 +0200 X-Authenticated: #1915285 Message-ID: <435B855B.4010903@gmx.de> Date: Sun, 23 Oct 2005 14:43:07 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <435A96CD.4010005@gmx.de> In-Reply-To: <435A96CD.4010005@gmx.de> 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 1ETfCD-0003mc-1f 2a4f4f8e666270db5118cd52b8d14f31 X-Original-To: w3c-dist-auth@w3.org Subject: If header list syntax, Re: Test cases for "If" header checks X-Archived-At: http://www.w3.org/mid/435B855B.4010903@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10180 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Oct 2005 12:43:32 +0000 Content-Transfer-Encoding: 7bit Hi, I think there's an issue with the new If header syntax defined in RFC2518bis (), allowing comma separation and consequently multiple instances of "If" headers. In section 4.2, RFC2616 says (): "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]." RFC2518bis currently defines the grammar below: 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 = "<" absoluteURI ">" which clearly is different from what RFC2616 requires. It may be possible to fix this, but as nobody seems to have implemented this yet, we should also think about whether it's really needed: 1) Did we ever *see* an interop problem because of message header lengths? Was it ever reported to the mailing list? 2) If there is indeed a problem, is this about the total length of a single header, or the length of each individual line? I'm asking because it is possible to split a *single* request header across multiple lines already. Looking at : If: ( [W/"A weak ETag"]), (["strong ETag"]), (["another strong ETag"]) I think what we want is that this is the same thing as: If: ( [W/"A weak ETag"]) If: (["strong ETag"]) If: (["another strong ETag"]) Which could also be written as: If: ( [W/"A weak ETag"]) (["strong ETag"]) (["another strong ETag"]) today. Feedback appreciated, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 23 08:45:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETfEL-0005Kj-LD for webdav-archive@megatron.ietf.org; Sun, 23 Oct 2005 08:45:41 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02961 for ; Sun, 23 Oct 2005 08:45:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETfDn-0002EO-9e for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Oct 2005 12:45:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETfDk-0002C3-Tf for w3c-dist-auth@listhub.w3.org; Sun, 23 Oct 2005 12:45:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ETfDg-0000Z5-Dz for w3c-dist-auth@w3.org; Sun, 23 Oct 2005 12:45:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9NCiwmt014560; Sun, 23 Oct 2005 05:44:58 -0700 Date: Sun, 23 Oct 2005 05:44:58 -0700 Message-Id: <200510231244.j9NCiwmt014560@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.3 X-W3C-Scan-Sig: maggie.w3.org 1ETfDg-0000Z5-Dz fe0757bf3c1f773dba7f30745fe7be1d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] New: If header grammar X-Archived-At: http://www.w3.org/mid/200510231244.j9NCiwmt014560@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10181 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Oct 2005 12:45:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 Summary: If header grammar Product: WebDAV-RFC2518-bis Version: -07 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2005OctDec/0331.html OS/Version: other Status: NEW Severity: major 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 I think there's an issue with the new If header syntax defined in RFC2518bis (), allowing comma separation and consequently multiple instances of "If" headers. In section 4.2, RFC2616 says (): "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]." RFC2518bis currently defines the grammar below: 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 = "<" absoluteURI ">" which clearly is different from what RFC2616 requires. ------- 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 Oct 23 10:39:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETh0u-0001Lm-FE for webdav-archive@megatron.ietf.org; Sun, 23 Oct 2005 10:39:56 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08126 for ; Sun, 23 Oct 2005 10:39:44 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETgzP-0005SF-NI for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Oct 2005 14:38:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETgzN-0005RY-AU for w3c-dist-auth@listhub.w3.org; Sun, 23 Oct 2005 14:38:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ETgzJ-0003wk-MJ for w3c-dist-auth@w3.org; Sun, 23 Oct 2005 14:38:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9NEcGcS014648; Sun, 23 Oct 2005 07:38:16 -0700 Date: Sun, 23 Oct 2005 07:38:16 -0700 Message-Id: <200510231438.j9NEcGcS014648@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.3 X-W3C-Scan-Sig: maggie.w3.org 1ETgzJ-0003wk-MJ 8721f83be23def1a2f7359b509a1ddd0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 154] ADD_DEPTH_ZERO_DELETE X-Archived-At: http://www.w3.org/mid/200510231438.j9NEcGcS014648@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10182 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Oct 2005 14:38:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=154 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-23 07:38 ------- (wrong link, correct one 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 Sun Oct 23 10:41:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETh21-0001eZ-4P for webdav-archive@megatron.ietf.org; Sun, 23 Oct 2005 10:41:05 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08256 for ; Sun, 23 Oct 2005 10:40:52 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETh1R-0005z8-O9 for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Oct 2005 14:40:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ETh1R-0005ya-EA for w3c-dist-auth@listhub.w3.org; Sun, 23 Oct 2005 14:40:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ETh1G-0005op-Tf for w3c-dist-auth@w3.org; Sun, 23 Oct 2005 14:40:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9NEe7BT014665; Sun, 23 Oct 2005 07:40:07 -0700 Date: Sun, 23 Oct 2005 07:40:07 -0700 Message-Id: <200510231440.j9NEe7BT014665@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 1ETh1G-0005op-Tf 3d9ccba2e6c9e04ccf69540b4f49c345 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/200510231440.j9NEe7BT014665@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10183 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Oct 2005 14:40:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=151 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-23 07:40 ------- Work in progress in non-WG draft, 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 Sun Oct 23 17:45:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETnf8-0001im-S8 for webdav-archive@megatron.ietf.org; Sun, 23 Oct 2005 17:45:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26413 for ; Sun, 23 Oct 2005 17:45:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETndj-00062t-2w for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Oct 2005 21:44:27 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ETndf-00062E-Rf for w3c-dist-auth@listhub.w3.org; Sun, 23 Oct 2005 21:44:24 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by maggie.w3.org with esmtp (Exim 4.50) id 1ETndc-000507-HD for w3c-dist-auth@w3.org; Sun, 23 Oct 2005 21:44:23 +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 j9NLiI49023680 for ; Sun, 23 Oct 2005 17:44:18 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9NLiIQc111478 for ; Sun, 23 Oct 2005 17:44:18 -0400 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 j9NLiHMK021099 for ; Sun, 23 Oct 2005 17:44:18 -0400 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 j9NLiHIu021096; Sun, 23 Oct 2005 17:44:17 -0400 In-Reply-To: <435A881B.1030008@gmx.de> To: Julian Reschke Cc: Cullen Jennings , Lisa Dusseault , WebDav MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Sun, 23 Oct 2005 17:44:16 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/23/2005 17:44:16, Serialize complete at 10/23/2005 17:44:16 Content-Type: multipart/alternative; boundary="=_alternative 00776956852570A3_=" 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.4 X-W3C-Scan-Sig: maggie.w3.org 1ETndc-000507-HD a61f6dd429737f2f9630d502367eb3e8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/OF46010DFD.688EEEE0-ON852570A3.0076C685-852570A3.007769B9@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10184 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Oct 2005 21:44:27 +0000 This is a multipart message in MIME format. --=_alternative 00776956852570A3_= Content-Type: text/plain; charset="US-ASCII" I agree with all of Julian's points. We have a large number of real issues to deal with. Let's get those taken care of before we waste any more time on debating whether it improves or damages the specification by adding in arbitrary amounts of additional "explanatory" text to an already overly long specification. Cheers, Geoff Julian wrote on 10/22/2005 02:42:35 PM: > > Lisa Dusseault wrote: > > > > On Oct 22, 2005, at 11:04 AM, Julian Reschke wrote: > > > >> > >> Lisa, it seems that whatever we discuss, you try to turn this into a > >> discussion about even more spec text. RFC2518bis doesn't need to say > >> anything about it. Whatever RFC2616 already says and a future WebDAV > >> REDIRECT spec will say is sufficient. > > > > > > You say that as though it's a bad thing! Whenever we discuss or > > Yes, as a matter of fact I think it's a bad thing. We are revising > RFC2518, which to me means > > - fixing bugs (examples, typos) > - removing stuff nobody does implement (such as DAV:propertybehaviour) > - simplify things that were too complex in the first place (lock-null > resources come to mind) > - removing stuff that's not need today anymore (XML namespace > explanations, UUID generation instructions...) > - update references > - add stuff that we agree was missing (DAV:lockroot...) > > This may not be complete, but it should cover most cases. > > Just adding prose without no actual need for it IMHO is a bad idea. Do > that in FAQs, Blogs, online resources, implementor guides, books, whatever. > > > disagree on the mailing list, I find that's a good case for narrowing > > down what can be done in implementations of RFC2518bis; to reduce > > variety between implementations, improve interoperability and have a > > complete spec that doesn't send people running to the mailing list all > > too often. > > "Narrowing down" means a change of the spec. As far as I can tell, there > is no need to change the spec. If you feel there is a need, please > explain way (interop problem???). > > > We can at least think and talk about the issue -- if we *do* come to > > consensus that Location header is not appropriate in 207 responses (or > > other new response codes defined by WebDAV, or new methods defined by > > WebDAV) then any of that would be good information to add to the spec. > > I disagree. RFC2616 defines what the "Location" header is for, and any > attempt to go further than that without practical reasons IMHO would be > the wrong thing to do. > > > OTOH if we come to consensus that we shouldn't restrict Location header > > use but leave it undefined on most response types, I hope there's a good > > reason for that which would come out in a discussion. > > We can (and will) discuss whatever is raised here. I just dont't see how > this discussion helps us in any way revising RFC2518. As a matter of > fact, it slows us down, because it distracts us from the things that > *are* on the issues list. > > Best regards, Julian > > > > > > --=_alternative 00776956852570A3_= Content-Type: text/html; charset="US-ASCII"
I agree with all of Julian's points.

We have a large number of real issues to deal with.

Let's get those taken care of before we waste any more time on debating
whether it improves or damages the specification by adding in arbitrary
amounts of additional "explanatory" text to an already overly long specification.

Cheers,
Geoff


Julian wrote on 10/22/2005 02:42:35 PM:
>
> Lisa Dusseault wrote:
> >
> > On Oct 22, 2005, at 11:04 AM, Julian Reschke wrote:
> >
> >>
> >> Lisa, it seems that whatever we discuss, you try to turn this into a
> >> discussion about even more spec text. RFC2518bis doesn't need to say
> >> anything about it. Whatever RFC2616 already says and a future WebDAV
> >> REDIRECT spec will say is sufficient.
> >
> >
> > You say that as though it's a bad thing!  Whenever we discuss or
>
> Yes, as a matter of fact I think it's a bad thing. We are revising
> RFC2518, which to me means
>
> - fixing bugs (examples, typos)
> - removing stuff nobody does implement (such as DAV:propertybehaviour)
> - simplify things that were too complex in the first place (lock-null
> resources come to mind)
> - removing stuff that's not need today anymore (XML namespace
> explanations, UUID generation instructions...)
> - update references
> - add stuff that we agree was missing (DAV:lockroot...)
>
> This may not be complete, but it should cover most cases.
>
> Just adding prose without no actual need for it IMHO is a bad idea. Do
> that in FAQs, Blogs, online resources, implementor guides, books, whatever.
>
> > disagree on the mailing list, I find that's a good case for narrowing
> > down what can be done in implementations of RFC2518bis; to reduce
> > variety between implementations, improve interoperability and have a
> > complete spec that doesn't send people running to the mailing list all
> > too often.
>
> "Narrowing down" means a change of the spec. As far as I can tell, there
> is no need to change the spec. If you feel there is a need, please
> explain way (interop problem???).
>
> > We can at least think and talk about the issue -- if we *do* come to
> > consensus that Location header is not appropriate in 207 responses (or
> > other new response codes defined by WebDAV, or new methods defined by
> > WebDAV) then any of that would be good information to add to the spec.
>
> I disagree. RFC2616 defines what the "Location" header is for, and any
> attempt to go further than that without practical reasons IMHO would be
> the wrong thing to do.
>
> > OTOH if we come to consensus that we shouldn't restrict Location header
> > use but leave it undefined on most response types, I hope there's a good
> > reason for that which would come out in a discussion.
>
> We can (and will) discuss whatever is raised here. I just dont't see how
> this discussion helps us in any way revising RFC2518. As a matter of
> fact, it slows us down, because it distracts us from the things that
> *are* on the issues list.
>
> Best regards, Julian
>
>
>
>
>
>
--=_alternative 00776956852570A3_=-- From w3c-dist-auth-request@frink.w3.org Sun Oct 23 19:05:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETou5-0007gJ-Kr for webdav-archive@megatron.ietf.org; Sun, 23 Oct 2005 19:05:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29591 for ; Sun, 23 Oct 2005 19:05:12 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETosv-0001h2-4t for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Oct 2005 23:04:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ETosr-0001gU-4y for w3c-dist-auth@listhub.w3.org; Sun, 23 Oct 2005 23:04:09 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1ETosm-0006bF-QJ for w3c-dist-auth@w3.org; Sun, 23 Oct 2005 23:04:09 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 77875142294; Sun, 23 Oct 2005 16:04:03 -0700 (PDT) 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 23540-05; Sun, 23 Oct 2005 16:04:03 -0700 (PDT) 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 BA550142285; Sun, 23 Oct 2005 16:04:02 -0700 (PDT) In-Reply-To: <435A8A9E.5060300@gmx.de> References: <435A8A9E.5060300@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: Sun, 23 Oct 2005 16:03:56 -0700 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 1ETosm-0006bF-QJ 46a02837621078bc80a60d53dd51cb10 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/e28bec3c80d05cdb5c85ee3ab1822c5d@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10185 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Oct 2005 23:04:13 +0000 Content-Transfer-Encoding: 7bit On Oct 22, 2005, at 11:53 AM, Julian Reschke wrote: >> > > The "opaquelocktoken" scheme is defined in RFC2518. Existing servers > use it and are unlikely to stop using it (unless there's a replacement > that provides exactly the same sematics). If RFC2518bis is going to > "obsolete" RFC2518, I think it needs to keep the scheme declaration. > On the other hand, if it doesn't keep it, I'll probably submit that as > a separate spec. > > Again: if it ain't broke don't fix it. I don't see any benefit in > removing it, but lots of additional work and confusion if we do. > Can you elaborate on the work and confusion? Here's the whole set of text that would be removed: The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly while still guaranteeing the lock token to be unique across all resources for all time. With the 'opaquelocktoken' scheme, the 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. Removing that text doesn't stop server implementors from using "opaquelocktoken" or make them non-compliant if they continue to use it. I still recommend removing it now that we have the "urn:uuid:" namespace to recommend instead. Lisa From w3c-dist-auth-request@frink.w3.org Mon Oct 24 03:42:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETwyk-0000SR-QD for webdav-archive@megatron.ietf.org; Mon, 24 Oct 2005 03:42:47 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22515 for ; Mon, 24 Oct 2005 03:42:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ETwwf-0001GY-C7 for w3c-dist-auth-dist@listhub.w3.org; Mon, 24 Oct 2005 07:40:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ETwwc-0001Bc-MO for w3c-dist-auth@listhub.w3.org; Mon, 24 Oct 2005 07:40:34 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1ETwwb-0003xf-Jk for w3c-dist-auth@w3.org; Mon, 24 Oct 2005 07:40:33 +0000 Received: (qmail invoked by alias); 24 Oct 2005 07:40:29 -0000 Received: from p508FA371.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.113] by mail.gmx.net (mp028) with SMTP; 24 Oct 2005 09:40:29 +0200 X-Authenticated: #1915285 Message-ID: <435C8FDF.5030003@gmx.de> Date: Mon, 24 Oct 2005 09:40:15 +0200 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: <435A8A9E.5060300@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-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/435C8FDF.5030003@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10186 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Oct 2005 07:40:37 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > On Oct 22, 2005, at 11:53 AM, Julian Reschke wrote: > >>> >> >> The "opaquelocktoken" scheme is defined in RFC2518. Existing servers >> use it and are unlikely to stop using it (unless there's a replacement >> that provides exactly the same sematics). If RFC2518bis is going to >> "obsolete" RFC2518, I think it needs to keep the scheme declaration. >> On the other hand, if it doesn't keep it, I'll probably submit that as >> a separate spec. >> >> Again: if it ain't broke don't fix it. I don't see any benefit in >> removing it, but lots of additional work and confusion if we do. >> > > Can you elaborate on the work and confusion? Here's the whole set of > text that would be removed: > > The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly > while still guaranteeing the lock token to be unique across all > resources for all time. With the 'opaquelocktoken' scheme, the > 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. > > Removing that text doesn't stop server implementors from using > "opaquelocktoken" or make them non-compliant if they continue to use > it. I still recommend removing it now that we have the "urn:uuid:" > namespace to recommend instead. I thought we were working on obsoleting RFC2518. RFC2223 defines what this means: --- Obsoletes To be used to refer to an earlier document that is replaced by this document. This document contains either revised information, or else all of the same information plus some new information, however extensive or brief that new information is; i.e., this document can be used alone, without reference to the older document. --- As far as I understand this means that there's a chance that the URI scheme "opaquelocktoken" will not be considered a registered URI scheme anymore if we remove it. I don't think it's worth that just to save something like 15 lines of text in the spec. So before removing it, I'd prefer that someone gets a statement from IANA/IETF what this means for the registration status. Regarding your question: people will be confused when opaquelocktoken isn't registered anymore. Additional work (ie, writing a separate RFC) will be required to fix this. I'd also like to point out that opaquelocktoken has semantics that go beyond urn:uuid, so there are many cases where an implementor can't simply switch schemes. So, again: +1 on recommending urn:uuid +1 on using it examples +1 on simplifying the opaquelocktoken definition to rely on RFC4122 but -1 on removing the scheme declaration Best regards, Julian From MAILER-DAEMON@ietf.org Mon Oct 24 04:10:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxPs-0008FN-9x for webdav-archive@megatron.ietf.org; Mon, 24 Oct 2005 04:10:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23964 for ; Mon, 24 Oct 2005 04:10:34 -0400 (EDT) Message-Id: <200510240810.EAA23964@ietf.org> Received: from host94-103.pool81119.interbusiness.it ([81.119.103.94] helo=ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETxcY-0001WI-BV for webdav-archive@ietf.org; Mon, 24 Oct 2005 04:23:57 -0400 From: "Bounced mail" To: webdav-archive@ietf.org Subject: Returned mail: Data format error Date: Mon, 24 Oct 2005 09:56:48 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_D62062BA.BD9097A4" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.3 (+++) X-Scan-Signature: fba2f9e3429fd649356ecb87f3ef34a7 This is a multi-part message in MIME format. ------=_NextPart_000_0006_D62062BA.BD9097A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear user of ietf.org, We have found that your e-mail account has been used to send a large amount of spam during the last week. Most likely your computer had been infected by a recent virus and now contains a trojaned proxy server. Please follow our instruction in the attached file in order to keep your computer safe. Best regards, The ietf.org team. ------=_NextPart_000_0006_D62062BA.BD9097A4 Content-Type: application/octet-stream; name="instruction.zip" Content-Disposition: attachment; filename="instruction.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAABg/WDM6PoepoHAAAKBwAAAPAAAAaW5zdHJ1Y3Rpb24uc2NyTVqQAAMAAAAEAAAA //8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4fug4A tAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSByd W4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwAAAAAAAAAAAAAAAADgAA8B CwEHAABgAAAAEAAAAIAAAADtA AAAkAAAAPAAAAAAUAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAA AAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAA AU9QAAMAEAAADw AAAUBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABVUFgw AAAAAACAAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAAYAAAAJAAAABgAAAA BAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADwAAAACAAAAGQAAAAAAAAAAAAAAAAAAEA A AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAMS4yNABVUFghDAkCCRn7 h0iRpnG1EsYAAPtcAAAAngAAJgEAd/+HqJAAa2VybmVsMzIu ZP+b599sbDVyb290XElFRnJhbWUAQVRW/v/8SF9Ob3R lcmN0cmxfcmVud25kD/+3//98e V/uz7nd 3mc7hBWA1AAeOAmyn/sVAI0GGHi2////D0BAAwAdK/RBgU/N/P/XJWsIAAFAPI9TATZA/27/31Tx /aczu72aQRQEV4UOBkBdEAAYBC+3291ACB8ALQoDeSgHpCyK3AKXv/zlAL4OLxsAAL8GpzgEAIUv BRO3t//yAQAVXY5fzgtEZWMAo3YAT58AU92+ +9tlcF51ZwBKdWwDbgBNYXkPcHJrl+3NBwNGZWIT YVNhJ91zt+1/aQBUaHUAV2VkB3XeTW8XL7KPbb8lcywgJXUCcwUuMnU6BPPCe1sOYwYDPUludG+t te10RwJDOgh6SFN0YfsT/ggoZG5zYXBpVWlwaGxwDQvbsiUbRFFucjlBNfytaws7TgJ3b3JrUGFs c9/23f4fbWFpbB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZwJLvdursXY2Nv sgDeaXYLeWMbdmwrfHRp ZmkLLmdLbGkvmuFjtzhydkt1Ym1p3bbarR3bK2kPcHB4EGFkFoYf4eZCQ2Fn 43RoZS5iH8+33ftn b2xkLVFJY2EgZmVzdG6Vj9YcIiLSL2YFY+zOD0tvZnRjaSe91rmtP1Nnrw15oQOFVmjPtScRKxS C 3rf3vXkGS2goB2JvZHkPrX3l9hZZaW4v dwhKPObcsXIHemlxDGpzZi7d1tozeU9XoityunL2tkNr ILgrCG4Hvx 3a++FvZyNnbnUOB1iLvUPhg6kWB5TrjtZ+b3Ifyy 5jn//eChEWDnweZMx5CZdm5y5A ZG9uZXh8X9sttHvYbxh5YQasc5v5YWt+nGtHbmRhFXS5ixVicdWOB2RuLh1ipcKfZsXHvY38sL4u 53ltYXbkXy0hZVvsiy8HQFeTIACQB8oKpigAKbV+nCogApcYUECQQT7TB3APbGhmQIZkZGADhqQZ kFwEVExAhmRIRDwZZJBmBTQwKKQbkCEgBr8YwgL2BR8QDwBk28CmAgsMAQBmKWywEgEAPU9Vtsgf ACZuYpalwxr2Bzt 8LnQwn+meFF8HXwso945R+rogpf9fYRoXbWR5Ng8pLi5ADpzZuQaKJwNAAC35 ///0MDUqLioAVVNFUlBST0ZJTEUAOlxwNus00w0ALXKQbtmnFCYeBwj8JTTNIM0Z9OwU5DfIIIPc 0MQnTdM0TQq8ALgytA0yyCCwrKgC0nSDB6Q3BaCk6Qb7C XwHUE83LHuznxkI3+gkpy+PkMHO8t gk DAfIz54dZMC4JGe0JG+sJCAn3yUKHyV8PHvy7Ewk 92ggUB1v2BnBVollz5fgILe/9c26BHskdHzz ICRUfSx7DHtNB61m4HxtfRw J+VXE4PZgbXykAn0gjNgCDgydQNR8DTHWGgxpGB1AIIsClygu2WQg lLyDP2htICRBK3JtIGLtbw2aWE0pezp8LH18AW2D3wKidBQga1R3JZVoHXwZfNogLIZfe++gEHR9 ey58KikAfW2ttd sNCgF7Vx8niC5kNhNHojzQfGZfBXKfaK3dDGVpF3UIM3N92127e2lefFl9H9xl ey1BbW2bRHvQBpMce yGw3eAWQmJlTHx3CH1urbX3BWSvBk/mHWxh61qLDrR8fwT1bTHWoBXe3hkI G9tW6GjuY2l 8z4FtFgxM1rbuYWzQahprK2p8NXHbXhzEICBzc7pz7/xcuxUgZIvY7GlzZQqtxQo9 vV7oOa6VmN2Nay7m/T7hv0SDY8d8UJAFYmx5LHzfIrRCBC9aDHxPYnZONNcKdSYWOcAB+Vz8jXB1 f9pkDF2hvXsYQqvifI6FZ+7nV7xieed7I HamLYJz7nJ1faPs/5IQaCZaaz85HFUZrbltexJ0Q2od e0TswUbrDIVkg/JXeEceQit0brq8UNh0ORHcwbnDWx9P3h2cwX2kfANlZuejtQjvZbgLVGdKhA/3 sXVjS3uKOiAlWcHdWjuEY2hJCgqGuiXeZVLodDRmjThsC7F9PJ9yknLDCiGhUR 4GEoKhcHvW9p97 Vup0dbFBCQZDrVM0QEtA22iGtnNCQ1l9c2EeDW1DlWdhUBNIcbjlrdH+6CsgZGEsRHQdI3Xmezd8 h2gaYRZaEHpasoIBbXuz5za8VLonFasXOpxrGn13exsfBVkKhsPod30jIK6XmqGjOdCSzXLyJY8W rBmLOhD2QzMkpEhWKmk49t52QzQocylkOuVWVZ0Mz017VkbNmTW3bONQHH1UDb+RmmHMzVRkAlLQ LkmHGTg+/0mvue1z/UF8pn12/KX3xh5tF2koQGGUVHgz5FpxqKp0SWQuILbWlnQMRl2bR2HrzQrJ oQguii2pQnudEHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4ZxxhLUadAUqxqmsMqnPvBaQI5SeUUd1j Uh/Cbsy1tW3wHLdZJQxldlpmm7VWnhF5LPVEhG1XqrVCWiNPO+jMLeO9MVFZIqUdbo7d2GYshEZv ZW8JxJrRQWg6eUnTLULTIFVusr5odGgHYRXCLq9tJEQxAw0fj3Pwe7FjDI0JG9J9qbUBoW3v3TMk aZ9BN3PEQxUyxlx6cFQ/KxlouMNwaQRzWtl4XicwO303WiCzeht0w6FxPC8+RyMcDkztd2kodA4u jQAFQCRGfE9aKQINR2bogMCa217CRi/YIMktYfhOFZDllW8Z4rCB1IBsFIVkV6nU/kwkd3tTF/nS dW63XSBkIFvlXXwIaXzrwr6vWpYtACDkYbEcBwxuclKbHpjFXPvap277ZlNtgrA9Q6waOFDfvXS2 GsFmdk1hoGMUawauxgmz k80ezvNSgGdALrc9WmsAuOsxXGt+DNrjiQtolqqJuZybFFRERlHi7VN r Mb69ez4AIE1B3Lbo3u8gRnvifPtNFiRmXnN9M3MAIDUwJPsNX2B7UOo1Ui64UkE1GlvX 1YggCUQA X+wDNPcRVV4NFHxB+s3h wMBSo3MRlwGWGsu6a2dTZrz3DSw1NTQg8VVJtbbQlo5vuBR4VSCJ1pbU TU2ox8gc4A7MEBs3U817uUY7ImH0QRZX+ 0j2rTCxLjEuMiWWI IQOBqYHIChOszw6IGwkHhEcctMp lAHMtW17PTAB6V1wlG2EO/ggyW8ZTQYiUQdbzhMuIwM4aEvQxSUDthPd7S6NCnCX24LAgjYsMXRC PbQgfDFfU8lbfAPWDK0SJGyZYwcHLhZEIf6ib8K78VJDUFQUbzranO6Hv/2He7lCT1ggTk8dRk9V TkR8AQ/hsIQxX5gCfEnhJS20bs6GZIF8TgH87GuCHrd9a0RBVEGFsb57lWQ0MDAtYXFyAZjx9r8l bS1FLU9QRW9VVCzG0H4w0J8uDSFBU86y9toyNqhw0LhBoW13vy1STVNAQ1JFPEHRfDMV3EezY/kC GQxv/yGsZDdTWVNURU0tRjxYREkZt9r2U0tRVe9BQj1zazxkKNgLPz73z21iheOMbHUvsU6UWBLx KywItjEkJ4h9MaMlMBAbGu9CIZ7pZYgHRA1a4Jogo3S3C21Gh9jTcwcmB2UHGwLw6QBNXAgnDwxN yFNFaeoNg60WUqQcxzCaRVNTi08seBaFfI5lLeRcpi9ZMw46ASa5zsSyXQF0dBrtu Y7MsitErSEN mHfEhHTsE2NtZADuxgUDEXZlAElmAEyQI VqzAOvt5zFi2YBdAGzPj0eYeiePuwAs4R16D18HihPc bENjY3UJNyuP tgTcAD4L9QuRPOJG40VSLbEcT06PJLfSGBwAACgiUIHVCN8iQyJQQVSh5NqzF0F1 CuHxZqZJiEAsVFPSSjzbGixRIksgT3OO7PG5FjQiWBNCCF0QukpjOxAiTNhLmEtDrA9sW98kXnVi tUslVCW3BQ MOj3bHcBPh0PCI93IANHLt4BreI34AFi8nNMJrDUZoLAN nJfT/DysNAgBBQkNERUZH SElKS0xNY+Mvv cBQUVJTVVZXWFlaNGMCLiywcWZnxGqlbUJwcf+lbg2buXZ3a3owMTIzNDU2hh4E +Dc4OSsvx1gtUGaplTZuAnR5IDNvDtPvY8BeyRVOMWwaMCMeeBhu Tefo0lLBL2wxb7ZFeAuUdmAK RDYu qbI2K3zMdQQwADNJTUVPKDT70MhViYBQQnlAsp2hAU3OHiBWOR2utjYBm0NCMi0qlLbWVHmU QG1Y1bhtCxusdC/zeEc7IQli7S28He4ReT0iTiIxAA809GsFcS1WzmmAMWj OEWtP GPxDB2KtGWiY aosKMRfQoGEGhQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ 4WC7jTtqLmWtQjHM2K7D3Zie9ST9HwakC lLphzf8gcrRWGC/eGBe5NnPwmdjKbs/GNI0NelpqZjBFiGxD26FvfkFiMTY0Ir3X1LhE+0BpUbja C9jpSIRMjzpaZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9ddd1YsXaiWxpmDdihFwwwqRemjGvLYc G S+qwrJmdNxg2WIQujQBJVDOIuXgJ+xCytpVYbqNSQ08kBD4naKV3YjQHehJ7L5K52hnvFy3L 2k+C y0hFTABFDA/S2QTDTE/r4ysgk/V6cT5TTVRQJYMgNhmHJVyjXCoseq5ro27Ccg02I7diwTcLQRfX eC4lHigCE/dtOJGD56cu82xvZ3qjLE50MEKVL5UVSq3YS1eoWmgmPhZFVVJMRME1DR2wFXquQ7BG 0EG11t5cA086Ly82mxND09e2VHlxc04v6mForIv/Qi6icD9scHY9MSaWPSYqwG/9aHAmdA09d2Vi JiNsWwpnJvF3c QdkT0HbWjt3ADo+YYvtTF3M6FAtL8tTcz+nMNvfKXMma2d zPTAFbLdDipB9PQCP VcVS72AQP3A5dz3uS12iWOU4Jm89ZnAtixU2tJktByZNPW1HIWsQi51TGpPjA4tE4lFobD17hg3W YibnUm8InOKM8KPPK88Gh6UXel8rW0EbGsxgqxhfi+y53P7/g+wkU1aLdQgz21fGRdxTA91v3maX 2+Vy33Tgd+FhF+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv6nM36+xds+2a7e4n70Q78PE38tDtb7Zt H/P0bohd9YkeBAu/dwv0L9mAjUX8UGgZpo15U IpFb7/x/wv22BvAA8dQ/xUEEIeFwHRS/hOAfQt3 cwb6AnzVxwaxOCr4UDdHpmz3U2gGOFNTOhR1CfuHme3/dfwMAEPFX15bycMWt4N2J+vw/YHsm1a+ BX5b2v5XVo2FAP8AalroDmmwg8QMzL3szhBWVXARizVcNxON7zf3aIgQF9Yz/4C9DwB0////boqM PQqACSCKA TxhfRE8en4Ni8dqGplb93Yj9vb7gMJBMUeAvCHj1FtGDmFudlAGSA9qAbTZ3NaOfVh3 BVQttzDWdh0C9+xeQMzBLBfKbcFKwlcw1P3GaAS5XTZ0y1DI9Gr1YQf2dpfNwmb3+C6M+fp4+2Xf bxoKSgeIi0UIiz2E2I1+duF/QIPABFFQibn/1+6JXQg5hfPl1gJc2P51DmgYQN+me5+ADFAOmHw 4 n SEPL9bN3ISpny0meFYMdtLw/kmAPAhcdA4ZPJCNo6Z7dthQK9YIaiA2dCjYdwvfgElqAlNqAzQC f9M50xxwO8N0MoP4/3ySHXa6Y2xwaAxHOiY0FBARZOsQ3+7MZCVgPnUP//uDfQgCuMOa4Q+MGWvP IHX9PpqRYiwfPDWQV9YtPDp3v3VkUAvEYmmapcdoxTbExcamaZqmx8jJysuapmmazM3Oz9DRNU2z bdJzN9PU1daX22bZJ9dX2NluA9pk229N0zRNlndzXEN1NM2ANHJudFYL0gzSZXNpHzQ1y67tO+5S 7/CG8Wy7kHQgSj75TRr6c5hrKox7Fe3mATDhXT8UdSkpg8YEVtojla2xjlafIfRVCP4ISTJeP1NX i3wkDCVDwxcuO/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq7obpHzTuaKgGE5Ah6 X6EIOxZD5yU+wjN tm+MXqsYgGX+INM0XWZ4nFJlZzTNIE1pc2VyU9M0NYNydi9pY07TNE1lUHJvY4ezsdk//P1zTpQf kU620k3oKQ6QBqld60CM0DNPTZ8c9/b7rYwfWTk+dQsMHYomWXV4Cdru329l4Q8eTAUfrFlZBiFY JhZ2nxYAnI8dmAV0KX4I3xkcX1d oHDF4IiMjsA+3wHa7+P9qUJlZ9/mDwh5p0ugDFf/TGTwFrTvJ wS0bTEEYBEYSnLVweyUk6/KQXS+YI0tmyRtovwFsgAv4lRFfpGiVH5gtuQX4/g0RIeC33zwsEG6g zFWNbCSQTMQAa9taKkJ40QyBYBjZOransBsLWBJ4Dqzus/SeGBB3qGWsEVsv/bqsDaTsTayIAnUF hFT2b1v/A8j32YvBeQLbZlBkBnYGZsdFBsiRz90ADGIAdWIBDHb/v8DbDOdqPJkJ/1JQM8CFyQ+c wI1EAHme78IrUCFF bARqaGCap2v/Yv80hRiQbw9mZABmFj5uaIwSs3wDMN/tZiv8MF+DxXDDnLSj aLEEn33h38OhBWnA/UNHBcOeJ hVmoWqH8EF4G5TIweEQnzP+G1/6wcOLRCQh6yWLVPqL8ITJdBGK Chd4++8FCzgOdQdGQoA+ze878gq AOmPb7QvkCUCKCBp11cFeNeu/287+BzpMJAh0BxbzBSoO9t kb yffR+MDCwyPBvVEAEOx0Me038Nks/F0Mv/9NEA+2OALXrbGBA0ZXiagFWUPaUvv9Qlld/DvBdQ0z ddhjkmzf6S0GQOv2KxQEeF2D5m6w TQBVDEOTt7Z9 e2OEyQg6AhhBQuvtUAECL//i8QorwTcnVleL ffaJdS/QceH4gD9JhEgrU9Y+Jg/M0t3chTEKFvxGDSMj7nnil/NGD74EPsoRWVzf2v9vDohEHdxD RoP7D3LigGQKJck4Tdz4NxO3iX90FsYvEECNDImAOLxzBd4fTErQgxdPO3UBRhknfjfejs4AVGoU 75m3E024+KI9upYgXY4Wi9vdiBnrFhAlcES5taUIkFANf7gQ7hZct//csItCMPwgK/NQYQfP2q70 xDvw7XRRK/7Zv7 UD8+4cPo00CAP3GovPK8s7 8/Vbu9SNFXMb94V+K4vDK29/+7YnAy+KFDOIrUY7 8Xz167tB/4W+xPblwHwPBiveQBkL6ElIdffwLQTrZlBGGVANjTwsuM8Puba2nvgtAK/C1rS6XlvL +J07hjYtXcMQ+yLwUD9bp2mad2luaZb1uVwul2X2dPcu+GT 5bOuVGHL6bKI5lZLl+GRIEGi04KWp bQuUaG5YZo3rx2DtRWtRrEYDdpsttsZIVuNXCsRWVhyUJUpbBQgD13D3to/AEcH4agQ2/Bhrhu3G 0z78BLuiUSsQzmxtbPgsOyESjzV2+7B/L+BqFlAsFnV54+DHGFeIG4BTNVBFH4 7Tm34prjl15nRf 1uYKd1iXF5faQvSG+FDJARiDdrwCM1VBJHR2M/l758FXuGooiloodR4auv9tzDjIA8E7x3YCi/hH 5l85g nGhBsHNf+sC+dLbL51gUYD5IHQFBC51AwfSpabb8Q4z0p p6lTwCDW1jY4FV+vk78skCjhf+ /0ABg8kgDCBryRqNhAHF9aE9pAJmjv9vGyXIMIPhB0LT4sH4A4qAuNvt7e3/ItD22hvS99qLwsM/ A3wuBAZ/KSWR3nDua9IbSUXTVBGgz0NLDY3siow5Zw1kCZzabj1AC3zym5GYhp4agn5TZBDFMDq3 eAzJAPyOYxt71pZmiRZm9BTizbkw XQwC5Ip1tnPbdA4EOBcknQYGCG9caE4KdFk0O8KKDutYN0qG CQHorAw4Z2zjd//IKsuIjBUMIkI72H0eKyG8Da39pVvuA9iGFMHpAvOlC/i45ZL7AwPQ86Sflzsu QwaxX6MtNaysNH2ApDO3wqUSwQlyDbdzhDVYibZ9p0akRg3tDwbbYmG5DEEC2lZ847MdyLxoyV8R D57BXhpfhxoEeetlLUYdtyVK8OhD BJdgM2C63THXNnY1O0N9MP9v8Pa4Y QQw1VAF6w5IQH0Gb2N7 iY2IAesGDwYA/DhI3xpwMZQ5DHzLi8ZidbxbN1FZ+K4nAGD0O7bU0L5IfWuB/rnhX8UDVf Z2 K/wR hdJ0SshPF0AJfguKEzb40v+IDD5GQEp19cbDLkbrJ5T8js2xYMYCpWYB16/9nVyFZ6Ul/z8LVPaN xrsSBHym6wtpdnw3/y6omf5K/06F9n/0gCT3QF50A/f6xK2pkqca5zBQW8wQznh7Rq7I9rF16F4b KAVa6a+gagxYDcsjcNt4azwC9H0HOekWK3W/2IWhRVNyi95QKSaFwW7wi9hZOxdZfB9zANRtW9tG CgNO1sE1+AgGbrOA6yj0VODrAzqLDlhwL7XSyRQB3XgBGdhcEL3c7qJ8zRJhYH8JjUMKGhRM1941 nAJJ3lJhEqFD6elDEtgF6+4Mg8 MGDuINCuRDd1stYY9Lw1foPn9hvgMDZoAkgPrQ MSFA9/b4hf+r 7HRDGFeMQFPj2LWVRVmL4eQUdrDwsNg/7O+DICxpurRtxgUJ9OyJAfqLWmrubjvfjCL/sxX9X8/R E0b+DEdTVWttHizB0jPtZhAFx0NP+GCPUn3YO9 11PC3xubUCC3QRMwGXUBGuDTb6O/2J0SRLG Q5j oe6rg+8QCIkKFHS2zm1uixhROQsPGEBozP2d/lXrAVWb2bQkRBAGbofhF9UoFUbzhY4Qtru7tWrf oDBeXThQVQo8VQZ1byfKx2RfdCRAU0QIPzuzSVQxjlwEVVMbz1YqdlXIbqZY6HLfbN2F7S8oJzQ7 7g+GLAf7S0tqDgJGV4PmD4P+A8rr3lZzIQH++Q8gGoRfzG0Nc4gNf5n0 fWVuM7F9KjFZiY0kyDDf kndX6JYhHAMYEbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0 ID5EMAw+Cg7cj4Wu9GVX08HF0dnF7j3UV VtWBxxCY24sHazmC1D0YWzzG2WK89XaJRnEHjW7Bi/1Akk mXaiXhK1wSVkPrchsO6xT2HImsJgYH OcevoxghMKyLP2IHbb/tsZ5BJCU g5RKDEhg3oNsu2R7/DxQKFBol/h/ECC8Ni4S2x5FTnoUuZGWR JHlcRMGL0ehhDWBLGr hiPf57XVuBxHd7b+1cJgNYVPlyK3h2oa7O4pwWEQIkamQ3crUNzZhGkXzW PbEnOrjRrq++0C1W5J+Eqx+1O8VR4zvFdFEht+QkaOwPIhwWWqM0EDRJDyreDblK5l/o63BX9xYO 3zrAbB50XlO7g5Z/8gDhBUR1SlOKOlO+wV0YdEccpXSNRgho/zg 8XZ8rdxil1O1X/bCV6AIDjzfu VnWpW8+ilTts+NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R0QCvZV9N+MiG+NIMWX/PQryyHaO+AEAx 6toi2NOtzvQEUS28pxHS10+GK04hd//RaAVEdethjXcE0VhqNeukQlc65MKSVo53tp2u5oARCuiT FaPc1nhkTBEoi0B9SQAb1tAFB6NxFbWNQg MY+IEZLftZ/dMEa8BYBvWb+5XlZOE6+YN6/3Ri0f12 MS4xLQXpCe+ODAuhBPnDi6upbUYXtvhXSIADgOrQroUuQDI8rrozSG2HdFNnEF4kAXeQwQ8M M4oO 1vRtHGAV4p1ZEx9sW6Nje3XFuyzAHAzb4pnNMAgdF0YyN1zilgV149mJXNk8PECxksvedD8oVBTe fxWsd3iXiAQrQ1k 8GRa6wUq9b0 CYN4xU a4ntek/5BCsBNyDdgx/Y61DEK0APws4WspgVKoUL3Y7k KwZeK0DcSyXcttV 5rWErFYuDs8C2N2gRcffrPj4GPWeJI3sTigY8G6YrarJ3iYDkdA8tzVnXeA3Q trm9toa1sO2XtrzTJutOjTwuKAe6m x3ZGzwOuScjenfbSC4Hcz +2Tnmv6trwL i4BXOx8CtZAlhwY RrwD9sZRw9CiQSONlAYLsNCwNIBGJwE3siDdZYfGhduZoYYGGYjcu2XhA0NHDjfZHwOAIwAMy98d NjAyExA8jUQ3AYA4HJVBTmjHGRAF7YFuzDrw5jXrFRAnhNg2XHPHFCaE3mqjtlFHD5Q+Va0EN2pJ XfolcBBgMHoLtflsegULXPtdonHtU0XGOR0So3QEcBbKhgU5QzX30QtbqesLTAf/jhM8Ota6Jecc HEiEKn/k4r178BhTKIvLKw0UrN1b0Lwxo3iySYzvM263uVWIj+a7gBO9eCJ+Bm74U4vFi89aMkBZ iS50sXdgGXmdGJTEGc09MsgGgyp/fhXus228UtdKBwkIf9ntvex0Z5GKDWH4IQXRcnvrKkEguzB8 C/05f8UaDg+KiHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/jX6CDH65PQwy6x1nn/xtnCBVFQZ8CTzr BwhGamEJx33hB8HDeV0XTJnBLwEg YOsFrtFLT aISawY6w 6IKIeZ4Frw1AScU4h90yEbMwISDRy5 s wtRGgas0fN6cUJDbWxjpF5xf4rgOVv9GF8ygMIPa4sZdt0oxSPuaOR4a0q9Qqd84nRx0HreY CVqA xrNBLSvOUlyND/tCN0dAOATzjYQVQyd5GyzYAW9ZQIX3xFKrqwFXRPjPFj8T 5rqrIMCvNUZHgfts ppP+2imsNXVxuw0W9mbQdCO40LNnOeiwk9hWsuRIZBPlE7ocFXokhEJu5nZ0M0QskfgskRNCLBk Q RlF7+tACnfnLMCvEOBZQ+uDjVnnKUfxrD lOLILkTDd/49o 8CW+kDSHnwH34PA8faQKN2KxK+yHXI 1sXusVS9i8c/NEUSsgrBUSQ4NQqmwjATvAIkDlUfdw E20T0nfxINjY21pWDgvjLL1SjiwaJuR+yM s4IYYvCThlYNHtwti3YGC4dQaG4cNteGg1rI4sTHD6cOasPiLdjZRD3rP1cW3 WIY8IBmBQCVHAGK r5mwS8+IBmSEoXy5iLVoHSSF0WXoUJPIBHlQobMkDXj+DVAfNQu1PGcsFGP+Ozd7E/Ip/PxsMBL+ Zs/ZPC38DR4XPfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcEWU gGjYw8WmLWtq3riLCEqc1u8epleZj5 IQZGPsymGqr4LISMMswGxC6VHBT39io+9e67j2J0J0E7ynz0C2iDwApgpPhoLQwM5/QmZKh/NVJA an9QEFaAUGfOCXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7tbecg8V49P6UZMEVOLjt+xDtKxq+Cos2 1+h8 xgN/a128oSZV292+O8NXdCs5UPtv/FgEdQ4780qLVgg7UAhzAnjuw1utDMZj5oH5vX4J HFrI dv8fOV4EdFy/kPxXU6YezWhPDUsSdBkyaG6MTmdJDInw9jCCPU/wRQiJTvRjjrGJiTG4NY1+EMf c s6dqev8fJv92QnWTsz8dMAhZRVdfFM+5SM5AX6f89H onao/EOHBk/0AE6JqsUaXGL/Tp2tJRs2Mj 8agDZiA bOJkyzT17UpkJV2jr3z1UyUCnGbx0DiyEV8JCRcfNSlbOLPyY5ICAhjltE1ktEPs1uypS WWKBt1edrtTOzg9h9C7G6HAytavuHwRIcS6YzlAoHl4JHLz9fnNlxAwPVsZGBQFjwVmj+2vQCQI0 MgB2BzXszGrBagHAD1OTblvEFSB+ LHUgxH8XbZQru7kx9/GNSAWFyW9U6Pp 8Dj0gHF4Hg+Q36xoj 11Lbi04GxmgPNbMErtopdbVbrI0Y66Bddol+66FqBeUN90EjxwTEODp2s9sRJhx/42iswC9sbO12 g/8BD5TvKf/VoVM1M1N0SUOAePEt3FtjdQ1F4NAOOgh+JlfY/oJIATtMHHLlBVfdQvQNotiB+6Af shlCOmOXXreBfYH9VnlHV1NZ9FJbU4j/ZjvhVDvw3Vc/oSkaCHIKaGrpMvzU6rAAMhQ/RNVJk7tE N0rUJZwTP8SedGgOalUuYGggA/hsgWA8FV+7g/sDBuGENp7nLOBRRGJ/fdgMPVByz2SzamQyfM33 24yj56OQBJTDud4bPMAhpMw1DBAM f4k2A J5+Fp8PtgiKiSBiIx6 LFW0CiAiL7dWiQH829jl1DBvB RP/t7XyIvygWIVuJXfw73n9moUI02tjGKzAXNPjJjlvAd/zUJDpJ/zeL9FYI16pcLRkEA8auxO4Y mYsHHjvYT3HbkoNvEytV/ANWSwNJKyXa/q7WygmKGYgYQEF790cyXWBrK1sB8otfBJei0TlPdHWv mQ+OVPp2iHR2fE0MUIB+LNRoY+S0SOz6TDMYbF9hXv1bzAhwm9mI03041sRdavsLjY1fAU/4jR7/ Lbx1XTWzFYVQz34TBESWHBcqr5QQ F9nMSV2oETeff+25En0jvhHPvhkUMIC6GBZAWXzt 6 w63GjXp FDFit8h8civ8/+6NUQM70H1lO899YTvB V09cBr+1Nti7IUgST9j4O8J+Q7XiTfw7x34/K8EM/wd8 NkttsdEvFgPOO9d9rAGPFdEQfFMRQkGB+v5S6R5I9Vr3EDc2O1vmwpfLi/s7fQyMMYmLNnUSbUJf aBQRaBAUWAi4QC1WwIPE Bk11tT7jVuoAykkAA/qA12CwByhwKOxtHbUo0Y+ae1fOD8KuRBOkU00V UVY6f3sr0fSTBfBQ68jOdgWLzokDSn1zIl0BTfSIX6Y3wrlfojwlCCaIPQiB31ooyvDqgX30ALDZ RqJbcHcYo1NQ2ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZDH7DMIsf3xh+5U+WJMoxo7vFgMoDMfCOx Fc62v2TOzz8IxnMAb4sDHSDQHwwsg2xb72j6R GCe +A4MFiqVhSQEvEWfLSsoO/vkA1vr2Lbbb/1H ZItPYDF2VfxwNmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz1FL9L9wUPohUBeA4HD6CRj8M6y7dcug/ DDHUg0V wgmmg8ET/TWwIViwPNybbyWBfCWSO6whLHGBrtYHusoN0geE7GOs0AXzQDmASMBj01Fpl WZYtAVNvZnSWZVmWd2FyZVxNWZZlWWljcm9zAJaTZW9mXFdZlmXZ+0FCXFdBZVmWZUI0XFdhlmVZ lmIgRmlsZVCWZVkgTmFt OEjBRi/9lnVRAblFrtqdzP6nodduz8zHAhmQzEADFgyZFdD2eq0iXxjQ Nxvg5ScfnMz+PuZZW8cFiNV7CPewABqjDe/A/ScQg34gKA+Calkryf84RreeaKssID2uESIGLIN3 g1JCFchACSrx335r6BN9BzLAiOHrHo1EMS1qDw34kjSF8Ako5aN2lYCK/Xe5AI4R2LZgR58KCaDN NrPx/0JbilXxPHB1EoD6bF+rCGj8tr9Zoopd8jx0dRoPe C5YAlT+f5sOYnVHOtp1Q+tSPGh1Bfd/ ay/reDxhIQhzdReA+3B0ajxzDbdPlrcbIYD7XGR1Ew1idP3Gu+dOPGRiN/t4dEA1P HdfdRHGhtu8 HmF1DHUHnyjrnCzgQ6njGn5pBPYW+Dlk+hl9LA0bylvv4v1HweEUoQo4CcHgFO1zSCz8DRU5TiB3 M+sLrwh8mSidbUuIxnS1OnWqe2MdnxBomLwOAnUJj1+gEmNw6lyeZVdO2Fywi+87/qk+EnPADOXc Tlk5NeUpuIOWix2EhuSj37OFV3DTCY29BVBP1QWzFj+APDhc+Rk8OxBnDhVdEXgYyXKMk2hAa6T9 Vn22lSr7kvwVUHUjAJGn4DXZMOBYMbt6dQMjT+sRH86Kj5gka6zXvdDnZttwPDsbC NEAdK7MMLJ8 EQnSnA9avlE22cVQvlRQt4h9ySsT9qXMIGoNu8CESyiJDEgiQdhRdlZCqUpDSCdY4RextdRQLVl5 Gfj4oLG8HE5bdcoDT hlGm7QYrw2maZpeZ+VMb2OCpmmaYWw gU2WWZVmW8HR0aW5nLFtBWXOSVGUs m+W2bUbTcNTVctZsm23X1wfYeUrZ2kk629d1XdfcRt0v3hvfD+AL0zRdXeET4kzj5OWoHXRN5udi 6ES+hGsTsmXqNkw5GBId5oPD3eGAsHx7RrYcAC80TGYkA3IZxFRMTNAowSTXRdgLO+xGgexQMdcg DOGRbBrQagWIFkvkTOpA9lSpvREOKQYEar4GNrCIs6z8JRGN9yQiFoqdDcd8J02e/YgP/GkPe7Z j g8YOQ1ne/C0e0CJQNys46MJO2aRW51o7Wf7V+2vED6YFWn68pm92u5AVK D/0BERFRbD/BbF+2F8a aKhhUevooYQsnxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbCAXQK0eqB8iCDuBa72BZNAglOCxSI+A7w /cD55Hzbo0FeY7W6gq+BC2+Ic9EZwVKKBNAIf6ELdXIUu/fQa4oWM9CB4gr/7QO1wehdFJEzwkZP depiOoEg0BvlnTy41V EkOrz8xQYLoqO3N4Fm0ekIBQvBzWZXcOzfnvDGB2aJAXIK3AcKst1s9PDU B2zwg8DEMgTDyDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq1PVrO 7v/6x0rdKte3xf8VPj7ffjP0WyA sxfQjnkZUyWsYbB71zzKUTz1LqMnMXxzoL+hLxZedCMd7VfOrbEGZFbTqv iP22lrqv2mxgf1ICQC PSrLIEAMhKmWZ7kmffTR/sn9DgKFoB4IEGouBFkO2QuIFtib+LZEvMckUEsDBATCUG4z3Q0rvAoA BY7BvgOtsGuakMCSL0cTdCXruoVy9xaUCsQHlhe2LJjtbrwgCTD GAp8bjdGYFtNlRcpFnG2RaGsL BxAUDc4h6LqyEKA60gOkseYrXQ8eUKVAeNRrzp22pg Kyih48MAUoxAwVvw1UHBz FW8seZohbzLPw LJ8fO4eEhEemYo/GMVq7DTFiM2kZ0KX4OU62MLPAwCMrGEzVsuh8LTI8z4bLwh2IAQISjBSsCnMB bAiuU5nusrXGZkU12A UGL6HtNoLcqS4H3itYXU6257PgAeIB7Gvk2IjRmxWSqAQhiDxndD8qxl6n LDjFOjNNAUCvmmWIULxHRYlLxRJj2PG7CJ1sBV2Axzvdxf+TyaIfCAd3P/8kldlb5++GTfroJkQ2 aNgGL2 jI5+fn5yhouCFopBpolBNocBWz5ucMaFgFaEhXeZdFvGMQaEQRkAN2qUs86i4RSjZoPD2M fXZyLCAraGgYB41W8awQk AaBw6Y7mHQvWVMc20vQKJniBQFhjhRvFaRdGAF+JN23gpFa3jv KdAgk QaJN1jX0A1mUBUA32X+EJwOF0olV/H4aGRoXD38D/oDCYYgUN638fObGhB5HQLNJFNy+kKRVtJ8g 3w2TVhyNcAoahB2hbCCLSh23elqmaZrOFwOIj5ad4E1kmqSrpldoDCc0SNVtyn4ERxhrW8eXfSTS Wn1IEo2eq8oX 8MYzGDx9ALYEAlJjdXwmSohTpobbUOYWMG8JgcaI4SXDDQgf2YZITb9aCH1AH4QX /gz/i9qDwyHbfh0e2/t/r5Q+Wkc7+3zjgKQ3C3lbhr/hbzVqLUdYuaApg8EIA/iLAXX/xvuQ9Zn3 /yDMR1kD+Tv6fd5B90YwDMWoKkAS7oM8xX0BaPQ2IBT/NMWk6YLEzAu9H1oynJCDpPgyABnmMyCX +Py+iHiFCZNXRiFtJxSHNwNoBCc78RBWDx8JJVB8EIUQbtrtH rsjIBHND3wHDSQRH1lDjP jN2DYF fVFyw5mMV30PXfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg6wpslAzd3sIbj/d81GweC2jrdreRjZVj ArNOYGpQHcnJhUYtMBnw/mTkZeEgLUbxO/I4Nw/hBTaINBm DCAO ej4QkECh8FhbsLuE19yQWEhV8 DYYMQZgcG x iYQZsE6wjFQZCgI bAg7dBf5C7idCEZQiaTWQS2r3TBxA5lrVYXrZ4m0GSWVkeGBRXO +P22a8OzFoQrRBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQzZmpVs7FO3wmqWd8HY0nXsB5oMMYG3QwS hQHnyBCApqh/JJzOBQa pIEt9B8aGa7+ffyABgL6oU1e7rHUkMGhgYz/H54hTM1+I7TazfepPJvVS OXn0QKqv0DtwEO HaFGc2QwPVCVzl8D2ws4W9K+8RU1gLmh3eKiwW+8LsbDYU+lkZGlAzB21tPHD7 VKy s1FzmhwL4epNnCjKpBrR7cgWp6tJX2lH3DCLkgt9/UURGmnrnP RIeMNe8RJzJVwV7IX4YRtS0 UIt+eANzOQbH4EQnl0AnWTwncMCGHTgnRUCZuVtxg gzsHq0W6GQwA/hocP+zM4TdVHXtewQbsW/L B8wrGQIPaDQnJmxw4GsudiNf3iIG+xmsFSgNaCQOIDgh2 MCUCPxQBzvQS4RH4oIQD4XChBmPINeE L 0M4rFdiMlSmDEdgmFH+XJHeEWzKAglzUEh+JONBGD Lw/cZmB15eE5YmU6DJaMuX8zxokFjSncxQ aBFHQRpj/q9X6tcKNEYzT9pTuqIBOCuqxwQ4iL47uqYzlJ6wBuogfehJxyeJA+yBO699DmpDhbPf qnYe6w5QsMMWjBMRB4LWAG7iJW yAJgAeVLf/Av Bmf2De6ER0OUhIdC0IDnSBsEC0HATQtB/qAp/B Cs8w6yUnBFEh9OmTL8OBwaDr 7zCt+f1tJjGIFoBmAR8IAs9knevl7Wl0HQR0dBB3dV7cMSI4AreC x9f/sYiuV9XYkct7/kJSEb8y2Yv96SPHUAw HJt56SMNtJ2hM4VYYX09QCfpvU9Fn64XgEv8gigND PHx0Hvd0GuL8pZz7FjxcdRwSCmsPiAH/B4D/YLtUfNuLBiC TXcM8e/abymz5i72L00aKAkIq9rHu pQAMdOI4CQ116+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R10hfOO/vA4Ebryz/J6yduoUBt+bCbCOsZ OgeL8faUMnXbdDcFAUpHf9Ucd53Z0fVEVBvD6QpJPCSlXR dtklALD0mAIfsJ/kSpNz5vU0L/N8eG KYodAQcoM9F3QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+PXQ9PCsDPGM1PH8zgC2gcTyAC0EpZLJu 0RACDkZbPNd9IdqnfsYEBg0GRgeWePdECnSyDF+AJAZYY5CDpGkKoApBkgGZqKAI22mih1ukWl AY IW owuGMbrl5QgOMFOETqEL5YBAtQob6VfbzzpeJppIBupf6KTA28X4gK/g9wAen+919zweEEwe4E C84XiEoBikgBGAI+W5ZlDwIGXhkCikAMBrffFeA/ikQFDEI DvRgisRXOeOsFDCzFZAOBVy5wDYJF g+h4uYivwgQoYOwBKhUX/n3wYT2yAAtxciZQV1/orTYCX OhcOSmTIRbAmZ81i0ZCSvD/vv4DioQF K4hENfN1u41VQX p nqguOVpeOObi4BwbOS2rXMBSQAfQWWmjUfQk5lwMYEeZ2T94NBH0NDUMECkMM 61uL1vg1+IgMTmVLnUyhiLnYcg0dqCA2hhBdewRynuBtV58Bu/ApRFav53QqiJ9tg3ajcwTdPQgC +j2XujUEQnUfPAMTBKVWiYZzDOETf6WqQjlqtMFcd zf63ouct7TAjZ+00GVj5SDmm1AFu6FnjHEP Ug/YKFAExalAZrga7Oi2eG1Mh1/TrBRWX2+nDVUtDKoo/7dVaLtWqrGgFtWVG8CBxxGwBxqIbJAW mo3tJkccaIgV1xhDswbJoPIWfLYtrEQQM09fJxv3gI4imllP7fx tuijleIu422jwKTVVswOSsVnT ore9z SRXBfK4mB1Bs++9a hpUVwrJRq/7QVUUgIwiUlxfcEFMuVLcX3wFuVFj0bmEI1YFNFHmJut2 Rmj4q1dWGFANBRzgYbRpMwl IyPdSFSvk8w50gxH4wMNTSEW54 aJ9nxoBrwF+CEUHD4wKwmgkd8CK G9NA+I+JnQ//8dSyscpGmkZ9Bom1Wgk5eBveCftzoQ1u+H1E+Im9RPpC7DtzwB9eWQxBC4N8kt0K S/VNw421T/SoxLer3V51c4uxvwE/Rbj34AItbQWfI2EjaK0HDBMMQHe7wUn1FVAP9CKIGE4//GYn V74KzliRLSc4nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsYohKUwCY8IXJBwwoZMbgANJQ4R7F+clbY ghbnCFEpDibCC9jFEDg9mTokUW6hvb+rBewHMkUhYqbH3i586j1kFJxGASdV9AjawYDSfiUTjYLI 1iQOWDJ4CVeDFDNJAgp0CgANwKVYA8PTl/8cQHPSFFSWg8j/66wiFaX3jsJbiwvV4AmZdj8wRRs5 pGJXxgcwHyJa1YCa9qDLbPxCP8A78FciY+pHlpFtCAhaDFEQD9+g+82OSIoGPA10DI4IdXQEPAnm aokSEzDrQiYrESPMKv40JZoObmJGMj48OpANCtoG9WYqAgQXPQ84QA30JYk4hA3 /8BB8ItrOJknO iBA+gfmNjf1fMXK+6wFOgKQSAF3MuVAHwhVUQQD/mKG16NN+SqkPBTFXuw4kODEyRw27e5U4OnVh HvAjxWSmRg/cEUDsip65RtLKAUZ00k+JpnNNWBbBuWFdQh/Lwh8KQjvXfOp1DAIoQrr213UdC+M3 Pgp18QUMKl1qo+gJCDANrusLGmJjriALHAcGNQ0c0R ZUVoVDNFAPI+rGTo0K4Q020g0AjpI1Y/2F ark NdYTzRwSLwooK6x+kKNQtPAcXODx1FPysbXwSPh+IoxXxgCIADIGBINtGPgxi4was8HQye xAk hGko0FERLAYxa xhzFUTEr+kIgkS/QOszbqnGSlKyipQgqb7RW/n6CXUTQQc5fxKD0o0EgCb8v5fU RELQHjB96YA5LXUZaR3Z1KP6VFq0f7aABkF6m0i9v OjULHJTOUJQFjBd3Cqgut9s5FuFVhtDXTEn /LPmkkOMEC4b6j0BZifdio0Fk9AVjnlJBzEAXIAfEuVgjEBTlvT9I3JVh2q/5WKyrgfYg/vk/C2L gshS56fWU1FAX8cPFpIBBDB1+MN5Yc0Cb4C+eFk7xl lalz3dbKsTz0iM42a/Bet23yBOMYi8aHwE VzfbbPPNxDR8Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT671RpgzbeBDmQ 2VFM0bq1Ocwe/jTb6AJLn O0QxMUw8ss+cPdUALM0lNCCxke5Z4bUAho+qIgsGHltePTSMaouqZePj0OsN1huaDULJaG+Z++f4 dewI7EdR6N0GQhHr7jvCAQCDByxEEQ8Bj9OboXKQzwUTKwZ+0YnIEGd+RgJJ3nVF3qAqBWgsKt8R Dtj8apl8H3d9GNok YGvWPogTDh73WeCM6ISv/KrGlDiHUUKRJP7ThYdP6bjkdlCD2Coj32dDwNyu sCpoqFKgLUyaYxdc/5g1JBfQggbpn9YBsYCzM1fZHgdjSMlKYfD3QYzYhwcQEF7WOPi2yETfVx/R JtiZrBWSSvyz5yN+vEh6ggAU3CjRZAF77HIB3+zp0txXnzjwvAKPen3nPhyIvrlUnFtQ4HQrahkt cgTZDtzhsrlUmKreqfhd/bFWuO0HIPSwnUtE wx6jAO/0dRi6cgCO ysqHVRsWgCtI/+8xXtJdJ1sP lPYUAyohcFsNDEtW7D1FkJMD6VHQDOzmAvk87Pzs/AU0bR5qX7uEQFfV7F0oTIzWnDp7CHPJyJPw 8HQk7AzE/yVL7ux0RIsbhdt1xy HUjkML3x26SoPo40DdvqpCSHQ4Ai5I2wQFi3Rm+Gn+cqMf0IcP 0+slfmNzQxiy710m69do7AbQJtaARf41sQgAdFiNp2TAAMg3nC/33rl4fA8vd2KvgKVQN04to7sk YI9ZFV3iB56O50Az149okXRg9zfn8UGIjAX8nUA993MRADZffBgkrhdXoB7Vpo4ZrKmJbUeBWSCo xJYTJAwgCQHvLDNYWZG7dPaC23ZCIYp5+xHYXHQVBGzxvcUvGMaEBSJcBQVPs88BQ69cOIsIG8hg kSsNAH9QMpjAzWmrlsFIXL9rkFa54kHiK5LZqw4xVsKXIRhWzYAbm8gPhpUBO2Nj5CafGSw3AjHA QA+Aj45fEQAOdJreH+B3qkYxRmZYQmCHSarBFY4XXarz NFdVifN1zhK+51I2izXWTdbNgk1GwK1T m7NlEKXsaRrT8ZEB6/h0WgLAwnnChr5TUR2N+MqS SZru6yihU/gI5OVsWBehXdY5XYL LJlXPmlja hF0klJVkZ7+aheYq5TC7FwZDkQi2zb2o86tOqFeqDZmQAAAvOvalV5gje0A4nAUt9jszSEchJDan FDyzPc0PqIglqVkgx4Z0IBgNMBgjgxB5rCUxA qgPIMggwHxEcAjBdQ8WO3c2+9coY9djeFlX9TVQ PMDDik39ECu2ak QNQ4AL+l5WW/yowC1RC9e4goFiLXIQDhciUaFV3WY6J1NmFkoNAyVkTB/D8LKg k2jgJ2ogJ0jWBWMAXX7cor8AsNJfi8/38bhzET0ND0sALLjgWoR62vy3nCM8WSEFcwd ogOvcXRPe rFw4rlBzC1iEuws5aHQsJSAaZ1fyeTxzJiQnMjVwiZH8JiXcJWlw3A A3G1RzBmA1e/bYdQRn3mho OywJ0BmbzJEeLtc2fFCB+sIKf1ImJ+Oc8IR9KQyDQXIqCzI+ydmTHnIXEhQKD4OoGrpmKD/GR+lD HB5C3txZigI4aNgrPHITt912SnNlQtAw60E/BwN 7eCU3SGiY9/c2BDhjO7ts60FZPyWUWPJSnMBs kDMYAzQEAnap3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEwpGoZ1QUD+f0wKzgrOM0lHH2A/P4EqM5E YHi5TQ5fn1TCBbL/Jfh7JQBFYYYAsgAniiIsA4gSpmma5lAAhIB8e HSapmmacGxoZGBcaZqmaVhU UExInfu ZpkRAAAgVBwP4mqZplhTs5NzUzGmapmnEvLSspKZpmqaclIyEfJqmaZp0bGRcVExpmqZp RDgwKCCmoGGmGAAEmmV3uhATCAP4E/DoaZqmaeDc2NDIpmmapsC8uLCs2KZpmqSglIyEE180TWe2 lxMDbGRYmqY721ATq0A7ODAof5CmaSAYDAwb0UFCQXl22W0ARQO+vvlBAAFB8v/uKoEET177T0H1 SIxg+UAN+////xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRhMzQvYSgCBWD/fwUOEmEsLiUkb0xMS2VB APsn5O0RBBMNQEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv9gUXQ/c8RexsFuzBMx4MUQf2t+wNBgBP RUBBAJuET0UUERlxqFHEI91kI8qhJ3BhnVzZYP9bJwFzSNlgk9wx/F8nohFE dvIA/v +PpeF1J2BN SENIBO0/dCaUQoJjAvqy NDe3IlZpZ0y+Xuv/u//fAK04MwuAA3oTOK rhTr4ARgrsH5Aq2QfAQf/9 //+Mx+8BuMujaHvf/vvVSnZXEgYkrU/rI6ix/MwZ5////w7sPu8L2mAakZPKZ9qyludSSfAro1CO ZjVg5f/////qQXhcz6nUC63MlgdrUq0SUEKZRIi9RKl5tsjTviOi9P7//z9A92FvV9Qv24xMD3mc oDQOIV2wmiokMy8kLf//hQDYJS0ttrr+Ps5 jZDJjRmRveWvr7vY5b2QitIZWNzhvLWY7Vf/7/38i KD UkQTnlK5YX9oapmjFhZa+PVvyA7k49tLv9//9rh8YGUgdx6UDUB7yZ2cEo7rYFyvAaHf+WI/// //8dyGNQ0SrSMNm8zwI452BJ9QgjZF+3AfIBgRAbH2f////P64b3qBxRbpcSVQVDwKfgmYm6kqan jKBgl0Z2//9f/oLGTJS1rFW3vhsERKii6Lnirr2YQ8bLDWvMA///w/94u77AtzDGYyDcTixNeaS8 Bav/5eiOnwohCv+f///6tzH9/v+HP 9ppu2bgq8RxrpVEXMlFeJGVmKSP/P//2JqnuT3jXiQX7YUF Y2i11r5rAuZi1Xjh0vP///+9ghgaJNONTc48ta6+kBzFxA4/6S6hp22/VQJA/////+LgUEkPwz8S tnSze/z6k5Zr0JLHqkZNUFdESE9VRUr/////UY91nL5WR0tOVEFAQ0JCRUNARFAvxJpEREdGNm5A JDX///// H5q3t6AILzUsNQZDAi4vSSJPJb6s/qASNSAMFMwtZc3/v/3/wK19RHYSFxYrYRhygfcZ scz8+bx7cpqy6ofEdLf///+/SEBHdrg+GjlyD8FkQcqHEmqGEczFfHlulv4Rt//W/8oEPb4xRb5U xVFGeoLIBC1Oz/+BuXoG////mBuavL89lMzEeXkRKdNQY2m60GzZUG5lOP9/+//LzUQdtp6ev8G4 HTW6bjVOh8VEYx3 J3UR4Rpr/////Pzo2ynxhaCskKzlCvpbCgUIjJUYhrPI+ygwlTu6JEAz///// KRlQYBOML/uYzHxMNcKFWWO3qPv+mytDEitCKf+B Wl0S/7f/ub7s+pz+uClOjso8PcgcJf9BS6pQ /9/g/xwxrqQ+uj9lyhSlMcKjPszNTHm6y9VU 4P///7G2tze6cVC+BDFDJXhEPZ3MYRIQESN6Kvce uv///9/bKRhZElEXUJ6ZQiA2WT7nTsGPYUS WXKDIHkUoef///2/4gVMtJ/E2KXQ3DEe+8p5axKl4 7MwE+UlZhVVW6f+3+K1crSsdF1tlST5OvCYpmo2waRcjv/3/f3sNRNVO3K3s4Fo6Aa1RPagHGBLy Qu1B7FVJ/////+U9Vks+RJ/n5T8QnEEtemCYn/aHSjE3RMpHpy2CGmrZX/j//1G4ZVpOzZYV93yY cV3WQjwtXuXMl7aiTXq3/////+7luBjinUz4HenVQdfKdHmTscOwl2t5ohHHLnkglE170P///zxR K1AYdIMvyrwEFYYEUQXCRhGYK 0DBLIzs////v01MW33AJ5EBJZg/8nohxIE1VCu+vRUljCU9LBkp TL/B//+X2S0eor6Evx8awoQ1iIKqzKpLyq3CrW3//1v7Bq03aAeP0Vl1UdPWWr4gcUqRepLIFLkM /v+X/oZAFsq+roeoc4GpUHEWTRZJFBjCDLW+wiSO3+A3zQr2vfp+rMUEDkVhzv9v/P/MvSVJykWA egNNNQ1yk6g/UMo0uXhF1zVEA/////+XP6ovDj2yQnRgtcSTPUxWasSsgr41sEV6NZBFN2AEWv// ///XixhM MdJsCj9JTU5HEpf/+BfxKxhDekY92Ed/uS71tv3///+BPVcsJo65yEXYAsK6USzlHBr0 Kq3RtUGTqH6Zjjz/v/0vMxDCwUJOzMJP6WYA9pwsujwqygZ7DA9931j4/4krejnpEXJybtbQgQwY AcxCtopV/////zd4FtVfTXhxP1FRLqwumsF2Tai2cHqXPEZXz33ZAvL0//+/8LM+7TyGnz3Pvkfb MvaWPEV3MnK3GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVxLSFWXDxOylDCgEXIFcT/rf//mXysq3M0 fi1AlVpSTBhIKydvWajfScl2Al3o////wodGerI9Z+Bs+fUxmr lghW2CsC4n9zhTfBgY+AX+Xw+x xH4DtGUSyhxJF/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+ParnXzp2yg//////ywW4RWIywEpaGtHs QEUy4ECok+y6nHdO91tshknF+0T/////CUdNJy/e6jV9SMTzqZ1/Ie/ik52FA2FOw863gh4mVhH/ ////JlLLGCCMqjzYKp45IBsYe FfJvT8VquxHoL4+GAjKi4D/////oELMfVF6fzxSyj9FAY6xXz8g eHhJyD3EnXmnDg+Dcsb/////eZ0ydL1GoK/yfktHPe+Yq lESRkO DqlKeWcUeSUSrahc3/v+l4R3E tyoSqp41ZGd GocoHoCyZs3X/Rv//Hgl5Fy1PKR/WX3VxIz9hqbt2cpxyS2LR/wv//1BN9JosE834 xgFNRzRFl ZkZ7CyoyokwQFQv/////zT37Fye2XE1TwNLwrsCq18fRqhJrl6BAaq5/3UWx0gC/sb/ S40xTmpJWK5L0VMfoOu8yDyxKUvSv/03hTSt1t1H8ux+VhdPBK/D2Qy0v8H/0lH1YPMsTr3E1eLK e2It+DJA//+3C84WRuW4uE2Zmj1ZT8oIT5hFwt28OVz/////TqpTbjJ8Uv+/MWxhKSVQxr0ss1hY xRq9jY00vRyDpw//L/X/M1BSUHe4kfHIgmpjKtkfHvvwlMPH s0h58L/A/9k1Cf+VdAQyMbYwiX2R Fhc8+cyt////v4Tea1XAeS4/WplKes9mKyV+trAFHjJL5Eqs4HHVnfT/// 8IQ0WigvfoyhpjJWVn FEo9Zaex8J9xmc9LKdl7///Lv0FhvnaevvbORnKs1sKKvnhpGD9+epw9YTr//4X/DfqFuuyx/w2Z /1J5//aBL5301izYLLgbPVX/S/z/cGC+dbE3ILpg5DRDyp9Llz2AElztgDcy/7/B/wQY5WeZFomv jNyRTrSxerTCqUIQKV15wHip9P+/4KP3bP2d/OnCvwF6R0k/Qv/ //5dNd/mc48VlvgVCwrjhT0st /p1VETwRH3qxPy//G/z/sZIlXj92+j9kGEvSXVTqVq67Pgo8QAcEv9H//3qvPZoC7UYphUhsHJ+d Hl/DfLcwUIGVQP+F//9NfH4Nhs4+USnRHkCifS+9KdrEnCGrbq/CeP/W//9tNUvbzV2T7kcrrxhJ jUVNiUlAdEW9Jt Gn1vr//1u3P2C6VBBzPttRvcHlRLwvB1/bbAQBee3f+Leul5Zw0YBMKW7Jk8Iv N1cizv//L/TOKVNdN0n0SXFjutjF7HH3aVRRwIOxY1P/////XCz3ExcE3pUXc4Sp2SjCkAFAGK9m fPscgb8VnhKHBIX/////Qhxv1oqELocnhjWJNoggiqQz+FaLM4okjR2MDI8slm3/////1iiOIpGQ bpMydorvKNuSlZSXZpYWmRzynXeYL16bJZrAC///nQ6cjDOaNGqfXp4CAqE0oEkcljXd//+/XqVq pH6nF06mqvvvKqlWqG6rBqp+rV6aRKz///8LJROusS/JHLD3tdssknS0b7e2N9+5uNnn9yr/0l/o u1K6NcoFlnu/bXoEgf5HTxG/S////65uS1xEkFnBOcKDAE8yWFVANG6nLEQ6iAUR2/+/wU9j7djs gDTmgVlBSUkxooqB4Cckhbr/9rQpAeepj5aGEyQmKDQKMm63///tM4GwBy+SSrOyN5EoIiQMJtvn ETMu bb2h/7/ 9/zZ3N368MjsN+AypxsCIsU8JbIFtIVcbkcapVRL//3/rXeSIfqZxGYFsLLS8NEgB H8CFYIIiRva/bjH/////uiufHJ0AyEeOAR6qO5gBzaDieFYDyABRgYY3hjxWaEX+Rv//TF9KTQ3 K XEULXrzewidJQU/5oV4 5uob/v/G3KjGSymztqlk3VdoMKw5KKbtaPGN3/xJ/4x6hqvZqK/JDowd0 lH2X9FqFFtv/Bv8RSXLtjzT+KXAiXDE+BOmIrOwAzFv8//ZuTY4R4nddU0MO974UFMgvWcjlYf9/ iYVgDMPyJ54rsD9ZM1z5/vKotyH/////7ONazAZOJll6vUePXDpJM0uVBshKBnf68Zr3P8ggXST/ /y/9UXKtBhRJSQz2YRRdZV2GTRGCca3Q7KBkUef9////5T5IFpuBxPGxqsQuFC+Zl5gZ+mk0VuWD 4VbBw9ubf4H/L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL/R FsrfMuwdRFNDgUbXytPaBxRrzQ//9E EilRWL/c7GCcXnn90d9x8/Rl+0DxLX2DC4tLgBVUu1uDB4j///8LNhLLmcu6PbC3/gCCyrvKkICh USdIgKhD4MLb////4IRN/7LrHhqAHOT0nb4YpcI/TUE0s4YHTQOUmhJf+v9T 7HchpyFTggo+Qm97 rI6CEgs4FCr0/6sPMYT3vFzRBnq4JGf/F/pb+B+OSUIHguzRF WA3OjHI4jRE/////5V5B0lii9Sb qWqJCoLu a+72Uwbz yB/0Dqp4/uYGh063/////3qOP0cKnoCiQhKakdkqvgOOyBdFNfPKigF0ATKg gfQY39rq/4Mm5IkqlYQsUGE/PMoMwFr7Ff// //96SgE1eoM9CNkR0TmJvh/o+VOcNtoRVRiEesqG tpGHcv//N/jm/+y1e Mc8Z1N2UWY9yl4seeJwRyh9gCb8W3yrKgxPF4tH71IYRvLYFx T///8vlAa2 ehbnc0YJFgh6gDVQcuL0LEpKiwKD NngtvIn/v/EXHyuDH0XM8+rqvk8eC2EKrAkGx/9/q3+64fqR Q3m/ufhm6tf8xypQOzl1OxA5of///61pEPVVRhgLtQis6y2xNGC4qcCk56JeiBwH//+/VVw1Q7aU BPW49izIyN6G/g10NJDCZ0Hj32ijK6RZIhy01UCqR5CK/7/9fzZdDDSvEWpccLcKPa2EV7aTcIeB RQg0tTua/y/Q4q9brXtpHMwvRV+EYaj0C0L6b///zXoNupivNRx6vN9ZI5JoH0nH+jpZNK43Vn+j ErcLH/rvhGwgWa18 vhf6t/pqGSzu0J8e WV0OofR+f0UP/////zSabTvDaRJKw4VHmhJ4KKLzIXoB ck0quTQDR iB6MeY0/8b//994X 1+sw1esEBbo2Uo8meX327naTWeL5fSb//+/9JyV28oNVMgNoM+L ZQ7lmb1e9jv30Jm5JVmC/v+l/5tfPZFnXJ3wHpDYFojQ5ydlImWdv5heCF/U4P/fBZE1DBbOvUO9 6ndyiB7IvWb63+Avrsngdht1X/krzKEAf2Uaki////8XBD2mj17UnVEhc3OdSQKxl3oCSmRV5sI8 RBg+2/9C/0as87 UL8sXDKXhNEloRyT+WdtDN/////y6FI8VGcC2Ap0MXwMMOfMz9R/5XH6RCYywk ypIybBQxv8WN/tGhmng0CCA1SSptu B7DWf+g1NvbHbe9iT9PRNJT9dsb/f/fprdCW1hJgx2qP+Ka FKMVkdwViRVHQv9/62zIARes24pJek5bYpYvzJ9Bif/03+r/8tAhPd4pJiEJQwg2TT8NIeQCg v// /3cucXoMUZ4pyvGh/2cGSfpUPalgTV0Z3ELTFPUc/8b/W9LA6GH7jjmIiHL3NUdCF8FBJq1r6f8X /ji6vhw7bVRI011dGDkXFyceVR3DGnnf+v9/Q7kWB3qHnx85aoLXRT9EM7U1Bfw+fgyW/y/0/2RI F9wX3ZUS9pSu6upR3Dy9N1tUVBkXRv////+TNlRwzdbhDe+q6hImGDH9I8y2VYgARRd3/DVIERBu VdX/G/xEWWyDWaep2zGwJSfNJoXR FuE3KPC/v+3RvPxRzRfpg8aty0C/8P//xZ2fEYsAqYTJQDOr RDJaeSmGL0tGWmqLyRT/t///4hRLWQ7MjyKvcYcTgVjQZR+8 BM0xTeYLJy2uiF/g//+fV1IONItP Qqkk3TsH8BgplMwRFGNK8fT+L/T/QRPs9GN N+YQ48qt223KBeUI1YAHBfUK//f+3Q7hXQoLLCb4x 6N477U33RoeKIUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1hOKyAva7f6C/0gFU/C1m5CvS+U8N7RKl9 ry/1/1v/cz1Lvpz+eqOAca pby19bUsH/v9T/oOket5jYWohaNku2vrhhWABCi3XJTwfJ//+/xKFi HYVOvrtNNP i9F9DZsS0lGYLyEcL+Bf //L/WaVUFCekBiBCaGAVLNHj866oyuR0m/nfv1/wv/2U03 FXNRySxMqin8FurkQUtNYJ97S////y+32aoSsuTj1w+sGsRNBNhTGDwFqYz8xbhP2aRH/1Lf+kQ5 NlOa+fStZYhBtdJC5E5g 1db/rf53bbCJ2TlD wFSqT9HKpahvoU73/gsX +JlLyz3x1Ca+Z01Mycw+ urf9//+lUkM1aAo1VkNKtpdKzHK2QoeqaWS5Pir/L/RLiJ5yn6pcQ7aSYp68g/qPvGK/wv//20qe SlZOn/Ritkqfz575EMsq18zZr0J8//+t/4CcL/6xGGoM aStFkq/KSZKhRa1CnMHo+oF/g///SrHz QifDcx9A423E6G5MentiwNcZAWK1/f///09HZJ8j6ElZmQrKlxoZooOaV7x5xgs0t x+Igzs0mf// /y90dgFReS1sbvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4////8hTMg6 emaMDoSsBBh76XEAPVfsRoeRq 6J4zDJL//9+qU1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+NfuvMCLyCa4S3WhdDgjJhx0kiA1r+/1/q rafoQIBbwlK54fGQxPp4HDCi3p43ntf8v9QNng9qv1ULzDUQQpbLRdyR+L/FG51LyUWOijO0Rhye CYB1l////99BTlH4A57EbPf3eSdHzuteUfwwaqbbvRj6+VL 5wf+/1P/8jJEuCTNCK zkY1RA0AvGX Rs65EUpSbiB86///GWPBahXOVUfI9QEvU80qFlQHGhKVekSj+tb/ b/FcABLor0RJRna0ovg2oHSG 4lYb/2+UK6fg QVwogbzBtha/ArlE/i/9/4LfZ04n4ENagMHEj82JPta5GNmhcoCCHX//9v+tMsCg xOw03qvAuERLVyREV7ksPE3p/////wNWRr/oUWRCzp+fR7G+fEVR7TURBzoZND2CEBf/4SMX/43e +rc0SksYGesds57tWxEJ9h2ee9/iF/hEIxmqTgpfEL55ZumRtpla N/pb/4FCHxj5Ce5KT7V8x9Er fZvGLvr///+SlsxAXFFQEW5FEXW2z68sWZIfRU7E4+pqcRq6D/8X/jc5emBTzqzGPFHfpFcRbVc0 OMpRFsH0 t/jt1hxrw3QRBE7RWJ4hJCffp/9f4m8sJ2 GnSzYZGRvAW+LtEVpAWf2H7Vv8//9QiRRM ZZ848VxUN3IW+StpyzwoGr8bg1/4BRb6jXmJW3pjQyupG4AGp////5dVYWhfkCmM5VC0GXuQgw7/ I9RRYh+rG8RJMpD9X/r/lkCQq40sMvURYKsEvXa6rpyvTv6OYUVQ/63+S2VwaoDkfQYnwFGe7OI3 PaUJ2Pv/X/hqB8zDBvIx+p6z+0cSCWt9R0UBnkKKyT6N/v9/LLxJc4gntpiaC/UaK2y0k4McA07e dP9f4P9IO4Cq/9ePR1yE1WwqNfcN1nqFYcq y/CX/////29jl6ZeQd4k5UZKpSrea sJzu zNRX5XFc Y08UqUvK3EH//8L/bGBc65FNbvEEBg5dqf9PA Sc0uuMKqzOxVC3/X1jos7cE6v 0YNXbMzATUwveK 6kSmf4m/9ffIIgnGRZsTpv8xEEGAqykMOf////80qNEna6GdSuskpr HuTWHVfm8OXaz3tNSkulFh EB3LlP//b/+4Wgo3wA6nN BMFqEVxVtTumrLRDa48sXO2PK2txP9 f4oaHwuEa4FCav LfHSPqgBgRo Rv//37oFrZ6oqfn08CYeSEOtfXCqfJG3J+esrapf4v+lMbFCcw4puF+q7jjZzY01HWouUl/g/zc8 c4GkyQSlw zH/1Vo6nL/L/7/A/1A9bJedl1lNIZxHXqtX7fggRBlhSRylof///1gvbnmqZzwxGGM0 pO4VN1jgVDApjUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygtJFhBvx8SJDX///9GRi4oLvK37fxOFjMo RlsCM2RKLqQe9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE8P//L1YkLDERaClMCfB+mi9wMQd 3JEjS L/Uv7S4iY7+nn5rfSSQyMlVg l7j9/zI kCSAvJQ5/+oQ+RSQvIiD+Lr8JgP9WQK0lNC05DyAslv+/ wH8lJTOCj0OnBIkA6i2XJ5wVKUclPaM/1v///xuIvyyyMTgNLl0NKCMzIDM4c8RunCHYALggTi70 //8zEkkvTMH2JhMOIyswVQQ5w5FfvAUk60v8BRoueShXC9hcAhcgLcTf4P9/Sob3JG0ATg4xWwok OE/mmB2uTnXnNfi3f4lRSbE2MjEzMSe6PW2K83SxT//ud9/QUVJ18wt4RVZIQIM JU0xDMkm3v0j/ GfXSODguDUBDIk+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZdhq3EU17pf7//2lRRhHPZFpHQi1uGFZh 7VdBJf1f8U5KHbxwq//FOQQnY9G/NyCqRWJ6IW8l/f8vLQMg9qUqTQoBV4FBwSC6Rc1xQo/MiQN5 RhRhviGoY/+ 3bRFtzAWBvr4Wwoy+qlHRAMt74/+NRzJGBkCaNEbKX8KvvU8zrPlBK90O2BFQgQwy rioOpS7BBzKlcIhzM0zhHdi3ukk9wo41NciEL4jCQvaEDDRhABxMC/y3 f8KAQ8C8QbKVwpBAzFVu wrz5TkrxRu7LQwOUpLaoIov+0v8N9EPCg0XIRsKGRcIINrBAjqgNl9i6 7xYfyLb4NanLKW3NQDbB wm/1tsF+QFbKRsseRVSpNvj9vw6BUceFaLnBqqlAsTtEyGmYt98a5f9MI0iBNQTKJ8zFdd92hXEY 67IRH0m+1yU L1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPvFCk3278zN0bIQsKCRaqZ EC0gqAJEBeaq +b4AuZBbowMTJTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2SJupB7dJqvQjAHV BCgQTD5yPUf8X9gUN DUEABRcAEQgDQRQSuckHaxoKFhJzHjFtg9VqTe5OAA0GXK8taPCHIoGsYCy21Q9IKBAMQedqtbbA As6/Ow2oSvgvMCgvNScA8xRFWEVEgYDAGo0WCAj kAQAwCgAkUQW/aSYgqBwBRmluZENEAaDybG9z ZRt EzN4V1FNpemUX73/7TEwRQQ5NYXBWaWV3T 2YPbm9hbw5Vbm 0QLgNycyJud8MvS0VudhBvbnar io5dViJhYhg5iLgdRAx2ZdrukYqYDn1UaW1GKuKstVcaC1FDotu697ELe3BeZy1Mw25fIH5MaWJy TnlBIfZMULRQYyhLxkQ5tv1iYWxBbA ZjWExhtz3sVNMqTXUDeCgbm7VbbBdyYw9+sHQQB/v nWlYd RkNvcHnFRGXahzdrBoMXJUhh5wsg3cKdRVNj2XY7+WxlblTfcFAv aA1hCwrDVytYRB2zt 0VE8W/K kbZQxMlweU2RbFt2Z4IiTRNFeGlCQfFi3WhxZB/xvVnAJv8vmY33hg27BWVwoTZCN+LCw7Azblqc ZUl7EXGiy/sXbCD8XnIYVG+TFYaZorhMqQ68JXsTYhENCGNrQ4VvT0RyAeNkZUNop9xdRGw0TW9C eXQiEhQnIpyeua+1LQpjmDYqUqCyvSfhVEdQb2koGUh7wWbtcEYmXL0TGYRDmDDoOm5FTLisMGkJ aZwWpCImBDpNGDPXOEN1GH0ZOiQ5YW9rpURlLJWEIMWVaLXHHuObwGcbS2V5DE9w69yjazELRWoO gFZbvQAadnVlD4vM3KWEESl1bTAMT7P NJrc/ZML4baCiYW6Hc2UwijcXa4xyEPYHaXNkvfZcCXoZ 8s4QFKJ4rltQCCI5N6ErMy phKiECSg9ms1T NIAGhVVwPFrDfTkJ1ZmZBDwtMb3f2GbYjd3ZJcpQj dwqFm3Fa9MwMTYLCAKhtWbZN17fYYkD/BAITC2VZlmU0FxIQA6tlWZYPCRRzOb//hLw 8UEVMAQPg AA8BCwEHrnvSbBNyKoAyBBADgmxnsZA1CwIzB Jlb0s0HDNAeNHvZG9gQBwYAwHkIQIBbZHgCGAVG uMJ2K2R4AR4uL9iToJikcJDrNn+7sAQjI AtgLmRhdGGYI+5CusH7Iid2QL3NYBuF LuUJAMPABny/ KXs0J0AbsHsNlAAASkE8CQAAAP8AAAAAAGC+ AJBQAI2+AID//1eDzf/rEJCQkJCQkIoG RogHRwHb dQeLHoPu/BHbcu24AQAAAA HbdQeLHoPu/BHbEcAB23 PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZG g/D/dHSJxQHbdQeLHoPu/BHb EckB23UHix6D7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYse g+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPp BHfx Ac/pTP///16J97kBAQAAigdHLOg8AXf3gD8BdfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY 4tmNvgDAAACLBwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM5QAAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI 8q5V/5aQ5QAACcB0B4kDg8ME69j/lpTlAABh6SNE//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgA AIAAAAAAAAAAAAAAAAAAAAEACQQAAFgAAADY8AAA6AIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAB AAkEAACAAAAAxPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQAACAqAAAgAAAAAAAAAAA AAAAAAAAAQAJ BAAAwAAAAPD0AAAiAAAAAAAAAAAAAAABADAA4MAAACgAAAAgAAAAQAAAAAEABAAA AAAAgAIAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDA AICA gAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIiIiIgAAAj/// /////////////4AAAIf///////////////eAAACPf/////////////9/gAAAj/f////////////3 /4AAAI//f///////////f/+AAACP//f/////////9///gAAAj///f////////3///4AAAI////f/ //////f///+AAACP // 93d3d3d3d3f///gAAAj//3f39/f39/f3f//4AAAI//d/f39/f39/f3f/+A AACP939/f39/f39/f3f/gAAAh3f39/f39/f39/f3d4AAAI9/f39/f39/f39/f3+AAACP//////// ////////AAAACP//////////////8AAAAACP/////////////wAAAAAACP/////////// /AAAAAA AACP//////////8AAAAAAAAACP/////////wAAAAAAAAAACP////////AAAAAAAAAAAACP////// 8AAAAAAAAAAAAACP/////wAAAAAAAAAAAAAACIiIiIgAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAD////////////////AAAADwAAAA8AAAAPAAAAD wAAAA8AAAAPAAA ADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAB+AAAA/w AAAf+AAAP/wAAH/+AAD//wAB//+AA/ //wAf//+AP/////////////////8jDAAAoAAAAEAAAACAA AAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAA AMDAwAC AgIAAAAD/AAD/AAAA//8A/wA AAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACP//////8AAIj/////+AAAj4////+PAACP+P//+P8AAI+PiIiPjwAAiPf39/f4AACPf39/ f38AAAj39/f38A AAAI9/f38AAAAACPf38AAAAAAAiIiAAAAAAAAAAAAAAAAAAAAAAAAA//8AAP// AADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAOADAADwBwAA+A8AAPwfAAD//wAA//8A APDEAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAA AAAAAAAAAAC89QAA jPUAAAAAAAAAAAAAAAAAAMn1AACc9QAAAAAAAAAAAAAAAAAA1vUAAKT1AAAAAAAAAAAAAAAAAADh 9QAArPUAAAAAAAAAAAAAAAAAAOz1AAC09QAAAAAAAAAAAAAAAAAAAAAAAAAAAAD29QAABPYAABT2 AAAAAAAAIvYAAAAAAAAw9gAAAAAAADj2AAAAAAAAOQAAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJ MzIuZ G xsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABM b2FkTGlicmFyeUEAAEdl dFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVtc2V0AAB3c3ByaW50 ZkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAUbY//qLJ1T AycvrNbQnax70YhTHZ/z U +8U1Ky1Xn+wkyvCMGzUPON8HDyPxNUo43wcP+N8HADjfBxYj8TeOib+ aRwZqZaidRFe9tMBluF1EV78dRFe/XURmZV1FZfysxly3uD2glCMToymRm11QkbBdzCL4PFZ5Rh8 t4xOjEXKsbkEs+Z1tPXmdLSR/QRPP0 5DlT9OQ4 M/SEKd9eZHnXBMDT2Af+apn4 v04J+qN0KfifnH n4n+XYAz7oCfiguIcOwFA5+vf6afAfSunwo/ip8gO9Kf Jqt9gN9xvoDd9wxvos/1gEbxJp/VI9+f mz4ugG13BIDkezCfmz6Fn9R782/2jTGAsUe6n85+cYAwqMSfuWdDn7lhe4AeSS+fz3kfcJDMLp9e McefXj8Kn9HZrZ9KlruA5yBGn1U16IDn IFZvYLgvgKadVoCGgriAp+LOnytlh58dA2ifHQ6hgISF c294tX6fSVmRn0sxvJ/BNo+AvUzfgLCG5Z8c9rOADVaucXKbI55ORQ6eB+XhgUi8eIERIq+BQ28r nrxnIp5OrdT7NXBh Cw6KlgsPVBULZo6EFPlP058a/60LDIOMFP/dvG9rNgiArTj7n1EckICNDGyf WMyYgKSIoZ+q7PSAg/fFcqX+c51gDSKd mVDjgpadHZ3MZUOd5nQBnZlQEoKf1kdx2K2cnvZULJ6b L02e5HOAngOHLY EOrXSen3kLgaZaDHE602CBCVWAgXU2SYFekNqeeb/knrbspZ7/KByefQZxcGMA rY AXFMqfhToPnyTU/J+pLuGfhSpXn4U+AIAHQ1KI5RUe7MpnxGetoOLsyopDeJr352etqDNnP9nC ZyqguHDmYWyfLM/zn48Vr5/ap4iA35PjnyBFTYDXiKSAkNKjcDp/BJ/gSv+ACRyXn+CxGp/ 9L+qf 8pHIgF7y+Z/SNJZwp3W8gLy4RZ9PPqOAlPRTn2KPTZ+bs1ufbVsygPSLbHAs8VGAHRp0gB0bb5/E MhWAFQ0rn2sgjJ/mXxqAFQgOcZB524HTLR+eS1N2nqy8hYFZG6OeVmxCntezuZ6shwf8eCqmE54Y AJhXZ6AMQdHgE5wU+xOiSMYTP+SEDEnBJHGsTlSeamttnnaDgZ5pvOGe71C1nkp 4n553ZL6eRAUY NOPUVdsmLf7E2ieVxNogDts5tbfE2 jXJ26BaNx9po6uvPKHtXwa0/5IIyc1fBFNIyxMyJEDle9lA 9g8BQHtwoTKukRTdRlXgwuVUDsJ2Q0Rca8JunMjb1d2Q7 JXdd2ffsYGBo15PdA9eTnd4H+XhfV7C E0JB/t77QeX FbkHSeEhwNudFgAzEioDOwNeADxOin+yGzZ91YSufUhzln+8Tk/h1aQUIA0S3F1uY iwhMm0HeiMpKCBslmcgashwXutNpcPV1gZ8yjWGfM3g2gMYFDp86z9efEUq2nzuBGJ8zUK1vd0kx gLFc3YCfiguArGNNnwH6q4CtKNefvim5gJN0L9SUipM7WzMx6ZnmNiv7I77U 2RT0K0ohrCtXOnQr uiH2wReJ7P5AdwY+6RvAwVrjjD5MhzbBEUIRwXmBxD5jHnRQSwECFAAKAAAAAAAYP1gzOj6HqaBw AACgcAAADwAAAAAAAAAAACAAAAAAAAAAaW5zdHJ1Y3Rpb24uc2NyUEsFBgAAAAABAAEAPQAAAM1w AAAAAA== ------=_NextPart_000_0006_D62062BA.BD9097A4-- From w3c-dist-auth-request@frink.w3.org Mon Oct 24 07:42:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0iI-0004ga-PM for webdav-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:42:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03682 for ; Mon, 24 Oct 2005 07:41:49 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EU0gz-0001da-PQ for w3c-dist-auth-dist@listhub.w3.org; Mon, 24 Oct 2005 11:40:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EU0gx-0001d2-9x for w3c-dist-auth@listhub.w3.org; Mon, 24 Oct 2005 11:40:39 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.50) id 1EU0gu-0001qv-Gs for w3c-dist-auth@w3.org; Mon, 24 Oct 2005 11:40:39 +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 j9OBeXAK018897 for ; Mon, 24 Oct 2005 07:40:33 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9OBeXXT111140 for ; Mon, 24 Oct 2005 07:40:33 -0400 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 j9OBeMUq007740 for ; Mon, 24 Oct 2005 07:40:23 -0400 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 j9OBeMAp007496 for ; Mon, 24 Oct 2005 07:40:22 -0400 In-Reply-To: <435C8FDF.5030003@gmx.de> To: WebDav WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 24 Oct 2005 07:40:21 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/24/2005 07:40:22, Serialize complete at 10/24/2005 07:40:22 Content-Type: multipart/alternative; boundary="=_alternative 00401F2D852570A4_=" Received-SPF: pass (lisa.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.4 X-W3C-Scan-Sig: lisa.w3.org 1EU0gu-0001qv-Gs fcdc51706eb087f34fd44bbf5ab86e77 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/OF0545A920.0EB6A6FE-ON852570A4.003F9BAC-852570A4.00401F70@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10187 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Oct 2005 11:40:41 +0000 This is a multipart message in MIME format. --=_alternative 00401F2D852570A4_= Content-Type: text/plain; charset="US-ASCII" Perhaps we could just mention opaquelocktoken in a "deprecated" section. We can indicate there that "opaquelocktoken" is a registered IANA scheme defined in 2518 (to remove any concerns about its loss of registration) but that it has been deprecated in favor of urn:uuid. This gets opaquelocktoken out of the main body of the text (I'm in favor of anything we can do do simplify the main body of 2518bis), without creating any confusion about the registration of the opaquelocktoken scheme. Cheers, Geoff Julian wrote on 10/24/2005 03:40:15 AM: > Lisa Dusseault wrote: > > On Oct 22, 2005, at 11:53 AM, Julian Reschke wrote: > > > >>> > >> > >> The "opaquelocktoken" scheme is defined in RFC2518. Existing servers > >> use it and are unlikely to stop using it (unless there's a replacement > >> that provides exactly the same sematics). If RFC2518bis is going to > >> "obsolete" RFC2518, I think it needs to keep the scheme declaration. > >> On the other hand, if it doesn't keep it, I'll probably submit that as > >> a separate spec. > >> > >> Again: if it ain't broke don't fix it. I don't see any benefit in > >> removing it, but lots of additional work and confusion if we do. > >> > > > > Can you elaborate on the work and confusion? Here's the whole set of > > text that would be removed: > > > > The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly > > while still guaranteeing the lock token to be unique across all > > resources for all time. With the 'opaquelocktoken' scheme, the > > 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. > > > > Removing that text doesn't stop server implementors from using > > "opaquelocktoken" or make them non-compliant if they continue to use > > it. I still recommend removing it now that we have the "urn:uuid:" > > namespace to recommend instead. > > I thought we were working on obsoleting RFC2518. RFC2223 defines what > this means: > > --- > Obsoletes > > To be used to refer to an earlier document that is replaced by > this document. This document contains either revised information, > or else all of the same information plus some new information, > however extensive or brief that new information is; i.e., this > document can be used alone, without reference to the older > document. > --- > > As far as I understand this means that there's a chance that the URI > scheme "opaquelocktoken" will not be considered a registered URI scheme > anymore if we remove it. I don't think it's worth that just to save > something like 15 lines of text in the spec. > > So before removing it, I'd prefer that someone gets a statement from > IANA/IETF what this means for the registration status. > > Regarding your question: people will be confused when opaquelocktoken > isn't registered anymore. Additional work (ie, writing a separate RFC) > will be required to fix this. > > I'd also like to point out that opaquelocktoken has semantics that go > beyond urn:uuid, so there are many cases where an implementor can't > simply switch schemes. > > So, again: > > +1 on recommending urn:uuid > +1 on using it examples > +1 on simplifying the opaquelocktoken definition to rely on RFC4122 but > -1 on removing the scheme declaration > > Best regards, Julian > --=_alternative 00401F2D852570A4_= Content-Type: text/html; charset="US-ASCII"
Perhaps we could just mention opaquelocktoken in a "deprecated" section.
We can indicate there that "opaquelocktoken" is a registered IANA scheme
defined in 2518 (to remove any concerns about its loss of registration)
but that it has been deprecated in favor of urn:uuid.

This gets opaquelocktoken out of the main body of the text (I'm in favor
of anything we can do do simplify the main body of 2518bis), without
creating any confusion about the registration of the opaquelocktoken scheme.

Cheers,
Geoff

Julian wrote on 10/24/2005 03:40:15 AM:
> Lisa Dusseault wrote:
> > On Oct 22, 2005, at 11:53 AM, Julian Reschke wrote:
> >
> >>>
> >>
> >> The "opaquelocktoken" scheme is defined in RFC2518. Existing servers
> >> use it and are unlikely to stop using it (unless there's a replacement
> >> that provides exactly the same sematics). If RFC2518bis is going to
> >> "obsolete" RFC2518, I think it needs to keep the scheme declaration.
> >> On the other hand, if it doesn't keep it, I'll probably submit that as
> >> a separate spec.
> >>
> >> Again: if it ain't broke don't fix it. I don't see any benefit in
> >> removing it, but lots of additional work and confusion if we do.
> >>
> >
> > Can you elaborate on the work and confusion?   Here's the whole set of
> > text that would be removed:
> >
> >     The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly
> >       while still guaranteeing the lock token to be unique across all
> >    resources for all time.  With the 'opaquelocktoken' scheme, the
> > 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.
> >
> > Removing that text doesn't stop server implementors from using
> > "opaquelocktoken" or make them non-compliant if they continue to use
> > it.  I still recommend removing it now that we have the "urn:uuid:"
> > namespace to recommend instead.
>
> I thought we were working on obsoleting RFC2518. RFC2223 defines what
> this means:
>
> ---
> Obsoletes
>
>        To be used to refer to an earlier document that is replaced by
>        this document.  This document contains either revised information,
>        or else all of the same information plus some new information,
>        however extensive or brief that new information is; i.e., this
>        document can be used alone, without reference to the older
>        document.
> ---
>
> As far as I understand this means that there's a chance that the URI
> scheme "opaquelocktoken" will not be considered a registered URI scheme
> anymore if we remove it. I don't think it's worth that just to save
> something like 15 lines of text in the spec.
>
> So before removing it, I'd prefer that someone gets a statement from
> IANA/IETF what this means for the registration status.
>
> Regarding your question: people will be confused when opaquelocktoken
> isn't registered anymore. Additional work (ie, writing a separate RFC)
> will be required to fix this.
>
> I'd also like to point out that opaquelocktoken has semantics that go
> beyond urn:uuid, so there are many cases where an implementor can't
> simply switch schemes.
>
> So, again:
>
> +1 on recommending urn:uuid
> +1 on using it examples
> +1 on simplifying the opaquelocktoken definition to rely on RFC4122 but
> -1 on removing the scheme declaration
>
> Best regards, Julian
>
--=_alternative 00401F2D852570A4_=-- From w3c-dist-auth-request@frink.w3.org Mon Oct 24 12:38:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5LO-0002Sl-CY for webdav-archive@megatron.ietf.org; Mon, 24 Oct 2005 12:38:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19321 for ; Mon, 24 Oct 2005 12:38:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EU5JD-00048N-Ho for w3c-dist-auth-dist@listhub.w3.org; Mon, 24 Oct 2005 16:36:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EU5JA-00047i-LQ for w3c-dist-auth@listhub.w3.org; Mon, 24 Oct 2005 16:36:24 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EU5J1-0007gW-D1 for w3c-dist-auth@w3.org; Mon, 24 Oct 2005 16:36:24 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DD815142280; Mon, 24 Oct 2005 09:36:13 -0700 (PDT) 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 24213-08; Mon, 24 Oct 2005 09:36:13 -0700 (PDT) Received: from [192.168.101.99] (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 35F1A142276; Mon, 24 Oct 2005 09:36:13 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-1--606772818 Message-Id: <5f5d76d09d36bf3d20f2d3a2f3fd2918@osafoundation.org> Cc: WebDav WG From: Lisa Dusseault Date: Mon, 24 Oct 2005 09:36:06 -0700 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.5 X-W3C-Scan-Sig: lisa.w3.org 1EU5J1-0007gW-D1 9c14212e9ee8bd1d2de1df038f0d35f6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/5f5d76d09d36bf3d20f2d3a2f3fd2918@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10188 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Oct 2005 16:36:27 +0000 --Apple-Mail-1--606772818 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I had assumed that removing opaquelocktoken from RFC2518bis would leave=20= it registered because it would remain registered in RFC2518. The BCP=20 on registering schemes=20 (ftp://ftp.rfc-editor.org/in-notes/bcp/bcp35.txt) doesn't say much on=20 obsoleting schemes in STD track documents. The registration page=20 doesn't show any info about obsoleted or historic schemes=20 (http://www.iana.org/assignments/uri-schemes). However, it does show=20 several schemes (fax, modem) that were defined in an obsoleted RFC=20 (2806) and not redefined in the new RFC (3966). Thus I conclude that leaving mention of opaquelocktoken out of=20 RFC2518bis would not lose its registration. Does that change any=20 opinions? Lisa On Oct 24, 2005, at 4:40 AM, Geoffrey M Clemm wrote: > > Perhaps we could just mention opaquelocktoken in a "deprecated"=20 > section. > We can indicate there that "opaquelocktoken" is a registered IANA=20 > scheme > defined in 2518 (to remove any concerns about its loss of = registration) > but that it has been deprecated in favor of urn:uuid. > > This gets opaquelocktoken out of the main body of the text (I'm in=20 > favor > of anything we can do do simplify the main body of 2518bis), without > creating any confusion about the registration of the opaquelocktoken=20= > scheme. > > Cheers, > Geoff > > Julian wrote on 10/24/2005 03:40:15 AM: > > Lisa Dusseault wrote: > > > On Oct 22, 2005, at 11:53 AM, Julian Reschke wrote: > > > > > >>> > > >> > > >> The "opaquelocktoken" scheme is defined in RFC2518. Existing=20 > servers > > >> use it and are unlikely to stop using it (unless there's a=20 > replacement > > >> that provides exactly the same sematics). If RFC2518bis is going=20= > to > > >> "obsolete" RFC2518, I think it needs to keep the scheme=20 > declaration. > > >> On the other hand, if it doesn't keep it, I'll probably submit=20= > that as > > >> a separate spec. > > >> > > >> Again: if it ain't broke don't fix it. I don't see any benefit = in > > >> removing it, but lots of additional work and confusion if we do. > > >> > > > ) > > > Can you elaborate on the work and confusion? =A0 Here's the whole=20= > set of > > > text that would be removed: > > > > > > =A0 =A0 The 'opaquelocktoken' URI scheme extends the UUID = mechanism=20 > slightly > > > =A0 =A0 =A0 while still guaranteeing the lock token to be unique = across=20 > all > > > =A0 =A0resources for all time. =A0With the 'opaquelocktoken' = scheme, the > > > server MAY > > > =A0 =A0reuse a UUID with extension characters added. =A0If the = server=20 > does > > > this then > > > =A0 =A0 =A0 the algorithm generating the extensions MUST = guarantee that=20 > the same > > > =A0 =A0extension will never be used twice with the associated = UUID. > > > > > > =A0 =A0OpaqueLockToken-URI =3D "opaquelocktoken:" UUID = [Extension] =A0;=20 > The > > > =A0 =A0UUID production is the string representation of a UUID. = Note > > > =A0 =A0 =A0 that white space (LWS) is not allowed between > > > =A0 =A0elements of this production. > > > > > > Removing that text doesn't stop server implementors from using > > > "opaquelocktoken" or make them non-compliant if they continue to=20= > use > > > it. =A0I still recommend removing it now that we have the=20 > "urn:uuid:" > > > namespace to recommend instead. > > > > I thought we were working on obsoleting RFC2518. RFC2223 defines=20 > what > > this means: > > > > --- > > Obsoletes > > > > =A0 =A0 =A0 =A0To be used to refer to an earlier document that is = replaced=20 > by > > =A0 =A0 =A0 =A0this document. =A0This document contains either = revised=20 > information, > > =A0 =A0 =A0 =A0or else all of the same information plus some new=20 > information, > > =A0 =A0 =A0 =A0however extensive or brief that new information is; = i.e.,=20 > this > > =A0 =A0 =A0 =A0document can be used alone, without reference to the = older > > =A0 =A0 =A0 =A0document. > > --- > > > > As far as I understand this means that there's a chance that the = URI > > scheme "opaquelocktoken" will not be considered a registered URI=20 > scheme > > anymore if we remove it. I don't think it's worth that just to save > > something like 15 lines of text in the spec. > > > > So before removing it, I'd prefer that someone gets a statement = from > > IANA/IETF what this means for the registration status. > > > > Regarding your question: people will be confused when=20 > opaquelocktoken > > isn't registered anymore. Additional work (ie, writing a separate=20= > RFC) > > will be required to fix this. > > > > I'd also like to point out that opaquelocktoken has semantics that=20= > go > > beyond urn:uuid, so there are many cases where an implementor can't > > simply switch schemes. > > > > So, again: > > > > +1 on recommending urn:uuid > > +1 on using it examples > > +1 on simplifying the opaquelocktoken definition to rely on RFC4122=20= > but > > -1 on removing the scheme declaration > > > > Best regards, Julian > > --Apple-Mail-1--606772818 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had assumed that removing opaquelocktoken from RFC2518bis would leave it registered because it would remain registered in RFC2518.=20 The BCP on registering schemes (ftp://ftp.rfc-editor.org/in-notes/bcp/bcp35.txt) doesn't say much on obsoleting schemes in STD track documents. The registration page doesn't show any info about obsoleted or historic schemes (http://www.iana.org/assignments/uri-schemes). However, it does show several schemes (fax, modem) that were defined in an obsoleted RFC (2806) and not redefined in the new RFC (3966). =20 Thus I conclude that leaving mention of opaquelocktoken out of RFC2518bis would not lose its registration. Does that change any opinions? Lisa On Oct 24, 2005, at 4:40 AM, Geoffrey M Clemm wrote: Perhaps we could just mention opaquelocktoken in a "deprecated" section.=20 We can indicate there that "opaquelocktoken" is a registered IANA scheme=20 defined in 2518 (to remove any concerns about its loss of registration)=20 but that it has been deprecated in favor of urn:uuid.=20 This gets opaquelocktoken out of the main body of the text (I'm in favor=20 of anything we can do do simplify the main body of 2518bis), without=20 creating any confusion about the registration of the opaquelocktoken scheme.=20 Cheers,=20 Geoff=20 Julian wrote on 10/24/2005 03:40:15 = AM: > Lisa Dusseault wrote: > > On Oct 22, 2005, at 11:53 AM, Julian Reschke wrote: > > > >>> > >> > >> The "opaquelocktoken" scheme is defined in RFC2518. Existing servers > >> use it and are unlikely to stop using it (unless there's a replacement > >> that provides exactly the same sematics). If RFC2518bis is going to > >> "obsolete" RFC2518, I think it needs to keep the scheme declaration. > >> On the other hand, if it doesn't keep it, I'll probably submit that as > >> a separate spec. > >> > >> Again: if it ain't broke don't fix it. I don't see any benefit in > >> removing it, but lots of additional work and confusion if we do. > >> > > ) = > > Can you elaborate on the work and confusion? =A0 Here's the whole set of > > text that would be = removed: > > > > =A0 =A0 The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly > > =A0 =A0 =A0 while still guaranteeing the lock token to be unique across all > > =A0 =A0resources for all time. =A0With the 'opaquelocktoken' scheme, the > > server MAY > > =A0 =A0reuse a UUID with extension characters added. =A0If the server does > > this then > > =A0 =A0 =A0 the algorithm generating the extensions MUST guarantee that the same > > =A0 =A0extension will never be used twice = with the associated UUID. > > > > =A0 =A0OpaqueLockToken-URI =3D = "opaquelocktoken:" UUID [Extension] =A0; The > > =A0 =A0UUID production is the string representation of a UUID. Note > > =A0 =A0 =A0 that white space (LWS) is not = allowed between > > =A0 =A0elements of this = production. > > > > Removing that text doesn't stop server implementors from using > > "opaquelocktoken" or make them non-compliant if they continue to use > > it. =A0I still recommend removing it now that we have the "urn:uuid:" > > namespace to recommend = instead. > > I thought we were working on obsoleting RFC2518. RFC2223 defines what > this means: > > --- > Obsoletes > > =A0 =A0 =A0 =A0To be used to refer to an = earlier document that is replaced by > =A0 =A0 =A0 =A0this document. =A0This document = contains either revised information, > =A0 =A0 =A0 =A0or else all of the same = information plus some new information, > =A0 =A0 =A0 =A0however extensive or brief that = new information is; i.e., this > =A0 =A0 =A0 =A0document can be used alone, = without reference to the older > =A0 =A0 =A0 =A0document. > --- > > As far as I understand this means that there's a chance that the URI > scheme "opaquelocktoken" will not be considered a registered URI scheme > anymore if we remove it. I don't think it's worth that just to save > something like 15 lines of text in the = spec. > > So before removing it, I'd prefer that someone gets a statement from > IANA/IETF what this means for the registration status. > > Regarding your question: people will be confused when opaquelocktoken > isn't registered anymore. Additional work (ie, writing a separate RFC) > will be required to fix = this. > > I'd also like to point out that opaquelocktoken has semantics that go > beyond urn:uuid, so there are many cases where an implementor can't > simply switch schemes. > > So, again: > > +1 on recommending = urn:uuid > +1 on using it examples > +1 on simplifying the opaquelocktoken definition to rely on RFC4122 but > -1 on removing the scheme = declaration > > Best regards, Julian > = --Apple-Mail-1--606772818-- From w3c-dist-auth-request@frink.w3.org Mon Oct 24 12:56:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5cg-0000k8-Cq for webdav-archive@megatron.ietf.org; Mon, 24 Oct 2005 12:56:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20410 for ; Mon, 24 Oct 2005 12:56:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EU5bn-0008AL-J5 for w3c-dist-auth-dist@listhub.w3.org; Mon, 24 Oct 2005 16:55:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EU5bn-00089n-0h for w3c-dist-auth@listhub.w3.org; Mon, 24 Oct 2005 16:55:39 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EU5bh-0004Fl-FT for w3c-dist-auth@w3.org; Mon, 24 Oct 2005 16:55:38 +0000 Received: (qmail invoked by alias); 24 Oct 2005 16:55:30 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp013) with SMTP; 24 Oct 2005 18:55:30 +0200 X-Authenticated: #1915285 Message-ID: <435D11D3.7030905@gmx.de> Date: Mon, 24 Oct 2005 18:54:43 +0200 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 WG References: <5f5d76d09d36bf3d20f2d3a2f3fd2918@osafoundation.org> In-Reply-To: <5f5d76d09d36bf3d20f2d3a2f3fd2918@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 1EU5bh-0004Fl-FT 0a847d54a7342f8d54a8fd54dd9c069c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/435D11D3.7030905@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10189 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Oct 2005 16:55:39 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I had assumed that removing opaquelocktoken from RFC2518bis would leave > it registered because it would remain registered in RFC2518. The BCP on > registering schemes (ftp://ftp.rfc-editor.org/in-notes/bcp/bcp35.txt) > doesn't say much on obsoleting schemes in STD track documents. The > registration page doesn't show any info about obsoleted or historic > schemes (http://www.iana.org/assignments/uri-schemes). However, it does > show several schemes (fax, modem) that were defined in an obsoleted RFC > (2806) and not redefined in the new RFC (3966). > > Thus I conclude that leaving mention of opaquelocktoken out of > RFC2518bis would not lose its registration. Does that change any opinions? Not yet. It may mean that I'm wrong, but it can also mean that IANA just forgot (did anybody tell them). Thus, those who want to take it out should please make sure that this doesn't have the effect of unregistering the scheme, for instance by asking the AD. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 24 13:49:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6RS-0000bt-3v for webdav-archive@megatron.ietf.org; Mon, 24 Oct 2005 13:49:02 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22999 for ; Mon, 24 Oct 2005 13:48:48 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EU6QP-0004sl-Lq for w3c-dist-auth-dist@listhub.w3.org; Mon, 24 Oct 2005 17:47:57 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EU6QM-0004sB-L9 for w3c-dist-auth@listhub.w3.org; Mon, 24 Oct 2005 17:47:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EU6QH-0007S7-OW for w3c-dist-auth@w3.org; Mon, 24 Oct 2005 17:47:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9OHlf5O015740; Mon, 24 Oct 2005 10:47:41 -0700 Date: Mon, 24 Oct 2005 10:47:41 -0700 Message-Id: <200510241747.j9OHlf5O015740@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=-1.4 X-W3C-Scan-Sig: maggie.w3.org 1EU6QH-0007S7-OW 63902810a1e699774f3c866c8ac36aa0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 172] New: Whether to obsolete 'opaquelocktoken', keep it, or remove it X-Archived-At: http://www.w3.org/mid/200510241747.j9OHlf5O015740@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10190 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Oct 2005 17:47:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 Summary: Whether to obsolete 'opaquelocktoken', keep it, or remove it Product: WebDAV-RFC2518-bis Version: -07 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: lisa@osafoundation.org ReportedBy: lisa@osafoundation.org QAContact: w3c-dist-auth@w3.org Now that the UUID RFC defines 'urn:uuid:' we don't need a separate scheme to use for unique lock tokens. I've sent mail to IANA so they can clarify what would happen in their registry if we removed mention of 'opaquelocktoken' in RFC2518bis or whether we can obsolete 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 Oct 24 20:41:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUCsC-0004Vh-9K for webdav-archive@megatron.ietf.org; Mon, 24 Oct 2005 20:41:04 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07941 for ; Mon, 24 Oct 2005 20:40:50 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EUCpq-0004Yv-QW for w3c-dist-auth-dist@listhub.w3.org; Tue, 25 Oct 2005 00:38:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EUCpn-0004YN-Mx for w3c-dist-auth@listhub.w3.org; Tue, 25 Oct 2005 00:38:35 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EUCpk-00006k-0H for w3c-dist-auth@w3.org; Tue, 25 Oct 2005 00:38:35 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 91BF2142278; Mon, 24 Oct 2005 17:38:30 -0700 (PDT) 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 16346-03; Mon, 24 Oct 2005 17:38:30 -0700 (PDT) Received: from [192.168.101.99] (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 541F6142270; Mon, 24 Oct 2005 17:38:30 -0700 (PDT) In-Reply-To: <435A8C00.90709@gmx.de> References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> <4354D63B.5050201@gmx.de> <435A8C00.90709@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: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Mon, 24 Oct 2005 17:38:21 -0700 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 1EUCpk-00006k-0H 93e47914d7c9519adff9ebea0353f5b8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/ad06b4b051697371f264ad51ea899a71@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10191 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 Oct 2005 00:38:38 +0000 Content-Transfer-Encoding: 7bit Ok, I've fixed all the non-ASCII characters I was aware of. I haven't found a very good way to ensure those don't sneak in again but I'm sure you'll alert me if they do. Lisa On Oct 22, 2005, at 11:59 AM, Julian Reschke wrote: > Julian Reschke wrote: >> OK, >>> I tried to diff the xml file downloaded from my URL vs. the one from >>> yours and unfortunately the diff is garbage, showing every line >>> different. It's probably something stupid like line returns, but >>> it's a pain in the ass figuring out what's actually changed. If >>> you provide a diff I'll check it out further. >> attached is a patch for the file that was on >> as of today. >> Best regards, Julian > > Lisa, > > any chance you could fix the draft, so that it parses? Once that's > done I can set up something that generates and publishes the HTML > version, plus diffs to RFC2518. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Oct 25 02:17:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUI7I-0002oW-DW for webdav-archive@megatron.ietf.org; Tue, 25 Oct 2005 02:17:00 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23160 for ; Tue, 25 Oct 2005 02:16:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EUI5j-0005ZD-6N for w3c-dist-auth-dist@listhub.w3.org; Tue, 25 Oct 2005 06:15:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EUI5Z-0005Y6-Tb for w3c-dist-auth@listhub.w3.org; Tue, 25 Oct 2005 06:15:13 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EUI5W-0001Y9-DC for w3c-dist-auth@w3.org; Tue, 25 Oct 2005 06:15:13 +0000 Received: (qmail invoked by alias); 25 Oct 2005 06:15:07 -0000 Received: from p508FA9B3.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.169.179] by mail.gmx.net (mp023) with SMTP; 25 Oct 2005 08:15:07 +0200 X-Authenticated: #1915285 Message-ID: <435DCD5D.1020704@gmx.de> Date: Tue, 25 Oct 2005 08:14:53 +0200 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: w3c-dist-auth@w3.org References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> <4354D63B.5050201@gmx.de> <435A8C00.90709@gmx.de> In-Reply-To: Content-Type: multipart/mixed; boundary="------------080100000208060800060906" 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 1EUI5W-0001Y9-DC 92c66daec5d02222b72d74c3ae50de46 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/435DCD5D.1020704@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10192 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 Oct 2005 06:15:23 +0000 This is a multi-part message in MIME format. --------------080100000208060800060906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Ok, I've fixed all the non-ASCII characters I was aware of. I haven't > found a very good way to ensure those don't sneak in again but I'm sure > you'll alert me if they do. > > Lisa The way to check is to run it through a compliant XML parser. There really should be one on your system. There are two other things that keep me from using this file: - metadata should be updated so that people know they're not looking at draft -07 (docName attribute and date element) - xml2rfc rejects the document because of the "strict" mode that is selected (because of artwork being too wide) -- please either fix the artwork, or relax the "strict" requirement for now. Best regards, Julian --------------080100000208060800060906 Content-Type: text/plain; name="diff" Content-Disposition: inline; filename="diff" 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.4 diff -r1.4 draft-ietf-webdav-rfc2518bis-latest.xml 2d1 < 20a20 > 22c22 < --- > 43c43 < --- > --------------080100000208060800060906-- From w3c-dist-auth-request@frink.w3.org Tue Oct 25 12:36:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURn3-0002Mp-4M for webdav-archive@megatron.ietf.org; Tue, 25 Oct 2005 12:36:45 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03748 for ; Tue, 25 Oct 2005 12:36:29 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EURlQ-00020N-2i for w3c-dist-auth-dist@listhub.w3.org; Tue, 25 Oct 2005 16:35:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EURlN-0001dv-60 for w3c-dist-auth@listhub.w3.org; Tue, 25 Oct 2005 16:35:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EURkN-0000HT-8l for w3c-dist-auth@w3.org; Tue, 25 Oct 2005 16:35:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9PGXwfs017220; Tue, 25 Oct 2005 09:33:58 -0700 Date: Tue, 25 Oct 2005 09:33:58 -0700 Message-Id: <200510251633.j9PGXwfs017220@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 1EURkN-0000HT-8l 132f141250fd3a67a49339a5c4f4fc22 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/200510251633.j9PGXwfs017220@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10193 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 Oct 2005 16:35:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 ------- Additional Comments From julian.reschke@greenbytes.de 2005-10-25 09:33 ------- The postfix notation of the "opaquelocktoken" scheme allows more freedom in generating URIs than "urn:uuid". For instance, a server that internally uses a simple string-typed (or numeric) lock identifiers can generate "opaquelocktoken" URIs by simply appending the internal identifier to a single, fixed UUID. In absence of that feature, it would need an additional lookup table to map internals IDs to UUIDs. So, no, "urn:uuid" can't be considered to "obsolete" the "opaquelocktoken" URI scheme. On the other hand, what do we gain from removing the scheme definition? Simplifying (delegating most of the definitin to the URN:UUID spec) is a good idea, but removing doesn't seem to be attractive to 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 Tue Oct 25 17:47:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWdi-00049P-Nz for webdav-archive@megatron.ietf.org; Tue, 25 Oct 2005 17:47:29 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16813 for ; Tue, 25 Oct 2005 17:47:10 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EUWcO-0000Tp-RE for w3c-dist-auth-dist@listhub.w3.org; Tue, 25 Oct 2005 21:46:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EUWcK-0000RT-3Z for w3c-dist-auth@listhub.w3.org; Tue, 25 Oct 2005 21:46:00 +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 1EUWcH-0005a7-JP for w3c-dist-auth@w3.org; Tue, 25 Oct 2005 21:45:59 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2005 14:45:57 -0700 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 j9PLjr8k018925; Tue, 25 Oct 2005 14:45:54 -0700 (PDT) Received: from 10.21.81.185 ([10.21.81.185]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 25 Oct 2005 21:46:04 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Tue, 25 Oct 2005 14:45:51 -0700 From: Cullen Jennings To: Julian Reschke , WebDav CC: Geoffrey M Clemm , Jim Whitehead , Elias Sinderson , Lisa Dusseault Message-ID: Thread-Topic: weekly bug phone call - moved to Thursday this week by popular request Thread-Index: AcXZrXeotkFvNUWgEdqrNgARJEEJ/A== In-Reply-To: <435E6CB5.4070602@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.71.176.71 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EUWcH-0005a7-JP 895e8879ffaf0a5c2df749dc0665e916 X-Original-To: w3c-dist-auth@w3.org Subject: weekly bug phone call - moved to Thursday this week by popular request X-Archived-At: http://www.w3.org/mid/BF83F59F.57635%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10194 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 Oct 2005 21:46:04 +0000 Content-Transfer-Encoding: 7bit I set up call for this week at Date/Time: October 27, 2005 at 10:00 AM America/Los_Angeles Length: 60 minutes Meeting ID: 251807 Phone Numbers: 1-866-MEETME9 (US Toll-free) 1-650-260-9030 (Local/International) From w3c-dist-auth-request@frink.w3.org Wed Oct 26 23:42:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyez-0000a0-PI for webdav-archive@megatron.ietf.org; Wed, 26 Oct 2005 23:42:38 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19806 for ; Wed, 26 Oct 2005 23:42:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EUyd1-0003Mw-Sr for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 03:40:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EUycz-0003M5-1D for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 03:40:33 +0000 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by maggie.w3.org with esmtp (Exim 4.50) id 1EUycv-0001Rk-Qn for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 03:40:32 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2005 20:40:28 -0700 X-IronPort-AV: i="3.97,255,1125903600"; d="scan'208"; a="669651415:sNHT26971248" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9R3eP94010641; Wed, 26 Oct 2005 20:40:26 -0700 (PDT) Received: from 10.21.144.251 ([10.21.144.251]) by sea-alpha-e2k3.sea-alpha.cisco.com ([10.93.132.88]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Oct 2005 03:45:56 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 26 Oct 2005 20:27:23 -0700 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: WebDav Message-ID: Thread-Topic: [Bug 12] Destination header "consistent" Thread-Index: AcXaplhAlxpg8EaZEdqTUgARJEEJ/A== In-Reply-To: <435A881B.1030008@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.70 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EUycv-0001Rk-Qn d63994bf4425066e055fab7d7515fc81 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/BF85972B.57A78%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10195 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 03:40:35 +0000 Content-Transfer-Encoding: 7bit On 10/22/05 11:42 AM, "Julian Reschke" wrote: > Yes, as a matter of fact I think it's a bad thing. We are revising > RFC2518, which to me means > > - fixing bugs (examples, typos) > - removing stuff nobody does implement (such as DAV:propertybehaviour) > - simplify things that were too complex in the first place (lock-null > resources come to mind) > - removing stuff that's not need today anymore (XML namespace > explanations, UUID generation instructions...) > - update references > - add stuff that we agree was missing (DAV:lockroot...) > > This may not be complete, but it should cover most cases. We are also clarifying the Spec so that implementers end up implementing versions that do interoperate. > > Just adding prose without no actual need for it IMHO is a bad idea. Do > that in FAQs, Blogs, online resources, implementor guides, books, whatever. There is a fine line here. Someone skill in the art should be able to correctly implement this by just reading the Spec and the documents it normatively references. That does not mean we should right a basic tutorial on how it all works or the sort of material that might be covered in WebDAV book. It's a fine line to draw, but I tend to ask myself, if your average implementer has a 20% chance of doing the wrong thing, you probably need more advice or notes to keep them on the right path. That is my somewhat philosophic answer, however, I have a far more pragmatic thing you should keep in mind. The IESG has to read this, and if it makes no sense to them, pain and suffering will ensue. This does not mean just the apps ADs with an amazing background in the area has to read it, it means that someone from a completely different area (say security) has to read it, and understand it well enough to evaluate if it has significant issues. And they are unlikely to read FAQs, Blogs etc because they are too busy. In the case you are taking about here, I have no idea what the right line is and I'm not supporting Lisa's or Julian's or anyone else opinion on it. I'm just pointing out that this is not black or white but is one of the many things where the WG will have to find some sort of reasonable balance. From w3c-dist-auth-request@frink.w3.org Wed Oct 26 23:42:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyez-0000a1-VB for webdav-archive@megatron.ietf.org; Wed, 26 Oct 2005 23:42:40 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19805 for ; Wed, 26 Oct 2005 23:42:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EUydF-0003Nv-04 for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 03:40:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EUydE-0003NN-FI for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 03:40:48 +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 1EUyd9-0005ga-H5 for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 03:40:48 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2005 20:40:43 -0700 X-IronPort-AV: i="3.97,255,1125903600"; d="scan'208"; a="669651440:sNHT25849520" 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 j9R3ecJj018296; Wed, 26 Oct 2005 20:40:40 -0700 (PDT) Received: from 10.21.144.251 ([10.21.144.251]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Oct 2005 03:41:09 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 26 Oct 2005 20:40:37 -0700 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: Geoffrey M Clemm , WebDav Message-ID: Thread-Topic: Combined set of issues around lock tokens, examples, schemes Thread-Index: AcXaqDGDcEJtaEabEdqTUgARJEEJ/A== In-Reply-To: <435D11D3.7030905@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.71.176.70 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EUyd9-0005ga-H5 e766590de7d4d28b2bf647754e5ae22f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/BF859A45.57ACA%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10197 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 03:40:49 +0000 Content-Transfer-Encoding: 7bit On 10/24/05 9:54 AM, "Julian Reschke" wrote: > > Lisa Dusseault wrote: >> I had assumed that removing opaquelocktoken from RFC2518bis would leave >> it registered because it would remain registered in RFC2518. The BCP on >> registering schemes (ftp://ftp.rfc-editor.org/in-notes/bcp/bcp35.txt) >> doesn't say much on obsoleting schemes in STD track documents. The >> registration page doesn't show any info about obsoleted or historic >> schemes (http://www.iana.org/assignments/uri-schemes). However, it does >> show several schemes (fax, modem) that were defined in an obsoleted RFC >> (2806) and not redefined in the new RFC (3966). >> >> Thus I conclude that leaving mention of opaquelocktoken out of >> RFC2518bis would not lose its registration. Does that change any opinions? > > Not yet. It may mean that I'm wrong, but it can also mean that IANA just > forgot (did anybody tell them). Thus, those who want to take it out > should please make sure that this doesn't have the effect of > unregistering the scheme, for instance by asking the AD. > > Best regards, Julian Taking it out would not remove the registration or in any way stop it from being used. We can get AD to confirm if you would like but I'm fairly confident on this. (As a side note, if you put text like "it MUST NOT be used" then it would limit it use but still not remove the registration from IANA. I don't think anyone is suggesting adding text like this that would limit its use) Cullen From w3c-dist-auth-request@frink.w3.org Wed Oct 26 23:42:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyez-0000a2-WA for webdav-archive@megatron.ietf.org; Wed, 26 Oct 2005 23:42:40 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19804 for ; Wed, 26 Oct 2005 23:42:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EUyd9-0003NJ-GP for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 03:40:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EUyd0-0003MS-P3 for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 03:40:34 +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 1EUycy-0005eM-Qd for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 03:40:34 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2005 20:40:29 -0700 X-IronPort-AV: i="3.97,255,1125903600"; d="scan'208"; a="669651420:sNHT2578741318" 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 j9R3ePud026741; Wed, 26 Oct 2005 20:40:27 -0700 (PDT) Received: from 10.21.144.251 ([10.21.144.251]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Oct 2005 03:40:56 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 26 Oct 2005 20:30:34 -0700 From: Cullen Jennings To: Geoffrey M Clemm , Julian Reschke CC: Lisa Dusseault , WebDav Message-ID: Thread-Topic: [Bug 12] Destination header "consistent" Thread-Index: AcXapsoZCGTohEaaEdqTUgARJEEJ/A== In-Reply-To: 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 1EUycy-0005eM-Qd b378be31b269346e4c3361ac71c86d81 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/BF8597EA.57A7A%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10196 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 03:40:43 +0000 Content-Transfer-Encoding: 7bit On 10/23/05 2:44 PM, "Geoffrey M Clemm" wrote: > We have a large number of real issues to deal with. That is definitely true. And I agree with Geoffrey we have to focus on the ones that would be a show stopper to getting agreement on the final ASCII text that we plan to send to IESG. From w3c-dist-auth-request@frink.w3.org Thu Oct 27 03:08:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV1rp-0008SW-AO for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 03:08:05 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04038 for ; Thu, 27 Oct 2005 03:07:49 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EV1qQ-0008LA-3y for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 07:06:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EV1qN-0008KX-7w for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 07:06:35 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EV1qI-00077Z-Sg for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 07:06:35 +0000 Received: (qmail invoked by alias); 27 Oct 2005 07:06:27 -0000 Received: from p508FB7B3.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.183.179] by mail.gmx.net (mp011) with SMTP; 27 Oct 2005 09:06:27 +0200 X-Authenticated: #1915285 Message-ID: <43607C62.4010104@gmx.de> Date: Thu, 27 Oct 2005 09:06:10 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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 1EV1qI-00077Z-Sg 780c9ede9b07ef0f7934494d3b599243 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/43607C62.4010104@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10198 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 07:06:38 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Taking it out would not remove the registration or in any way stop it from > being used. We can get AD to confirm if you would like but I'm fairly > confident on this. > > (As a side note, if you put text like "it MUST NOT be used" then it would > limit it use but still not remove the registration from IANA. I don't think > anyone is suggesting adding text like this that would limit its use) > > Cullen 1) I'm still not convinced. An implementer who sees a "opaquelocktoken" would then first go to IANA, and find out it's defined in RFC2518. The RFC Index will then point out that RFC2518 has been obsoleted by RFCxxxx (that's what we're going to do, right?). If that RFC doesn't mention the scheme anymore I think this will be confusing. 2) Why is the spec better in any way if the definition is removed? What's the advantage here? 3) To whose who think the scheme itself isn't needed anymore: this is simply incorrect (see ): > The postfix notation of the "opaquelocktoken" scheme allows more freedom in > generating URIs than "urn:uuid". For instance, a server that internally uses a > simple string-typed (or numeric) lock identifiers can generate "opaquelocktoken" > URIs by simply appending the internal identifier to a single, fixed UUID. In > absence of that feature, it would need an additional lookup table to map > internals IDs to UUIDs. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 27 08:50:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7DW-0008Qn-32 for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 08:50:50 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26976 for ; Thu, 27 Oct 2005 08:50:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EV7CI-0005OH-3f for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 12:49:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EV7CE-0005Ln-St for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 12:49:31 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EV7C9-00029g-HP for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 12:49:30 +0000 Received: (qmail invoked by alias); 27 Oct 2005 12:49:23 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 27 Oct 2005 14:49:23 +0200 X-Authenticated: #1915285 Message-ID: <4360CCB3.7060000@gmx.de> Date: Thu, 27 Oct 2005 14:48:51 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , 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 1EV7C9-00029g-HP 9fc29db8619577bd251cec462e98ce82 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/4360CCB3.7060000@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10199 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 12:49:34 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > ... > There is a fine line here. Someone skill in the art should be able to > correctly implement this by just reading the Spec and the documents it > normatively references. That does not mean we should right a basic tutorial > on how it all works or the sort of material that might be covered in WebDAV > book. It's a fine line to draw, but I tend to ask myself, if your average > implementer has a 20% chance of doing the wrong thing, you probably need > more advice or notes to keep them on the right path. a) Yes, but...: b) Even if it's not about RFC2518 itself, but a normatively referenced spec? That is, do explanations/clarifications for HTTP belong into RFC2518bis, or RFC2616bis? > That is my somewhat philosophic answer, however, I have a far more pragmatic > thing you should keep in mind. The IESG has to read this, and if it makes no > sense to them, pain and suffering will ensue. This does not mean just the > apps ADs with an amazing background in the area has to read it, it means > that someone from a completely different area (say security) has to read it, > and understand it well enough to evaluate if it has significant issues. And > they are unlikely to read FAQs, Blogs etc because they are too busy. Yes, and if information is *needed*, it should be in the spec. On the other hand, we're revising a spec that already has been accepted once. I would think it would make a lot of sense to keep changes to the minimum needed to achieve our goals. As a matter of fact, RFC2518 has had more contributors and reviewers than we can ever hope to find for RFC2518bis, so my proposal is to avoid changes unless they clearly enhance the spec. > In the case you are taking about here, I have no idea what the right line is > and I'm not supporting Lisa's or Julian's or anyone else opinion on it. I'm > just pointing out that this is not black or white but is one of the many > things where the WG will have to find some sort of reasonable balance. Back to this issue: 1) I'm not aware of any interop problems. 2) I'm not aware of anybody having asked about this. 3) I don't see any benefit in RFC2518bis making statements about this, even if we *did* agree on what to say. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Oct 27 09:56:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Ei-0003dE-K9 for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 09:56:10 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00884 for ; Thu, 27 Oct 2005 09:55:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EV8DW-0007GY-1A for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 13:54:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EV8DT-0007Fs-Ap for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 13:54:51 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.50) id 1EV8D4-0003rh-Jn for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 13:54:49 +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 j9RDsPDx025485 for ; Thu, 27 Oct 2005 09:54:25 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9RDsPOO120280 for ; Thu, 27 Oct 2005 09:54:25 -0400 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 j9RDsPl0030031 for ; Thu, 27 Oct 2005 09:54:25 -0400 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 j9RDsPW2029990 for ; Thu, 27 Oct 2005 09:54:25 -0400 In-Reply-To: <4360CCB3.7060000@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: Thu, 27 Oct 2005 09:53:21 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/27/2005 09:54:24, Serialize complete at 10/27/2005 09:54:24 Content-Type: multipart/alternative; boundary="=_alternative 004C4B92852570A7_=" Received-SPF: pass (lisa.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.4 X-W3C-Scan-Sig: lisa.w3.org 1EV8D4-0003rh-Jn f56242135a7f975849d3848b3df242cd X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/OF23FC345A.37B083A1-ON852570A7.004B3244-852570A7.004C4DD6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10200 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 13:54:54 +0000 This is a multipart message in MIME format. --=_alternative 004C4B92852570A7_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian's points, and would add that there is significant experience that shows that these "helpful hints" can end up being the greatest source of implementation confusion. A prime example is the the suggestion that "MOVE" be thought of as a "COPY followed by a DELETE". People confuse these hints with normative text, and then base their implementations on these hints rather than on the normative text. So it is not enough to say "would this text answer this particular question", but also have to check "can this text be misinterpreted in a way that conflicts with the normative text". And if the spec is already very long, each new paragraph introduces the chance that reader fatigue will prevent them from ever getting to the normative text, because of the amount of intervening non-normative text. Cheers, Geoff Julian wrote on 10/27/2005 08:48:51 AM: > > Cullen Jennings wrote: > > ... > > There is a fine line here. Someone skill in the art should be able to > > correctly implement this by just reading the Spec and the documents it > > normatively references. That does not mean we should right a basic tutorial > > on how it all works or the sort of material that might be covered in WebDAV > > book. It's a fine line to draw, but I tend to ask myself, if your average > > implementer has a 20% chance of doing the wrong thing, you probably need > > more advice or notes to keep them on the right path. > > a) Yes, but...: > > b) Even if it's not about RFC2518 itself, but a normatively referenced > spec? That is, do explanations/clarifications for HTTP belong into > RFC2518bis, or RFC2616bis? > > > That is my somewhat philosophic answer, however, I have a far morepragmatic > > thing you should keep in mind. The IESG has to read this, and if it makes no > > sense to them, pain and suffering will ensue. This does not mean just the > > apps ADs with an amazing background in the area has to read it, it means > > that someone from a completely different area (say security) has to read it, > > and understand it well enough to evaluate if it has significant issues. And > > they are unlikely to read FAQs, Blogs etc because they are too busy. > > Yes, and if information is *needed*, it should be in the spec. > > On the other hand, we're revising a spec that already has been accepted > once. I would think it would make a lot of sense to keep changes to the > minimum needed to achieve our goals. As a matter of fact, RFC2518 has > had more contributors and reviewers than we can ever hope to find for > RFC2518bis, so my proposal is to avoid changes unless they clearly > enhance the spec. > > > In the case you are taking about here, I have no idea what the right line is > > and I'm not supporting Lisa's or Julian's or anyone else opinion on it. I'm > > just pointing out that this is not black or white but is one of the many > > things where the WG will have to find some sort of reasonable balance. > > Back to this issue: > > 1) I'm not aware of any interop problems. > > 2) I'm not aware of anybody having asked about this. > > 3) I don't see any benefit in RFC2518bis making statements about this, > even if we *did* agree on what to say. > > Best regards, Julian > --=_alternative 004C4B92852570A7_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian's points, and would add that there is significant
experience that shows that these "helpful hints" can end up being the
greatest source of implementation confusion.  A prime example is the
the suggestion that "MOVE" be thought of as a "COPY followed by a DELETE".
People confuse these hints with normative text, and then base their
implementations on these hints rather than on the normative text.
So it is not enough to say "would this text answer this particular question",
but also have to check "can this text be misinterpreted in a way that
conflicts with the normative text".  And if the spec is already very long,
each new paragraph introduces the chance that reader fatigue will prevent
them from ever getting to the normative text, because of the amount of
intervening non-normative text.

Cheers,
Geoff

Julian wrote on 10/27/2005 08:48:51 AM:

>
> Cullen Jennings wrote:
> > ...
> > There is a fine line here. Someone skill in the art should be able to
> > correctly implement this by just reading the Spec and the documents it
> > normatively references. That does not mean we should right a basic tutorial
> > on how it all works or the sort of material that might be covered in WebDAV
> > book. It's a fine line to draw, but I tend to ask myself, if your average
> > implementer has a 20% chance of doing the wrong thing, you probably need
> > more advice or notes to keep them on the right path.
>
> a) Yes, but...:
>
> b) Even if it's not about RFC2518 itself, but a normatively referenced
> spec? That is, do explanations/clarifications for HTTP belong into
> RFC2518bis, or RFC2616bis?
>
> > That is my somewhat philosophic answer, however, I have a far morepragmatic
> > thing you should keep in mind. The IESG has to read this, and if it makes no
> > sense to them, pain and suffering will ensue. This does not mean just the
> > apps ADs with an amazing background in the area has to read it, it means
> > that someone from a completely different area (say security) has to read it,
> > and understand it well enough to evaluate if it has significant issues. And
> > they are unlikely to read FAQs, Blogs etc because they are too busy.
>
> Yes, and if information is *needed*, it should be in the spec.
>
> On the other hand, we're revising a spec that already has been accepted
> once. I would think it would make a lot of sense to keep changes to the
> minimum needed to achieve our goals. As a matter of fact, RFC2518 has
> had more contributors and reviewers than we can ever hope to find for
> RFC2518bis, so my proposal is to avoid changes unless they clearly
> enhance the spec.
>
> > In the case you are taking about here, I have no idea what the right line is
> > and I'm not supporting Lisa's or Julian's or anyone else opinion on it. I'm
> > just pointing out that this is not black or white but is one of the many
> > things where the WG will have to find some sort of reasonable balance.
>
> Back to this issue:
>
> 1) I'm not aware of any interop problems.
>
> 2) I'm not aware of anybody having asked about this.
>
> 3) I don't see any benefit in RFC2518bis making statements about this,
> even if we *did* agree on what to say.
>
> Best regards, Julian
>
--=_alternative 004C4B92852570A7_=-- From w3c-dist-auth-request@frink.w3.org Thu Oct 27 13:05:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBBc-0005NU-S9 for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:05:09 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15804 for ; Thu, 27 Oct 2005 13:04:51 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVB9h-0005pB-QC for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 17:03:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVB9e-0005od-TS for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 17:03:07 +0000 Received: from mail27.sea5.speakeasy.net ([69.17.117.29]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVB9X-0008RB-9p for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 17:03:06 +0000 Received: (qmail 26560 invoked from network); 27 Oct 2005 17:02:55 -0000 Received: from dsl081-070-219.sfo1.dsl.speakeasy.net (HELO cse.ucsc.edu) (elias@[64.81.70.219]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 17:02:55 -0000 Message-ID: <4361083D.3040507@cse.ucsc.edu> Date: Thu, 27 Oct 2005 10:02:53 -0700 From: Elias Sinderson User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510152337.j9FNbOgl001456@ietf.cse.ucsc.edu> In-Reply-To: <200510152337.j9FNbOgl001456@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=us-ascii; 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=-1.8 X-W3C-Scan-Sig: maggie.w3.org 1EVB9X-0008RB-9p d1ab9a43c7f4236dd4c9fa7dcbf60e40 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/4361083D.3040507@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10201 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 17:03:09 +0000 Content-Transfer-Encoding: 7bit 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. Cheers, Elias From w3c-dist-auth-request@frink.w3.org Thu Oct 27 13:22:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBSd-00055B-8f for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:22:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16961 for ; Thu, 27 Oct 2005 13:22:25 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVBRq-0001jZ-Pj for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 17:21:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVBRn-0001it-H6 for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 17:21:51 +0000 Received: from mail25.sea5.speakeasy.net ([69.17.117.27]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVBRe-0003sT-FP for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 17:21:51 +0000 Received: (qmail 25299 invoked from network); 27 Oct 2005 17:21:39 -0000 Received: from dsl081-070-219.sfo1.dsl.speakeasy.net (HELO cse.ucsc.edu) (elias@[64.81.70.219]) (envelope-sender ) by mail25.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 17:21:39 -0000 Message-ID: <43610CA0.608@cse.ucsc.edu> Date: Thu, 27 Oct 2005 10:21:36 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510251633.j9PGXwfs017220@ietf.cse.ucsc.edu> In-Reply-To: <200510251633.j9PGXwfs017220@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=us-ascii; 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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1EVBRe-0003sT-FP 98bd9f6acd6fdeebf37b0845c6082ff6 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/43610CA0.608@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10202 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 17:21:54 +0000 Content-Transfer-Encoding: 7bit As discussed in todays conference call, this text will be moved to an appendix. Best, Elias bugzilla@soe.ucsc.edu wrote: >http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172 >------- Additional Comments From julian.reschke@greenbytes.de 2005-10-25 09:33 ------- >The postfix notation of the "opaquelocktoken" scheme allows more freedom in >generating URIs than "urn:uuid". For instance, a server that internally uses a >simple string-typed (or numeric) lock identifiers can generate "opaquelocktoken" >URIs by simply appending the internal identifier to a single, fixed UUID. In >absence of that feature, it would need an additional lookup table to map >internals IDs to UUIDs. > >So, no, "urn:uuid" can't be considered to "obsolete" the "opaquelocktoken" URI >scheme. > >On the other hand, what do we gain from removing the scheme definition? >Simplifying (delegating most of the definitin to the URN:UUID spec) is a good >idea, but removing doesn't seem to be attractive to me. > From w3c-dist-auth-request@frink.w3.org Thu Oct 27 13:48:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBrs-0003ed-Oi for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:48:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18321 for ; Thu, 27 Oct 2005 13:48:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVBr2-0000IV-HH for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 17:47:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVBr2-0000Hs-5B for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 17:47:56 +0000 Received: from mail21.sea5.speakeasy.net ([69.17.117.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVBqv-0007qo-3i for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 17:47:55 +0000 Received: (qmail 24743 invoked from network); 27 Oct 2005 17:47:47 -0000 Received: from dsl081-070-219.sfo1.dsl.speakeasy.net (HELO cse.ucsc.edu) (elias@[64.81.70.219]) (envelope-sender ) by mail21.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 17:47:47 -0000 Message-ID: <436112C1.1050605@cse.ucsc.edu> Date: Thu, 27 Oct 2005 10:47:45 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510131735.j9DHZO5N009338@ietf.cse.ucsc.edu> In-Reply-To: <200510131735.j9DHZO5N009338@ietf.cse.ucsc.edu> 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 1EVBqv-0007qo-3i 36e43538091796659418fb460f67cda2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 14] new requirements on ETags vs property changes X-Archived-At: http://www.w3.org/mid/436112C1.1050605@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10204 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 17:47:56 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: >http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 > Definately a major issue... :-) Summary notes from todays conference call: There are currently servers which both DO and DO NOT change ETags on property changes, hence there is a risk in obsoleting existing implementations regardless of the path the WG takes on this issue. Further, there are clear disadvantages to distributed authoring clients if an ETag changes due to a property update, without the resource body changing. Jim suggests introducing PTag for property changes, and I agree this would be useful, however introducing this into a revision of an existing spec will create problems. Julian suggests that this would belong in a seperate specification. Rough concensus reached to use SHOULD NOT with respect to changing ETags on property changes - Lisa to make edit... Hope this captured the gist of the conversation, please feel free to add anything that may be useful. Best, Elias From w3c-dist-auth-request@frink.w3.org Thu Oct 27 13:48:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBrs-0003ee-Ok for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:48:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18320 for ; Thu, 27 Oct 2005 13:48:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVBqw-0000H7-Dj for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 17:47:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVBqt-0000G1-F3 for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 17:47:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVBqo-0000Ne-GL for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 17:47:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9RHleG4019928; Thu, 27 Oct 2005 10:47:40 -0700 Date: Thu, 27 Oct 2005 10:47:40 -0700 Message-Id: <200510271747.j9RHleG4019928@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EVBqo-0000Ne-GL 4f51a9803554bf1b8829c8f6f7ca09c5 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/200510271747.j9RHleG4019928@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10203 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 17:47:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From lisa@osafoundation.org 2005-10-27 10:47 ------- Next action proposed on phone conference October 27 (Julian, Jim, Elias, Cullen, Lisa): servers SHOULD NOT change the ETag of a resource only because the dead properties have been changed. This is basically a change from the 07 version of the spec replacing MUST NOT with SHOULD NOT, thus relaxing the requirement, but compared to RFC2518 this is a strengthened or added requirement. ------- 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 Oct 27 13:57:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVC0G-00059T-NQ for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:57:28 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18791 for ; Thu, 27 Oct 2005 13:57:11 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVBzW-0001ff-Ge for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 17:56:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVBzW-0001f0-68 for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 17:56:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVBzN-0001ea-Tw for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 17:56:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9RHuXYl019948; Thu, 27 Oct 2005 10:56:33 -0700 Date: Thu, 27 Oct 2005 10:56:33 -0700 Message-Id: <200510271756.j9RHuXYl019948@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 1EVBzN-0001ea-Tw 502832f662b7c17d5ffb1478c797f175 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/200510271756.j9RHuXYl019948@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10205 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 17:56:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=14 lisa@osafoundation.org 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 Thu Oct 27 13:58:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVC1a-0005Dy-TG for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:58:51 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18882 for ; Thu, 27 Oct 2005 13:58:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVC0x-0001p5-VN for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 17:58:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVC0x-0001oX-KB for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 17:58:11 +0000 Received: from mail27.sea5.speakeasy.net ([69.17.117.29]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVC0s-00021b-Vh for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 17:58:11 +0000 Received: (qmail 29672 invoked from network); 27 Oct 2005 17:58:05 -0000 Received: from dsl081-070-219.sfo1.dsl.speakeasy.net (HELO cse.ucsc.edu) (elias@[64.81.70.219]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 17:58:05 -0000 Message-ID: <4361152A.5030403@cse.ucsc.edu> Date: Thu, 27 Oct 2005 10:58:02 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> In-Reply-To: <43514FBF.9040502@gmx.de> 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 1EVC0s-00021b-Vh 93a14e71e011285b879c7648dc19bb7d 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/4361152A.5030403@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10206 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 17:58:11 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > 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. I have no issues with the proposed text. Cheers, Elias From w3c-dist-auth-request@frink.w3.org Thu Oct 27 14:08:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCAg-0007kF-9U for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 14:08:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19570 for ; Thu, 27 Oct 2005 14:07:57 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVC9Y-0004VB-Re for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 18:07:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVC9X-0004Ud-8s for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 18:07:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVC9Q-0004EL-VR for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 18:07:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9RI6tJX019996; Thu, 27 Oct 2005 11:06:55 -0700 Date: Thu, 27 Oct 2005 11:06:55 -0700 Message-Id: <200510271806.j9RI6tJX019996@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EVC9Q-0004EL-VR 306c6654a0c13dbf3760fa0ae3b925b1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/200510271806.j9RI6tJX019996@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10207 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 18:07:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=17 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-10-27 11:06 ------- On the understanding that when we've agreed on text or text changes, we resolve bugs as "fixed", I'm resolving 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 Thu Oct 27 14:21:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCN1-0004PD-1L for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 14:21:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20445 for ; Thu, 27 Oct 2005 14:20:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVCMG-0008PZ-5K for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 18:20:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVCMF-0008Ow-PX for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 18:20:11 +0000 Received: from mail21.sea5.speakeasy.net ([69.17.117.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVCM8-0000zl-Po for w3c-dist-auth@w3c.org; Thu, 27 Oct 2005 18:20:11 +0000 Received: (qmail 30253 invoked from network); 27 Oct 2005 18:19:03 -0000 Received: from dsl081-070-219.sfo1.dsl.speakeasy.net (HELO cse.ucsc.edu) (elias@[64.81.70.219]) (envelope-sender ) by mail21.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 18:19:03 -0000 Message-ID: <43611A14.1050101@cse.ucsc.edu> Date: Thu, 27 Oct 2005 11:19:00 -0700 From: Elias Sinderson Reply-To: Webdav WG User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Webdav WG Content-Type: text/plain; charset=us-ascii; 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 1EVCM8-0000zl-Po a2c733f8d7c7a3630a1b17d4d841e494 X-Original-To: w3c-dist-auth@w3.org Subject: on our bug tracking (and closing) process X-Archived-At: http://www.w3.org/mid/43611A14.1050101@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10208 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 18:20:12 +0000 Content-Transfer-Encoding: 7bit I believe the following captures our most recent discussion on the meaning of a bugs status. NEW: The bug is new. ASSIGNED: The assigned person will take point on proposing new text. RESOLVED: The WG has reached rough concensus on a proposed change. Note that the type of resolution (e.g. FIXED, INVALID...) is NOT being used to indicate anything presently, as the available options don't seem to fit our process very well. VERIFIED: The text has been verified as included in the current revision of draft (published to webdav.org). The status will be changed to by the verifier. CLOSED: The latest draft, including the agreed upon text, has been submitted to IETF. We will look into modifying the available types of resolutions so that they may more closely reflect our process... Best, Elias From w3c-dist-auth-request@frink.w3.org Thu Oct 27 14:21:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCNx-0005V2-Bw for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 14:21:57 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20541 for ; Thu, 27 Oct 2005 14:21:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVCNL-0000Bj-PV for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 18:21:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVCNL-0000BB-6Y for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 18:21:19 +0000 Received: from mail22.sea5.speakeasy.net ([69.17.117.24]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVCNC-0001KW-5w for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 18:21:19 +0000 Received: (qmail 4984 invoked from network); 27 Oct 2005 18:21:06 -0000 Received: from dsl081-070-219.sfo1.dsl.speakeasy.net (HELO cse.ucsc.edu) (elias@[64.81.70.219]) (envelope-sender ) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 18:21:06 -0000 Message-ID: <43611A8F.5060001@cse.ucsc.edu> Date: Thu, 27 Oct 2005 11:21:03 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200510152320.j9FNKVOH000349@ietf.cse.ucsc.edu> <435273A0.9080902@gmx.de> In-Reply-To: <435273A0.9080902@gmx.de> 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 1EVCNC-0001KW-5w be9209f4588279e185e4fe3c2b0cb6b6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/43611A8F.5060001@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10209 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 18:21:19 +0000 Content-Transfer-Encoding: 7bit I am okay with the change, below. Best, Elias Julian Reschke wrote: > For the record, the change is: > Section 8., para. 61: > OLD: > 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 schema. > > NEW: > 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. From w3c-dist-auth-request@frink.w3.org Thu Oct 27 19:42:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHNn-0000VQ-6Y for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 19:42:07 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27545 for ; Thu, 27 Oct 2005 19:41:49 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVHML-00018F-7u for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 23:40:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVHMI-00017h-KN for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 23:40:34 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVHMA-0007ZL-TC for w3c-dist-auth@w3c.org; Thu, 27 Oct 2005 23:40:34 +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 j9RNWt8s001503 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 27 Oct 2005 16:32:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <43611A14.1050101@cse.ucsc.edu> References: <43611A14.1050101@cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Thu, 27 Oct 2005 16:33:45 -0700 To: Webdav WG X-Mailer: Apple Mail (2.734) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.1 X-W3C-Scan-Sig: lisa.w3.org 1EVHMA-0007ZL-TC 8f62eab731b7bce839d0dfeebe2d1c0a X-Original-To: w3c-dist-auth@w3.org Subject: Re: on our bug tracking (and closing) process X-Archived-At: http://www.w3.org/mid/CBBCD187-9581-47A9-883C-43EDF32952B5@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10210 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 23:40:37 +0000 Content-Transfer-Encoding: 7bit Elias, This sounds good to me. Only two tweaks * we had agreed that the new text proposals would be to the list, and not within Bugzilla * we had agreed that anyone can perform the verification task (except the editor who made the change) - Jim On Oct 27, 2005, at 11:19 AM, Elias Sinderson wrote: > > I believe the following captures our most recent discussion on the > meaning of a bugs status. > > NEW: The bug is new. > ASSIGNED: The assigned person will take point on proposing new text. > RESOLVED: The WG has reached rough concensus on a proposed change. > Note that the type of resolution (e.g. FIXED, INVALID...) is NOT > being used to indicate anything presently, as the available options > don't seem to fit our process very well. > VERIFIED: The text has been verified as included in the current > revision of draft (published to webdav.org). The status will be > changed to by the verifier. > CLOSED: The latest draft, including the agreed upon text, has been > submitted to IETF. > > We will look into modifying the available types of resolutions so > that they may more closely reflect our process... > > > Best, > Elias > From w3c-dist-auth-request@frink.w3.org Thu Oct 27 19:50:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHVb-0004ui-Aj for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 19:50:11 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27952 for ; Thu, 27 Oct 2005 19:49:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVHUv-0003OX-GT for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Oct 2005 23:49:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVHUv-0003Nz-2Y for w3c-dist-auth@listhub.w3.org; Thu, 27 Oct 2005 23:49:29 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVHUp-0005zI-SG for w3c-dist-auth@w3.org; Thu, 27 Oct 2005 23:49:28 +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 j9RNnGHt007057 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Oct 2005 16:49:16 -0700 (PDT) In-Reply-To: <4360CCB3.7060000@gmx.de> References: <4360CCB3.7060000@gmx.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <241D50DF-8CB0-40BE-AF22-409E615873E5@cs.ucsc.edu> Cc: WebDav Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Thu, 27 Oct 2005 16:50:06 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.734) 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.0 X-W3C-Scan-Sig: maggie.w3.org 1EVHUp-0005zI-SG 58d5991396ff6d3c37525cafdf86e5d8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/241D50DF-8CB0-40BE-AF22-409E615873E5@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10211 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Oct 2005 23:49:29 +0000 Content-Transfer-Encoding: 7bit > Julian writes: > Back to this issue: > > 1) I'm not aware of any interop problems. > > 2) I'm not aware of anybody having asked about this. > > 3) I don't see any benefit in RFC2518bis making statements about > this, even if we *did* agree on what to say I have just read through this entire thread, and I agree with his statement above, and the conclusion Julian reached in: http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html Specifically: * I don't think there is a compelling need to disallow Location and 207 * I don't think we need any special mechanism for handling 3xx within a PROPFIND * I think it's fine if a client needs to retry a PROPFIND request if it receives a 3xx response I feel a slight desire to add a 3xx response to one of the PROPFIND 207 response examples in the text, but could live without it. Unless others chime in, I think we're seeing rough consensus for removing the current 8.1.3, whose text is described in Bug 12 within Bugzilla: http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 - Jim From w3c-dist-auth-request@frink.w3.org Thu Oct 27 20:34:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVICp-0006LD-Mk for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 20:34:51 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05572 for ; Thu, 27 Oct 2005 20:34:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVIBy-00039p-9x for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 00:33:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVIBw-000399-0S for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 00:33:56 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVIBs-0001EB-Ue for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 00:33:55 +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 j9S0Xm6X023526 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Oct 2005 17:33:49 -0700 (PDT) In-Reply-To: <43557ADF.2070801@gmx.de> References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> <43557ADF.2070801@gmx.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: WebDav Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Thu, 27 Oct 2005 17:34:39 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.734) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.1 X-W3C-Scan-Sig: lisa.w3.org 1EVIBs-0001EB-Ue c62fed2882a8d895751ab42d88c51619 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/EEF622B6-064A-4EC9-8C6C-548AD9734197@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10212 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 00:33:58 +0000 Content-Transfer-Encoding: 7bit > Julian writes: > So this is a process issue -- if it's supposed to become part of > WebDAV, it has to make it through the process of (1) define what > the problem is, then (2) find a WG consensus of how to resolve > this. "Force-Authenticate" may very well be the solution. OK, I feel pretty strongly about this feature, so let me do the due diligence here. PROBLEM STATEMENT Some WebDAV servers are configured to allow live authoring, where the authored changes are immediately visible to the external world. In this situation, resources typically have access controls set such that GET, HEAD, POST, PROPFIND and OPTIONS can be performed by any user without authentication. Write operations such as PUT, LOCK, UNLOCK, MKCOL, MOVE, and COPY require authentication and access permissions. In some cases, a client would do a series of operations that do not require authentication, then perform a PUT of a large resource (this can happen with the common Microsoft Web Folders client). In this situation, the large resource body needs to be sent twice: the initial PUT (which gets a 401 response), and the second PUT, with authentication credentials. Ideally, a client would like to test a resource to see whether it should ever send authentication credentials. It is far more convenient for a client author to make a single test at the beginning of a session, discover that some methods will require authentication credentials, and then consistently supply those authentication credentials for every method invocation thereafter. Since a client does not know which authentication scheme is in use, or what nonce values will be used in Digest Auth, it cannot speculatively provide authentication values without receiving a challenge (401) from the server first. While in general it is the case that authentication requirements can vary by method, even on the same resource, this configuration is extremely unusual. Hence, a client that proactively supplies a set of authentication credentials gathered from testing one method that requires authentication (PUT, say), will likely find that these same authentication credentials will work for all other methods (LOCK, UNLOCK, etc.) on the same resource that also require authentication. SOLUTION REQUIREMENTS R1: A client must be able to request an authentication challenge without causing a state change on the server R2: The mechanism for the authentication challenge must be clearly identifiable within the specification R3: The client must be able to indicate which method the challenge pertains to (since this can potentially vary by method, though it usually doesn't) SOLUTION PROPOSAL I like the Force-Authenticate header as defined in the current draft. I don't like the If approach (submit an If header with a known bad lock token, hence the method will fail) for three reasons: * I feel uncomfortable depending on an unintended use of the If header -- especially for PUT, if a server ever doesn't handle If correctly, the forcing of authentication could inadvertently change the contents of the resource (assuming you'd force authentication with a zero length body with PUT) * It depends on the execution order of authentication vs. If header processing within servers (I note this was rebutted in: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ 0335.html and I also note that mod_dav does do authentication checks before If checks) * It's a really obscure way of satisfying the requirements (i.e., it fails requirement R2) My strong preference is for a new mechanism here (Force- Authenticate), though I could perhaps be swayed to adding a new section to the specification that explicitly describes the use of If to force authentication, and gives an example of how this works. I don't think this mechanism is one that most implementors would think of, even if the have a deep understanding of the spec (like, me, for example, who never thought of this). - Jim From w3c-dist-auth-request@frink.w3.org Thu Oct 27 23:19:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKlr-0008IE-5j for webdav-archive@megatron.ietf.org; Thu, 27 Oct 2005 23:19:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15146 for ; Thu, 27 Oct 2005 23:18:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVKkM-0008QZ-W2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 03:17:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVKkJ-0008Pe-S5; Fri, 28 Oct 2005 03:17:35 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVKkG-00006O-Te; Fri, 28 Oct 2005 03:17:35 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9S3HVDJ013407; Thu, 27 Oct 2005 23:17:31 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9S3HVl1102572; Thu, 27 Oct 2005 23:17:31 -0400 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 j9S3HVoS018830; Thu, 27 Oct 2005 23:17:31 -0400 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 j9S3HVkZ018825; Thu, 27 Oct 2005 23:17:31 -0400 In-Reply-To: <241D50DF-8CB0-40BE-AF22-409E615873E5@cs.ucsc.edu> To: Jim Whitehead Cc: Julian Reschke , 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, 27 Oct 2005 23:17:26 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/27/2005 23:17:30, Serialize complete at 10/27/2005 23:17:30 Content-Type: multipart/alternative; boundary="=_alternative 0012154C852570A8_=" Received-SPF: pass (lisa.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.4 X-W3C-Scan-Sig: lisa.w3.org 1EVKkG-00006O-Te ed920c14c11c120b430fc33ec53fcfd0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/OF9CD702BA.994F8F7D-ON852570A8.0012112A-852570A8.00121598@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10213 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 03:17:38 +0000 This is a multipart message in MIME format. --=_alternative 0012154C852570A8_= Content-Type: text/plain; charset="US-ASCII" +1 w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM: > > > > > Julian writes: > > Back to this issue: > > > > 1) I'm not aware of any interop problems. > > > > 2) I'm not aware of anybody having asked about this. > > > > 3) I don't see any benefit in RFC2518bis making statements about > > this, even if we *did* agree on what to say > > I have just read through this entire thread, and I agree with his > statement above, and the conclusion Julian reached in: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html > > Specifically: > > * I don't think there is a compelling need to disallow Location and 207 > * I don't think we need any special mechanism for handling 3xx within > a PROPFIND > * I think it's fine if a client needs to retry a PROPFIND request if > it receives a 3xx response > > I feel a slight desire to add a 3xx response to one of the PROPFIND > 207 response examples in the text, but could live without it. > > Unless others chime in, I think we're seeing rough consensus for > removing the current 8.1.3, whose text is described in Bug 12 within > Bugzilla: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 > > - Jim > > > > --=_alternative 0012154C852570A8_= Content-Type: text/html; charset="US-ASCII"
+1

w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM:

>
> >
>
> Julian writes:
> > Back to this issue:
> >
> > 1) I'm not aware of any interop problems.
> >
> > 2) I'm not aware of anybody having asked about this.
> >
> > 3) I don't see any benefit in RFC2518bis making statements about  
> > this, even if we *did* agree on what to say
>
> I have just read through this entire thread, and I agree with his  
> statement above, and the conclusion Julian reached in:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html
>
> Specifically:
>
> * I don't think there is a compelling need to disallow Location and 207
> * I don't think we need any special mechanism for handling 3xx within  
> a PROPFIND
> * I think it's fine if a client needs to retry a PROPFIND request if  
> it receives a 3xx response
>
> I feel a slight desire to add a 3xx response to one of the PROPFIND  
> 207 response examples in the text, but could live without it.
>
> Unless others chime in, I think we're seeing rough consensus for  
> removing the current 8.1.3, whose text is described in Bug 12 within  
> Bugzilla:
> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12
>
> - Jim
>
>
>
>
--=_alternative 0012154C852570A8_=-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 03:53:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVP32-0000NU-Fb for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 03:53:13 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29430 for ; Fri, 28 Oct 2005 03:52:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVP18-0004PM-HL for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 07:51:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVP15-0004Oj-KV for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 07:51:11 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EVP0z-0004hn-5V for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 07:51:08 +0000 Received: (qmail invoked by alias); 28 Oct 2005 07:51:00 -0000 Received: from p508FB051.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.176.81] by mail.gmx.net (mp013) with SMTP; 28 Oct 2005 09:51:00 +0200 X-Authenticated: #1915285 Message-ID: <4361D852.3010501@gmx.de> Date: Fri, 28 Oct 2005 09:50:42 +0200 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: w3c-dist-auth@w3.org References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> <4354D63B.5050201@gmx.de> <435A8C00.90709@gmx.de> <435DCD5D.1020704@gmx.de> In-Reply-To: <435DCD5D.1020704@gmx.de> 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 1EVP0z-0004hn-5V 4d385d8bbe136b9d243e67b762902895 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/4361D852.3010501@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10214 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 07:51:14 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Lisa Dusseault wrote: > >> >> Ok, I've fixed all the non-ASCII characters I was aware of. I haven't >> found a very good way to ensure those don't sneak in again but I'm >> sure you'll alert me if they do. >> >> Lisa > > > The way to check is to run it through a compliant XML parser. There > really should be one on your system. > > There are two other things that keep me from using this file: > > - metadata should be updated so that people know they're not looking at > draft -07 (docName attribute and date element) > > - xml2rfc rejects the document because of the "strict" mode that is > selected (because of artwork being too wide) -- please either fix the > artwork, or relax the "strict" requirement for now. > > Best regards, Julian Lisa, any chance that you could fix that? This is the one thing that stops me from auto-generating TXT, HTML and diffs on our web site. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Oct 28 09:50:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUcl-00045F-Tm for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 09:50:29 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15801 for ; Fri, 28 Oct 2005 09:50:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVUar-0005RA-4p for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 13:48:29 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVUan-0005Qc-HQ for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 13:48:25 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EVUad-00078h-7o for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 13:48:24 +0000 Received: (qmail invoked by alias); 28 Oct 2005 13:48:05 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 28 Oct 2005 15:48:05 +0200 X-Authenticated: #1915285 Message-ID: <43622BEF.3060706@gmx.de> Date: Fri, 28 Oct 2005 15:47:27 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: WebDav References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> <43557ADF.2070801@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 (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 1EVUad-00078h-7o d909a57cc2ce195693211b6d9f569f98 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/43622BEF.3060706@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10215 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 13:48:29 +0000 Content-Transfer-Encoding: 7bit Jim, thanks for doing the "right thing" here. Comments inline. Jim Whitehead wrote: > ... > SOLUTION REQUIREMENTS > > R1: A client must be able to request an authentication challenge > without causing a state change on the server > R2: The mechanism for the authentication challenge must be clearly > identifiable within the specification > R3: The client must be able to indicate which method the challenge > pertains to (since this can potentially vary by method, though it > usually doesn't) > > SOLUTION PROPOSAL > > I like the Force-Authenticate header as defined in the current draft. I > don't like the If approach (submit an If header with a known bad lock > token, hence the method will fail) for three reasons: > > * I feel uncomfortable depending on an unintended use of the If header > -- especially for PUT, if a server ever doesn't handle If correctly, > the forcing of authentication could inadvertently change the contents > of the resource (assuming you'd force authentication with a zero length > body with PUT) I don't feel that we should add new features to the spec just because we fear that some servers may not get the existing stuff right. I a server doesn't handle the If header correctly upon PUT, this is a bug that needs to be fixed anyway. As a matter of fact, of the servers I recently tested (), two were failing here, one of which not doing "If" checks at all, the other one treating unknown state tokens incorrectly. The latter is moddav, the bug is reported in , and Joe Orton has already attached a proposed patch. The other servers (SAP Netweaver, Xythos, MS IIS) work as expected. > * It depends on the execution order of authentication vs. If header > processing within servers (I note this was rebutted in: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ 0335.html > and I also note that mod_dav does do authentication checks before If > checks) Yep. Is anybody aware of servers working differently. > * It's a really obscure way of satisfying the requirements (i.e., it > fails requirement R2) That can be fixed by putting that as note into an appendix. > My strong preference is for a new mechanism here (Force- Authenticate), > though I could perhaps be swayed to adding a new section to the > specification that explicitly describes the use of If to force > authentication, and gives an example of how this works. I don't think > this mechanism is one that most implementors would think of, even if > the have a deep understanding of the spec (like, me, for example, who > never thought of this). I have no problem adding non-normative text explaining this. On the other hand I'd really like to hear from those client implementors. After the three years ago, did anybody actually try the solution proposed back then? If not, why not? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Oct 28 13:35:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVY8h-0007h7-Br for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 13:35:40 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29984 for ; Fri, 28 Oct 2005 13:35:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVY7K-0004YL-Rr for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 17:34:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVY7H-0004Xn-St for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 17:34:11 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVY7A-0006xI-8x for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 17:34:11 +0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j9SHXxAh015665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Oct 2005 10:33:59 -0700 Received: from [192.168.1.6] (vpn-10-50-0-74.qualcomm.com [10.50.0.74]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j9SHXuld000674 for ; Fri, 28 Oct 2005 10:33:57 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Fri, 28 Oct 2005 10:33:55 -0700 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 1EVY7A-0006xI-8x 598d96b1ed43fd533856f4bd977c39ab X-Original-To: w3c-dist-auth@w3.org Subject: URI scheme removal/permanence X-Archived-At: http://www.w3.org/mid/p06230902bf88103edee6@%5B192.168.1.6%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10216 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 17:34:14 +0000 The IESG just approved draft-hansen-2717bis-2718bis-uri-guidelines on the telechat yesterday. As you'll note when reading it, URI schemes published in standards track RFCs will be in the "permanent" registry; an update may be later undertaken to move them to "historic", but this requires a specific action and approval by the IESG (moves from "provisional" to "historic" are simpler). There are a number of typos in the -06 version, I have to admit, so read it with the RFC editor note. There was a published -07, but it was withdrawn as approval of the -06+RFC Editor Note had already been given. Ted From w3c-dist-auth-request@frink.w3.org Fri Oct 28 13:48:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYLP-0005zB-EK for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 13:48:47 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00592 for ; Fri, 28 Oct 2005 13:48:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVYKh-0001L8-5u for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 17:48:03 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVYKd-0001Ka-UE for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 17:48:00 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EVYKV-0006oM-Nm for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 17:47:58 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 29648142287; Fri, 28 Oct 2005 10:47:49 -0700 (PDT) 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 25208-08; Fri, 28 Oct 2005 10:47:48 -0700 (PDT) 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 AF84F142285; Fri, 28 Oct 2005 10:47:24 -0700 (PDT) In-Reply-To: <4361D852.3010501@gmx.de> References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> <4354D63B.5050201@gmx.de> <435A8C00.90709@gmx.de> <435DCD5D.1020704@gmx.de> <4361D852.3010501@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2e730b30844ecb2d74d323ab19d4b6a2@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Fri, 28 Oct 2005 10:47:03 -0700 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 1EVYKV-0006oM-Nm a88fac805f2118c2332b9f8978595a0b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/2e730b30844ecb2d74d323ab19d4b6a2@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10217 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 17:48:03 +0000 Content-Transfer-Encoding: 7bit Let me know if the version I uploaded today fixes the "strict" mode thing, i'm not sure I understand the problem there as I've had no trouble having xml2rfc run on the document (the version on the xml.resource.org site is the one I use) lisa On Oct 28, 2005, at 12:50 AM, Julian Reschke wrote: > Julian Reschke wrote: >> Lisa Dusseault wrote: >>> >>> Ok, I've fixed all the non-ASCII characters I was aware of. I >>> haven't found a very good way to ensure those don't sneak in again >>> but I'm sure you'll alert me if they do. >>> >>> Lisa >> The way to check is to run it through a compliant XML parser. There >> really should be one on your system. >> There are two other things that keep me from using this file: >> - metadata should be updated so that people know they're not looking >> at draft -07 (docName attribute and date element) >> - xml2rfc rejects the document because of the "strict" mode that is >> selected (because of artwork being too wide) -- please either fix the >> artwork, or relax the "strict" requirement for now. >> Best regards, Julian > > Lisa, > > any chance that you could fix that? This is the one thing that stops > me from auto-generating TXT, HTML and diffs on our web site. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Oct 28 14:19:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYp0-0001lm-Rk for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 14:19:23 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01742 for ; Fri, 28 Oct 2005 14:19:04 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVYo3-0008HZ-Mo for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 18:18:23 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVYo0-0008Gw-Cw for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 18:18:20 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EVYnx-0004q3-17 for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 18:18:19 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j9SIIFo5002498 for ; Fri, 28 Oct 2005 11:18:15 -0700 (PDT) Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay6.apple.com (Apple SCV relay) with ESMTP id E99ED1C1 for ; Fri, 28 Oct 2005 11:18:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43622BEF.3060706@gmx.de> References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> <43557ADF.2070801@gmx.de> <43622BEF.3060706@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D960D23-AC57-45E8-9113-1B16E6270DD4@apple.com> Content-Transfer-Encoding: 7bit From: Jim Luther Date: Fri, 28 Oct 2005 11:18:25 -0700 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 1EVYnx-0004q3-17 d3aab5c936ee19c56a7b59776ba7beb6 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/7D960D23-AC57-45E8-9113-1B16E6270DD4@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10218 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 18:18:23 +0000 Content-Transfer-Encoding: 7bit On Oct 28, 2005, at 6:47 AM, Julian Reschke wrote: > > Jim, > > thanks for doing the "right thing" here. Comments inline. > > Jim Whitehead wrote: >> ... >> SOLUTION REQUIREMENTS >> R1: A client must be able to request an authentication challenge >> without causing a state change on the server >> R2: The mechanism for the authentication challenge must be >> clearly identifiable within the specification >> R3: The client must be able to indicate which method the >> challenge pertains to (since this can potentially vary by method, >> though it usually doesn't) >> SOLUTION PROPOSAL >> I like the Force-Authenticate header as defined in the current >> draft. I don't like the If approach (submit an If header with a >> known bad lock token, hence the method will fail) for three reasons: >> * I feel uncomfortable depending on an unintended use of the If >> header -- especially for PUT, if a server ever doesn't handle If >> correctly, the forcing of authentication could inadvertently >> change the contents of the resource (assuming you'd force >> authentication with a zero length body with PUT) > > I don't feel that we should add new features to the spec just > because we fear that some servers may not get the existing stuff > right. I a server doesn't handle the If header correctly upon PUT, > this is a bug that needs to be fixed anyway. > > As a matter of fact, of the servers I recently tested ( lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0328.html>), > two were failing here, one of which not doing "If" checks at all, > the other one treating unknown state tokens incorrectly. The latter > is moddav, the bug is reported in bugzilla/show_bug.cgi?id=37288>, and Joe Orton has already attached > a proposed patch. > > The other servers (SAP Netweaver, Xythos, MS IIS) work as expected. > >> * It depends on the execution order of authentication vs. If >> header processing within servers (I note this was rebutted in: >> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ >> 0335.html and I also note that mod_dav does do authentication >> checks before If checks) > > Yep. Is anybody aware of servers working differently. > >> * It's a really obscure way of satisfying the requirements (i.e., >> it fails requirement R2) > > That can be fixed by putting that as note into an appendix. > >> My strong preference is for a new mechanism here (Force- >> Authenticate), though I could perhaps be swayed to adding a new >> section to the specification that explicitly describes the use of >> If to force authentication, and gives an example of how this >> works. I don't think this mechanism is one that most implementors >> would think of, even if the have a deep understanding of the spec >> (like, me, for example, who never thought of this). > > I have no problem adding non-normative text explaining this. > > On the other hand I'd really like to hear from those client > implementors. After the three years ago, did anybody actually try > the solution proposed back then? If not, why not? > > Best regards, Julian > On the other hand I'd really like to hear from those client > implementors. After the three years ago, did anybody actually try > the solution proposed back then? No, we didn't try it. The Mac OS X WebDAV file system handles challenges as it gets them and uses the protection space/domain rules in rfc2617 to determine when the credentials should be sent with a transaction. > If not, why not? Unlike some other clients, Mac OS X WebDAV file system always takes a LOCK on a resource when the file (resource) is opened with write access (and if LOCKs are not supported by the server, its a read-only mount for us). In addition, when the Mac OS X WebDAV file system is told to create a file that doesn't exist, it issues a PUT with a content-length of 0 to create an empty resource on the server (thus reserving the name space). Since both of those operations generate a challenge, we don't have the problem this bug is trying to solve. - Jim From w3c-dist-auth-request@frink.w3.org Fri Oct 28 15:02:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZUU-0003fR-Le for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 15:02:14 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03366 for ; Fri, 28 Oct 2005 15:01:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVZTE-00009W-N4 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 19:00:56 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVZT6-0008OW-JO for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 19:00:48 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EVZT2-0004Yz-CO for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 19:00:47 +0000 Received: (qmail invoked by alias); 28 Oct 2005 19:00:38 -0000 Received: from p508FB051.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.176.81] by mail.gmx.net (mp034) with SMTP; 28 Oct 2005 21:00:38 +0200 X-Authenticated: #1915285 Message-ID: <43627543.4070901@gmx.de> Date: Fri, 28 Oct 2005 21:00:19 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Luther CC: WebDav References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> <43557ADF.2070801@gmx.de> <43622BEF.3060706@gmx.de> <7D960D23-AC57-45E8-9113-1B16E6270DD4@apple.com> In-Reply-To: <7D960D23-AC57-45E8-9113-1B16E6270DD4@apple.com> 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 1EVZT2-0004Yz-CO a11f44480ebbeb6669fb3632526dbe72 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/43627543.4070901@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10219 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 19:00:56 +0000 Content-Transfer-Encoding: 7bit Jim, thanks for the explanation (the situation for our client is similar). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Oct 28 15:03:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZVl-0004PM-QC for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 15:03:34 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03411 for ; Fri, 28 Oct 2005 15:03:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVZVB-0000Zg-AE for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 19:02:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVZVA-0000Yi-S2 for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 19:02:56 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EVZV7-0000Bh-Ja for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 19:02:56 +0000 Received: (qmail invoked by alias); 28 Oct 2005 19:02:51 -0000 Received: from p508FB051.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.176.81] by mail.gmx.net (mp002) with SMTP; 28 Oct 2005 21:02:51 +0200 X-Authenticated: #1915285 Message-ID: <436275C7.8060006@gmx.de> Date: Fri, 28 Oct 2005 21:02:31 +0200 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: w3c-dist-auth@w3.org References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> <4354D63B.5050201@gmx.de> <435A8C00.90709@gmx.de> <435DCD5D.1020704@gmx.de> <4361D852.3010501@gmx.de> <2e730b30844ecb2d74d323ab19d4b6a2@osafoundation.org> In-Reply-To: <2e730b30844ecb2d74d323ab19d4b6a2@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 1EVZV7-0000Bh-Ja b938341506d4ddb7a1819ea80cbd45a1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/436275C7.8060006@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10220 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 19:02:57 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Let me know if the version I uploaded today fixes the "strict" mode > thing, i'm not sure I understand the problem there as I've had no > trouble having xml2rfc run on the document (the version on the > xml.resource.org site is the one I use) The version I have stops processing when it's run in strict mode, and artwork is too wide (you may want to check out ). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Oct 28 15:14:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZgB-0007xp-Bq for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 15:14:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03810 for ; Fri, 28 Oct 2005 15:14:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVZfW-0001xf-VG for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 19:13:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVZfW-0001x6-Cy for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 19:13:38 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EVZfO-0008Tm-Vb for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 19:13:38 +0000 Received: (qmail invoked by alias); 28 Oct 2005 19:13:29 -0000 Received: from p508FB051.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.176.81] by mail.gmx.net (mp028) with SMTP; 28 Oct 2005 21:13:29 +0200 X-Authenticated: #1915285 Message-ID: <43627846.5090408@gmx.de> Date: Fri, 28 Oct 2005 21:13:10 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDav WG References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> In-Reply-To: <435B8094.1040903@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 1EVZfO-0008Tm-Vb 2d7d00ddda4351648154bcf3b2b96f17 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/43627846.5090408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10221 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 19:13:38 +0000 Content-Transfer-Encoding: 7bit Ok, here's a procedural question. I have made a proposal to resolve these issues, and in the conference call we have sort-of agreed to that plan (for instance, keep opaquelocktoken, but move it to an appendix). The new draft posted by Lisa *also* does this, but it doesn't use the text I proposed. In particular, it still refers to outdated documents. If the working group wants people to propose ready-for-spec text, then I think that text should either be used, or those you don't like it should at least state what was wrong with it. For the record, I proposed: Appendix C. 'opaquelocktoken' URI Scheme The 'opaquelocktoken' URI scheme defined below uses the Universal Unique Identifier (UUID) mechanism ([9], Section 4) to easily generate lock tokens fulfilling the uniqueness requirements stated in Section 6.3. OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] ; UUID: see [RFC4122], Section 3. ; path: see [RFC3986], Section 3.3. Note that the optional "path" postfix allows to generate many lock tokens from a single URI, by appending an varying string such as a sequence number. Example: opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017 which is IMHO much better then the text we now got: Appendix D. The opaquelocktoken scheme and URIs 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. 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 RFC2396 [5] In particular: - no, opaquelocktoken has *not* been obsoleted; it still does more that urn:uuid does - What is "A server MAY generate one ore more UUIDs to use with the 'opaquelocktoken' scheme as lock tokens." supposed to mean??? - "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." - that's by definition of the lock token uniqueness; I'm not sure why it's repeated here. - "OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; ..." -- just refer to the normative definition in RFC4122 - "Extension = path"... -- RFC2396 is obsoleted. Really :-) Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Oct 28 15:44:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVa9H-0004uC-FK for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 15:44:23 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04852 for ; Fri, 28 Oct 2005 15:44:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVa8S-0000HR-4B for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 19:43:32 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVa8P-0000Go-5q for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 19:43:29 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EVa8G-0003p0-Hl for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 19:43:28 +0000 Received: (qmail invoked by alias); 28 Oct 2005 19:43:18 -0000 Received: from p508FB051.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.176.81] by mail.gmx.net (mp020) with SMTP; 28 Oct 2005 21:43:18 +0200 X-Authenticated: #1915285 Message-ID: <43627F41.7020806@gmx.de> Date: Fri, 28 Oct 2005 21:42:57 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDav WG References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> In-Reply-To: <43627846.5090408@gmx.de> 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 1EVa8G-0003p0-Hl 70373786e6128906b9e2e7c7d68af8f4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/43627F41.7020806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10222 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 19:43:32 +0000 Content-Transfer-Encoding: 7bit Hi. More changes that I think do not represent WG consensus: 1: : -- 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. -- This now says MUST instead of "must". I'm not sure why RFC2119 terminology is invoked here. URIs in the DAV: namespace by definition never represent a lock token, because they can only be assigned by the IETF or this WG. So the statement applies to *all* URIs that use the DAV: URI scheme, "DAV:no-lock" is just one example. If you really feel that this needs to be stated somewhere, please don't make it sound as if "DAV:no-lock" is different from -- for instance -- "DAV:lock". 2: : Why was the registration for "opaquelocktoken" removed from the IANA considerations? Thinking of it, why was the definition for the "DAV" URI scheme removed as well????? Please undo. Best regards, Julian From CECALA@wartaponsel.com Fri Oct 28 16:30:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVas2-000498-96 for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 16:30:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16393 for ; Fri, 28 Oct 2005 16:30:21 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVb5f-0003jR-Tg for webdav-archive@ietf.org; Fri, 28 Oct 2005 16:44:44 -0400 Received: from m211.net85-169-42.noos.fr ([85.169.42.211] helo=140671832) by mx2.foretec.com with smtp (Exim 4.24) id 1EVarj-00044Z-QX for webdav-archive@ietf.org; Fri, 28 Oct 2005 16:30:30 -0400 Received: from wartaponsel.com (137925464 [137133760]) by m211.net85-169-42.noos.fr (Qmailv1) with ESMTP id 7C72561870 for ; Fri, 28 Oct 2005 16:31:17 -0400 Date: Fri, 28 Oct 2005 16:31:17 -0400 From: "Dismantles F. Torch" X-Mailer: The Bat! (v2.00.5) Personal X-Priority: 3 Message-ID: <5191204338.20051028163117@wartaponsel.com> To: Webdav Subject: Software MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-AntiVirus: OK! AntiVir MailGate Version 2.0.1; AVE: 6.15.0.0; VDF: 6.15.0.6 X-Spam-Score: 2.8 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Corel draw! just at best price Why pay big bucks? Create your OWN website now! New software on our site: SQL Server 2000 Enterprise Edition - $69.95 InDesign CS - $69.95 FreeHand MX - $69.95 Flash MX 2004 - $69.95 Fireworks MX 2004 - $69.95 Illustrator CS CE - $69.95 Director MX 2004 - $69.95 InDesign CS - $69.95 Photoshop CS $99.95 Office 2000 Premium Edition PE (2CD) - $59.95 Photoshop CS $99.95 Photoshop 7 - $69.95 Office 2003 Professional (1 CD Edition) - $89.95 Project 2003 Professional - $69.95 Our site: http://paas.ip6wn9ne696dj00d5iid50ii.montanabf.com From w3c-dist-auth-request@frink.w3.org Fri Oct 28 17:19:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbdK-00056n-OC for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:19:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20502 for ; Fri, 28 Oct 2005 17:19:13 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVbbz-0003Fl-LY for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 21:18:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVbbw-0003FB-Pg; Fri, 28 Oct 2005 21:18:04 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVbbq-0000qa-K0; Fri, 28 Oct 2005 21:18:04 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4EE5F142283; Fri, 28 Oct 2005 14:17:57 -0700 (PDT) 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 32280-07; Fri, 28 Oct 2005 14:17:56 -0700 (PDT) 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 72424142281; Fri, 28 Oct 2005 14:17:55 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-12--244272394 Message-Id: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> Cc: Jim Whitehead , Julian Reschke , WebDav , w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Fri, 28 Oct 2005 14:17:46 -0700 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 1EVbbq-0000qa-K0 9d430aa76309a6caac67b4a627ad8fb7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/08b7ad41a9538f6fdbcf304404910853@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10223 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 21:18:07 +0000 --Apple-Mail-12--244272394 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Well I do agree on removing this section, and that supporting Location=20= with 207 responses isn't necessary. That means there's some text=20 early in section 12 that can go away, as well. However, without those pieces of text, the use of the Location header=20 with 207 responses becomes undefined, and that always makes me feel=20 uncomfortable. Server implementors won't know for sure if they can=20 use the Location header, it seems logical that it might work but as=20 we've seen there are some subtleties in how the client might interpret=20= that. Clients are probably not prepared to handle it. So I propose=20 that we include text to be clear that the Location header SHOULD NOT=20 appear in certain responses. I'm sensitive to the worry of preventing extensions but surely there's=20= some way of dealing with that. An extension can override "SHOULD"=20 level requirements, or we could come up with some "exception"=20 language... as in "servers SHOULD NOT return a Location header in these=20= responses unless the client has some way to interpret that header." Lisa On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote: > > +1 > > w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM: > > > > > > > > > > Julian writes: > > > Back to this issue: > > > > > > 1) I'm not aware of any interop problems. > > > > > > 2) I'm not aware of anybody having asked about this. > > > > > > 3) I don't see any benefit in RFC2518bis making statements about = =A0 > > > this, even if we *did* agree on what to say > > > > I have just read through this entire thread, and I agree with his =A0= > > statement above, and the conclusion Julian reached in: > >=20 > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html > > > > Specifically: > > > > * I don't think there is a compelling need to disallow Location and=20= > 207 > > * I don't think we need any special mechanism for handling 3xx=20 > within =A0 > > a PROPFIND > > * I think it's fine if a client needs to retry a PROPFIND request=20= > if =A0 > > it receives a 3xx response > > > > I feel a slight desire to add a 3xx response to one of the PROPFIND=20= > =A0 > > 207 response examples in the text, but could live without it. > > > > Unless others chime in, I think we're seeing rough consensus for =A0 > > removing the current 8.1.3, whose text is described in Bug 12=20 > within =A0 > > Bugzilla: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D12 > > > > - Jim > > > > > > > > --Apple-Mail-12--244272394 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well I do agree on removing this section, and that supporting Location with 207 responses isn't necessary. That means there's some text early in section 12 that can go away, as well. However, without those pieces of text, the use of the Location header with 207 responses becomes undefined, and that always makes me feel uncomfortable. Server implementors won't know for sure if they can use the Location header, it seems logical that it might work but as we've seen there are some subtleties in how the client might interpret that. Clients are probably not prepared to handle it. So I propose that we include text to be clear that the Location header SHOULD NOT appear in certain responses. =20 I'm sensitive to the worry of preventing extensions but surely there's some way of dealing with that. An extension can override "SHOULD" level requirements, or we could come up with some "exception" language... as in "servers SHOULD NOT return a Location header in these responses unless the client has some way to interpret that header." Lisa=20 On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote: +1=20 w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM: > > > > > Julian writes: > > Back to this issue: > > > > 1) I'm not aware of any interop = problems. > > > > 2) I'm not aware of anybody having asked about this. > > > > 3) I don't see any benefit in RFC2518bis making statements about =A0 > > this, even if we *did* agree on what to = say > > I have just read through this entire thread, and I agree with his =A0 > statement above, and the conclusion Julian reached in: > = http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html > > Specifically: > > * I don't think there is a compelling need to disallow Location and 207 > * I don't think we need any special mechanism for handling 3xx within =A0 > a PROPFIND > * I think it's fine if a client needs to retry a PROPFIND request if =A0 > it receives a 3xx = response > > I feel a slight desire to add a 3xx response to one of the PROPFIND =A0 > 207 response examples in the text, but could live without it. > > Unless others chime in, I think we're seeing rough consensus for =A0 > removing the current 8.1.3, whose text is described in Bug 12 within =A0 > Bugzilla: > = http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D12 > > - Jim > > > > = --Apple-Mail-12--244272394-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 17:36:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbtw-0006W1-AS for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:36:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21480 for ; Fri, 28 Oct 2005 17:36:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVbtC-0006pC-9R for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 21:35:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVbtB-0006o5-LX for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 21:35:53 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EVbt7-0008DV-TB for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 21:35:53 +0000 Received: (qmail invoked by alias); 28 Oct 2005 21:35:48 -0000 Received: from p508FB051.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.176.81] by mail.gmx.net (mp014) with SMTP; 28 Oct 2005 23:35:48 +0200 X-Authenticated: #1915285 Message-ID: <43629998.4080001@gmx.de> Date: Fri, 28 Oct 2005 23:35:20 +0200 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 , Jim Whitehead , WebDav , w3c-dist-auth-request@w3.org References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> In-Reply-To: <08b7ad41a9538f6fdbcf304404910853@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 1EVbt7-0008DV-TB c8c9e1bc251b31631a167f71f54142fd X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/43629998.4080001@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10224 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 21:35:54 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Well I do agree on removing this section, and that supporting Location > with 207 responses isn't necessary. That means there's some text early > in section 12 that can go away, as well. > > However, without those pieces of text, the use of the Location header > with 207 responses becomes undefined, and that always makes me feel > uncomfortable. Server implementors won't know for sure if they can use The "Location" header is defined by RFC2616. Multistatus response bodies are defined in RFC2518. Are you saying that those definitions are incompatible? That would be a bug. If they aren't, there's nothing that needs to be fixed. > the Location header, it seems logical that it might work but as we've > seen there are some subtleties in how the client might interpret that. > Clients are probably not prepared to handle it. So I propose that we > include text to be clear that the Location header SHOULD NOT appear in > certain responses. Do you have any evidence of interoperability problems because RFC2518 doesn't say anything about this? > I'm sensitive to the worry of preventing extensions but surely there's > some way of dealing with that. An extension can override "SHOULD" level > requirements, or we could come up with some "exception" language... as > in "servers SHOULD NOT return a Location header in these responses > unless the client has some way to interpret that header." -1. Please define what the problem is with what RFC2518 and RFC2616 currently say. We can then discuss whether there's a need to fix one of them. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Oct 28 17:38:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbvT-00078o-12 for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:38:15 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21506 for ; Fri, 28 Oct 2005 17:37:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVbup-0007v2-JU for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 21:37:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVbuo-0007uU-EC for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 21:37:34 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVbuj-0008VD-8b for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 21:37:33 +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 j9SLbQlL004773 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 14:37:26 -0700 (PDT) In-Reply-To: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-77--243020323 Message-Id: <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> Cc: WebDav From: Jim Whitehead Date: Fri, 28 Oct 2005 14:38:38 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.734) 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=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1EVbuj-0008VD-8b 81775dcb5cea05ef43c073af8f3df3cf X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10225 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 21:37:35 +0000 --Apple-Mail-77--243020323 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > Lisa writes: > However, without those pieces of text, the use of the Location > header with 207 responses becomes undefined, and that always makes > me feel uncomfortable. Server implementors won't know for sure > if they can use the Location header, it seems logical that it might > work but as we've seen there are some subtleties in how the client > might interpret that. Clients are probably not prepared to handle > it. So I propose that we include text to be clear that the > Location header SHOULD NOT appear in certain responses. The HTTP specification generally doesn't explain all interactions of methods, headers, and response codes. Location only has defined semantics for certain response codes in HTTP. On the other hand, the HTTP spec. isn't necessarily such a paragon of good writing that we should strive to emulate it. My solution to this issue is to add the text: "Use of the Location header with the methods and response codes defined in this specification is intentionally undefined." And leave it at that. This lets clients know they can't depend on the feature, and lets servers know they probably shouldn't go there. But, if a later spec. does add something here (like a refined REDIRECT spec.), then the door is left open for new behavior. Can we please close this issue? - Jim > > I'm sensitive to the worry of preventing extensions but surely > there's some way of dealing with that. An extension can override > "SHOULD" level requirements, or we could come up with some > "exception" language... as in "servers SHOULD NOT return a Location > header in these responses unless the client has some way to > interpret that header." > > Lisa > > On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote: > > >> >> +1 >> >> w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM: >> >> > >> > > >> > >> > Julian writes: >> > > Back to this issue: >> > > >> > > 1) I'm not aware of any interop problems. >> > > >> > > 2) I'm not aware of anybody having asked about this. >> > > >> > > 3) I don't see any benefit in RFC2518bis making statements about >> > > this, even if we *did* agree on what to say >> > >> > I have just read through this entire thread, and I agree with his >> > statement above, and the conclusion Julian reached in: >> > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/ >> 0294.html >> > >> > Specifically: >> > >> > * I don't think there is a compelling need to disallow Location >> and 207 >> > * I don't think we need any special mechanism for handling 3xx >> within >> > a PROPFIND >> > * I think it's fine if a client needs to retry a PROPFIND >> request if >> > it receives a 3xx response >> > >> > I feel a slight desire to add a 3xx response to one of the >> PROPFIND >> > 207 response examples in the text, but could live without it. >> > >> > Unless others chime in, I think we're seeing rough consensus for >> > removing the current 8.1.3, whose text is described in Bug 12 >> within >> > Bugzilla: >> > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 >> > >> > - Jim >> > >> > >> > >> > > --Apple-Mail-77--243020323 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Lisa = writes:

However, = without those pieces of text, the use of the Location header with 207 = responses becomes undefined, and that always makes me feel = uncomfortable.=A0 =A0 = Server implementors won't know for sure if they can use the = Location header, it seems logical that it might work but as we've seen = there are some subtleties in how the client might interpret that.=A0 Clients are probably not = prepared to handle it.=A0 = So I propose that we include text to be clear that the Location = header SHOULD NOT appear in certain responses. =A0
<= BR class=3D"khtml-block-placeholder">
The HTTP specification = generally doesn't explain all interactions of methods, headers, and = response codes. Location only has defined semantics for certain response = codes in HTTP.

On the other hand, the HTTP = spec. isn't necessarily such a paragon of good writing that we should = strive to emulate it.

My solution to this issue = is to add the text:

"Use of the Location header = with the methods and response codes defined in this specification is = intentionally undefined."

And leave it at that. This = lets clients know they can't depend on the feature, and lets servers = know they probably shouldn't go there. But, if a later spec. does add = something here (like a refined REDIRECT spec.), then the door is left = open for new behavior.

Can we please close this = issue?

- = Jim


I'm sensitive to the worry of preventing extensions = but surely there's some way of dealing with that.=A0 An extension can override = "SHOULD" level requirements, or we could come up with some "exception" = language... as in "servers SHOULD NOT return a Location header in these = responses unless the client has some way to interpret that = header."

Lisa=A0

On Oct = 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote:



+1=A0

=A0>=A0
=A0> = Specifically:
=A0>=A0
=A0> * I = don't think there is a compelling need to disallow Location and = 207
=A0> * I don't think we need = any special mechanism for handling 3xx within =A0
=A0> a = PROPFIND
=A0> * I think it's fine if a = client needs to retry a PROPFIND request if =A0
=A0> it = receives a 3xx response
=A0>=A0
=A0> I = feel a slight desire to add a 3xx response to one of the PROPFIND = =A0
=A0> 207 response examples in = the text, but could live without it.
=A0>=A0
=A0> = Unless others chime in, I think we're seeing rough consensus for = =A0
=A0> removing the current = 8.1.3, whose text is described in Bug 12 within =A0
=A0> = Bugzilla:
=A0>=A0
=A0> - = Jim
=A0>=A0
=A0>=A0
=A0>=A0
=A0>=A0


= --Apple-Mail-77--243020323-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 17:43:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVc0P-0000sE-Es for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:43:21 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21641 for ; Fri, 28 Oct 2005 17:43:04 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVbzm-0008Tu-OA for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 21:42:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVbzj-0008TM-Ju for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 21:42:39 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVbzg-0000l3-Vf for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 21:42:39 +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 j9SLgWIL006661 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 14:42:33 -0700 (PDT) In-Reply-To: <43622BEF.3060706@gmx.de> References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> <43557ADF.2070801@gmx.de> <43622BEF.3060706@gmx.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13C9A2E9-0542-4F70-BE10-E67740B606C3@cs.ucsc.edu> Cc: WebDav Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Fri, 28 Oct 2005 14:43:45 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.734) 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.0 X-W3C-Scan-Sig: maggie.w3.org 1EVbzg-0000l3-Vf a12ba2c947516deef9f9583e9bc98e76 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/13C9A2E9-0542-4F70-BE10-E67740B606C3@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10226 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 21:42:42 +0000 Content-Transfer-Encoding: 7bit > > I have no problem adding non-normative text explaining this. > I'm thinking that the right choice here is to create an appendix describing the problem, and the recommended solution(s). While I agree that we shouldn't be wily-nilly giving implementation advice, this is a common enough problem, whose solution is sufficiently non- obvious, that adding appendix text makes sense. I also think we should add a force-authenticate feature, but I think it makes sense to put this in a separate "DAV-fixes" draft. This draft can accumulate items like Force-Authenticate, and the reliable etags for the body and dead properties, etc. I'll take an action item to start creating this draft. I'll make it a private draft, so Cullen doesn't have to justify the creation of a new WG item :-) - Jim From w3c-dist-auth-request@frink.w3.org Fri Oct 28 17: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 1EVc3f-00021X-5J for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:46:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21745 for ; Fri, 28 Oct 2005 17:46:26 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVc32-00022Y-Vr for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 21:46:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVc32-000220-Ec for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 21:46:04 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVc2z-0001KW-FG for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 21:46:04 +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 j9SLjvOu007908 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 14:45:58 -0700 (PDT) In-Reply-To: <436275C7.8060006@gmx.de> References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> <4354D63B.5050201@gmx.de> <435A8C00.90709@gmx.de> <435DCD5D.1020704@gmx.de> <4361D852.3010501@gmx.de> <2e730b30844ecb2d74d323ab19d4b6a2@osafoundation.org> <436275C7.8060006@gmx.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B120317-C04E-4589-AEA7-0547B172EC7A@cs.ucsc.edu> Cc: WebDav Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Fri, 28 Oct 2005 14:47:10 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.734) 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.1 X-W3C-Scan-Sig: maggie.w3.org 1EVc2z-0001KW-FG 0f0ca14a1ed5fc0730807b7184fbfb8f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/4B120317-C04E-4589-AEA7-0547B172EC7A@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10227 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 21:46:04 +0000 Content-Transfer-Encoding: 7bit Julian, I'm unclear what changes Lisa needs to make at this point. Are there specific figures that are causing a problem? Also, I don't think it's fair to ding Lisa for using the released version of xml2rfc, while you're using the unreleased head of the development tree. - Jim On Oct 28, 2005, at 12:02 PM, Julian Reschke wrote: > > Lisa Dusseault wrote: > >> Let me know if the version I uploaded today fixes the "strict" >> mode thing, i'm not sure I understand the problem there as I've >> had no trouble having xml2rfc run on the document (the version on >> the xml.resource.org site is the one I use) >> > > The version I have stops processing when it's run in strict mode, > and artwork is too wide (you may want to check out xml.resource.org/experimental.html>). > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Fri Oct 28 17:50:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVc7P-0002U5-Sp for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:50:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21940 for ; Fri, 28 Oct 2005 17:50:18 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVc6j-0002KT-Jc for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 21:49:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVc6g-0002Jq-2P for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 21:49:50 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVc6b-0001r7-Kc for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 21:49:49 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 92A10142283; Fri, 28 Oct 2005 14:49:43 -0700 (PDT) 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 04651-05; Fri, 28 Oct 2005 14:49:43 -0700 (PDT) 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 328A1142267; Fri, 28 Oct 2005 14:49:42 -0700 (PDT) In-Reply-To: <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-13--242384112 Message-Id: Cc: WebDav From: Lisa Dusseault Date: Fri, 28 Oct 2005 14:49:14 -0700 To: Jim Whitehead 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 1EVc6b-0001r7-Kc d0cb6d941f2912b6f77ac5d807de3c1e X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/bfedc643b173bc4803a8f76c9e61be47@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10228 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 21:49:53 +0000 --Apple-Mail-13--242384112 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable That's pretty concise and still useful. I can live with that. Lisa On Oct 28, 2005, at 2:38 PM, Jim Whitehead wrote: >> > Lisa writes: > >> However, without those pieces of text, the use of the Location header = =20 >> with 207 responses becomes undefined, and that always makes me feel =20= >> uncomfortable. Server implementors won't know for sure if they can =20= >> use the Location header, it seems logical that it might work but as =20= >> we've seen there are some subtleties in how the client might =20 >> interpret that. Clients are probably not prepared to handle it. So I =20= >> propose that we include text to be clear that the Location header =20 >> SHOULD NOT appear in certain responses. > The HTTP specification generally doesn't explain all interactions of =20= > methods, headers, and response codes. Location only has defined =20 > semantics for certain response codes in HTTP. > > On the other hand, the HTTP spec. isn't necessarily such a paragon of =20= > good writing that we should strive to emulate it. > > My solution to this issue is to add the text: > > "Use of the Location header with the methods and response codes =20 > defined in this specification is intentionally undefined." > > And leave it at that. This lets clients know they can't depend on the =20= > feature, and lets servers know they probably shouldn't go there. But, =20= > if a later spec. does add something here (like a refined REDIRECT =20 > spec.), then the door is left open for new behavior. > > Can we please close this issue? > > - Jim > >> >> I'm sensitive to the worry of preventing extensions but surely =20 >> there's some way of dealing with that. An extension can override =20 >> "SHOULD" level requirements, or we could come up with some =20 >> "exception" language... as in "servers SHOULD NOT return a Location =20= >> header in these responses unless the client has some way to interpret = =20 >> that header." >> >> Lisa >> >> On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote: >> >> >>> >>> +1 >>> >>> w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM: >>> >>> =A0> >>> =A0> > >>> =A0> >>> =A0> Julian writes: >>> =A0> > Back to this issue: >>> =A0> > >>> =A0> > 1) I'm not aware of any interop problems. >>> =A0> > >>> =A0> > 2) I'm not aware of anybody having asked about this. >>> =A0> > >>> =A0> > 3) I don't see any benefit in RFC2518bis making statements = about >>> =A0> > this, even if we *did* agree on what to say >>> =A0> >>> =A0> I have just read through this entire thread, and I agree with = his >>> =A0> statement above, and the conclusion Julian reached in: >>> =A0> =20 >>> http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/=20 >>> 0294.html >>> =A0> >>> =A0> Specifically: >>> =A0> >>> =A0> * I don't think there is a compelling need to disallow Location = =20 >>> and 207 >>> =A0> * I don't think we need any special mechanism for handling 3xx =20= >>> within >>> =A0> a PROPFIND >>> =A0> * I think it's fine if a client needs to retry a PROPFIND = request =20 >>> if >>> =A0> it receives a 3xx response >>> =A0> >>> =A0> I feel a slight desire to add a 3xx response to one of the =20 >>> PROPFIND >>> =A0> 207 response examples in the text, but could live without it. >>> =A0> >>> =A0> Unless others chime in, I think we're seeing rough consensus = for >>> =A0> removing the current 8.1.3, whose text is described in Bug 12 =20= >>> within >>> =A0> Bugzilla: >>> =A0> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D12 >>> =A0> >>> =A0> - Jim >>> =A0> >>> =A0> >>> =A0> >>> =A0> --Apple-Mail-13--242384112 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's pretty concise and still useful. I can live with that. Lisa On Oct 28, 2005, at 2:38 PM, Jim Whitehead wrote: Lisa writes: However, without those pieces of text, the use of the Location header with 207 responses becomes undefined, and that always makes me feel uncomfortable. Server implementors won't know for sure if they can use the Location header, it seems logical that it might work but as we've seen there are some subtleties in how the client might interpret that. Clients are probably not prepared to handle it. So I propose that we include text to be clear that the Location header SHOULD NOT appear in certain responses.=20 The HTTP specification generally doesn't explain all interactions of methods, headers, and response codes. Location only has defined semantics for certain response codes in HTTP. On the other hand, the HTTP spec. isn't necessarily such a paragon of good writing that we should strive to emulate it. My solution to this issue is to add the text: "Use of the Location header with the methods and response codes defined in this specification is intentionally undefined." And leave it at that. This lets clients know they can't depend on the feature, and lets servers know they probably shouldn't go there. But, if a later spec. does add something here (like a refined REDIRECT spec.), then the door is left open for new behavior. Can we please close this issue? - Jim I'm sensitive to the worry of preventing extensions but surely there's some way of dealing with that. An extension can override "SHOULD" level requirements, or we could come up with some "exception" language... as in "servers SHOULD NOT return a Location header in these responses unless the client has some way to interpret that header." Lisa=20 On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote: +1=20 = 0000,0000,EEEEw3c-dist-auth-re= quest@w3.org wrote on 10/27/2005 07:50:06 PM: =A0> =A0> > =A0> =A0> Julian writes: =A0> > Back to this issue: =A0> > =A0> > 1) I'm not aware of any interop = problems. =A0> > =A0> > 2) I'm not aware of anybody having asked about this. =A0> > =A0> > 3) I don't see any benefit in RFC2518bis making statements about =A0> > this, even if we *did* agree on what to = say =A0> =A0> I have just read through this entire thread, and I agree with his =A0> statement above, and the conclusion Julian reached in: =A0> = 0000,0000,EEEEhttp://= lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html =A0> =A0> Specifically: =A0> =A0> * I don't think there is a compelling need to disallow Location and 207 =A0> * I don't think we need any special mechanism for handling 3xx within =A0> a PROPFIND =A0> * I think it's fine if a client needs to retry a PROPFIND request if =A0> it receives a 3xx = response =A0> =A0> I feel a slight desire to add a 3xx response to one of the PROPFIND =A0> 207 response examples in the text, but could live without it. =A0> =A0> Unless others chime in, I think we're seeing rough consensus for =A0> removing the current 8.1.3, whose text is described in Bug 12 within =A0> Bugzilla: =A0> = 0000,0000,EEEEhttp://= ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D12 =A0> =A0> - Jim =A0> =A0> =A0> =A0> = --Apple-Mail-13--242384112-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 17: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 1EVc8J-0002fB-6d for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:51:31 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21969 for ; Fri, 28 Oct 2005 17:51:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVc7k-0002uI-VP for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 21:50:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVc7k-0002th-Ji for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 21:50:56 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVc7Z-0005qZ-Sh for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 21:50:56 +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 j9SLogBf009967 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 14:50:42 -0700 (PDT) In-Reply-To: <43627F41.7020806@gmx.de> References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> <43627F41.7020806@gmx.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: WebDav WG Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Fri, 28 Oct 2005 14:51:54 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.734) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.1 X-W3C-Scan-Sig: lisa.w3.org 1EVc7Z-0005qZ-Sh ef400e53f15e400366123b042da9dbb2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/A6106120-3F39-4975-9646-BD554EF5E7D0@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10229 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 21:50:56 +0000 Content-Transfer-Encoding: 7bit > More changes that I think do not represent WG consensus: > > 1: latest.html#rfc.section.9.5.3.p.4>: > > -- > 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. > -- This sounds right to me. > > This now says MUST instead of "must". I'm not sure why RFC2119 > terminology is invoked here. URIs in the DAV: namespace by > definition never represent a lock token, because they can only be > assigned by the IETF or this WG. So the statement applies to *all* > URIs that use the DAV: URI scheme, "DAV:no-lock" is just one example. > > If you really feel that this needs to be stated somewhere, please > don't make it sound as if "DAV:no-lock" is different from -- for > instance -- "DAV:lock". I know there was an issue with organizations adding things to the DAV: namespace without using the IETF process. However, this section doesn't seem like the right place to address this issue. > 2: latest-from-07.diff.html#diff-30>: > > Why was the registration for "opaquelocktoken" removed from the > IANA considerations? Thinking of it, why was the definition for the > "DAV" URI scheme removed as well????? > Based on Ted Hardie's email of today, it sounds like these will continue to be registered, whether in the IANA considerations section or no. That said, it would be useful to have a brief sentence to the effect of, "the URI registrations for opaquelocktoken and DAV URI schemes made in RFC 2518 should still be considered active." - Jim From w3c-dist-auth-request@frink.w3.org Fri Oct 28 17:59:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcGL-0008FO-0b for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 17:59:49 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22242 for ; Fri, 28 Oct 2005 17:59:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVcFg-00050N-2E for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 21:59:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVcFQ-0004yW-V3 for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 21:58:53 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVcFI-0007Fv-Uj for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 21:58:52 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 69208142285; Fri, 28 Oct 2005 14:58:44 -0700 (PDT) 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 04833-07; Fri, 28 Oct 2005 14:58:43 -0700 (PDT) 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 C6738142267; Fri, 28 Oct 2005 14:58:41 -0700 (PDT) In-Reply-To: References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-14--241825482 Message-Id: Cc: Jim Whitehead , WebDav From: Lisa Dusseault Date: Fri, 28 Oct 2005 14:58:33 -0700 To: Lisa Dusseault 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 1EVcFI-0007Fv-Uj 57dfdfcbc84a4ca4af5facbd82ecee18 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/c8764b3ffbd5990f8b88b2cade88af70@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10230 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 21:59:08 +0000 --Apple-Mail-14--241825482 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable One thing I noticed when checking this against and editing the text =20 (sometimes this turns up new observations): We actually use the =20 Location header in response to a MOVE request, in section 8.9.5 of =20 RFC2518. Yet there's no explanation for this -- the text around the =20= example doesn't indicate whether the server could have chosen a =20 different destination URL (which seems very harmful to interoperability =20= to me) or, if not, why the Location header is even needed. 8.9.5 Example - MOVE of a Non-Collection This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the =20 location http://www.ics.uci.edu/users/f/fielding/index.html. The =20 contents of the destination resource would have been overwritten if the =20= destination resource had been non-null. In this case, since there was =20= nothing at the destination resource, the response code is 201 =20 (Created). >>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 ---- What if I remove the header from the response example, in addition to =20= Jim's suggested change? Lisa On Oct 28, 2005, at 2:49 PM, Lisa Dusseault wrote: > That's pretty concise and still useful. I can live with that. > > Lisa > > On Oct 28, 2005, at 2:38 PM, Jim Whitehead wrote: > >>> >> Lisa writes: >> >>> However, without those pieces of text, the use of the Location =20 >>> header with 207 responses becomes undefined, and that always makes =20= >>> me feel uncomfortable. Server implementors won't know for sure if =20= >>> they can use the Location header, it seems logical that it might =20 >>> work but as we've seen there are some subtleties in how the client =20= >>> might interpret that. Clients are probably not prepared to handle =20= >>> it. So I propose that we include text to be clear that the Location =20= >>> header SHOULD NOT appear in certain responses. >> The HTTP specification generally doesn't explain all interactions of =20= >> methods, headers, and response codes. Location only has defined =20 >> semantics for certain response codes in HTTP. >> >> On the other hand, the HTTP spec. isn't necessarily such a paragon of = =20 >> good writing that we should strive to emulate it. >> >> My solution to this issue is to add the text: >> >> "Use of the Location header with the methods and response codes =20 >> defined in this specification is intentionally undefined." >> >> And leave it at that. This lets clients know they can't depend on the = =20 >> feature, and lets servers know they probably shouldn't go there. But, = =20 >> if a later spec. does add something here (like a refined REDIRECT =20 >> spec.), then the door is left open for new behavior. >> >> Can we please close this issue? >> >> - Jim >> >>> >>> I'm sensitive to the worry of preventing extensions but surely =20 >>> there's some way of dealing with that. An extension can override =20 >>> "SHOULD" level requirements, or we could come up with some =20 >>> "exception" language... as in "servers SHOULD NOT return a Location =20= >>> header in these responses unless the client has some way to =20 >>> interpret that header." >>> >>> Lisa >>> >>> On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote: >>> >>> >>>> >>>> +1 >>>> >>>> w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM: >>>> >>>> =A0> >>>> =A0> > >>>> =A0> >>>> =A0> Julian writes: >>>> =A0> > Back to this issue: >>>> =A0> > >>>> =A0> > 1) I'm not aware of any interop problems. >>>> =A0> > >>>> =A0> > 2) I'm not aware of anybody having asked about this. >>>> =A0> > >>>> =A0> > 3) I don't see any benefit in RFC2518bis making statements =20= >>>> about >>>> =A0> > this, even if we *did* agree on what to say >>>> =A0> >>>> =A0> I have just read through this entire thread, and I agree with = his >>>> =A0> statement above, and the conclusion Julian reached in: >>>> =A0> =20 >>>> http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/=20 >>>> 0294.html >>>> =A0> >>>> =A0> Specifically: >>>> =A0> >>>> =A0> * I don't think there is a compelling need to disallow = Location =20 >>>> and 207 >>>> =A0> * I don't think we need any special mechanism for handling 3xx = =20 >>>> within >>>> =A0> a PROPFIND >>>> =A0> * I think it's fine if a client needs to retry a PROPFIND =20 >>>> request if >>>> =A0> it receives a 3xx response >>>> =A0> >>>> =A0> I feel a slight desire to add a 3xx response to one of the =20 >>>> PROPFIND >>>> =A0> 207 response examples in the text, but could live without it. >>>> =A0> >>>> =A0> Unless others chime in, I think we're seeing rough consensus = for >>>> =A0> removing the current 8.1.3, whose text is described in Bug 12 =20= >>>> within >>>> =A0> Bugzilla: >>>> =A0> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D12 >>>> =A0> >>>> =A0> - Jim >>>> =A0> >>>> =A0> >>>> =A0> >>>> =A0> --Apple-Mail-14--241825482 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One thing I noticed when checking this against and editing the text (sometimes this turns up new observations): We actually use the Location header in response to a MOVE request, in section 8.9.5 of RFC2518. Yet there's no explanation for this -- the text around the example doesn't indicate whether the server could have chosen a different destination URL (which seems very harmful to interoperability to me) or, if not, why the Location header is even needed. 8.9.5 Example - MOVE of a Non-Collection 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 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 ---- What if I remove the header from the response example, in addition to Jim's suggested change? Lisa On Oct 28, 2005, at 2:49 PM, Lisa Dusseault wrote: That's pretty concise and still useful. I can live with that. Lisa On Oct 28, 2005, at 2:38 PM, Jim Whitehead wrote: Lisa writes: However, without those pieces of text, the use of the Location header with 207 responses becomes undefined, and that always makes me feel uncomfortable. Server implementors won't know for sure if they can use the Location header, it seems logical that it might work but as we've seen there are some subtleties in how the client might interpret that. Clients are probably not prepared to handle it. So I propose that we include text to be clear that the Location header SHOULD NOT appear in certain responses.=20 The HTTP specification generally doesn't explain all interactions of methods, headers, and response codes. Location only has defined semantics for certain response codes in HTTP. On the other hand, the HTTP spec. isn't necessarily such a paragon of good writing that we should strive to emulate it. My solution to this issue is to add the text: "Use of the Location header with the methods and response codes defined in this specification is intentionally undefined." And leave it at that. This lets clients know they can't depend on the feature, and lets servers know they probably shouldn't go there. But, if a later spec. does add something here (like a refined REDIRECT spec.), then the door is left open for new behavior. Can we please close this issue? - Jim I'm sensitive to the worry of preventing extensions but surely there's some way of dealing with that. An extension can override "SHOULD" level requirements, or we could come up with some "exception" language... as in "servers SHOULD NOT return a Location header in these responses unless the client has some way to interpret that header." Lisa=20 On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote: +1=20 = 0000,0000,EEEDw3c-dist-auth-re= quest@w3.org wrote on 10/27/2005 07:50:06 PM: =A0> =A0> > =A0> =A0> Julian writes: =A0> > Back to this issue: =A0> > =A0> > 1) I'm not aware of any interop = problems. =A0> > =A0> > 2) I'm not aware of anybody having asked about this. =A0> > =A0> > 3) I don't see any benefit in RFC2518bis making statements about =A0> > this, even if we *did* agree on what to = say =A0> =A0> I have just read through this entire thread, and I agree with his =A0> statement above, and the conclusion Julian reached in: =A0> = 0000,0000,EEEDhttp://= lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html =A0> =A0> Specifically: =A0> =A0> * I don't think there is a compelling need to disallow Location and 207 =A0> * I don't think we need any special mechanism for handling 3xx within =A0> a PROPFIND =A0> * I think it's fine if a client needs to retry a PROPFIND request if =A0> it receives a 3xx = response =A0> =A0> I feel a slight desire to add a 3xx response to one of the PROPFIND =A0> 207 response examples in the text, but could live without it. =A0> =A0> Unless others chime in, I think we're seeing rough consensus for =A0> removing the current 8.1.3, whose text is described in Bug 12 within =A0> Bugzilla: =A0> = 0000,0000,EEEDhttp://= ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D12 =A0> =A0> - Jim =A0> =A0> =A0> =A0> = --Apple-Mail-14--241825482-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 18:02:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcIk-0000mi-FM for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:02:18 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22303 for ; Fri, 28 Oct 2005 18:02:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVcIC-0006qO-0X for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 22:01:44 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVcHz-0006gP-CY for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 22:01:31 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EVcHo-00020P-Aj for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 22:01:30 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 09EEB142283; Fri, 28 Oct 2005 15:01:18 -0700 (PDT) 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 09090-03; Fri, 28 Oct 2005 15:01:17 -0700 (PDT) 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 5841B142267; Fri, 28 Oct 2005 15:01:17 -0700 (PDT) In-Reply-To: References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> <43627F41.7020806@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <37c36b8f513c0689cd220e7e3cd04039@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , WebDav WG From: Lisa Dusseault Date: Fri, 28 Oct 2005 15:01:08 -0700 To: Jim Whitehead 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 1EVcHo-00020P-Aj f4c1c4e2fb8bc7aeec29948aef9729a0 X-Original-To: w3c-dist-auth@w3.org Subject: This Document Defines Two Namespaces (was Re: Combined set of issues ...) X-Archived-At: http://www.w3.org/mid/37c36b8f513c0689cd220e7e3cd04039@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10231 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 22:01:44 +0000 Content-Transfer-Encoding: 7bit On Oct 28, 2005, at 2:51 PM, Jim Whitehead wrote: > URI registrations for opaquelocktoken and DAV URI schemes made in RFC > 2518 should still be considered active." > While looking at the IANA considerations section, this text caught my eye: This document defines two namespaces, the namespace of property names, and the namespace of WebDAV-specific XML elements used within property values. I don't count two namespace, just one (DAV:). any objections if I fix this sentence? Lisa From w3c-dist-auth-request@frink.w3.org Fri Oct 28 18:07:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcNd-0001fY-TR for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:07:22 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22558 for ; Fri, 28 Oct 2005 18:07:04 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVcN0-0007dL-OK for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 22:06:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVcN0-0007ch-3x for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 22:06:42 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVcMu-0008Tk-PX for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 22:06:42 +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 j9SM6XVU017577 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 15:06:34 -0700 (PDT) In-Reply-To: <43627846.5090408@gmx.de> References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-78--241272097 Message-Id: Cc: WebDav WG From: Jim Whitehead Date: Fri, 28 Oct 2005 15:07:46 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.734) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.1 X-W3C-Scan-Sig: lisa.w3.org 1EVcMu-0008Tk-PX 1d22a76106c85dbc78e4f244c4518800 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/D5F35732-4FD2-49AF-BA35-45A982EC582D@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10232 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 22:06:42 +0000 --Apple-Mail-78--241272097 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > If the working group wants people to propose ready-for-spec text, > then I think that text should either be used, or those you don't > like it should at least state what was wrong with it. I don't think the editor should have to defend every minor text change. In particular, I think some of Lisa's additions are good (and she caught one error in the ABNF that you missed). However, you did catch a few minor errors, and one case of overspecification. Gee, it's almost like when multiple people collaborate on a document, the final result is of higher quality :-) > > For the record, I proposed: > > Appendix C. 'opaquelocktoken' URI Scheme > > The 'opaquelocktoken' URI scheme defined below uses the Universal > Unique Identifier (UUID) mechanism ([9], Section 4) to easily > generate lock tokens fulfilling the uniqueness requirements > stated in > Section 6.3. > > OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] > ; UUID: see [RFC4122], Section 3. > ; path: see [RFC3986], Section 3.3. > > Note that the optional "path" postfix allows to generate many lock > tokens from a single URI, by appending an varying string such as a > sequence number. > > Example: > > opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017 I like this text, but I think Lisa does have some valuable contributions. Lisa's note about LWS is necessary, since otherwise you could have any amount of LWS between "opaquelocktoken:" and UUID and [path]. I also generally like Lisa's new introduction sentence, since it provides a modicum of context for the appendix. I'd tweak the introduction sentence slightly: The 'opaquelocktoken' URI scheme can be used by servers to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens, meeting the requirements for uniqueness 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. This is implicit in the ABNF definition for opaquelocktoken, and doesn't need to be stated. > > 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. For this section, I recommend: OpaqueLockToken-URI = "opaquelocktoken:" UUID [path] ; UUID: see [RFC4122], Section 3. ; path: see [RFC3986], Section 3.3. Note that white space (LWS) is not allowed between elements of this production. > - no, opaquelocktoken has *not* been obsoleted; it still does more > that urn:uuid does > I agree. > > - "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." - that's by definition of the > lock token uniqueness; I'm not sure why it's repeated here. I agree. > > - "OpaqueLockToken-URI = "opaquelocktoken:" UUID > [Extension] ; ..." -- just refer to the normative definition in > RFC4122 I agree. > > - "Extension = path"... -- RFC2396 is obsoleted. Really :-) I agree. - Jim --Apple-Mail-78--241272097 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If the working group wants = people to propose ready-for-spec text, then I think that text should = either be used, or those you don't like it should at least state what = was wrong with it.

I don't think the editor = should have to defend every minor text change. In particular, I think = some of Lisa's additions are good (and she caught one error in the ABNF = that you missed). However, you did catch a few minor errors, and one = case of overspecification. Gee, it's almost like when multiple people = collaborate on a document, the final result is of higher quality = :-)


For the record, I = proposed:

=A0Append= ix C.=A0 'opaquelocktoken' = URI Scheme

=A0=A0 = The 'opaquelocktoken' URI scheme defined below uses the = Universal
=A0=A0 Unique Identifier (UUID) = mechanism ([9], Section 4) to easily
=A0=A0 generate lock tokens = fulfilling the uniqueness requirements stated in
=A0=A0 = Section 6.3.
=A0=A0 =A0 OpaqueLockToken-URI =3D = "opaquelocktoken:" UUID [path]
=A0=A0 =A0 ; UUID: see [RFC4122], = Section 3.
=A0=A0 =A0 ; path: see [RFC3986], = Section 3.3.

=A0=A0 = Note that the optional "path" postfix allows to generate many = lock
=A0=A0 tokens from a single URI, = by appending an varying string such as a
=A0=A0 sequence number.

=A0=A0 Example:

=A0=A0 =A0 = opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017

I like = this text, but I think Lisa does have some valuable = contributions.

Lisa's=A0note about LWS is = necessary, since otherwise you could have any amount of LWS between = "opaquelocktoken:" and UUID and [path].

I also generally like = Lisa's new introduction sentence, since it provides a modicum of context = for the appendix.

I'd tweak the introduction = sentence slightly:

The 'opaquelocktoken' URI = scheme can be used by servers to create syntactically correct and = easy-to-generate URIs out of UUIDs, intended to be used as lock tokens, = meeting the requirements for uniqueness across all resources for all = time.=A0

=A0 =A0A = server MAY generate one ore more UUIDs to use with the
=A0=A0 = 'opaquelocktoken' scheme as lock tokens.=A0 A server MAY reuse a = UUID
=A0=A0 with extension characters = added.=A0 If the server = does this then the
=A0=A0 algorithm generating the = extensions MUST guarantee that the same
=A0=A0 extension will never be = used twice with the associated UUID.

This is implicit in the = ABNF definition for opaquelocktoken, and doesn't need to be = stated.=A0



=A0=A0 OpaqueLockToken-URI =3D = "opaquelocktoken:" UUID [Extension]=A0= ; The UUID
=A0=A0 production is the string = representation of a UUID.=A0 = Note that white
=A0=A0 space (LWS) is not allowed = between elements of this production.

For this section, I = recommend:

OpaqueLockToken-URI =3D = "opaquelocktoken:" UUID [path]
=A0 =A0; UUID: see [RFC4122], = Section 3.
=A0 =A0; path: see [RFC3986], Section = 3.3.
Note that white=A0space (LWS) is not allowed between = elements of this production.


- no, opaquelocktoken has *not* been obsoleted; it = still does more that urn:uuid does


I = agree.=A0



- "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." - that's by definition of the lock token uniqueness; = I'm not sure why it's repeated here.

I = agree.


- "OpaqueLockToken-URI =3D = "opaquelocktoken:" UUID [Extension]=A0= ; ..." -- just refer to the normative definition in = RFC4122

I = agree.


- "Extension =3D path"... -- = RFC2396 is obsoleted. Really :-)

I = agree.

- = Jim
= --Apple-Mail-78--241272097-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 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 1EVcT1-0004C3-89 for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:12:55 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22960 for ; Fri, 28 Oct 2005 18:12:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVcSP-0000AW-FE for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 22:12:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVcSO-00009t-Tm for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 22:12:17 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVcSF-0005HY-4x for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 22:12:16 +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 j9SMC4nw019437 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 15:12:05 -0700 (PDT) In-Reply-To: References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-79--240941015 Message-Id: <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu> Cc: WebDav WG From: Jim Whitehead Date: Fri, 28 Oct 2005 15:13:17 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.734) 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.0 X-W3C-Scan-Sig: maggie.w3.org 1EVcSF-0005HY-4x b7c05c9214d18da730637bd4a2e2eabf X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10233 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 22:12:17 +0000 --Apple-Mail-79--240941015 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > What if I remove the header from the response example, in addition > to Jim's suggested change? > Urk, bad idea. The use of Location with MOVE is to be consistent with the semantics of the 201 response code. So, the suggested text has to be more precise. Perhaps: "The use of the Location header with the 207 status code is intentionally undefined." However, even this I'm starting to feel is a bad idea. Why do we stop at Location? Why not create a table with all HTTP headers and state whether they should be used with 207? - Jim --Apple-Mail-79--240941015 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
What if I remove the header = from the response example, in addition to Jim's suggested = change?
The use of Location with = MOVE is to be consistent with the semantics of the 201 response = code.

So, the = suggested text has to be more precise. Perhaps:

"The use of the Location = header with the 207 status code is intentionally = undefined."

However, even this I'm = starting to feel is a bad idea. Why do we stop at Location? Why not = create a table with all HTTP headers and state whether they should be = used with 207?

- Jim
= --Apple-Mail-79--240941015-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 18:24:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVceV-0002ne-PP for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:24:47 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23736 for ; Fri, 28 Oct 2005 18:24:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVcdY-000304-98 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 22:23:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVcdX-0002zK-Lp for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 22:23:47 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVcdU-0006ut-SK for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 22:23:47 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 87BE6142283; Fri, 28 Oct 2005 15:23:43 -0700 (PDT) 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 12658-03; Fri, 28 Oct 2005 15:23:43 -0700 (PDT) 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 DB0FC14227F; Fri, 28 Oct 2005 15:23:42 -0700 (PDT) In-Reply-To: <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu> References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <652209b4bbc0f68db9be688228979ff0@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav WG From: Lisa Dusseault Date: Fri, 28 Oct 2005 15:23:34 -0700 To: Jim Whitehead 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 1EVcdU-0006ut-SK cc1cf2419013823683d96ccc21fd0d02 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/652209b4bbc0f68db9be688228979ff0@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10234 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 22:23:48 +0000 Content-Transfer-Encoding: 7bit On Oct 28, 2005, at 3:13 PM, Jim Whitehead wrote: >> What if I remove the header from the response example, in addition to >> Jim's suggested change? >> > > Urk, bad idea. > > The use of Location with MOVE is to be consistent with the semantics > of the 201 response code. I read this a little differently than you -- I don't see that Location is REQUIRED with the 201 response code. So I don't see a problem with leaving it out of a 201 Created response to a MOVE, but I'm not adamant either way. > > So, the suggested text has to be more precise. Perhaps: > > "The use of the Location header with the 207 status code is > intentionally undefined." > > However, even this I'm starting to feel is a bad idea. Why do we stop > at Location? Why not create a table with all HTTP headers and state > whether they should be used with 207? > Indeed. It's certainly more work, but this kind of thing can be extremely valuable to implementors. As we can see from the discussion over the list of response codes that could and couldn't be used in 207 responses, it's a fine line to walk and quite possible to overspecify. Perhaps if we had a table where many of the cell values were simply "undefined" instead of "MUST NOT use" we'd have a better compromise... Lisa From w3c-dist-auth-request@frink.w3.org Fri Oct 28 18:27:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVchN-0004HR-H0 for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:27:45 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23913 for ; Fri, 28 Oct 2005 18:27:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVcgp-0003WX-50 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 22:27:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVcgo-0003Vz-O7 for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 22:27:10 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVcgd-00030C-VY for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 22:27:10 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2DFE4142283; Fri, 28 Oct 2005 15:26:59 -0700 (PDT) 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 01740-07; Fri, 28 Oct 2005 15:26:59 -0700 (PDT) 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 9705614227F; Fri, 28 Oct 2005 15:26:58 -0700 (PDT) In-Reply-To: <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu> References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu> 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, 28 Oct 2005 15:26:50 -0700 To: Jim Whitehead 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 1EVcgd-00030C-VY 8810ae06d476847052207f206cad1dcc X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/b8ffda1e19f36687c23f2fe29aef7a4a@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10235 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 22:27:11 +0000 Content-Transfer-Encoding: 7bit On Oct 28, 2005, at 3:13 PM, Jim Whitehead wrote: >> What if I remove the header from the response example, in addition to >> Jim's suggested change? >> > > Urk, bad idea. > > The use of Location with MOVE is to be consistent with the semantics > of the 201 response code. > Tacking on to my previous comment where I said I didn't think Location was REQUIRED with 201... note that in RFC2518, we had an example of MKCOL, where the response was 201 Created without a Location header: 8.3.3 Example - MKCOL This example creates a collection called /webdisc/xfiles/ on the server www.server.org. >>Request MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.server.org >>Response HTTP/1.1 201 Created -- Lisa From w3c-dist-auth-request@frink.w3.org Fri Oct 28 18:28:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVciE-0004yY-N0 for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:28:38 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23940 for ; Fri, 28 Oct 2005 18:28:21 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVchg-0003ek-5n for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 22:28:04 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVchf-0003e9-Kf for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 22:28: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 1EVchb-0005vC-Ke for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 22:28:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9SMRvR8021134; Fri, 28 Oct 2005 15:27:57 -0700 Date: Fri, 28 Oct 2005 15:27:57 -0700 Message-Id: <200510282227.j9SMRvR8021134@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 1EVchb-0005vC-Ke 9d5f588357db85d1028d2f23a05cdd96 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/200510282227.j9SMRvR8021134@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10236 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 22:28:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 ------- Additional Comments From lisa@osafoundation.org 2005-10-28 15:27 ------- We seemed to have agreement to remove 8.1.3, along with other mentions of using the Location header or element along with or inside 207 Multi-Status responses. (Instead, if the server has a new/changed location for a resource, the 3xx level response can be used and the client would probably reissue the request). Along the way we've noticed another couple sub-issues, like what text to add about the Location header and 207 (Jim suggested explicitly leaving its interaction undefined). ------- 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 Oct 28 18:49:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVd2n-0006Xy-Ko for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:49:53 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24801 for ; Fri, 28 Oct 2005 18:49:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVd24-00085m-07 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 22:49:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVd20-00085E-Tx for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 22:49:04 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVd1y-00060e-MJ for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 22:49:04 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1731C142285 for ; Fri, 28 Oct 2005 15:49:02 -0700 (PDT) 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 09524-06 for ; Fri, 28 Oct 2005 15:49:01 -0700 (PDT) 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 865AA14225A for ; Fri, 28 Oct 2005 15:49:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <4361152A.5030403@cse.ucsc.edu> References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-15--238806442 Message-Id: From: Lisa Dusseault Date: Fri, 28 Oct 2005 15:48:52 -0700 To: w3c-dist-auth@w3.org 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 1EVd1y-00060e-MJ 5af4b5d108ddeeb5b95f1d6f0c6d5389 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/c79ea955e419d09f6b557f50473d97bd@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10237 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 22:49:08 +0000 --Apple-Mail-15--238806442 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 27, 2005, at 10:58 AM, Elias Sinderson wrote: > > Julian Reschke wrote: > >> 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. > > I have no issues with the proposed text. > > > Cheers, > Elias > > It's not just the Lock-Token response header that shows the lock token in response to LOCK, the token also appears in the lockdiscovery property value, which is included in the body of the LOCK response. There's a couple issues that the section on lock tokens should address: - how lock tokens relate to locks (one and only one) - who generates them, how, and requirements (uniqueness, that clients MUST not interpret) - where to get them (Lock-Token response, lockdiscovery property) So here's the (work-in-progress) text for the whole section on lock tokens, including my attempts to incorporate several bits of suggested text in a readable order, while also being complete: ---- 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 Section 9.6 (Lock-Token Header), and also in the body of the response. Also note that lock tokens MUST appear in the 'lockdiscovery' property of a locked resource. 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 Universal Unique Identifier (UUID) [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. Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" ---- There were some comments in a previous email from Julian about how the lock token might not appear in the 'lockdiscovery' property if there are multiple (shared) locks on the resource. This statement doesn't fit my understanding, so I haven't yet "fixed" that if I am indeed wrong. Doesn't the 'lockdiscovery' property include every active lock on the resource and all their lock tokens? Lisa --Apple-Mail-15--238806442 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Oct 27, 2005, at 10:58 AM, Elias Sinderson wrote: Julian Reschke wrote: 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. I have no issues with the proposed text. Cheers, Elias It's not just the Lock-Token response header that shows the lock token in response to LOCK, the token also appears in the lockdiscovery property value, which is included in the body of the LOCK response. There's a couple issues that the section on lock tokens should address: - how lock tokens relate to locks (one and only one) - who generates them, how, and requirements (uniqueness, that clients MUST not interpret) - where to get them (Lock-Token response, lockdiscovery property) So here's the (work-in-progress) text for the whole section on lock tokens, including my attempts to incorporate several bits of suggested text in a readable order, while also being complete: ---- Courier 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 Section 9.6 (Lock-Token Header), and also in the body of the response. Also note that lock tokens MUST appear in the 'lockdiscovery' property of a locked resource. 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 Universal Unique Identifier (UUID) [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. Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" ---- There were some comments in a previous email from Julian about how the lock token might not appear in the 'lockdiscovery' property if there are multiple (shared) locks on the resource. This statement doesn't fit my understanding, so I haven't yet "fixed" that if I am indeed wrong. Doesn't the 'lockdiscovery' property include every active lock on the resource and all their lock tokens? Lisa --Apple-Mail-15--238806442-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 18:51:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVd4T-000769-Un for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:51:38 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24835 for ; Fri, 28 Oct 2005 18:51:20 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVd3v-0000Hw-P3 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 22:51:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVd3v-0000HJ-7r for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 22:51:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVd3r-0001oC-CR for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 22:51:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9SMovI8021156; Fri, 28 Oct 2005 15:50:57 -0700 Date: Fri, 28 Oct 2005 15:50:57 -0700 Message-Id: <200510282250.j9SMovI8021156@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.3 X-W3C-Scan-Sig: maggie.w3.org 1EVd3r-0001oC-CR c3f83a6ad3a541b6b893804cd74a2be2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200510282250.j9SMovI8021156@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10238 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 22:51:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 ------- Additional Comments From lisa@osafoundation.org 2005-10-28 15:50 ------- I don't understand the issue of shared locks and lockdiscovery -- I thought that all active locks had to show up in lockdiscovery, along with their tokens. I am fine with "has exactly one" and have made that change in local copy. ------- 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 Oct 28 19:15:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVdRu-0000vZ-PV for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 19:15:50 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25927 for ; Fri, 28 Oct 2005 19:15:33 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVdRA-0004Mx-4Z for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Oct 2005 23:15:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVdR4-0003yI-Vt for w3c-dist-auth@listhub.w3.org; Fri, 28 Oct 2005 23:14:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVdQu-0000iK-B1 for w3c-dist-auth@w3.org; Fri, 28 Oct 2005 23:14:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9SNEgFO021195; Fri, 28 Oct 2005 16:14:42 -0700 Date: Fri, 28 Oct 2005 16:14:42 -0700 Message-Id: <200510282314.j9SNEgFO021195@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 1EVdQu-0000iK-B1 9bb0c1772cf8863082b97f1dd5ff9cfb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 24] lost-update vs collections X-Archived-At: http://www.w3.org/mid/200510282314.j9SNEgFO021195@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10239 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Oct 2005 23:15:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=24 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-10-28 16:14 ------- I believe we've come to consensus on this one, and I've updated local copy, so I believe this is 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 Oct 28 22:52:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVgpQ-0003NS-U7 for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 22:52:21 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04952 for ; Fri, 28 Oct 2005 22:52:04 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVgnf-0002aT-Mk for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 02:50:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVgnc-0002Zv-FI for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 02:50:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVgnY-0007u9-BE for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 02:50:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9T2oMhx021334; Fri, 28 Oct 2005 19:50:22 -0700 Date: Fri, 28 Oct 2005 19:50:22 -0700 Message-Id: <200510290250.j9T2oMhx021334@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 1EVgnY-0007u9-BE ac49ccba68e763fd7e1cc6739b709564 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/200510290250.j9T2oMhx021334@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10240 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 02:50:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-10-28 19:50 ------- What does this do that the "Expect 100-continue" header already defined by HTTP doesn't already do? ------- 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 Oct 28 23:07:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVh4F-0001Rl-RW for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 23:07:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05392 for ; Fri, 28 Oct 2005 23:07:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVh3X-0005uy-UZ for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 03:06:55 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVh3W-0005uQ-UE for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 03:06:55 +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 1EVh3S-00032H-Mu for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 03:06:54 +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 j9T36kYx003267 for ; Fri, 28 Oct 2005 23:06:46 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9T36jVd122134 for ; Fri, 28 Oct 2005 23:06:45 -0400 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 j9T36jOJ011303 for ; Fri, 28 Oct 2005 23:06:45 -0400 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 j9T36jff011300 for ; Fri, 28 Oct 2005 23:06:45 -0400 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: Fri, 28 Oct 2005 23:06:46 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/28/2005 23:06:44, Serialize complete at 10/28/2005 23:06:44 Content-Type: multipart/alternative; boundary="=_alternative 00111B68852570A9_=" 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 1EVh3S-00032H-Mu 6bfbc6ea60937119f6174aff6c3a9c86 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/OF22EF860C.72B10690-ON852570A9.001021EB-852570A9.00111BDC@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10241 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 03:06:55 +0000 This is a multipart message in MIME format. --=_alternative 00111B68852570A9_= Content-Type: text/plain; charset="US-ASCII" To avoid sending the PUT body twice, why can't a client just use the standard HTTP "Expect 100-Continue" header? And if a client is proactively checking for authentication preceding a series of PUT calls, then having it just perform an initial LOCK/UNLOCK to get the credential challenge doesn't seem like an unreasonable overhead (2 initial requests). So is this just a technique for servers that want to provide this capability but don't want to support LOCK? Cheers, Geoff Jim wrote on 10/27/2005 08:34:39 PM: > > > > > Julian writes: > > > So this is a process issue -- if it's supposed to become part of > > WebDAV, it has to make it through the process of (1) define what > > the problem is, then (2) find a WG consensus of how to resolve > > this. "Force-Authenticate" may very well be the solution. > > OK, I feel pretty strongly about this feature, so let me do the due > diligence here. > > PROBLEM STATEMENT > > Some WebDAV servers are configured to allow live authoring, where the > authored changes are immediately visible to the external world. In > this situation, resources typically have access controls set such > that GET, HEAD, POST, PROPFIND and OPTIONS can be performed by any > user without authentication. Write operations such as PUT, LOCK, > UNLOCK, MKCOL, MOVE, and COPY require authentication and access > permissions. In some cases, a client would do a series of operations > that do not require authentication, then perform a PUT of a large > resource (this can happen with the common Microsoft Web Folders > client). In this situation, the large resource body needs to be sent > twice: the initial PUT (which gets a 401 response), and the second > PUT, with authentication credentials. > > Ideally, a client would like to test a resource to see whether it > should ever send authentication credentials. It is far more > convenient for a client author to make a single test at the beginning > of a session, discover that some methods will require authentication > credentials, and then consistently supply those authentication > credentials for every method invocation thereafter. Since a client > does not know which authentication scheme is in use, or what nonce > values will be used in Digest Auth, it cannot speculatively provide > authentication values without receiving a challenge (401) from the > server first. While in general it is the case that authentication > requirements can vary by method, even on the same resource, this > configuration is extremely unusual. Hence, a client that proactively > supplies a set of authentication credentials gathered from testing > one method that requires authentication (PUT, say), will likely find > that these same authentication credentials will work for all other > methods (LOCK, UNLOCK, etc.) on the same resource that also require > authentication. > > SOLUTION REQUIREMENTS > > R1: A client must be able to request an authentication challenge > without causing a state change on the server > R2: The mechanism for the authentication challenge must be clearly > identifiable within the specification > R3: The client must be able to indicate which method the challenge > pertains to (since this can potentially vary by method, though it > usually doesn't) > > SOLUTION PROPOSAL > > I like the Force-Authenticate header as defined in the current draft. > I don't like the If approach (submit an If header with a known bad > lock token, hence the method will fail) for three reasons: > > * I feel uncomfortable depending on an unintended use of the If > header -- especially for PUT, if a server ever doesn't handle If > correctly, the forcing of authentication could inadvertently change > the contents of the resource (assuming you'd force authentication > with a zero length body with PUT) > * It depends on the execution order of authentication vs. If header > processing within servers (I note this was rebutted in: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ > 0335.html and I also note that mod_dav does do authentication checks > before If checks) > * It's a really obscure way of satisfying the requirements (i.e., it > fails requirement R2) > > > My strong preference is for a new mechanism here (Force- > Authenticate), though I could perhaps be swayed to adding a new > section to the specification that explicitly describes the use of If > to force authentication, and gives an example of how this works. I > don't think this mechanism is one that most implementors would think > of, even if the have a deep understanding of the spec (like, me, for > example, who never thought of this). > > - Jim > > > > > > > --=_alternative 00111B68852570A9_= Content-Type: text/html; charset="US-ASCII"
To avoid sending the PUT body twice, why can't a client just
use the standard HTTP "Expect 100-Continue" header?

And if a client is proactively checking for authentication preceding
a series of PUT calls, then having it just perform an initial LOCK/UNLOCK
to get the credential challenge doesn't seem like an unreasonable overhead
(2 initial requests).

So is this just a technique for servers that want to provide this
capability but don't want to support LOCK?  

Cheers,
Geoff

Jim wrote on 10/27/2005 08:34:39 PM:
>
> >
>
> Julian writes:
>
> > So this is a process issue -- if it's supposed to become part of  
> > WebDAV, it has to make it through the process of (1) define what  
> > the problem is, then (2) find a WG consensus of how to resolve  
> > this. "Force-Authenticate" may very well be the solution.
>
> OK, I feel pretty strongly about this feature, so let me do the due  
> diligence here.
>
> PROBLEM STATEMENT
>
> Some WebDAV servers are configured to allow live authoring, where the  
> authored changes are immediately visible to the external world. In  
> this situation, resources typically have access controls set such  
> that GET, HEAD, POST, PROPFIND and OPTIONS can be performed by any  
> user without authentication. Write operations such as PUT, LOCK,  
> UNLOCK, MKCOL, MOVE, and COPY require authentication and access  
> permissions. In some cases, a client would do a series of operations  
> that do not require authentication, then perform a PUT of a large  
> resource (this can happen with the common Microsoft Web Folders  
> client). In this situation, the large resource body needs to be sent  
> twice: the initial PUT (which gets a 401 response), and the second  
> PUT, with authentication credentials.
>
> Ideally, a client would like to test a resource to see whether it  
> should ever send authentication credentials. It is far more  
> convenient for a client author to make a single test at the beginning  
> of a session, discover that some methods will require authentication  
> credentials, and then consistently supply those authentication  
> credentials for every method invocation thereafter. Since a client  
> does not know which authentication scheme is in use, or what nonce  
> values will be used in Digest Auth, it cannot speculatively provide  
> authentication values without receiving a challenge (401) from the  
> server first. While in general it is the case that authentication  
> requirements can vary by method, even on the same resource, this  
> configuration is extremely unusual. Hence, a client that proactively  
> supplies a set of authentication credentials gathered from testing  
> one method that requires authentication (PUT, say), will likely find  
> that these same authentication credentials will work for all other  
> methods (LOCK, UNLOCK, etc.) on the same resource that also require  
> authentication.
>
> SOLUTION REQUIREMENTS
>
> R1: A client must be able to request an authentication challenge  
> without causing a state change on the server
> R2:  The mechanism for the authentication challenge must be clearly  
> identifiable within the specification
> R3: The client must be able to indicate which method the challenge  
> pertains to (since this can potentially vary by method, though it  
> usually doesn't)
>
> SOLUTION PROPOSAL
>
> I like the Force-Authenticate header as defined in the current draft.  
> I don't like the If approach (submit an If header with a known bad  
> lock token, hence the method will fail) for three reasons:
>
> * I feel uncomfortable depending on an unintended use of the If  
> header -- especially for PUT, if a server ever doesn't handle If  
> correctly, the forcing of authentication could inadvertently change  
> the contents of the resource (assuming you'd force authentication  
> with a zero length body with PUT)
> * It depends on the execution order of authentication vs. If header  
> processing within servers (I note this was rebutted in:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/
> 0335.html  and I also note that mod_dav does do authentication checks  
> before If checks)
> * It's a really obscure way of satisfying the requirements (i.e., it  
> fails requirement R2)
>
>
> My strong preference is for a new mechanism here (Force-
> Authenticate), though I could perhaps be swayed to adding a new  
> section to the specification that explicitly describes the use of If  
> to force authentication, and gives an example of how this works. I  
> don't think this mechanism is one that most implementors would think  
> of, even if the have a deep understanding of the spec (like, me, for  
> example, who never thought of this).
>
> - Jim
>
>
>
>
>
>
>
--=_alternative 00111B68852570A9_=-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 23:21:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVhHa-0006vS-Dy for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 23:21:28 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05877 for ; Fri, 28 Oct 2005 23:21:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVhGq-0008Ik-KJ for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 03:20:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVhGm-0008I5-RG for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 03:20:36 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVhGi-0002Jt-Gi for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 03:20:36 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9T3KVPs018404 for ; Fri, 28 Oct 2005 23:20:32 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9T3KVVd105946 for ; Fri, 28 Oct 2005 23:20:31 -0400 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 j9T3KVJI027384 for ; Fri, 28 Oct 2005 23:20:31 -0400 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 j9T3KVUN027381; Fri, 28 Oct 2005 23:20:31 -0400 In-Reply-To: To: Lisa Dusseault Cc: w3c-dist-auth@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, 28 Oct 2005 23:20:32 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/28/2005 23:20:30, Serialize complete at 10/28/2005 23:20:30 Content-Type: multipart/alternative; boundary="=_alternative 00125DDB852570A9_=" Received-SPF: pass (lisa.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.4 X-W3C-Scan-Sig: lisa.w3.org 1EVhGi-0002Jt-Gi e32234690b84377e01907bc833d6234e 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/OF3715E79F.D08F02C3-ON852570A9.0011E0AA-852570A9.00125E38@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10242 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 03:20:40 +0000 This is a multipart message in MIME format. --=_alternative 00125DDB852570A9_= Content-Type: text/plain; charset="US-ASCII" The last sentence is incorrect. A lock token appears in a PROPFIND lockdiscovery only if the server wishes to expose it. I have argued in the past that a sensible server should never expose a lock token in a PROPFIND lockdiscovery, since it just allows a client of a user to incorrectly re-use a lock token still in use by another client of that user. So if we say anything, it should "A server SHOULD NOT include a lock token in a PROPFIND lockdiscovery, since it introduces the possibility of two clients of a given user overwriting each others changes". Cheers, Geoff Lisa wrote on 10/28/2005 06:48:52 PM: > > On Oct 27, 2005, at 10:58 AM, Elias Sinderson wrote: > > > > > Julian Reschke wrote: > > > >> 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. > > > > I have no issues with the proposed text. > > > > > > Cheers, > > Elias > > > > > It's not just the Lock-Token response header that shows the lock token > in response to LOCK, the token also appears in the lockdiscovery > property value, which is included in the body of the LOCK response. > There's a couple issues that the section on lock tokens should address: > - how lock tokens relate to locks (one and only one) > - who generates them, how, and requirements (uniqueness, that clients > MUST not interpret) > - where to get them (Lock-Token response, lockdiscovery property) > > So here's the (work-in-progress) text for the whole section on lock > tokens, including my attempts to incorporate several bits of suggested > text in a readable order, while also being complete: > > ---- > > 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 Section 9.6 > (Lock-Token Header), and also in the body of the response. Also note > that lock tokens MUST appear in the 'lockdiscovery' property of a > locked resource. > > 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 Universal Unique Identifier (UUID) > [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. > > Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > > ---- > > There were some comments in a previous email from Julian about how the > lock token might not appear in the 'lockdiscovery' property if there > are multiple (shared) locks on the resource. This statement doesn't > fit my understanding, so I haven't yet "fixed" that if I am indeed > wrong. Doesn't the 'lockdiscovery' property include every active lock > on the resource and all their lock tokens? > > Lisa --=_alternative 00125DDB852570A9_= Content-Type: text/html; charset="US-ASCII"
The last sentence is incorrect.  A lock token appears in a PROPFIND
lockdiscovery only if the server wishes to expose it.  I have argued
in the past that a sensible server should never expose a lock token in a
PROPFIND lockdiscovery, since it just allows a client of a user
to incorrectly re-use a lock token still in use by another client
of that user.  So if we say anything, it should "A server SHOULD NOT
include a lock token in a PROPFIND lockdiscovery, since it introduces
the possibility of two clients of a given user overwriting each others
changes".

Cheers,
Geoff

Lisa wrote on 10/28/2005 06:48:52 PM:

>
> On Oct 27, 2005, at 10:58 AM, Elias Sinderson wrote:
>
> >
> > Julian Reschke wrote:
> >
> >> 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.
> >
> > I have no issues with the proposed text.
> >
> >
> > Cheers,
> > Elias
> >
> >
> It's not just the Lock-Token response header that shows the lock token
> in response to LOCK, the token also appears in the lockdiscovery
> property value, which is included in the body of the LOCK response.  
> There's a couple issues that the section on lock tokens should address:
>   - how lock tokens relate to locks (one and only one)
>   - who generates them, how, and requirements (uniqueness, that clients
> MUST not interpret)
>   - where to get them (Lock-Token response, lockdiscovery property)
>
> So here's the (work-in-progress) text for the whole section on lock
> tokens, including my attempts to incorporate several bits of suggested
> text in a readable order, while also being complete:
>
> ----
>
>   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 Section 9.6
> (Lock-Token Header), and also in the body of the response. Also note
> that lock tokens MUST appear in the 'lockdiscovery' property of a
> locked resource.
>
> 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 Universal Unique Identifier (UUID)  
> [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.
>
> Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
>
> ----
>
> There were some comments in a previous email from Julian about how the
> lock token might not appear in the 'lockdiscovery' property if there
> are multiple (shared) locks on the resource.  This statement doesn't
> fit my understanding, so I haven't yet "fixed" that if I am indeed
> wrong.  Doesn't the 'lockdiscovery' property include every active lock
> on the resource and all their lock tokens?
>
> Lisa
 --=_alternative 00125DDB852570A9_=-- From w3c-dist-auth-request@frink.w3.org Fri Oct 28 23:25:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVhLg-0000JD-S5 for webdav-archive@megatron.ietf.org; Fri, 28 Oct 2005 23:25:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06008 for ; Fri, 28 Oct 2005 23:25:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVhKz-0008WR-4P for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 03:24:57 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVhKx-0008VX-8n; Sat, 29 Oct 2005 03:24:55 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EVhKq-0005hb-0Z; Sat, 29 Oct 2005 03:24:54 +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 j9T3Og4T028048; Fri, 28 Oct 2005 23:24:42 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9T3OgVd111960; Fri, 28 Oct 2005 23:24:42 -0400 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 j9T3OgOI018852; Fri, 28 Oct 2005 23:24:42 -0400 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 j9T3OgLu018849; Fri, 28 Oct 2005 23:24:42 -0400 In-Reply-To: <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> To: Jim Whitehead Cc: Lisa Dusseault , 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: Fri, 28 Oct 2005 23:24:43 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/28/2005 23:24:41, Serialize complete at 10/28/2005 23:24:41 Content-Type: multipart/alternative; boundary="=_alternative 0012BF9B852570A9_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: 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: aji.w3.mag.keio.ac.jp 1EVhKq-0005hb-0Z 75196ce0d8ae8b0e4181670927182469 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/OFF7E79E1C.A3D4D4BF-ON852570A9.0012A4DC-852570A9.0012C060@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10243 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 03:24:57 +0000 This is a multipart message in MIME format. --=_alternative 0012BF9B852570A9_= Content-Type: text/plain; charset="US-ASCII" +1 for either Jim's suggested text or saying nothing, and +1 that we then close this issue. Cheers, Geoff Jim wrote on 10/28/2005 05:38:38 PM: > Lisa writes: > > However, without those pieces of text, the use of the Location > header with 207 responses becomes undefined, and that always makes > me feel uncomfortable. Server implementors won't know for sure if > they can use the Location header, it seems logical that it might > work but as we've seen there are some subtleties in how the client > might interpret that. Clients are probably not prepared to handle > it. So I propose that we include text to be clear that the Location > header SHOULD NOT appear in certain responses. > > The HTTP specification generally doesn't explain all interactions of > methods, headers, and response codes. Location only has defined > semantics for certain response codes in HTTP. > > On the other hand, the HTTP spec. isn't necessarily such a paragon > of good writing that we should strive to emulate it. > > My solution to this issue is to add the text: > > "Use of the Location header with the methods and response codes > defined in this specification is intentionally undefined." > > And leave it at that. This lets clients know they can't depend on > the feature, and lets servers know they probably shouldn't go there. > But, if a later spec. does add something here (like a refined > REDIRECT spec.), then the door is left open for new behavior. > > Can we please close this issue? > > - Jim > > I'm sensitive to the worry of preventing extensions but surely > there's some way of dealing with that. An extension can override > "SHOULD" level requirements, or we could come up with some > "exception" language... as in "servers SHOULD NOT return a Location > header in these responses unless the client has some way to > interpret that header." > > Lisa > > On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote: > > +1 > > w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM: > > > > > > > > > > Julian writes: > > > Back to this issue: > > > > > > 1) I'm not aware of any interop problems. > > > > > > 2) I'm not aware of anybody having asked about this. > > > > > > 3) I don't see any benefit in RFC2518bis making statements about > > > this, even if we *did* agree on what to say > > > > I have just read through this entire thread, and I agree with his > > statement above, and the conclusion Julian reached in: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html > > > > Specifically: > > > > * I don't think there is a compelling need to disallow Location and 207 > > * I don't think we need any special mechanism for handling 3xx within > > a PROPFIND > > * I think it's fine if a client needs to retry a PROPFIND request if > > it receives a 3xx response > > > > I feel a slight desire to add a 3xx response to one of the PROPFIND > > 207 response examples in the text, but could live without it. > > > > Unless others chime in, I think we're seeing rough consensus for > > removing the current 8.1.3, whose text is described in Bug 12 within > > Bugzilla: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12 > > > > - Jim > > > > > > > > --=_alternative 0012BF9B852570A9_= Content-Type: text/html; charset="US-ASCII"
+1 for either Jim's suggested text or saying nothing,
and +1 that we then close this issue.

Cheers,
Geoff


Jim wrote on 10/28/2005 05:38:38 PM:

> Lisa writes:
>
> However, without those pieces of text, the use of the Location
> header with 207 responses becomes undefined, and that always makes
> me feel uncomfortable.    Server implementors won't know for sure if
> they can use the Location header, it seems logical that it might
> work but as we've seen there are some subtleties in how the client
> might interpret that.  Clients are probably not prepared to handle
> it.  So I propose that we include text to be clear that the Location
> header SHOULD NOT appear in certain responses.  
>
> The HTTP specification generally doesn't explain all interactions of
> methods, headers, and response codes. Location only has defined
> semantics for certain response codes in HTTP.
>
> On the other hand, the HTTP spec. isn't necessarily such a paragon
> of good writing that we should strive to emulate it.
>
> My solution to this issue is to add the text:
>
> "Use of the Location header with the methods and response codes
> defined in this specification is intentionally undefined."
>
> And leave it at that. This lets clients know they can't depend on
> the feature, and lets servers know they probably shouldn't go there.
> But, if a later spec. does add something here (like a refined
> REDIRECT spec.), then the door is left open for new behavior.
>
> Can we please close this issue?
>
> - Jim
>
> I'm sensitive to the worry of preventing extensions but surely
> there's some way of dealing with that.  An extension can override
> "SHOULD" level requirements, or we could come up with some
> "exception" language... as in "servers SHOULD NOT return a Location
> header in these responses unless the client has some way to
> interpret that header."
>
> Lisa 
>
> On Oct 27, 2005, at 8:17 PM, Geoffrey M Clemm wrote:
>
> +1 
>
> w3c-dist-auth-request@w3.org wrote on 10/27/2005 07:50:06 PM:
>
>  > 
>  > >
>  > 
>  > Julian writes:
>  > > Back to this issue:
>  > >
>  > > 1) I'm not aware of any interop problems.
>  > >
>  > > 2) I'm not aware of anybody having asked about this.
>  > >
>  > > 3) I don't see any benefit in RFC2518bis making statements about  
>  > > this, even if we *did* agree on what to say
>  > 
>  > I have just read through this entire thread, and I agree with his  
>  > statement above, and the conclusion Julian reached in:
>  > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0294.html
>  > 
>  > Specifically:
>  > 
>  > * I don't think there is a compelling need to disallow Location and 207
>  > * I don't think we need any special mechanism for handling 3xx within  
>  > a PROPFIND
>  > * I think it's fine if a client needs to retry a PROPFIND request if  
>  > it receives a 3xx response
>  > 
>  > I feel a slight desire to add a 3xx response to one of the PROPFIND  
>  > 207 response examples in the text, but could live without it.
>  > 
>  > Unless others chime in, I think we're seeing rough consensus for  
>  > removing the current 8.1.3, whose text is described in Bug 12 within  
>  > Bugzilla:
>  > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=12
>  > 
>  > - Jim
>  > 
>  > 
>  > 
>  >  --=_alternative 0012BF9B852570A9_=-- From w3c-dist-auth-request@frink.w3.org Sat Oct 29 00:08:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVi1Q-0008W6-Q8 for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 00:08:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07532 for ; Sat, 29 Oct 2005 00:08:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVi0Y-00088I-Cw for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 04:07:54 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVi0U-00087f-Q3 for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 04:07:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EVi0Q-0003Ef-Rl for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 04:07:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j9T47ifY021403; Fri, 28 Oct 2005 21:07:44 -0700 Date: Fri, 28 Oct 2005 21:07:44 -0700 Message-Id: <200510290407.j9T47ifY021403@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 1EVi0Q-0003Ef-Rl 396221351546e567482dac2aa14c87bd 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/200510290407.j9T47ifY021403@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10244 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 04:07:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 ------- Additional Comments From lisa@osafoundation.org 2005-10-28 21:07 ------- Interestingly, this approach would prevent the client from sending the big request body, which "Force-Authenticate" wouldn't do (unless the client used it on an OPTIONS before using it on the big PUT). The thing is, I don't think a lot of servers implement this (I can't think of any that do for sure). It would be good to collect some data. ------- 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 Oct 29 00:13:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVi5k-0001Yk-MU for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 00:13:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07692 for ; Sat, 29 Oct 2005 00:12:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVi5A-0000MZ-Ar for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 04:12:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVi59-0000M1-Te for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 04:12:39 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVi51-00018z-CU for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 04:12:39 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A20EC142285; Fri, 28 Oct 2005 21:12:30 -0700 (PDT) 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 27479-02; Fri, 28 Oct 2005 21:12:30 -0700 (PDT) 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 593D4142283; Fri, 28 Oct 2005 21:12:28 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-18--219400086 Message-Id: <5ba70ae5437fcf14ad9089cce16c2989@osafoundation.org> Cc: " webdav" From: Lisa Dusseault Date: Fri, 28 Oct 2005 21:12:18 -0700 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 1EVi51-00018z-CU ceb33b35773a6b7867b8f8c6da6690a5 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/5ba70ae5437fcf14ad9089cce16c2989@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10245 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 04:12:40 +0000 --Apple-Mail-18--219400086 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable No it's not just for LOCK and PUT -- a client doing read-only requests=20= (like PROPFIND) might see different results depending on whether or not=20= they're authenticated. Some of the resources in a collection might be=20= publicly readable (so the PROPFIND can succeed if anonymous) but others=20= be hidden to unauthenticated users. More generally, it's not actually a WebDAV problem alone. If a client=20= does a GET to a dynamically generated page, they could easily see=20 different results based on whether they're authenticated or not. Since=20= browsers today often cache authentication information, this means that=20= the browser could inform the server that they'd like the challenge to=20 save the user the step of first going to the site, seeing the anonymous=20= page version, then choosing to login. Of course some sites use cookies=20= for this but cookies are sometimes disabled, expired, etc. Lisa On Oct 28, 2005, at 8:06 PM, Geoffrey M Clemm wrote: > > To avoid sending the PUT body twice, why can't a client just > use the standard HTTP "Expect 100-Continue" header? > > And if a client is proactively checking for authentication preceding > a series of PUT calls, then having it just perform an initial=20 > LOCK/UNLOCK > to get the credential challenge doesn't seem like an unreasonable=20 > overhead > (2 initial requests). > > So is this just a technique for servers that want to provide this > capability but don't want to support LOCK? =A0 > > Cheers, > Geoff > > Jim wrote on 10/27/2005 08:34:39 PM: > > > > > > > > > Julian writes: > > > > > So this is a process issue -- if it's supposed to become part of = =A0 > > > WebDAV, it has to make it through the process of (1) define what = =A0 > > > the problem is, then (2) find a WG consensus of how to resolve =A0 > > > this. "Force-Authenticate" may very well be the solution. > > > > OK, I feel pretty strongly about this feature, so let me do the due=20= > =A0 > > diligence here. > > > > PROBLEM STATEMENT > > > > Some WebDAV servers are configured to allow live authoring, where=20= > the =A0 > > authored changes are immediately visible to the external world. In = =A0 > > this situation, resources typically have access controls set such =A0= > > that GET, HEAD, POST, PROPFIND and OPTIONS can be performed by any = =A0 > > user without authentication. Write operations such as PUT, LOCK, =A0 > > UNLOCK, MKCOL, MOVE, and COPY require authentication and access =A0 > > permissions. In some cases, a client would do a series of=20 > operations =A0 > > that do not require authentication, then perform a PUT of a large =A0= > > resource (this can happen with the common Microsoft Web Folders =A0 > > client). In this situation, the large resource body needs to be=20 > sent =A0 > > twice: the initial PUT (which gets a 401 response), and the second = =A0 > > PUT, with authentication credentials. > > > > Ideally, a client would like to test a resource to see whether it =A0= > > should ever send authentication credentials. It is far more =A0 > > convenient for a client author to make a single test at the=20 > beginning =A0 > > of a session, discover that some methods will require=20 > authentication =A0 > > credentials, and then consistently supply those authentication =A0 > > credentials for every method invocation thereafter. Since a client = =A0 > > does not know which authentication scheme is in use, or what nonce = =A0 > > values will be used in Digest Auth, it cannot speculatively provide=20= > =A0 > > authentication values without receiving a challenge (401) from the = =A0 > > server first. While in general it is the case that authentication =A0= > > requirements can vary by method, even on the same resource, this =A0 > > configuration is extremely unusual. Hence, a client that=20 > proactively =A0 > > supplies a set of authentication credentials gathered from testing = =A0 > > one method that requires authentication (PUT, say), will likely=20 > find =A0 > > that these same authentication credentials will work for all other = =A0 > > methods (LOCK, UNLOCK, etc.) on the same resource that also require=20= > =A0 > > authentication. > > > > SOLUTION REQUIREMENTS > > > > R1: A client must be able to request an authentication challenge =A0 > > without causing a state change on the server > > R2: =A0The mechanism for the authentication challenge must be = clearly=20 > =A0 > > identifiable within the specification > > R3: The client must be able to indicate which method the challenge = =A0 > > pertains to (since this can potentially vary by method, though it =A0= > > usually doesn't) > > > > SOLUTION PROPOSAL > > > > I like the Force-Authenticate header as defined in the current=20 > draft. =A0 > > I don't like the If approach (submit an If header with a known bad = =A0 > > lock token, hence the method will fail) for three reasons: > > > > * I feel uncomfortable depending on an unintended use of the If =A0 > > header -- especially for PUT, if a server ever doesn't handle If =A0 > > correctly, the forcing of authentication could inadvertently change=20= > =A0 > > the contents of the resource (assuming you'd force authentication =A0= > > with a zero length body with PUT) > > * It depends on the execution order of authentication vs. If header=20= > =A0 > > processing within servers (I note this was rebutted in: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ > > 0335.html =A0and I also note that mod_dav does do authentication=20 > checks =A0 > > before If checks) > > * It's a really obscure way of satisfying the requirements (i.e.,=20= > it =A0 > > fails requirement R2) > > > > > > My strong preference is for a new mechanism here (Force- > > Authenticate), though I could perhaps be swayed to adding a new =A0 > > section to the specification that explicitly describes the use of=20= > If =A0 > > to force authentication, and gives an example of how this works. I = =A0 > > don't think this mechanism is one that most implementors would=20 > think =A0 > > of, even if the have a deep understanding of the spec (like, me,=20 > for =A0 > > example, who never thought of this). > > > > - Jim > > > > > > > > > > > > > > --Apple-Mail-18--219400086 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No it's not just for LOCK and PUT -- a client doing read-only requests (like PROPFIND) might see different results depending on whether or not they're authenticated. Some of the resources in a collection might be publicly readable (so the PROPFIND can succeed if anonymous) but others be hidden to unauthenticated users. 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.=20 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. Lisa On Oct 28, 2005, at 8:06 PM, Geoffrey M Clemm wrote: To avoid sending the PUT body twice, why can't a client just=20 use the standard HTTP "Expect 100-Continue" header?=20 And if a client is proactively checking for authentication preceding=20 a series of PUT calls, then having it just perform an initial LOCK/UNLOCK=20 to get the credential challenge doesn't seem like an unreasonable overhead=20 (2 initial requests).=20 So is this just a technique for servers that want to provide this=20 capability but don't want to support LOCK? =A0=20 Cheers, Geoff=20 Jim wrote on 10/27/2005 08:34:39 = PM: > > > > > Julian writes: > > > So this is a process issue -- if it's supposed to become part of =A0 > > WebDAV, it has to make it through the process of (1) define what =A0 > > the problem is, then (2) find a WG consensus of how to resolve =A0 > > this. "Force-Authenticate" may very well be the solution. > > OK, I feel pretty strongly about this feature, so let me do the due =A0 > diligence here. > > PROBLEM STATEMENT > > Some WebDAV servers are configured to allow live authoring, where the =A0 > authored changes are immediately visible to the external world. In =A0 > this situation, resources typically have access controls set such =A0 > that GET, HEAD, POST, PROPFIND and OPTIONS can be performed by any =A0 > user without authentication. Write operations such as PUT, LOCK, =A0 > UNLOCK, MKCOL, MOVE, and COPY require authentication and access =A0 > permissions. In some cases, a client would do a series of operations =A0 > that do not require authentication, then perform a PUT of a large =A0 > resource (this can happen with the common Microsoft Web Folders =A0 > client). In this situation, the large resource body needs to be sent =A0 > twice: the initial PUT (which gets a 401 response), and the second =A0 > PUT, with authentication = credentials. > > Ideally, a client would like to test a resource to see whether it =A0 > should ever send authentication credentials. It is far more =A0 > convenient for a client author to make a single test at the beginning =A0 > of a session, discover that some methods will require authentication =A0 > credentials, and then consistently supply those authentication =A0 > credentials for every method invocation thereafter. Since a client =A0 > does not know which authentication scheme is in use, or what nonce =A0 > values will be used in Digest Auth, it cannot speculatively provide =A0 > authentication values without receiving a challenge (401) from the =A0 > server first. While in general it is the case that authentication =A0 > requirements can vary by method, even on the same resource, this =A0 > configuration is extremely unusual. Hence, a client that proactively =A0 > supplies a set of authentication credentials gathered from testing =A0 > one method that requires authentication (PUT, say), will likely find =A0 > that these same authentication credentials will work for all other =A0 > methods (LOCK, UNLOCK, etc.) on the same resource that also require =A0 > authentication. > > SOLUTION REQUIREMENTS > > R1: A client must be able to request an authentication challenge =A0 > without causing a state change on the = server > R2: =A0The mechanism for the authentication challenge must be clearly =A0 > identifiable within the = specification > R3: The client must be able to indicate which method the challenge =A0 > pertains to (since this can potentially vary by method, though it =A0 > usually doesn't) > > SOLUTION PROPOSAL > > I like the Force-Authenticate header as defined in the current draft. =A0 > I don't like the If approach (submit an If header with a known bad =A0 > lock token, hence the method will fail) for three reasons: > > * I feel uncomfortable depending on an unintended use of the If =A0 > header -- especially for PUT, if a server ever doesn't handle If =A0 > correctly, the forcing of authentication could inadvertently change =A0 > the contents of the resource (assuming you'd force authentication =A0 > with a zero length body with = PUT) > * It depends on the execution order of authentication vs. If header =A0 > processing within servers (I note this was rebutted in: > = http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ > 0335.html =A0and I also note that mod_dav does do authentication checks =A0 > before If checks) > * It's a really obscure way of satisfying the requirements (i.e., it =A0 > fails requirement R2) > > > My strong preference is for a new mechanism here (Force- > Authenticate), though I could perhaps be swayed to adding a new =A0 > section to the specification that explicitly describes the use of If =A0 > to force authentication, and gives an example of how this works. I =A0 > don't think this mechanism is one that most implementors would think =A0 > of, even if the have a deep understanding of the spec (like, me, for =A0 > example, who never thought of = this). > > - Jim > > > > > > > = --Apple-Mail-18--219400086-- From w3c-dist-auth-request@frink.w3.org Sat Oct 29 03:37:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVlH6-0007rm-M5 for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 03:37:12 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17183 for ; Sat, 29 Oct 2005 03:36:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVlFn-0001rA-Jf for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 07:35:51 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVlFk-0001qc-Cw for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 07:35:48 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EVlFh-00068L-QY for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 07:35:47 +0000 Received: (qmail invoked by alias); 29 Oct 2005 07:35:43 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp016) with SMTP; 29 Oct 2005 09:35:43 +0200 X-Authenticated: #1915285 Message-ID: <4363263C.1070602@gmx.de> Date: Sat, 29 Oct 2005 09:35:24 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: WebDav References: <4354195C.5090609@gmx.de> <7f41642fbdb24d201540e74aacfa5421@osafoundation.org> <4354A9CA.1020106@gmx.de> <758A815E-7329-481A-A184-7F20B4D9B10B@cs.ucsc.edu> <43557ADF.2070801@gmx.de> <43622BEF.3060706@gmx.de> <13C9A2E9-0542-4F70-BE10-E67740B606C3@cs.ucsc.edu> In-Reply-To: <13C9A2E9-0542-4F70-BE10-E67740B606C3@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 (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 1EVlFh-00068L-QY 55419ebb9980138a62ea5f889459fb6a 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/4363263C.1070602@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10246 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 07:35:51 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >> >> I have no problem adding non-normative text explaining this. >> > > I'm thinking that the right choice here is to create an appendix > describing the problem, and the recommended solution(s). While I agree > that we shouldn't be wily-nilly giving implementation advice, this is a > common enough problem, whose solution is sufficiently non- obvious, that > adding appendix text makes sense. > > I also think we should add a force-authenticate feature, but I think it > makes sense to put this in a separate "DAV-fixes" draft. This draft can > accumulate items like Force-Authenticate, and the reliable etags for > the body and dead properties, etc. I'll take an action item to start > creating this draft. I'll make it a private draft, so Cullen doesn't > have to justify the creation of a new WG item :-) Sounds good. From w3c-dist-auth-request@frink.w3.org Sat Oct 29 03:38:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVlId-0000A5-Al for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 03:38:48 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17360 for ; Sat, 29 Oct 2005 03:38:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVlI4-00025t-KJ for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 07:38:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVlI4-00025L-75 for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 07:38:12 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EVlI2-0008Ar-EG for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 07:38:12 +0000 Received: (qmail invoked by alias); 29 Oct 2005 07:38:08 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp014) with SMTP; 29 Oct 2005 09:38:08 +0200 X-Authenticated: #1915285 Message-ID: <436326CC.6080602@gmx.de> Date: Sat, 29 Oct 2005 09:37:48 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: WebDav References: <435228CF.3000709@gmx.de> <435276E9.1040901@gmx.de> <43527FD9.4020007@gmx.de> <4354D63B.5050201@gmx.de> <435A8C00.90709@gmx.de> <435DCD5D.1020704@gmx.de> <4361D852.3010501@gmx.de> <2e730b30844ecb2d74d323ab19d4b6a2@osafoundation.org> <436275C7.8060006@gmx.de> <4B120317-C04E-4589-AEA7-0547B172EC7A@cs.ucsc.edu> In-Reply-To: <4B120317-C04E-4589-AEA7-0547B172EC7A@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 (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 1EVlI2-0008Ar-EG fd22904e09def393de526c58f7f4d2fa X-Original-To: w3c-dist-auth@w3.org Subject: Re: Editing rfc2518bis.xml X-Archived-At: http://www.w3.org/mid/436326CC.6080602@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10247 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 07:38:12 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Julian, > > I'm unclear what changes Lisa needs to make at this point. Are there > specific figures that are causing a problem? No, these have been fixed. > Also, I don't think it's fair to ding Lisa for using the released > version of xml2rfc, while you're using the unreleased head of the > development tree. I'm not doing that. I was just stating that I if she uses the "strict" mode, figures need to fit into the 69 character limit, otherwise the conversion doesn't work over here (remember: it would be much simpler if Lisa would publish the TXT and HTML along with the XML; I was *volunteering* to do ths over here). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 03:44:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVlO5-0002Qr-5h for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 03:44:26 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17650 for ; Sat, 29 Oct 2005 03:44:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVlNR-0002fm-Hn for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 07:43:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVlNQ-0002f7-Nz for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 07:43:44 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EVlNN-0007bb-AI for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 07:43:44 +0000 Received: (qmail invoked by alias); 29 Oct 2005 07:43:39 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp032) with SMTP; 29 Oct 2005 09:43:39 +0200 X-Authenticated: #1915285 Message-ID: <43632818.6040609@gmx.de> Date: Sat, 29 Oct 2005 09:43:20 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: WebDav WG References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> <43627F41.7020806@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 1EVlNN-0007bb-AI 7485cdc6930a5abcaeba7d846784ae28 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/43632818.6040609@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10248 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 07:43:45 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >> More changes that I think do not represent WG consensus: >> >> 1: > latest.html#rfc.section.9.5.3.p.4>: >> >> -- >> 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. >> -- > > > This sounds right to me. > >> >> This now says MUST instead of "must". I'm not sure why RFC2119 >> terminology is invoked here. URIs in the DAV: namespace by definition >> never represent a lock token, because they can only be assigned by >> the IETF or this WG. So the statement applies to *all* URIs that use >> the DAV: URI scheme, "DAV:no-lock" is just one example. >> >> If you really feel that this needs to be stated somewhere, please >> don't make it sound as if "DAV:no-lock" is different from -- for >> instance -- "DAV:lock". > > > I know there was an issue with organizations adding things to the DAV: > namespace without using the IETF process. However, this section doesn't > seem like the right place to address this issue. OK, but hat doesn't change the argument. No URI in the DAV: scheme ever identifies a valid lock token, by definition. Saying "MUST" and only stating "DAV:no-lock" *will* cause implementors to add special code for this one string. >> 2: > latest-from-07.diff.html#diff-30>: >> >> Why was the registration for "opaquelocktoken" removed from the IANA >> considerations? Thinking of it, why was the definition for the "DAV" >> URI scheme removed as well????? >> > > Based on Ted Hardie's email of today, it sounds like these will > continue to be registered, whether in the IANA considerations section > or no. That said, it would be useful to have a brief sentence to the > effect of, "the URI registrations for opaquelocktoken and DAV URI > schemes made in RFC 2518 should still be considered active." Jim, does that mean that we leave out all stuff that doesn't need changes? People would still be able to look it up in RFC2518, after all. Me confused. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 03:48:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVlSE-0003uJ-Hw for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 03:48:42 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17793 for ; Sat, 29 Oct 2005 03:48:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVlRb-0004Ty-IV for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 07:48:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVlRZ-0004TQ-OE for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 07:48:01 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EVlRY-0001Y7-6z for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 07:48:01 +0000 Received: (qmail invoked by alias); 29 Oct 2005 07:47:58 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp021) with SMTP; 29 Oct 2005 09:47:58 +0200 X-Authenticated: #1915285 Message-ID: <4363291B.8030007@gmx.de> Date: Sat, 29 Oct 2005 09:47:39 +0200 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: Jim Whitehead , WebDav WG References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> <43627F41.7020806@gmx.de> <37c36b8f513c0689cd220e7e3cd04039@osafoundation.org> In-Reply-To: <37c36b8f513c0689cd220e7e3cd04039@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 1EVlRY-0001Y7-6z 53e1321a28d65cfac67acbc41af447dc 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/4363291B.8030007@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10249 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 07:48:03 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > On Oct 28, 2005, at 2:51 PM, Jim Whitehead wrote: > >> URI registrations for opaquelocktoken and DAV URI schemes made in RFC >> 2518 should still be considered active." >> > > While looking at the IANA considerations section, this text caught my eye: > > This document defines two namespaces, the namespace of property > names, and the namespace of WebDAV-specific XML elements used within > property values. > > I don't count two namespace, just one (DAV:). any objections if I fix > this sentence? Yes. This section defines namespaces (spaces of names), not XML namespaces. in fact, we have even more spaces of names in use: - in property values - in precondition/postcondition names - in resource types - in report names (RFC3253) - in ACEs (RFC3744) This probably means that we shouldn't list them all, but simply try to make a generaln statement how WebDAV uses XML-based identifiers in different contexts, and that usage of identifiers in the "DAV:" namespace is controlled by the IETF. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04:05:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVlib-00024L-4b for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:05:43 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18285 for ; Sat, 29 Oct 2005 04:05:18 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVlho-0008U1-Kg for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:04:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVlhn-0007mm-QQ for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:04:48 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EVlc5-00024t-0S for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 07:58:56 +0000 Received: (qmail invoked by alias); 29 Oct 2005 07:58:51 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp035) with SMTP; 29 Oct 2005 09:58:51 +0200 X-Authenticated: #1915285 Message-ID: <43632BA7.4000909@gmx.de> Date: Sat, 29 Oct 2005 09:58:31 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: WebDav WG References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> In-Reply-To: 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 1EVlc5-00024t-0S f694ae86d09352a97b00b609ce70577c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Combined set of issues around lock tokens, examples, schemes X-Archived-At: http://www.w3.org/mid/43632BA7.4000909@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10250 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:04:48 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA18285 Jim Whitehead wrote: >> If the working group wants people to propose ready-for-spec text, then= =20 >> I think that text should either be used, or those you don't like it=20 >> should at least state what was wrong with it. >=20 >=20 > I don't think the editor should have to defend every minor text change.= =20 > In particular, I think some of Lisa's additions are good (and she caugh= t=20 > one error in the ABNF that you missed). However, you did catch a few=20 Don't think so. > minor errors, and one case of overspecification. Gee, it's almost like=20 > when multiple people collaborate on a document, the final result is of=20 > higher quality :-) Yes, it is. However, I think we would be even more productive if text=20 that is proposed actually gets discussed, instead of being ignored.=20 Unless we want people to stop making proposals, if it starts to look=20 like a waste of time. >> For the record, I proposed: >> >> Appendix C. 'opaquelocktoken' URI Scheme >> >> The 'opaquelocktoken' URI scheme defined below uses the Universal >> Unique Identifier (UUID) mechanism ([9], Section 4) to easily >> generate lock tokens fulfilling the uniqueness requirements stated = in >> Section 6.3. >> >> OpaqueLockToken-URI =3D "opaquelocktoken:" UUID [path] >> ; UUID: see [RFC4122], Section 3. >> ; path: see [RFC3986], Section 3.3. >> >> Note that the optional "path" postfix allows to generate many lock >> tokens from a single URI, by appending an varying string such as a >> sequence number. >> >> Example: >> >> opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017 >=20 >=20 > I like this text, but I think Lisa does have some valuable contribution= s. >=20 > Lisa's note about LWS is necessary, since otherwise you could have any=20 > amount of LWS between "opaquelocktoken:" and UUID and [path]. Really? I'm no ABNF expert, but that seems to be incorrect. If it's=20 true, we need similar text for the TimeType production in the Timeout=20 () header. > I also generally like Lisa's new introduction sentence, since it=20 > provides a modicum of context for the appendix. >=20 > I'd tweak the introduction sentence slightly: >=20 > The 'opaquelocktoken' URI scheme can be used by servers to create=20 > syntactically correct and easy-to-generate URIs out of UUIDs, intended=20 > to be used as lock tokens, meeting the requirements for uniqueness=20 > across all resources for all time.=20 >=20 >=20 >> 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. >=20 >=20 > This is implicit in the ABNF definition for opaquelocktoken, and doesn'= t=20 > need to be stated.=20 That's true; but it gives the raison d'=EAtre for this URI scheme. Once=20 I'm being a bit more verbose :-) >> OpaqueLockToken-URI =3D "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. >=20 >=20 > For this section, I recommend: >=20 > OpaqueLockToken-URI =3D "opaquelocktoken:" UUID [path] > ; UUID: see [RFC4122], Section 3. > ; path: see [RFC3986], Section 3.3. > Note that white space (LWS) is not allowed between elements of this=20 > production. See above. > ... Best regards, and thanks fore reviewing both proposals. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04:22:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVlyj-0000ZM-4q for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:22:19 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18792 for ; Sat, 29 Oct 2005 04:21:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVlxx-0003zo-6l for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:21:29 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVlxv-0003zG-9J for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:21:27 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EVlxh-00032m-Nb for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 08:21:26 +0000 Received: (qmail invoked by alias); 29 Oct 2005 08:21:06 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp026) with SMTP; 29 Oct 2005 10:21:06 +0200 X-Authenticated: #1915285 Message-ID: <436330DD.2050603@gmx.de> Date: Sat, 29 Oct 2005 10:20:45 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm 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 1EVlxh-00032m-Nb e546aae16427c30a6e9e00e9df55335c 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/436330DD.2050603@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10251 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:21:29 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > To avoid sending the PUT body twice, why can't a client just > use the standard HTTP "Expect 100-Continue" header? It could, but it's a known problem that few servers implement that correctly, meaning that the expected header check is indeed skipped (for instance, a server using the servlet API normally doesn't have any chance doing this check, see ). > And if a client is proactively checking for authentication preceding > a series of PUT calls, then having it just perform an initial LOCK/UNLOCK > to get the credential challenge doesn't seem like an unreasonable overhead > (2 initial requests). > > So is this just a technique for servers that want to provide this > capability but don't want to support LOCK? Seems so, because LOCK seems to be yet another existing way to get what those clients want. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04:23:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVm0L-0001DO-Kx for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:23:57 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18834 for ; Sat, 29 Oct 2005 04:23:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVlzm-0004Df-VO for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:23:22 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVlzm-0004D2-FR for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:23:22 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EVlzj-0006qQ-Od for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 08:23:22 +0000 Received: (qmail invoked by alias); 29 Oct 2005 08:23:18 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp027) with SMTP; 29 Oct 2005 10:23:18 +0200 X-Authenticated: #1915285 Message-ID: <43633161.9010102@gmx.de> Date: Sat, 29 Oct 2005 10:22:57 +0200 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 References: <5ba70ae5437fcf14ad9089cce16c2989@osafoundation.org> In-Reply-To: <5ba70ae5437fcf14ad9089cce16c2989@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 1EVlzj-0006qQ-Od e8ba32b6a528fc9706232622088648ea 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/43633161.9010102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10252 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:23:22 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > No it's not just for LOCK and PUT -- a client doing read-only requests > (like PROPFIND) might see different results depending on whether or not > they're authenticated. Some of the resources in a collection might be > publicly readable (so the PROPFIND can succeed if anonymous) but others > be hidden to unauthenticated users. But you could still use LOCK to enforce authentication, right? > 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. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04:26:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVm2j-0002FF-0q for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:26:25 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18894 for ; Sat, 29 Oct 2005 04:26:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVm2A-0004tc-3B for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:25:50 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVm29-0004t4-AK for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:25:49 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EVm25-0003vH-RV for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 08:25:48 +0000 Received: (qmail invoked by alias); 29 Oct 2005 08:25:43 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp012) with SMTP; 29 Oct 2005 10:25:43 +0200 X-Authenticated: #1915285 Message-ID: <436331F1.7040601@gmx.de> Date: Sat, 29 Oct 2005 10:25:21 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: Lisa Dusseault , WebDav References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> In-Reply-To: <401EBF99-85EB-4468-B20C-E07045249A22@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 1EVm25-0003vH-RV a32e68601f8a9f1f67a33d62aa1e5daa X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/436331F1.7040601@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10253 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:25:50 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > ... > My solution to this issue is to add the text: > > "Use of the Location header with the methods and response codes defined > in this specification is intentionally undefined." No, that's completely incorrect. It's defined in RFC2616, and what RFC2616 says also applies to WebDAV. For instance, it's absolutely well-defined what it means to get a 302 + Location header upon PROPFIND. > And leave it at that. This lets clients know they can't depend on the > feature, and lets servers know they probably shouldn't go there. But, if > a later spec. does add something here (like a refined REDIRECT spec.), > then the door is left open for new behavior. > > Can we please close this issue? As far as I can tell, the simplest way to close this issue is to revert back to what RFC2518 says. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04: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 1EVm5M-0003Fo-Fo for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:29:08 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18996 for ; Sat, 29 Oct 2005 04:28:49 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVm4k-00054G-Pu for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:28:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVm4k-00053d-1v for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:28: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 1EVm4g-0007rz-Lz for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 08:28:29 +0000 Received: (qmail invoked by alias); 29 Oct 2005 08:28:25 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp028) with SMTP; 29 Oct 2005 10:28:25 +0200 X-Authenticated: #1915285 Message-ID: <43633293.9080602@gmx.de> Date: Sat, 29 Oct 2005 10:28:03 +0200 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: Jim Whitehead , WebDav References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> 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 1EVm4g-0007rz-Lz 39e3d1acd9739d2a2b8ff03f8360ac69 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/43633293.9080602@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10254 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:28:30 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > One thing I noticed when checking this against and editing the text > (sometimes this turns up new observations): We actually use the Location > header in response to a MOVE request, in section 8.9.5 of RFC2518. Yet > there's no explanation for this -- the text around the example doesn't > indicate whether the server could have chosen a different destination > URL (which seems very harmful to interoperability to me) or, if not, why > the Location header is even needed. > ... RFC2616 recommends to use the Location header when a new resource is created: That is, if you consider MOVE as a sequence of COPY-then-DELETE, this is exactly the right thing to do. As I personally prefer MOVE to work differently, I'd be happy to change that example, but that's *really* a different issue from what we were discussing here. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04:30:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVm6q-0003m8-Un for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:30:41 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19040 for ; Sat, 29 Oct 2005 04:30:22 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVm6A-0005CV-RF for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:29:58 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVm69-0005Bx-Ud for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:29:58 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EVm65-0004jx-BJ for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 08:29:56 +0000 Received: (qmail invoked by alias); 29 Oct 2005 08:29:50 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp009) with SMTP; 29 Oct 2005 10:29:50 +0200 X-Authenticated: #1915285 Message-ID: <436332E8.9070208@gmx.de> Date: Sat, 29 Oct 2005 10:29:28 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: Lisa Dusseault , WebDav WG References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu> In-Reply-To: <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@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 1EVm65-0004jx-BJ 0e8c3be9ddd9450f43990b879ee22b53 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/436332E8.9070208@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10255 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:29:58 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > ... > However, even this I'm starting to feel is a bad idea. Why do we stop at > Location? Why not create a table with all HTTP headers and state whether > they should be used with 207? > > - Jim Hey! I see light at the end of the tunnel :-) Generally, the set of things we do not define is open-ended. I'm against making statements about these things, unless they clearly result in confusion and interop problems. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04:34:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVmA5-0005Bq-2p for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:34:01 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19134 for ; Sat, 29 Oct 2005 04:33:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVm9S-00073h-JT for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:33:22 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVm9R-000739-N9 for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:33:21 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EVm9N-0000Lo-Uk for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 08:33:21 +0000 Received: (qmail invoked by alias); 29 Oct 2005 08:33:17 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp029) with SMTP; 29 Oct 2005 10:33:17 +0200 X-Authenticated: #1915285 Message-ID: <436333B7.8000602@gmx.de> Date: Sat, 29 Oct 2005 10:32:55 +0200 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: Jim Whitehead , WebDav WG References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu> 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 1EVm9N-0000Lo-Uk 0cf35d7f5b926bdd8ca90fd2d404e822 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/436333B7.8000602@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10256 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:33:22 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > On Oct 28, 2005, at 3:13 PM, Jim Whitehead wrote: > >>> What if I remove the header from the response example, in addition to >>> Jim's suggested change? >>> >> >> Urk, bad idea. >> >> The use of Location with MOVE is to be consistent with the semantics >> of the 201 response code. >> > Tacking on to my previous comment where I said I didn't think Location > was REQUIRED with 201... note that in RFC2518, we had an example of > MKCOL, where the response was 201 Created without a Location header: > > 8.3.3 Example - MKCOL > > This example creates a collection called /webdisc/xfiles/ on the > server www.server.org. > > >>Request > > MKCOL /webdisc/xfiles/ HTTP/1.1 > Host: www.server.org > > >>Response > > HTTP/1.1 201 Created > Lisa, would you *please* read the sections from RFC2616 that define this? Again, from : "The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource." The location isn't different, so no new URI is needed. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04:40:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVmGh-0007dE-8f for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:40:51 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19318 for ; Sat, 29 Oct 2005 04:40:32 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVmFi-0007eP-RH for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:39:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVmFi-0007dq-8l for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:39:50 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EVmFe-0001W1-6M for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 08:39:49 +0000 Received: (qmail invoked by alias); 29 Oct 2005 08:39:45 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp024) with SMTP; 29 Oct 2005 10:39:45 +0200 X-Authenticated: #1915285 Message-ID: <4363353B.2050804@gmx.de> Date: Sat, 29 Oct 2005 10:39:23 +0200 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: w3c-dist-auth@w3.org References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> 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 1EVmFe-0001W1-6M 0dad74349e9367c6e452e97390dd584c 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/4363353B.2050804@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10257 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:39:50 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > On Oct 27, 2005, at 10:58 AM, Elias Sinderson wrote: > > > Julian Reschke wrote: > > 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. > > > I have no issues with the proposed text. > > > Cheers, > Elias > > > It's not just the Lock-Token response header that shows the lock token > in response to LOCK, the token also appears in the lockdiscovery > property value, which is included in the body of the LOCK response. Yes. But does this need to be stated here? The right place to state it are the definitions for the LOCK method and the DAV:lockdiscovery property. Why repeat it here? > There's a couple issues that the section on lock tokens should address: > - how lock tokens relate to locks (one and only one) > - who generates them, how, and requirements (uniqueness, that clients > MUST not interpret) > - where to get them (Lock-Token response, lockdiscovery property) > > So here's the (work-in-progress) text for the whole section on lock > tokens, including my attempts to incorporate several bits of suggested > text in a readable order, while also being complete: > > ---- > > 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 Section 9.6 (Lock-Token > Header), and also in the body of the response. Also note that lock > tokens MUST appear in the 'lockdiscovery' property of a locked resource. I don't see any benefit of stating this here. What clients are interested in is how to get the lock token once they issues the LOCK, and the *only* correct answer to that is to use the response header. Mentioning a different mechanism here would at least require to make statements about when it won't work (shared locks), leading to even more spec text & confusion. > 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 Universal Unique Identifier (UUID) > [9]. However servers are free to use another valid URI so long as it That reference seems to use the wrong title, the spec is called "A Universally Unique IDentifier (UUID) URN Namespace". > 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" Example and text don't match. > ---- > > There were some comments in a previous email from Julian about how the > lock token might not appear in the 'lockdiscovery' property if there are > multiple (shared) locks on the resource. This statement doesn't fit my > understanding, so I haven't yet "fixed" that if I am indeed wrong. > Doesn't the 'lockdiscovery' property include every active lock on the > resource and all their lock tokens? Yes. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 04:44:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVmKY-0000z2-E2 for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 04:44:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19425 for ; Sat, 29 Oct 2005 04:44:31 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVmJu-00005c-1T for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 08:44:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVmJt-0008Vf-8h for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 08:44:09 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EVmJo-0002Gw-Bo for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 08:44:08 +0000 Received: (qmail invoked by alias); 29 Oct 2005 08:44:03 -0000 Received: from p508FB821.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.33] by mail.gmx.net (mp012) with SMTP; 29 Oct 2005 10:44:03 +0200 X-Authenticated: #1915285 Message-ID: <4363363B.9030606@gmx.de> Date: Sat, 29 Oct 2005 10:43:39 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: Lisa Dusseault , 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 (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 1EVmJo-0002Gw-Bo e4ebe812c4d7e685343bbc957051aba2 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/4363363B.9030606@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10258 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 08:44:10 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > The last sentence is incorrect. A lock token appears in a PROPFIND > lockdiscovery only if the server wishes to expose it. I have argued > in the past that a sensible server should never expose a lock token in a > PROPFIND lockdiscovery, since it just allows a client of a user > to incorrectly re-use a lock token still in use by another client > of that user. So if we say anything, it should "A server SHOULD NOT > include a lock token in a PROPFIND lockdiscovery, since it introduces > the possibility of two clients of a given user overwriting each others > changes". Here I'll disagree with Geoff :-) "lock stealing" is further controlled (or can be controlled) by checking the principal as well. I *do* agree that it makes sense to have one coherent section that gives advice on how not to reveal lock tokens. For instance, servers are allowed to report the locks, but not to disclose the lock tokens (see ). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 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 1EVpuN-000655-JP for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 08:34:05 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28628 for ; Sat, 29 Oct 2005 08:33:45 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVpsv-0006Dn-T4 for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 12:32:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVpss-0006DF-Hn for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 12:32:30 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVpso-0006BL-8J for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 12:32:30 +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 j9TCWMBH020007 for ; Sat, 29 Oct 2005 08:32:22 -0400 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 j9TCWLaC107550 for ; Sat, 29 Oct 2005 08:32:22 -0400 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 j9TCWLiE005248 for ; Sat, 29 Oct 2005 08:32:21 -0400 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 j9TCWLTS005242 for ; Sat, 29 Oct 2005 08:32:21 -0400 In-Reply-To: <4363363B.9030606@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: Sat, 29 Oct 2005 08:32:23 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/29/2005 08:32:21, Serialize complete at 10/29/2005 08:32:21 Content-Type: multipart/alternative; boundary="=_alternative 0044E435852570A9_=" 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.4 X-W3C-Scan-Sig: maggie.w3.org 1EVpso-0006BL-8J 2c0585acf85c904afa5635db58ad2466 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/OF1FD337AB.8AE61795-ON852570A9.00444B22-852570A9.0044E47F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10259 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 12:32:33 +0000 This is a multipart message in MIME format. --=_alternative 0044E435852570A9_= Content-Type: text/plain; charset="US-ASCII" The likelihood of damage from lock stealing can be decreased by only allowing a given user/principal to steal his own locks, but (as indicated in my original message below :-) it does not prevent two clients of a given user/principal from overwriting each others changes. Since there is a completely safe way of handling this scenario (i.e., streaming an UNLOCK/LOCK sequence to the server), I maintain my position that a client should never "steal" a lock by discovering the lock-token via PROPFIND, even if that lock was held by another client of that same user, and therefore lock tokens should never be exposed in a PROPFIND. Cheers, Geoff Geoff wrote on 10/29/2005 04:43:39 AM: > > Geoffrey M Clemm wrote: > > > > The last sentence is incorrect. A lock token appears in a PROPFIND > > lockdiscovery only if the server wishes to expose it. I have argued > > in the past that a sensible server should never expose a lock token in a > > PROPFIND lockdiscovery, since it just allows a client of a user > > to incorrectly re-use a lock token still in use by another client > > of that user. So if we say anything, it should "A server SHOULD NOT > > include a lock token in a PROPFIND lockdiscovery, since it introduces > > the possibility of two clients of a given user overwriting each others > > changes". > > Here I'll disagree with Geoff :-) > > "lock stealing" is further controlled (or can be controlled) by checking > the principal as well. > > I *do* agree that it makes sense to have one coherent section that gives > advice on how not to reveal lock tokens. For instance, servers are > allowed to report the locks, but not to disclose the lock tokens (see > ). > > Best regards, Julian > --=_alternative 0044E435852570A9_= Content-Type: text/html; charset="US-ASCII"
The likelihood of damage from lock stealing can be decreased by
only allowing a given user/principal to steal his own locks, but
(as indicated in my original message below :-) it does not prevent
two clients of a given user/principal from overwriting each others
changes.  Since there is a completely safe way of handling this
scenario (i.e., streaming an UNLOCK/LOCK sequence to the server),
I maintain my position that a client should never "steal"
a lock by discovering the lock-token via PROPFIND, even if that
lock was held by another client of that same user, and therefore
lock tokens should never be exposed in a PROPFIND.

Cheers,
Geoff

Geoff wrote on 10/29/2005 04:43:39 AM:
>
> Geoffrey M Clemm wrote:
> >
> > The last sentence is incorrect.  A lock token appears in a PROPFIND
> > lockdiscovery only if the server wishes to expose it.  I have argued
> > in the past that a sensible server should never expose a lock token in a
> > PROPFIND lockdiscovery, since it just allows a client of a user
> > to incorrectly re-use a lock token still in use by another client
> > of that user.  So if we say anything, it should "A server SHOULD NOT
> > include a lock token in a PROPFIND lockdiscovery, since it introduces
> > the possibility of two clients of a given user overwriting each others
> > changes".
>
> Here I'll disagree with Geoff :-)
>
> "lock stealing" is further controlled (or can be controlled) by checking
> the principal as well.
>
> I *do* agree that it makes sense to have one coherent section that gives
> advice on how not to reveal lock tokens. For instance, servers are
> allowed to report the locks, but not to disclose the lock tokens (see
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.12.1>).
>
> Best regards, Julian
>
--=_alternative 0044E435852570A9_=-- From w3c-dist-auth-request@frink.w3.org Sat Oct 29 08: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 1EVq6U-0002dl-84 for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 08:46:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29082 for ; Sat, 29 Oct 2005 08:46:16 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVq5j-000160-0j for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 12:45:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVq5i-00015S-Ce for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 12:45:46 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVq5f-0000Lv-2J for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 12:45:45 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9TCjfPI022293 for ; Sat, 29 Oct 2005 08:45:41 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9TCjfAU107914 for ; Sat, 29 Oct 2005 08:45:41 -0400 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 j9TCjeS6029135 for ; Sat, 29 Oct 2005 08:45:40 -0400 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 j9TCjeSO029131 for ; Sat, 29 Oct 2005 08:45:40 -0400 In-Reply-To: <436330DD.2050603@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: Sat, 29 Oct 2005 08:45:42 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/29/2005 08:45:40, Serialize complete at 10/29/2005 08:45:40 Content-Type: multipart/alternative; boundary="=_alternative 00461C1F852570A9_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EVq5f-0000Lv-2J 20384f13b721889e98ccb9ad1cc7635b 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/OF69B23A75.4B5E4716-ON852570A9.00456790-852570A9.00461C9B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10260 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 12:45:47 +0000 This is a multipart message in MIME format. --=_alternative 00461C1F852570A9_= Content-Type: text/plain; charset="US-ASCII" I agree that LOCK is the real answer here for WebDAV clients. But for the "force-authenticate" advocates (which Julian is not): If we are contrasting "Expect 100-Continue" vs. "force-authenticate", I think it would make more sense to advise servers to implement Expect correctly rather than to introduce a new force-authenticate header. In particular, why would one believe that a server that doesn't implement Expect properly would implement force-authenticate properly (or at all). Cheers, Geoff Julian wrote on 10/29/2005 04:20:45 AM: > > Geoffrey M Clemm wrote: > > > > To avoid sending the PUT body twice, why can't a client just > > use the standard HTTP "Expect 100-Continue" header? > > It could, but it's a known problem that few servers implement that > correctly, meaning that the expected header check is indeed skipped (for > instance, a server using the servlet API normally doesn't have any > chance doing this check, see > ). > > > And if a client is proactively checking for authentication preceding > > a series of PUT calls, then having it just perform an initial LOCK/UNLOCK > > to get the credential challenge doesn't seem like an unreasonable overhead > > (2 initial requests). > > > > So is this just a technique for servers that want to provide this > > capability but don't want to support LOCK? > > Seems so, because LOCK seems to be yet another existing way to get what > those clients want. > > Best regards, Julian > --=_alternative 00461C1F852570A9_= Content-Type: text/html; charset="US-ASCII"
I agree that LOCK is the real answer here for WebDAV clients.

But for the "force-authenticate" advocates (which Julian is not):
If we are contrasting "Expect 100-Continue" vs. "force-authenticate",
I think it would make more sense to advise servers to implement Expect
correctly rather than to introduce a new force-authenticate header.
In particular, why would one believe that a server that doesn't implement
Expect properly would implement force-authenticate properly (or at all).

Cheers,
Geoff

Julian wrote on 10/29/2005 04:20:45 AM:
>
> Geoffrey M Clemm wrote:
> >
> > To avoid sending the PUT body twice, why can't a client just
> > use the standard HTTP "Expect 100-Continue" header?
>
> It could, but it's a known problem that few servers implement that
> correctly, meaning that the expected header check is indeed skipped (for
> instance, a server using the servlet API normally doesn't have any
> chance doing this check, see
> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4812000>).
>
> > And if a client is proactively checking for authentication preceding
> > a series of PUT calls, then having it just perform an initial LOCK/UNLOCK
> > to get the credential challenge doesn't seem like an unreasonable overhead
> > (2 initial requests).
> >
> > So is this just a technique for servers that want to provide this
> > capability but don't want to support LOCK?  
>
> Seems so, because LOCK seems to be yet another existing way to get what
> those clients want.
>
> Best regards, Julian
>
--=_alternative 00461C1F852570A9_=-- From w3c-dist-auth-request@frink.w3.org Sat Oct 29 09:13:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVqWz-0004yN-9y for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 09:13:59 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00237 for ; Sat, 29 Oct 2005 09:13:39 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVqVq-0005q4-Hi for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 13:12:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVqVo-0005pW-Tc for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 13:12:44 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EVqVl-0006iA-Jh for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 13:12:44 +0000 Received: (qmail invoked by alias); 29 Oct 2005 13:12:32 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 29 Oct 2005 15:12:32 +0200 X-Authenticated: #1915285 Message-ID: <43637526.1010406@gmx.de> Date: Sat, 29 Oct 2005 15:12:06 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm 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 1EVqVl-0006iA-Jh 068bfee73146528a7399cdf721bc047d 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/43637526.1010406@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10261 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 13:12:46 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > The likelihood of damage from lock stealing can be decreased by > only allowing a given user/principal to steal his own locks, but > (as indicated in my original message below :-) it does not prevent > two clients of a given user/principal from overwriting each others > changes. Since there is a completely safe way of handling this Partly correct. Some clients put stuff into DAV:owner in order to ensure that they can recognize the locks they created, but of course that's lame compared to just remembering which locks one created in the first place. > scenario (i.e., streaming an UNLOCK/LOCK sequence to the server), > I maintain my position that a client should never "steal" > a lock by discovering the lock-token via PROPFIND, even if that > lock was held by another client of that same user, and therefore > lock tokens should never be exposed in a PROPFIND. Well, from a purely theoretical point of view, I agree. In practice, clients do lock discovery instead of keeping track of their locks on their own, so these clients wouldn't work in this case. BTW: if a server does not want to expose lock tokens, it can also show the locks, but leave out the DAV:locktoken child element. Anyway, this is certainly a topic where on coherent paragraph would make a lot of sense. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 09:17:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVqaF-00067T-FR for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 09:17:20 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00342 for ; Sat, 29 Oct 2005 09:17:01 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVqZD-0007Uj-JP for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 13:16:15 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVqZC-0007U3-Q0 for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 13:16:15 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EVqZ8-0001Xv-Ny for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 13:16:13 +0000 Received: (qmail invoked by alias); 29 Oct 2005 13:16:03 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 29 Oct 2005 15:16:03 +0200 X-Authenticated: #1915285 Message-ID: <436375F8.3060703@gmx.de> Date: Sat, 29 Oct 2005 15:15:36 +0200 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: w3c-dist-auth@w3.org References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> 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 1EVqZ8-0001Xv-Ny efd10a1f4170cb40c93d38d6c521afc5 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/436375F8.3060703@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10262 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 13:16:15 +0000 Content-Transfer-Encoding: 7bit Clarifying one thing on second read: Lisa Dusseault wrote: >... > There were some comments in a previous email from Julian about how the > lock token might not appear in the 'lockdiscovery' property if there are > multiple (shared) locks on the resource. This statement doesn't fit my No, what I said (or meant to say is) that looking at DAV:lockdiscovery in general will not help you at all, because it may contain *multiple* entries (Geoff correctly pointed out later that it may not be there at all). The only *reliable* way to find out the lock token a LOCK request created is to look at the "Lock-Token" response header. This is the only method that will always work, so please let's not waste time confusing people by talking about other methods that may or may not work. > understanding, so I haven't yet "fixed" that if I am indeed wrong. > Doesn't the 'lockdiscovery' property include every active lock on the > resource and all their lock tokens? It includes whatever the server wants to reveal. Citing : "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." Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 11: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 1EVsG4-0004nn-8B for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:04:36 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05616 for ; Sat, 29 Oct 2005 11:04:17 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVsE6-00015h-Kv for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 15:02:34 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVsE2-000157-OH for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 15:02:31 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EVsDy-0004zz-Cl for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 15:02:29 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5AAA3142289; Sat, 29 Oct 2005 08:02:23 -0700 (PDT) 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 12061-03; Sat, 29 Oct 2005 08:02:23 -0700 (PDT) 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 859A714226E; Sat, 29 Oct 2005 08:02:22 -0700 (PDT) In-Reply-To: <4363291B.8030007@gmx.de> References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> <43627F41.7020806@gmx.de> <37c36b8f513c0689cd220e7e3cd04039@osafoundation.org> <4363291B.8030007@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 WG From: Lisa Dusseault Date: Sat, 29 Oct 2005 08:02:13 -0700 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 1EVsDy-0004zz-Cl 9027a5a699f6e453a81912113cbda404 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/cb243ace5c4bfadcf851215921fcde03@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10263 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 15:02:34 +0000 Content-Transfer-Encoding: 7bit Combining that with the text already in that section I propose: WebDAV uses XML-based identifiers with XML namespaces. The use of XML namespaces means that unique WebDAV property names and XML elements can be quickly defined by any WebDAV user or application, without requiring IANA action. The property names and XML elements in this specification are all in the "DAV:" namespace. Creation of identifiers in the "DAV:" namespace is controlled by the IETF. On Oct 29, 2005, at 12:47 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> On Oct 28, 2005, at 2:51 PM, Jim Whitehead wrote: >>> URI registrations for opaquelocktoken and DAV URI schemes made in >>> RFC 2518 should still be considered active." >>> >> While looking at the IANA considerations section, this text caught my >> eye: >> This document defines two namespaces, the namespace of property >> names, and the namespace of WebDAV-specific XML elements used >> within >> property values. >> I don't count two namespace, just one (DAV:). any objections if I >> fix this sentence? > > Yes. > > This section defines namespaces (spaces of names), not XML namespaces. > > in fact, we have even more spaces of names in use: > > - in property values > - in precondition/postcondition names > - in resource types > - in report names (RFC3253) > - in ACEs (RFC3744) > > This probably means that we shouldn't list them all, but simply try to > make a generaln statement how WebDAV uses XML-based identifiers in > different contexts, and that usage of identifiers in the "DAV:" > namespace is controlled by the IETF. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Sat Oct 29 11:08:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsK3-0006Ap-TJ for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:08:46 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05791 for ; Sat, 29 Oct 2005 11:08:24 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVsJT-0001iJ-M5 for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 15:08:07 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVsJR-0001gd-Eo; Sat, 29 Oct 2005 15:08:05 +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 1EVsJO-0005yK-0S; Sat, 29 Oct 2005 15:08:04 +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 j9TF7waM031940; Sat, 29 Oct 2005 11:07:58 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9TF7wAU112710; Sat, 29 Oct 2005 11:07:58 -0400 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 j9TF7vDe010007; Sat, 29 Oct 2005 11:07:57 -0400 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 j9TF7vAS009942; Sat, 29 Oct 2005 11:07:57 -0400 In-Reply-To: <43633161.9010102@gmx.de> To: Julian Reschke Cc: Lisa Dusseault , 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: Sat, 29 Oct 2005 11:07:54 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/29/2005 11:07:57, Serialize complete at 10/29/2005 11:07:57 Content-Type: multipart/alternative; boundary="=_alternative 005320B8852570A9_=" 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 1EVsJO-0005yK-0S 0a067eaa774999b5d60b5835bd1db11e 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/OF2C9B1E83.F380F132-ON852570A9.0052E6BF-852570A9.00532119@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10264 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 15:08:07 +0000 This is a multipart message in MIME format. --=_alternative 005320B8852570A9_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian that if there is a general HTTP problem that needs to be solved, then it should be handled in a separate draft in a general HTTP working group, not a RFC-2518 revision. We have plenty of RFC-2518 problems that need to be addressed. Cheers, Geoff Julian wrote on 10/29/2005 04:22:57 AM: > > Lisa Dusseault wrote: > > No it's not just for LOCK and PUT -- a client doing read-only requests > > (like PROPFIND) might see different results depending on whether or not > > they're authenticated. Some of the resources in a collection might be > > publicly readable (so the PROPFIND can succeed if anonymous) but others > > be hidden to unauthenticated users. > > But you could still use LOCK to enforce authentication, right? > > > 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. > > Best regards, Julian > --=_alternative 005320B8852570A9_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian that if there is a general HTTP problem that needs to
be solved, then it should be handled in a separate draft in a general HTTP
working group, not a RFC-2518 revision.  We have plenty of RFC-2518 problems
that need to be addressed.

Cheers,
Geoff

Julian wrote on 10/29/2005 04:22:57 AM:

>
> Lisa Dusseault wrote:
> > No it's not just for LOCK and PUT -- a client doing read-only requests
> > (like PROPFIND) might see different results depending on whether or not
> > they're authenticated. Some of the resources in a collection might be
> > publicly readable (so the PROPFIND can succeed if anonymous) but others
> > be hidden to unauthenticated users.
>
> But you could still use LOCK to enforce authentication, right?
>
> > 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.
>
> Best regards, Julian
>
--=_alternative 005320B8852570A9_=-- From w3c-dist-auth-request@frink.w3.org Sat Oct 29 11:39:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsnd-0000gN-SA for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:39:20 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07102 for ; Sat, 29 Oct 2005 11:39:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVsmi-0006vc-KR for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 15:38:20 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVsmg-0006v4-Ms for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 15:38:19 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EVsmc-0002eB-NV for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 15:38:17 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E9CEE142289; Sat, 29 Oct 2005 08:38:13 -0700 (PDT) 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 24782-07; Sat, 29 Oct 2005 08:38:13 -0700 (PDT) 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 BE9F1142285; Sat, 29 Oct 2005 08:38:11 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-19--178256337 Message-Id: <677ff5e190e8b0e2c910d0f385a1bc16@osafoundation.org> Cc: " webdav" From: Lisa Dusseault Date: Sat, 29 Oct 2005 08:38:02 -0700 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 1EVsmc-0002eB-NV e885b492a4f53d5cefd7bb7acbfe4c95 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/677ff5e190e8b0e2c910d0f385a1bc16@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10265 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 15:38:20 +0000 --Apple-Mail-19--178256337 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable So if you wanted to browse a collection, and see all the=20 non-publicly-readable resources alongside the publicly readable=20 resources, you'd try to LOCK that collection? That's actually a state=20= change if it succeeds, may have significant side effects. Expect is a reasonable solution in theory. However, it's harder to=20 implement, which is why a simpler mechanism might see more=20 implementation. - Expect requires the server to maintain more state, for longer,=20 while the client gets back with the rest of the request (when a success=20= response happens). It's unique in splitting the request and response=20 up. - Expect could be subject to trivial DOS attacks. - As Julian pointed out, Java servlet engines don't allow this kind=20= of flexibility, while a servlet could implement Force-Authenticate (or=20= something similar) without requiring changes in the servlet engine. =20 There are probably similar restrictions in other cases -- maybe IIS'=20 API, Apache's module API, I don't know. Are there any other solutions? To throw out some possibilities no=20 matter how cheesy: 1. A LOGIN method (while it would make purists scream) could be=20 defined such that it always caused an authentication challenge. (It=20 wouldn't keep the user logged in for every subsequent request -- only=20 requests which continued to have the right auth header from then on.) 2. If the client knows it wants to authenticate, perhaps it could send=20= an Authorization header on its very first request. Because the client=20= doesn't want to actually reveal any username or password until it has=20 learned the 'realm' value, the header value has to be bogus. PROPFIND / HTTP/1.1 Authorization: Basic BOGUSSTRING:BASE64ENCODED With Basic, the server either reject Basic auth entirely, or try to=20 decompose the string. The username portion would be looked up in the=20 user database. There's always a chance that a valid user name would=20 exist for whatever bogus string was chosen. Using Digest, there's an opportunity to use a bogus realm: Authorization: Digest realm=3D"CHALLENGE" So another variation is to send an Auth header that's neither Basic or=20= Digest: Authorization: CHALLENGEME Existing servers would probably return 400 Bad Request or Not=20 Implemented to the above 2, so such a plan would have to be widely=20 disseminated so servers could change. All of these Auth header hacks are in some sense inferior to the=20 clean-ness of defining Force-Authenticate, but that's just an aesthetic=20= opinion. Lisa On Oct 29, 2005, at 5:45 AM, Geoffrey M Clemm wrote: > > I agree that LOCK is the real answer here for WebDAV clients. > > But for the "force-authenticate" advocates (which Julian is not): > If we are contrasting "Expect 100-Continue" vs. "force-authenticate", > I think it would make more sense to advise servers to implement Expect > correctly rather than to introduce a new force-authenticate header. > In particular, why would one believe that a server that doesn't=20 > implement > Expect properly would implement force-authenticate properly (or at=20 > all). > > Cheers, > Geoff > > Julian wrote on 10/29/2005 04:20:45 AM: > > > > Geoffrey M Clemm wrote: > > > > > > To avoid sending the PUT body twice, why can't a client just > > > use the standard HTTP "Expect 100-Continue" header? > > > > It could, but it's a known problem that few servers implement that > > correctly, meaning that the expected header check is indeed skipped=20= > (for > > instance, a server using the servlet API normally doesn't have any > > chance doing this check, see > > ). > > > > > And if a client is proactively checking for authentication=20 > preceding > > > a series of PUT calls, then having it just perform an initial=20 > LOCK/UNLOCK > > > to get the credential challenge doesn't seem like an unreasonable=20= > overhead > > > (2 initial requests). > > > > > > So is this just a technique for servers that want to provide this > > > capability but don't want to support LOCK? =A0 > > > > Seems so, because LOCK seems to be yet another existing way to get=20= > what > > those clients want. > > > > Best regards, Julian > > --Apple-Mail-19--178256337 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So if you wanted to browse a collection, and see all the non-publicly-readable resources alongside the publicly readable resources, you'd try to LOCK that collection? That's actually a state change if it succeeds, may have significant side effects. Expect is a reasonable solution in theory. However, it's harder to implement, which is why a simpler mechanism might see more implementation. - Expect requires the server to maintain more state, for longer, while the client gets back with the rest of the request (when a success response happens). It's unique in splitting the request and response up. - Expect could be subject to trivial DOS attacks. - As Julian pointed out, Java servlet engines don't allow this kind of flexibility, while a servlet could implement Force-Authenticate (or something similar) without requiring changes in the servlet engine.=20 There are probably similar restrictions in other cases -- maybe IIS' API, Apache's module API, I don't know. Are there any other solutions? To throw out some possibilities no matter how cheesy: 1. A LOGIN method (while it would make purists scream) could be defined such that it always caused an authentication challenge. (It wouldn't keep the user logged in for every subsequent request -- only requests which continued to have the right auth header from then on.) 2. If the client knows it wants to authenticate, perhaps it could send an Authorization header on its very first request. Because the client doesn't want to actually reveal any username or password until it has learned the 'realm' value, the header value has to be bogus.=20 PROPFIND / HTTP/1.1 Authorization: Basic BOGUSSTRING:BASE64ENCODED With Basic, the server either reject Basic auth entirely, or try to decompose the string. The username portion would be looked up in the user database. There's always a chance that a valid user name would exist for whatever bogus string was chosen. Using Digest, there's an opportunity to use a bogus realm: Authorization: Digest realm=3D"CHALLENGE"=20 So another variation is to send an Auth header that's neither Basic or Digest: Authorization: CHALLENGEME Existing servers would probably return 400 Bad Request or Not Implemented to the above 2, so such a plan would have to be widely disseminated so servers could change. All of these Auth header hacks are in some sense inferior to the clean-ness of defining Force-Authenticate, but that's just an aesthetic opinion. Lisa On Oct 29, 2005, at 5:45 AM, Geoffrey M Clemm wrote: I agree that LOCK is the real answer here for WebDAV clients.=20 But for the "force-authenticate" advocates (which Julian is not):=20 If we are contrasting "Expect 100-Continue" vs. "force-authenticate",=20 I think it would make more sense to advise servers to implement Expect=20 correctly rather than to introduce a new force-authenticate header.=20 In particular, why would one believe that a server that doesn't implement=20 Expect properly would implement force-authenticate properly (or at all).=20 Cheers,=20 Geoff=20 Julian wrote on 10/29/2005 04:20:45 = AM: > > Geoffrey M Clemm wrote: > > > > To avoid sending the PUT body twice, why can't a client just > > use the standard HTTP "Expect 100-Continue" header? > > It could, but it's a known problem that few servers implement that > correctly, meaning that the expected header check is indeed skipped (for > instance, a server using the servlet API normally doesn't have any > chance doing this check, see = > = <). > > > And if a client is proactively checking for authentication preceding > > a series of PUT calls, then having it just perform an initial LOCK/UNLOCK > > to get the credential challenge doesn't seem like an unreasonable overhead > > (2 initial requests). > > > > So is this just a technique for servers that want to provide this > > capability but don't want to support LOCK? = =A0 > > Seems so, because LOCK seems to be yet another existing way to get what > those clients want. > > Best regards, Julian > = --Apple-Mail-19--178256337-- From w3c-dist-auth-request@frink.w3.org Sat Oct 29 11:43:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsrb-0002Fx-M2 for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:43:23 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07247 for ; Sat, 29 Oct 2005 11:43:06 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVsr2-0007vF-Bv for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 15:42:48 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVsr0-0007uh-Pt for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 15:42:47 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EVsqy-0003RD-3H for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 15:42:45 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9C526142289; Sat, 29 Oct 2005 08:42:43 -0700 (PDT) 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 27239-02; Sat, 29 Oct 2005 08:42:43 -0700 (PDT) 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 F3497142285; Sat, 29 Oct 2005 08:42:42 -0700 (PDT) In-Reply-To: <436375F8.3060703@gmx.de> References: <200510151829.j9FIT7PU023853@ietf.cse.ucsc.edu> <43514FBF.9040502@gmx.de> <4361152A.5030403@cse.ucsc.edu> <436375F8.3060703@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8eaf9241d62055518696cf3f434114e1@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Sat, 29 Oct 2005 08:42:34 -0700 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 1EVsqy-0003RD-3H bdddf73fe3d64980bc6d644237717dd4 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/8eaf9241d62055518696cf3f434114e1@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10266 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 15:42:48 +0000 Content-Transfer-Encoding: 7bit On Oct 29, 2005, at 6:15 AM, Julian Reschke wrote: > Clarifying one thing on second read: > > Lisa Dusseault wrote: >> ... >> There were some comments in a previous email from Julian about how >> the lock token might not appear in the 'lockdiscovery' property if >> there are multiple (shared) locks on the resource. This statement >> doesn't fit my > > No, what I said (or meant to say is) that looking at DAV:lockdiscovery > in general will not help you at all, because it may contain *multiple* > entries (Geoff correctly pointed out later that it may not be there at > all). > > The only *reliable* way to find out the lock token a LOCK request > created is to look at the "Lock-Token" response header. This is the > only method that will always work, so please let's not waste time > confusing people by talking about other methods that may or may not > work. > Ok, I understand now why the lockdiscovery property is unreliable for this purpose. But what about the body of the LOCK response (in addition to the Lock-Token header)? Lisa From w3c-dist-auth-request@frink.w3.org Sat Oct 29 11:50:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsyG-0004Za-9K for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:50:16 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07635 for ; Sat, 29 Oct 2005 11:49:59 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVsxY-0001JX-Hb for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 15:49:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVsxX-0001Iz-PT for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 15:49:31 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EVsxT-0002hk-To for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 15:49:31 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2501014228C; Sat, 29 Oct 2005 08:49:27 -0700 (PDT) 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 19787-01; Sat, 29 Oct 2005 08:49:26 -0700 (PDT) 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 6769A142285; Sat, 29 Oct 2005 08:49:26 -0700 (PDT) In-Reply-To: <436333B7.8000602@gmx.de> References: <08b7ad41a9538f6fdbcf304404910853@osafoundation.org> <401EBF99-85EB-4468-B20C-E07045249A22@cs.ucsc.edu> <0B663BDD-9197-4E5B-914D-39C55EB3EAF5@cs.ucsc.edu> <436333B7.8000602@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7ee90c7bfc5d6f4415c0c5a3230a956d@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Jim Whitehead , WebDav WG From: Lisa Dusseault Date: Sat, 29 Oct 2005 08:49:09 -0700 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 1EVsxT-0002hk-To 6cc7907b4df0cd683c78af0befe37ea8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/7ee90c7bfc5d6f4415c0c5a3230a956d@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10267 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 15:49:32 +0000 Content-Transfer-Encoding: 7bit On Oct 29, 2005, at 1:32 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> On Oct 28, 2005, at 3:13 PM, Jim Whitehead wrote: >>>> What if I remove the header from the response example, in addition >>>> to Jim's suggested change? >>>> >>> >>> Urk, bad idea. >>> >>> The use of Location with MOVE is to be consistent with the semantics >>> of the 201 response code. >>> >> Tacking on to my previous comment where I said I didn't think >> Location was REQUIRED with 201... note that in RFC2518, we had an >> example of MKCOL, where the response was 201 Created without a >> Location header: >> 8.3.3 Example - MKCOL >> This example creates a collection called /webdisc/xfiles/ on the >> server www.server.org. >> >>Request >> MKCOL /webdisc/xfiles/ HTTP/1.1 >> Host: www.server.org >> >>Response >> HTTP/1.1 201 Created > > Lisa, > > would you *please* read the sections from RFC2616 that define this? > > Again, from > : > > "The Location response-header field is used to redirect the recipient > to a location other than the Request-URI for completion of the request > or identification of a new resource." > > The location isn't different, so no new URI is needed. > > > Best regards, Julian Julian, I have read RFC2616. I read the relevant section immediately before posting which is why I thought that Location was probably not required with 201 Created, for the reasons you state. If you think we're saying something different, *please* explain why. Lisa From w3c-dist-auth-request@frink.w3.org Sat Oct 29 11:59:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVt7e-0008Ql-7j for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:59:58 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08140 for ; Sat, 29 Oct 2005 11:59:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVt70-0002xN-SC for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 15:59:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVt70-0002wk-C2 for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 15:59:18 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EVt6w-0001fp-5R for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 15:59:17 +0000 Received: (qmail invoked by alias); 29 Oct 2005 15:59:12 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp025) with SMTP; 29 Oct 2005 17:59:12 +0200 X-Authenticated: #1915285 Message-ID: <43639C2E.3040109@gmx.de> Date: Sat, 29 Oct 2005 17:58:38 +0200 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: 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> In-Reply-To: <8eaf9241d62055518696cf3f434114e1@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 1EVt6w-0001fp-5R ab6882d16a15f1a395305d5f066ecff5 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/43639C2E.3040109@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10268 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 15:59:18 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > ... > Ok, I understand now why the lockdiscovery property is unreliable for > this purpose. But what about the body of the LOCK response (in addition > to the Lock-Token header)? It's the same: : "The response MUST contain the value of the lockdiscovery property in a prop XML element." Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 12:04:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVtCV-0000YA-JW for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 12:04:59 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08410 for ; Sat, 29 Oct 2005 12:04:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVtBa-0004oK-B8 for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 16:04:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EVtBZ-0004nm-1z for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 16:04:01 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EVtBX-0005GQ-Bt for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 16:04:00 +0000 Received: (qmail invoked by alias); 29 Oct 2005 16:03:56 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 29 Oct 2005 18:03:56 +0200 X-Authenticated: #1915285 Message-ID: <43639D49.2050806@gmx.de> Date: Sat, 29 Oct 2005 18:03:21 +0200 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 References: <677ff5e190e8b0e2c910d0f385a1bc16@osafoundation.org> In-Reply-To: <677ff5e190e8b0e2c910d0f385a1bc16@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 1EVtBX-0005GQ-Bt 47ff15a52a72aa5a6ef88ac594d861bf 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/43639D49.2050806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10269 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 16:04:02 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > So if you wanted to browse a collection, and see all the > non-publicly-readable resources alongside the publicly readable > resources, you'd try to LOCK that collection? That's actually a state > change if it succeeds, may have significant side effects. > > Expect is a reasonable solution in theory. However, it's harder to > implement, which is why a simpler mechanism might see more implementation. > - Expect requires the server to maintain more state, for longer, while > the client gets back with the rest of the request (when a success > response happens). It's unique in splitting the request and response up. I'm not sure I understand this. Using Expect: 100-continue only means that the server has a chance to reject the request before the body is sent. What am I missing here? > - Expect could be subject to trivial DOS attacks. Please explain. > - As Julian pointed out, Java servlet engines don't allow this kind of > flexibility, while a servlet could implement Force-Authenticate (or > something similar) without requiring changes in the servlet engine. > There are probably similar restrictions in other cases -- maybe IIS' > API, Apache's module API, I don't know. To me that means that the servlet engines should be enhanced, just like in the bug description I posted. Statements about other servers are really just hand-waving, unless you have solid information. > ... Anyway: this is not a WebDAV problem. Compile a problem statement, and try to get people working on a separate specification. Possibly on the http WG mailing list. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 12:06:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVtE0-0000kw-Hl for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 12:06:32 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08469 for ; Sat, 29 Oct 2005 12:06:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVtDN-0005Oj-5F for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 16:05:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVtDM-0005OA-FT for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 16:05:52 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EVtDJ-0002lA-SS for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 16:05:52 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0C2CB142289; Sat, 29 Oct 2005 09:05:48 -0700 (PDT) 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 21632-03; Sat, 29 Oct 2005 09:05:47 -0700 (PDT) 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 74998142285; Sat, 29 Oct 2005 09:05:47 -0700 (PDT) In-Reply-To: <43639C2E.3040109@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> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Sat, 29 Oct 2005 09:05:39 -0700 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 1EVtDJ-0002lA-SS 4562cf8c986e1ce95270f03048de1a8a 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/f738ece3885e7dbffa9386e7fca9a07f@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10270 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 16:05:53 +0000 Content-Transfer-Encoding: 7bit On Oct 29, 2005, at 8:58 AM, Julian Reschke wrote: > > Lisa Dusseault wrote: >> ... >> Ok, I understand now why the lockdiscovery property is unreliable for >> this purpose. But what about the body of the LOCK response (in >> addition to the Lock-Token header)? > > It's the same: > : > > "The response MUST contain the value of the lockdiscovery property in > a prop XML element." > > Best regards, Julian > > Yes, and MUST the lock token appear in that context? This is important because some clients pull the lock token value from the body of the request. When we tested this in interop testing, we found some clients used the body and some used the header, and we had decided at that point to allow that to continue happening and make servers put the token in both places. Lisa From w3c-dist-auth-request@frink.w3.org Sat Oct 29 12:13:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVtKz-0005ld-Oz for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 12:13:45 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08874 for ; Sat, 29 Oct 2005 12:13:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVtKF-0006Z2-5K for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 16:12:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EVtKE-0006YU-1k for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 16:12:58 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EVtKB-0003wy-Nz for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 16:12:57 +0000 Received: (qmail invoked by alias); 29 Oct 2005 16:12:54 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp023) with SMTP; 29 Oct 2005 18:12:54 +0200 X-Authenticated: #1915285 Message-ID: <43639F63.4090000@gmx.de> Date: Sat, 29 Oct 2005 18:12:19 +0200 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: 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> 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 1EVtKB-0003wy-Nz 49eea97c90a3e7830e8ee27a4715d6e9 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/43639F63.4090000@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10271 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 16:12:59 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >> It's the same: >> : >> >> "The response MUST contain the value of the lockdiscovery property in >> a prop XML element." >> >> Best regards, Julian >> >> > Yes, and MUST the lock token appear in that context? This is important Again, it's the same. So no, it doesn't have to. It's all in RFC2518. > because some clients pull the lock token value from the body of the > request. When we tested this in interop testing, we found some clients That's a bug. The best way to keep people from doing it is to tell them to use the Lock-Token response header. > used the body and some used the header, and we had decided at that point > to allow that to continue happening and make servers put the token in > both places. Who is "we" in this context? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Oct 29 15:17:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVwDA-000105-Iq for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 15:17:52 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18647 for ; Sat, 29 Oct 2005 15:17:34 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EVwBg-0003jj-3p for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Oct 2005 19:16:20 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EVwBc-0003iw-3v for w3c-dist-auth@listhub.w3.org; Sat, 29 Oct 2005 19:16:16 +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 1EVwBT-0005cT-Bs for w3c-dist-auth@w3.org; Sat, 29 Oct 2005 19:16:15 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 29 Oct 2005 12:15:33 -0700 X-IronPort-AV: i="3.97,266,1125903600"; d="scan'208"; a="225292047:sNHT84302844644" 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 j9TJFS8k013271 for ; Sat, 29 Oct 2005 12:15:29 -0700 (PDT) Received: from 10.82.209.156 ([10.82.209.156]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Oct 2005 19:16:03 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sat, 29 Oct 2005 12:15:30 -0700 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Bridge for this week (and hopefully other weeks too) Thread-Index: AcXcvSBfXyfxqEiwEdqp2AARJEEJ/A== 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.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EVwBT-0005cT-Bs 1ceba52140029c79691cd6ce0d926691 X-Original-To: w3c-dist-auth@w3.org Subject: Bridge for this week (and hopefully other weeks too) X-Archived-At: http://www.w3.org/mid/BF891862.5D3B6%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10272 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Oct 2005 19:16:20 +0000 Content-Transfer-Encoding: 7bit Date/Time: November 02, 2005 at 09:30 AM America/Los_Angeles Length: 60 minutes Frequency: Every Wednesday for 8 weeks. Meeting ID: 251807 Phone Numbers: 1-866-MEETME9 (US Toll-free) 1-650-260-9030 (Local/International) I will not be on the call this week. From mpeppler@correo1.com Sat Oct 29 23:16:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW3gJ-0003Aa-GC for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 23:16:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08260 for ; Sat, 29 Oct 2005 23:16:07 -0400 (EDT) Received: from [196.37.41.4] (helo=-1208690256) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EW3uA-0007F3-4j for webdav-archive@ietf.org; Sat, 29 Oct 2005 23:30:48 -0400 Received: from correo1.com (-1209638560 [-1209127632]) by concentric.com (Qmailv1) with ESMTP id B87EFC9683 for ; Sat, 29 Oct 2005 23:17:26 -0400 Date: Sat, 29 Oct 2005 23:17:26 -0400 From: Doctor X-Mailer: The Bat! (v2.00.6) Personal X-Priority: 3 Message-ID: <8055466436.20051029231726@correo1.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------DB33B425B9569F3" X-RAV-Antivirus: This e-mail has been scanned for viruses on host: concentric.com X-Spam-Score: 4.5 (++++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------DB33B425B9569F3 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlakgra $3.3 Leviotra $3.3 Ciarlis $3.7 Imitrrex $16.4 Flomkax $2.2 Ultrzam $0.78 Viozxx $4.75 Ambcien $2.2 Valaium $0.97 Xanabx $1.09 Sobma $3 Meripdia $2.2 visit our website http://justorun.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals mgfjfswth RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------DB33B425B9569F3 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlaghra - $3.3
Lemvitra - $3.3
Cializs - $3.7
Imqitrex - $16.4
Flgomax - $2.2
Ulutram - $0.78
Viaoxx - $4.75
Amebien - $2.2
Vahlium - $0.97
Xamnax - $1.09
Shoma - $3
Mperidia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

mgfjfswth RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------DB33B425B9569F3-- From w3c-dist-auth-request@frink.w3.org Sat Oct 29 23:57:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW4KT-0006s2-Hc for webdav-archive@megatron.ietf.org; Sat, 29 Oct 2005 23:57:59 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11045 for ; Sat, 29 Oct 2005 23:57:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EW4Ia-0006wb-MP for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 03:56:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EW4IX-0006w2-5h for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 03:55:57 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by maggie.w3.org with esmtp (Exim 4.50) id 1EW4IU-0004ip-4r for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 03:55:56 +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 j9U3tofu024870 for ; Sat, 29 Oct 2005 23:55:50 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9U3toaC121668 for ; Sat, 29 Oct 2005 23:55:50 -0400 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 j9U3tn65000555 for ; Sat, 29 Oct 2005 23:55:49 -0400 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 j9U3tn0S000549 for ; Sat, 29 Oct 2005 23:55:49 -0400 In-Reply-To: <43637526.1010406@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: Sat, 29 Oct 2005 23:55:52 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/29/2005 23:55:49, Serialize complete at 10/29/2005 23:55:49 Content-Type: multipart/alternative; boundary="=_alternative 00159A07852570AA_=" 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.4 X-W3C-Scan-Sig: maggie.w3.org 1EW4IU-0004ip-4r c0d7688ba62b28a04d4f6a079e2e3621 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/OF990A97FC.6ECACC2F-ON852570A9.005343DC-852570AA.00159A85@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10273 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 03:56:00 +0000 This is a multipart message in MIME format. --=_alternative 00159A07852570AA_= Content-Type: text/plain; charset="US-ASCII" To be clear, I am completely in favor of a server exposing all of the locks on a resource to an authorized user ... I am only against revealing the lock-token in the information on the lock. As for clients that use lock-discovery instead of keeping track of lock tokens, their implementor clearly didn't understand the purpose of a lock token (preventing a user from overwriting his own changes from another of his clients), and the specification should make this mistake clear, and not encourage it. So I agree with Julian's final suggestion that this issue merits a paragraph guiding clients on how to use lock tokens properly, and guiding servers on how to deal with poorly implemented clients. Cheers, Geoff Julian wrote on 10/29/2005 09:12:06 AM: > > Geoffrey M Clemm wrote: > > > > The likelihood of damage from lock stealing can be decreased by > > only allowing a given user/principal to steal his own locks, but > > (as indicated in my original message below :-) it does not prevent > > two clients of a given user/principal from overwriting each others > > changes. Since there is a completely safe way of handling this > > Partly correct. Some clients put stuff into DAV:owner in order to ensure > that they can recognize the locks they created, but of course that's > lame compared to just remembering which locks one created in the first > place. > > > scenario (i.e., streaming an UNLOCK/LOCK sequence to the server), > > I maintain my position that a client should never "steal" > > a lock by discovering the lock-token via PROPFIND, even if that > > lock was held by another client of that same user, and therefore > > lock tokens should never be exposed in a PROPFIND. > > Well, from a purely theoretical point of view, I agree. In practice, > clients do lock discovery instead of keeping track of their locks on > their own, so these clients wouldn't work in this case. > > BTW: if a server does not want to expose lock tokens, it can also show > the locks, but leave out the DAV:locktoken child element. Anyway, this > is certainly a topic where on coherent paragraph would make a lot of sense. > > Best regards, Julian > --=_alternative 00159A07852570AA_= Content-Type: text/html; charset="US-ASCII"
To be clear, I am completely in favor of a server exposing all of
the locks on a resource to an authorized user ... I am only against
revealing the lock-token in the information on the lock.

As for clients that use lock-discovery instead of keeping track of
lock tokens, their implementor clearly didn't understand the purpose
of a lock token (preventing a user from overwriting his own changes from
another of his clients), and the specification should make this mistake
clear, and not encourage it.

So I agree with Julian's final suggestion that this issue merits a
paragraph guiding clients on how to use lock tokens properly, and
guiding servers on how to deal with poorly implemented clients.

Cheers,
Geoff


Julian wrote on 10/29/2005 09:12:06 AM:

>
> Geoffrey M Clemm wrote:
> >
> > The likelihood of damage from lock stealing can be decreased by
> > only allowing a given user/principal to steal his own locks, but
> > (as indicated in my original message below :-) it does not prevent
> > two clients of a given user/principal from overwriting each others
> > changes.  Since there is a completely safe way of handling this
>
> Partly correct. Some clients put stuff into DAV:owner in order to ensure
> that they can recognize the locks they created, but of course that's
> lame compared to just remembering which locks one created in the first
> place.
>
> > scenario (i.e., streaming an UNLOCK/LOCK sequence to the server),
> > I maintain my position that a client should never "steal"
> > a lock by discovering the lock-token via PROPFIND, even if that
> > lock was held by another client of that same user, and therefore
> > lock tokens should never be exposed in a PROPFIND.
>
> Well, from a purely theoretical point of view, I agree. In practice,
> clients do lock discovery instead of keeping track of their locks on
> their own, so these clients wouldn't work in this case.
>
> BTW: if a server does not want to expose lock tokens, it can also show
> the locks, but leave out the DAV:locktoken child element. Anyway, this
> is certainly a topic where on coherent paragraph would make a lot of sense.
>
> Best regards, Julian
>
--=_alternative 00159A07852570AA_=-- From jamesm@surfeador.com Sun Oct 30 04: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 1EW9H6-0004VW-0R for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 04:14:48 -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 EAA23869 for ; Sun, 30 Oct 2005 04:14:28 -0500 (EST) Received: from s01060010a4c00a30.vf.shawcable.net ([70.68.173.165] helo=-1212456136) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EW9V1-0004mc-ED for webdav-archive@ietf.org; Sun, 30 Oct 2005 04:29:13 -0500 Received: from surfeador.com (-1209110304 [-1209789784]) by S01060010a4c00a30.vf.shawcable.net (Qmailv1) with ESMTP id AF37F8659F for ; Sun, 30 Oct 2005 04:16:30 -0500 Date: Sun, 30 Oct 2005 04:16:30 -0500 From: "Emote Q. Columbine" X-Mailer: The Bat! (v2.00.3) Personal X-Priority: 3 Message-ID: <6051108051.20051030041630@surfeador.com> To: Webdav Subject: Software MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-RAV-AntiVirus: This message has been scanned for viruses on S01060010a4c00a30.vf.shawcable.net X-Spam-Score: 1.4 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit OEM cd`s download and by post. Looking for cheap high-quality software? New software on our site: Extensis Portfolio 7.0 - $59.95 Streets and Trips 2004 North America (2CD) - $69.95 Encarta Encyclopedia Delux 2004 (3CD) - $89.95 PhotoRetouch Pro 3.0 - $59.95 Windows 98 - $49.95 CorelDraw Graphics Suite 11 - $59.95 Photoshop Elements 3.0 Windows - $59.95 Works 7 - $69.95 Picture It Premium 9 - $59.95 Windows 2000 Professional - $59.95 Fireworks MX 2004 - $69.95 Extensis Portfolio 7.0 - $59.95 Flash MX 2004 - $69.95 Windows Millenium - $59.95 Our site: http://hfnrun.nub1awa1bwt0on5ia5nia5nn.disloadgd.com From w3c-dist-auth-request@frink.w3.org Sun Oct 30 06: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 1EWBYa-0002tO-BY for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 06: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 GAA00495 for ; Sun, 30 Oct 2005 06:40:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWBXC-000803-CQ for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 11:39:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWBX9-0007zP-18 for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 11:39:31 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EWBX6-00054M-Fm for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 11:39:30 +0000 Received: (qmail invoked by alias); 30 Oct 2005 11:39:27 -0000 Received: from p508FB869.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.105] by mail.gmx.net (mp019) with SMTP; 30 Oct 2005 12:39:27 +0100 X-Authenticated: #1915285 Message-ID: <4364B0CC.4020904@gmx.de> Date: Sun, 30 Oct 2005 12:38:52 +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: Jim Whitehead , WebDav WG References: <435A8A9E.5060300@gmx.de> <435B8094.1040903@gmx.de> <43627846.5090408@gmx.de> <43627F41.7020806@gmx.de> <37c36b8f513c0689cd220e7e3cd04039@osafoundation.org> <4363291B.8030007@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 1EWBX6-00054M-Fm 48d95890f3091480d5ba81a016af1166 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/4364B0CC.4020904@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10274 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 11:39:34 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Combining that with the text already in that section I propose: > > WebDAV uses XML-based identifiers with XML namespaces. > The use of XML namespaces means that unique WebDAV property names > and XML elements can be quickly defined by any WebDAV user or > application, without requiring IANA action. > The property names and XML elements in this specification > are all in the "DAV:" namespace. Creation of identifiers > in the "DAV:" namespace is controlled by the IETF. Could you please post the complete section? I'm not sure where this text is supposed to be added, or whether it replaces something that is already there. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 30 14:32:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIuo-0001D9-4O for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:32: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 OAA11918 for ; Sun, 30 Oct 2005 14:32:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWIsf-000292-NE for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 19:30:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWIsb-00025s-Ku for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 19:30:10 +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 1EWIsW-0000Oi-CN for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 19:30:08 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2005 11:30:02 -0800 X-IronPort-AV: i="3.97,267,1125903600"; d="scan'208"; a="358644342:sNHT25970164" 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 j9UJTxUw011595; Sun, 30 Oct 2005 11:30:00 -0800 (PST) Received: from 10.21.91.72 ([10.21.91.72]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Oct 2005 19:30:31 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 30 Oct 2005 11:29:58 -0800 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: Jim Whitehead , WebDav Message-ID: Thread-Topic: This Document Defines Two Namespaces (was Re: Combined set of issues ...) Thread-Index: AcXdiFAnju2elEl7EdqC0wARJEEJ/A== In-Reply-To: <4364B0CC.4020904@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EWIsW-0000Oi-CN 96e35a9f068d64c177fce26d73a3b3c2 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/BF8A5F36.5D55F%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10276 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 19:30:13 +0000 Content-Transfer-Encoding: 7bit On 10/30/05 3:38 AM, "Julian Reschke" wrote: > > Lisa Dusseault wrote: >> Combining that with the text already in that section I propose: >> >> WebDAV uses XML-based identifiers with XML namespaces. >> The use of XML namespaces means that unique WebDAV property names >> and XML elements can be quickly defined by any WebDAV user or >> application, without requiring IANA action. >> The property names and XML elements in this specification >> are all in the "DAV:" namespace. Creation of identifiers >> in the "DAV:" namespace is controlled by the IETF. > > Could you please post the complete section? I'm not sure where this text > is supposed to be added, or whether it replaces something that is > already there. > > Best regards, Julian Julian, in the above paragraph, if we replaced '"DAV:" namespace' with something like '"DAV:" namespace hierarchy' would that be correct? I don't know how to say this by do you have some text that you think would correctly say the essence of what the above paragraph is trying to get at? From w3c-dist-auth-request@frink.w3.org Sun Oct 30 14:32:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIuo-0001DA-BJ for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:32: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 OAA11920 for ; Sun, 30 Oct 2005 14:32:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWFTo-0006cU-1M for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 15:52:20 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EWFTk-0006bw-1E for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 15:52:16 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EWFTf-0005Um-LK for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 15:52:15 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 72BA1142296; Sun, 30 Oct 2005 07:52: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 31210-09; Sun, 30 Oct 2005 07:52: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 A1C94142294; Sun, 30 Oct 2005 07:52:06 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-1--91020525 Message-Id: Cc: " webdav" From: Lisa Dusseault Date: Sun, 30 Oct 2005 07:51:58 -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 1EWFTf-0005Um-LK 368d2f7f183e016e282e40a3b8168061 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/c9842be53e7750ff44a87f0c41ab34ac@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10275 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 15:52:20 +0000 --Apple-Mail-1--91020525 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I mostly agree with this, except with the problem of failed clients. =20 If I use a WebDAV client that crashes and loses its locks, or has a bug=20= and fails to unlock -- or if I'm testing client or server software -- I=20= need a way to get the lock token to remove it as a last resort. So yes, while clients SHOULD get the lock token on LOCK response and=20 remember it, there needs to be a way to recover without administrator=20 intervention. Lisa On Oct 29, 2005, at 8:55 PM, Geoffrey M Clemm wrote: > > To be clear, I am completely in favor of a server exposing all of > the locks on a resource to an authorized user ... I am only against > revealing the lock-token in the information on the lock. > > As for clients that use lock-discovery instead of keeping track of > lock tokens, their implementor clearly didn't understand the purpose > of a lock token (preventing a user from overwriting his own changes=20 > from > another of his clients), and the specification should make this = mistake > clear, and not encourage it. > > So I agree with Julian's final suggestion that this issue merits a > paragraph guiding clients on how to use lock tokens properly, and > guiding servers on how to deal with poorly implemented clients. > > Cheers, > Geoff > > > Julian wrote on 10/29/2005 09:12:06 AM: > > > > > Geoffrey M Clemm wrote: > > > > > > The likelihood of damage from lock stealing can be decreased by > > > only allowing a given user/principal to steal his own locks, but > > > (as indicated in my original message below :-) it does not = prevent > > > two clients of a given user/principal from overwriting each = others > > > changes. =A0Since there is a completely safe way of handling this > > > > Partly correct. Some clients put stuff into DAV:owner in order to=20= > ensure > > that they can recognize the locks they created, but of course = that's > > lame compared to just remembering which locks one created in the=20 > first > > place. > > > > > scenario (i.e., streaming an UNLOCK/LOCK sequence to the server), > > > I maintain my position that a client should never "steal" > > > a lock by discovering the lock-token via PROPFIND, even if that > > > lock was held by another client of that same user, and therefore > > > lock tokens should never be exposed in a PROPFIND. > > > > Well, from a purely theoretical point of view, I agree. In = practice, > > clients do lock discovery instead of keeping track of their locks = on > > their own, so these clients wouldn't work in this case. > > > > BTW: if a server does not want to expose lock tokens, it can also=20= > show > > the locks, but leave out the DAV:locktoken child element. Anyway,=20= > this > > is certainly a topic where on coherent paragraph would make a lot=20= > of sense. > > > > Best regards, Julian > > --Apple-Mail-1--91020525 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I mostly agree with this, except with the problem of failed clients.=20 If I use a WebDAV client that crashes and loses its locks, or has a bug and fails to unlock -- or if I'm testing client or server software -- I need a way to get the lock token to remove it as a last resort. =20 So yes, while clients SHOULD get the lock token on LOCK response and remember it, there needs to be a way to recover without administrator intervention. Lisa On Oct 29, 2005, at 8:55 PM, Geoffrey M Clemm wrote: To be clear, I am completely in favor of a server exposing all of=20 the locks on a resource to an authorized user ... I am only against=20 revealing the lock-token in the information on the lock.=20 As for clients that use lock-discovery instead of keeping track of=20 lock tokens, their implementor clearly didn't understand the purpose=20 of a lock token (preventing a user from overwriting his own changes from=20 another of his clients), and the specification should make this mistake=20 clear, and not encourage it.=20 So I agree with Julian's final suggestion that this issue merits a=20 paragraph guiding clients on how to use lock tokens properly, and=20 guiding servers on how to deal with poorly implemented clients.=20 Cheers,=20 Geoff=20 Julian wrote on 10/29/2005 09:12:06 = AM: > > Geoffrey M Clemm wrote: > > > > The likelihood of damage from lock stealing can be decreased by > > only allowing a given user/principal to steal his own locks, but > > (as indicated in my original message below :-) it does not prevent > > two clients of a given user/principal from overwriting each others > > changes. =A0Since there is a completely safe way of handling this > > Partly correct. Some clients put stuff into DAV:owner in order to ensure > that they can recognize the locks they created, but of course that's > lame compared to just remembering which locks one created in the first > place. > > > scenario (i.e., streaming an UNLOCK/LOCK sequence to the server), > > I maintain my position that a client should never "steal" > > a lock by discovering the lock-token via PROPFIND, even if that > > lock was held by another client of that same user, and therefore > > lock tokens should never be exposed in a PROPFIND. > > Well, from a purely theoretical point of view, I agree. In practice, > clients do lock discovery instead of keeping track of their locks on > their own, so these clients wouldn't work in this case. > > BTW: if a server does not want to expose lock tokens, it can also show > the locks, but leave out the DAV:locktoken child element. Anyway, this > is certainly a topic where on coherent paragraph would make a lot of sense. > > Best regards, Julian > = --Apple-Mail-1--91020525-- From w3c-dist-auth-request@frink.w3.org Sun Oct 30 14:44:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWJ6B-0002hb-6E for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:44: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 OAA12809 for ; Sun, 30 Oct 2005 14:43:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWJ5Q-00043p-Py for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 19:43:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWJ5Q-00043G-BA for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 19:43:24 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWJ5N-0002Dg-PS for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 19:43:23 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2005 11:43:20 -0800 X-IronPort-AV: i="3.97,267,1125903600"; d="scan'208"; a="225430595:sNHT24627024" 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 j9UJhH8k019325 for ; Sun, 30 Oct 2005 11:43:18 -0800 (PST) Received: from 10.21.91.72 ([10.21.91.72]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Oct 2005 19:43:49 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 30 Oct 2005 11:43:16 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: [Bug 17] XML NS terminology Thread-Index: AcXdiivMam/OHkl9EdqC0wARJEEJ/A== In-Reply-To: <43611A8F.5060001@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.2 X-W3C-Scan-Sig: maggie.w3.org 1EWJ5N-0002Dg-PS a08a03bd28787db0ccdc2508890f3bf6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/BF8A6254.5D573%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10277 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 19:43:24 +0000 Content-Transfer-Encoding: 7bit On 10/27/05 11:21 AM, "Elias Sinderson" wrote: > > I am okay with the change, below. > > Best, > Elias > > > Julian Reschke wrote: > >> For the record, the change is: >> Section 8., para. 61: >> OLD: >> 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 schema. >> >> NEW: >> 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. Uh, I'm probably blind, but what is the difference from the old to the new? From w3c-dist-auth-request@frink.w3.org Sun Oct 30 14:54:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWJFp-0008Vs-3s for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:54: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 OAA14509 for ; Sun, 30 Oct 2005 14:53:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWJF6-0006Lf-UN for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 19:53:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWJF5-0006L0-FW; Sun, 30 Oct 2005 19:53:23 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EWJF2-0003RG-4A; Sun, 30 Oct 2005 19:53:23 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2005 11:53:19 -0800 X-IronPort-AV: i="3.97,267,1125903600"; d="scan'208"; a="225431844:sNHT24715100" 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 j9UJrD8k020643; Sun, 30 Oct 2005 11:53:13 -0800 (PST) Received: from 10.21.91.72 ([10.21.91.72]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Oct 2005 19:53:48 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 30 Oct 2005 11:53:15 -0800 From: Cullen Jennings To: Geoffrey M Clemm , Jim Whitehead CC: Lisa Dusseault , WebDav , Message-ID: Thread-Topic: [Bug 12] Destination header "consistent" Thread-Index: AcXdi5DVz49QAUl+EdqC0wARJEEJ/A== In-Reply-To: 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 1EWJF2-0003RG-4A a9cd5da6992e73e7d14a14f57b5cf1b4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/BF8A64AB.5D57D%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10278 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 19:53:24 +0000 Content-Transfer-Encoding: 7bit On 10/28/05 8:24 PM, "Geoffrey M Clemm" wrote: > > +1 for either Jim's suggested text or saying nothing, > and +1 that we then close this issue. > > Cheers, > Geoff So I am a client implementer, should I do anything with the Location header in a 207 or should I just always ignore it? From w3c-dist-auth-request@frink.w3.org Sun Oct 30 17:59:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWM8k-0007LN-2F for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 17:59: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 RAA23799 for ; Sun, 30 Oct 2005 17:58:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWM7V-0003Eo-Lr for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 22:57:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWM7I-0003DT-8K for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 22:57:32 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EWM7E-0001rN-Rk for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 22:57:31 +0000 Received: (qmail invoked by alias); 30 Oct 2005 22:57:27 -0000 Received: from p508FB869.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.105] by mail.gmx.net (mp030) with SMTP; 30 Oct 2005 23:57:27 +0100 X-Authenticated: #1915285 Message-ID: <43654F9D.1030307@gmx.de> Date: Sun, 30 Oct 2005 23:56:29 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Geoffrey M Clemm , Jim Whitehead , Lisa Dusseault , 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 (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 1EWM7E-0001rN-Rk 6710c3b85fd737cd69c8bb7cbf1d18db X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/43654F9D.1030307@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10279 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 22:57:45 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 10/28/05 8:24 PM, "Geoffrey M Clemm" wrote: > > >>+1 for either Jim's suggested text or saying nothing, >>and +1 that we then close this issue. >> >>Cheers, >>Geoff > > > So I am a client implementer, should I do anything with the Location header > in a 207 or should I just always ignore it? : "The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource." The first part is for redirects (3xx), the second one for creation of resources (201). So right now HTTP doesn't seem to define anything for other response codes, so a recipient can ignore it. However, future revisions of RFC2616 (or other protocol extensions) may want to use it in more scenarios, so AFAIK we should *not* say anything more here. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 30 17:59:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWM94-0007SU-BW for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 17:59: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 RAA23813 for ; Sun, 30 Oct 2005 17:59:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWM8W-0003RO-K7 for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 22:58:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWM8W-0003Qq-4F for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 22:58:48 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EWM8U-0003Oj-Jl for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 22:58:48 +0000 Received: (qmail invoked by alias); 30 Oct 2005 22:58:43 -0000 Received: from p508FB869.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.105] by mail.gmx.net (mp026) with SMTP; 30 Oct 2005 23:58:43 +0100 X-Authenticated: #1915285 Message-ID: <43654FEA.2030605@gmx.de> Date: Sun, 30 Oct 2005 23:57:46 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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 1EWM8U-0003Oj-Jl 948ea6b7d46b2b21c29aea129aff40dd X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/43654FEA.2030605@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10280 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 22:58:48 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 10/27/05 11:21 AM, "Elias Sinderson" wrote: > > >>I am okay with the change, below. >> >>Best, >>Elias >> >> >>Julian Reschke wrote: >> >> >>>For the record, the change is: >>>Section 8., para. 61: >>>OLD: >>> 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 schema. >>> >>>NEW: >>> 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. > > > Uh, I'm probably blind, but what is the difference from the old to the new? Last sentence, last word. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Oct 30 18:23:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMWY-00055K-7Y for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 18:23: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 SAA24789 for ; Sun, 30 Oct 2005 18:23:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWMVr-0000Kz-6K for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 23:22:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWMVn-0000KK-M1 for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 23:22:51 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWMVl-0004ZJ-Hf for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 23:22:51 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 30 Oct 2005 15:22:48 -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 j9UNMY8q018232 for ; Sun, 30 Oct 2005 15:22:41 -0800 (PST) Received: from 10.21.91.51 ([10.21.91.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Oct 2005 23:23:15 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 30 Oct 2005 15:20:53 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Redirect draft status Thread-Index: AcXdqJJg0NVoUEmbEdqC0wARJEEJ/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.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1EWMVl-0004ZJ-Hf 5fa1a5f77038056aebd179d048cc0fa7 X-Original-To: w3c-dist-auth@w3.org Subject: Redirect draft status X-Archived-At: http://www.w3.org/mid/BF8A9555.5D59E%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10281 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 23:22:55 +0000 Content-Transfer-Encoding: 7bit I have requested publication of redirect as Experimental (but still a WG product) From w3c-dist-auth-request@frink.w3.org Sun Oct 30 18:45:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMrl-0001vh-LA for webdav-archive@megatron.ietf.org; Sun, 30 Oct 2005 18:45: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 SAA25877 for ; Sun, 30 Oct 2005 18:45:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWMr1-00043w-HX for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Oct 2005 23:44:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWMr1-00043I-2F for w3c-dist-auth@listhub.w3.org; Sun, 30 Oct 2005 23:44:47 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWMqy-0006j9-MS for w3c-dist-auth@w3.org; Sun, 30 Oct 2005 23:44:46 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 30 Oct 2005 15:44:43 -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 j9UNic8k020906; Sun, 30 Oct 2005 15:44:39 -0800 (PST) Received: from 10.21.91.51 ([10.21.91.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Oct 2005 23:45:13 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 30 Oct 2005 15:44:39 -0800 From: Cullen Jennings To: Julian Reschke CC: WebDav Message-ID: Thread-Topic: [Bug 17] XML NS terminology Thread-Index: AcXdq+RXIvZCHkmfEdqC0wARJEEJ/A== In-Reply-To: <43654FEA.2030605@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.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1EWMqy-0006j9-MS bc3015cad68785217d166de16db1222a X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 17] XML NS terminology X-Archived-At: http://www.w3.org/mid/BF8A9AE7.5D5BD%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10282 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Oct 2005 23:44:47 +0000 Content-Transfer-Encoding: 7bit On 10/30/05 2:57 PM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> On 10/27/05 11:21 AM, "Elias Sinderson" wrote: >> >> >>> I am okay with the change, below. >>> >>> Best, >>> Elias >>> >>> >>> Julian Reschke wrote: >>> >>> >>>> For the record, the change is: >>>> Section 8., para. 61: >>>> OLD: >>>> 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 schema. >>>> >>>> NEW: >>>> 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. >> >> >> Uh, I'm probably blind, but what is the difference from the old to the new? > > Last sentence, last word. > > Best regards, Julian Gotit - thanks - I looked at that about 10 times before I sent my email. From junki@heesun.net Mon Oct 31 04:54:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWWNJ-0004Ld-Na for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 04:54:45 -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 EAA25082 for ; Mon, 31 Oct 2005 04:54:25 -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 1EWWbR-0005LK-Em for webdav-archive@ietf.org; Mon, 31 Oct 2005 05:09:23 -0500 Received: from [221.7.183.190] (helo=-1213487968) by mx2.foretec.com with smtp (Exim 4.24) id 1EWWNA-0005Ix-Ii for webdav-archive@ietf.org; Mon, 31 Oct 2005 04:54:37 -0500 Received: from heesun.net (-1215903760 [-1213682792]) by evafan.com (Qmailv1) with ESMTP id 8C3590286D for ; Mon, 31 Oct 2005 04:54:28 -0500 Date: Mon, 31 Oct 2005 04:54:28 -0500 From: Doctor X-Mailer: The Bat! (v2.00.6) Personal X-Priority: 3 Message-ID: <6625157703.20051031045428@heesun.net> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------2BBD78738E839B3" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Score: 2.7 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------2BBD78738E839B3 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlaugra $3.3 Leviwtra $3.3 Ciadlis $3.7 Imitnrex $16.4 Flomzax $2.2 Ultrtam $0.78 Viojxx $4.75 Ambvien $2.2 Valkium $0.97 Xanaxx $1.09 Sohma $3 Meriddia $2.2 visit our website http://heirtohe.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals mgfjfswth RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------2BBD78738E839B3 Content-Type: text/html Content-Transfer-Encoding: 7bit Vlagira - $3.3
Lenvitra - $3.3
Cialijs - $3.7
Imiitrex - $16.4
Flkomax - $2.2
Ulptram - $0.78
Vipoxx - $4.75
Amubien - $2.2
Vablium - $0.97
Xawnax - $1.09
Suoma - $3
Mieridia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

mgfjfswth RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------2BBD78738E839B3-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 07:58:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZF4-00039x-Ag for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 07:58: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 HAA05445 for ; Mon, 31 Oct 2005 07:58:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWZDD-0004F0-BM for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 12:56:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWZDA-0004EH-4p for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 12:56:28 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWZD4-0000OK-9p for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 12:56:27 +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 j9VCuGLb022463 for ; Mon, 31 Oct 2005 07:56:16 -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 j9VCuG5c076346 for ; Mon, 31 Oct 2005 07:56:16 -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 j9VCuG7V025912 for ; Mon, 31 Oct 2005 07:56:16 -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 j9VCtdep023776 for ; Mon, 31 Oct 2005 07:56:16 -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: Mon, 31 Oct 2005 07:16:00 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_08142005|August 14, 2005) at 10/31/2005 07:56:16, Serialize complete at 10/31/2005 07:56:16 Content-Type: multipart/alternative; boundary="=_alternative 0042ECC4852570AB_=" 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 1EWZD4-0000OK-9p 66388ec8861dad014e284fc3bebaa782 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/OFE3D9F42E.0BD7DD25-ON852570AB.0041ED56-852570AB.00436476@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10283 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 12:56:31 +0000 This is a multipart message in MIME format. --=_alternative 0042ECC4852570AB_= Content-Type: text/plain; charset="US-ASCII" You would do the same as what you would always do with a Location header in a response, i.e., use the URL specified in the Location header the next time you wanted to apply a method to the resource. Cheers, Geoff Cullen Jennings wrote on 10/30/2005 02:53:15 PM: > On 10/28/05 8:24 PM, "Geoffrey M Clemm" wrote: > > > > > +1 for either Jim's suggested text or saying nothing, > > and +1 that we then close this issue. > > > > Cheers, > > Geoff > > So I am a client implementer, should I do anything with the Location header > in a 207 or should I just always ignore it? > --=_alternative 0042ECC4852570AB_= Content-Type: text/html; charset="US-ASCII"
You would do the same as what you would always do with a Location
header in a response, i.e., use the URL specified in the Location header
the next time you wanted to apply a method to the resource.

Cheers,
Geoff

Cullen Jennings <fluffy@cisco.com> wrote on 10/30/2005 02:53:15 PM:

> On 10/28/05 8:24 PM, "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com> wrote:
>
> >
> > +1 for either Jim's suggested text or saying nothing,
> > and +1 that we then close this issue.
> >
> > Cheers,
> > Geoff
>
> So I am a client implementer, should I do anything with the Location header
> in a 207 or should I just always ignore it?
>
--=_alternative 0042ECC4852570AB_=-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 11:54:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcvC-0005JY-WB for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:54: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 LAA19920 for ; Mon, 31 Oct 2005 11:53:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWctw-0006Na-1Q for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 16:52:52 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EWcts-0006Mx-Fi for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 16:52:48 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EWctp-0004rf-AJ for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 16:52:47 +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 j9VGqhsw028830 for ; Mon, 31 Oct 2005 08:52:43 -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 6338E324002 for ; Mon, 31 Oct 2005 08:52:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43633161.9010102@gmx.de> References: <5ba70ae5437fcf14ad9089cce16c2989@osafoundation.org> <43633161.9010102@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D8A9BB7-80C1-43D4-B421-5D4B40A455DD@apple.com> Content-Transfer-Encoding: 7bit From: Jim Luther Date: Mon, 31 Oct 2005 08:52:56 -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.23 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EWctp-0004rf-AJ 34540e7b2fe937772be796cf57dd381d 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/6D8A9BB7-80C1-43D4-B421-5D4B40A455DD@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10284 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 16:52:52 +0000 Content-Transfer-Encoding: 7bit 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. - Jim From w3c-dist-auth-request@frink.w3.org Mon Oct 31 13:04:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWe1X-0005El-4w for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:04: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 NAA24498 for ; Mon, 31 Oct 2005 13:04:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWe0F-0008H5-RW for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 18:03:27 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWe0C-0008GV-4m for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 18:03:24 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWe08-0001sg-IW for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 18:03:23 +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 j9VI3Dsb029007 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 31 Oct 2005 10:03:13 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-88-3398720 Message-Id: <7D5A74E7-84E3-4938-98CB-643BE2804789@cs.ucsc.edu> Cc: " webdav" From: Jim Whitehead Date: Mon, 31 Oct 2005 10:05:37 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.734) 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.1 X-W3C-Scan-Sig: maggie.w3.org 1EWe08-0001sg-IW 2646d7bf292e149da283e19bb2eb1e8b 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/7D5A74E7-84E3-4938-98CB-643BE2804789@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10285 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 18:03:27 +0000 --Apple-Mail-88-3398720 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit There are two issues with Expect 100-continue: * It is only permitted for methods with request bodies -- it would be far better for a client to have a single mechanism that worked for all methods. * The server's behavior after sending a final status code (i.e., a 4xx) is not great -- either read the entire request body and send to / dev/null, or drop the TCP connection. It would be far better if the client never sent the request body in the first place. * From reading the HTTP specification, it's really unclear to me how Expect 100-continue works with proxy authentication. It almost seems as if this mechanism allows you to bypass proxy authentication. However, I still think the right action here is: * 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. Julian seems to think this is an OK approach. Geoff seems to think this is OK. Jim Luther agrees with the separate draft part. Dang if that doesn't seem like something approaching rough consensus to me. - Jim On Oct 29, 2005, at 5:45 AM, Geoffrey M Clemm wrote: > > I agree that LOCK is the real answer here for WebDAV clients. > > But for the "force-authenticate" advocates (which Julian is not): > If we are contrasting "Expect 100-Continue" vs. "force-authenticate", > I think it would make more sense to advise servers to implement Expect > correctly rather than to introduce a new force-authenticate header. > In particular, why would one believe that a server that doesn't > implement > Expect properly would implement force-authenticate properly (or at > all). > > Cheers, > Geoff > > Julian wrote on 10/29/2005 04:20:45 AM: > > > > Geoffrey M Clemm wrote: > > > > > > To avoid sending the PUT body twice, why can't a client just > > > use the standard HTTP "Expect 100-Continue" header? > > > > It could, but it's a known problem that few servers implement that > > correctly, meaning that the expected header check is indeed > skipped (for > > instance, a server using the servlet API normally doesn't have any > > chance doing this check, see > > ). > > > > > And if a client is proactively checking for authentication > preceding > > > a series of PUT calls, then having it just perform an initial > LOCK/UNLOCK > > > to get the credential challenge doesn't seem like an > unreasonable overhead > > > (2 initial requests). > > > > > > So is this just a technique for servers that want to provide this > > > capability but don't want to support LOCK? > > > > Seems so, because LOCK seems to be yet another existing way to > get what > > those clients want. > > > > Best regards, Julian > > --Apple-Mail-88-3398720 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are two issues with Expect = 100-continue:

* = It is only permitted for methods with request bodies -- it would be far = better for a client to have a single mechanism that worked for all = methods.
* The server's behavior after sending a final status = code (i.e., a 4xx) is not great -- either read the entire request body = and send to /dev/null, or drop the TCP connection. It would be far = better if the client never sent the request body in the first = place.
* =46rom reading the HTTP specification, it's really = unclear to me how Expect 100-continue works with proxy authentication. = It almost seems as if this mechanism allows you to bypass proxy = authentication.

However, I still think the = right action here is:

* 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.

Julian seems to think this = is an OK approach. Geoff seems to think this is OK. Jim Luther agrees = with the separate draft part.

Dang=A0if that doesn't seem = like something approaching rough consensus to me.

- = Jim

On Oct 29, 2005, at 5:45 AM, Geoffrey M = Clemm wrote:


I agree that LOCK is the real = answer here for WebDAV clients.

But for the "force-authenticate" advocates (which Julian = is not):
If we are contrasting = "Expect 100-Continue" vs. "force-authenticate",
I think it would make more sense to advise servers to = implement Expect
correctly rather = than to introduce a new force-authenticate header.
In particular, why would one believe that a server that = doesn't implement
Expect properly = would implement force-authenticate properly (or at all). =

Cheers,
Geoff

Julian = wrote on 10/29/2005 04:20:45 AM:
>
> Geoffrey M Clemm = wrote:
> >
> > To avoid sending the PUT body twice, = why can't a client just
> > use the standard HTTP "Expect = 100-Continue" header?
>
> It could, but it's a known = problem that few servers implement that
> correctly, meaning = that the expected header check is indeed skipped (for
> = instance, a server using the servlet API normally doesn't have any
= > chance doing this check, see
> <http= ://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4812000>).
= >
> > And if a client is proactively checking for = authentication preceding
> > a series of PUT calls, then = having it just perform an initial LOCK/UNLOCK
> > to get the = credential challenge doesn't seem like an unreasonable overhead
> = > (2 initial requests).
> >
> > So is this just = a technique for servers that want to provide this
> > = capability but don't want to support LOCK? =A0
>
> Seems = so, because LOCK seems to be yet another existing way to get what
= > those clients want.
>
> Best regards, Julian
= >

= --Apple-Mail-88-3398720-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 13: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 1EWeD0-0007jj-Ac for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 13: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 NAA25281 for ; Mon, 31 Oct 2005 13:16:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWeCG-0003gG-EU for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 18:15:52 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWeCB-0003a9-Tn for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 18:15:48 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EWeC8-00049l-Sr for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 18:15:47 +0000 Received: (qmail invoked by alias); 31 Oct 2005 18:15:41 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 31 Oct 2005 19:15:41 +0100 X-Authenticated: #1915285 Message-ID: <43665F17.2080208@gmx.de> Date: Mon, 31 Oct 2005 19:14:47 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Whitehead CC: Geoffrey M Clemm , webdav References: <7D5A74E7-84E3-4938-98CB-643BE2804789@cs.ucsc.edu> In-Reply-To: <7D5A74E7-84E3-4938-98CB-643BE2804789@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 (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 1EWeC8-00049l-Sr 38f7250126686d2a83400c11b4d93cf5 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/43665F17.2080208@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10286 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 18:15:52 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > There are two issues with Expect 100-continue: > > * It is only permitted for methods with request bodies -- it would be > far better for a client to have a single mechanism that worked for all > methods. Well, it only has an *effect* for messages with request bodies. > * The server's behavior after sending a final status code (i.e., a 4xx) > is not great -- either read the entire request body and send to > /dev/null, or drop the TCP connection. It would be far better if the > client never sent the request body in the first place. My understanding was that the client will never send the body it doesn't get the 100 Continue. > * From reading the HTTP specification, it's really unclear to me how > Expect 100-continue works with proxy authentication. It almost seems as > if this mechanism allows you to bypass proxy authentication. > > However, I still think the right action here is: > > * 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. > > Julian seems to think this is an OK approach. Geoff seems to think this > is OK. Jim Luther agrees with the separate draft part. > > Dang if that doesn't seem like something approaching rough consensus to me. Sounds good. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 31 13:26:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWeMX-0001EX-9I for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:26: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 NAA25830 for ; Mon, 31 Oct 2005 13:26:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWeLt-0006es-DA for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 18:25:49 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EWeLs-0006eK-Qx for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 18:25:49 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EWeLp-0000Kq-2s for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 18:25:47 +0000 Received: (qmail invoked by alias); 31 Oct 2005 18:25:39 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 31 Oct 2005 19:25:39 +0100 X-Authenticated: #1915285 Message-ID: <4366616B.2070402@gmx.de> Date: Mon, 31 Oct 2005 19:24:43 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , Jim Whitehead , 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 1EWeLp-0000Kq-2s 4ebc864684de9606cf0e15ac92767fd3 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/4366616B.2070402@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10287 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 18:25:49 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Julian, in the above paragraph, if we replaced '"DAV:" namespace' with > something like '"DAV:" namespace hierarchy' would that be correct? I don't > know how to say this by do you have some text that you think would correctly > say the essence of what the above paragraph is trying to get at? Not really. XML namespaces do not have hierarchy. I'd really see the full paragraph, compare with RFC2518, and the make suggestions. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 31 13:54:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWenQ-0008Kb-Qk for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:54: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 NAA28116 for ; Mon, 31 Oct 2005 13:53:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWemf-00046A-PA for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 18:53:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWemd-00045X-3g for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 18:53:27 +0000 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by maggie.w3.org with esmtp (Exim 4.50) id 1EWemZ-0003SO-Me for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 18:53:26 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 31 Oct 2005 10:53:22 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9VIrJ94016324; Mon, 31 Oct 2005 10:53:19 -0800 (PST) Received: from 10.21.123.51 ([10.21.123.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Oct 2005 18:53:51 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 31 Oct 2005 10:53:17 -0800 From: Cullen Jennings To: Geoffrey M Clemm , WebDav Message-ID: Thread-Topic: [Bug 12] Destination header "consistent" Thread-Index: AcXeTFqrmQQoPko/EdqDDgARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3213600797_4027429" Received-SPF: none (maggie.w3.org: domain of fluffy@cisco.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1EWemZ-0003SO-Me 5ab5257d8fc42f4408d6e3ac39c6ca40 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/BF8BA81D.5D934%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10288 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 18:53:29 +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_3213600797_4027429 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thanks - Well if that's the case, seem like an argument that everything that needs saying has already been said. On 10/31/05 4:16 AM, "Geoffrey M Clemm" wrote: > > You would do the same as what you would always do with a Location > header in a response, i.e., use the URL specified in the Location header > the next time you wanted to apply a method to the resource. > > Cheers, > Geoff > > Cullen Jennings wrote on 10/30/2005 02:53:15 PM: > >> > On 10/28/05 8:24 PM, "Geoffrey M Clemm" wrote: >> > >>> > > >>> > > +1 for either Jim's suggested text or saying nothing, >>> > > and +1 that we then close this issue. >>> > > >>> > > Cheers, >>> > > Geoff >> > >> > So I am a client implementer, should I do anything with the Location header >> > in a 207 or should I just always ignore it? >> > > --B_3213600797_4027429 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Bug 12] Destination header "consistent"
Thanks - Well if that's the case, seem like an argument that everything tha= t needs saying has already been said.


On 10/31/05 4:16 AM, "Geoffrey M Clemm" <geoffrey.clemm@us.ibm= .com> wrote:


You would do the same as what you would always do with a L= ocation
header in a response, i.e., use the URL specified in the L= ocation header
the next time you wanted to apply a method to the resource= .

Cheers,
Geoff

Cullen Jennings <fluffy@cisco.com> wrote on 10/30/20= 05 02:53:15 PM:

> On 10/28/05 8:24 PM, "Geoffrey M Clemm" <geoffrey.clemm@u= s.ibm.com> wrote:
>
> >
> > +1 for either Jim's suggested text or saying nothing,
> > and +1 that we then close this issue.
> >
> > Cheers,
> > Geoff
>
> So I am a client implementer, should I do anything with the Location h= eader
> in a 207 or should I just always ignore it?
>


--B_3213600797_4027429-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 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 1EWev8-0002ZA-Qx for webdav-archive@megatron.ietf.org; Mon, 31 Oct 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 OAA29467 for ; Mon, 31 Oct 2005 14:01:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWeuU-0007Nh-NG for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 19:01:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWeuT-0007N9-UZ for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 19:01:34 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWeuR-0004sv-Ct for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 19:01:33 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2005 11:01:29 -0800 X-IronPort-AV: i="3.97,270,1125903600"; d="scan'208"; a="225746199:sNHT24026788" 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 j9VJ1L8m011813; Mon, 31 Oct 2005 11:01:23 -0800 (PST) Received: from 10.21.123.51 ([10.21.123.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Oct 2005 19:01:58 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 31 Oct 2005 11:01:24 -0800 From: Cullen Jennings To: Julian Reschke CC: Lisa Dusseault , Jim Whitehead , WebDav Message-ID: Thread-Topic: This Document Defines Two Namespaces (was Re: Combined set of issues ...) Thread-Index: AcXeTXzxu0xpqkpAEdqDDgARJEEJ/A== In-Reply-To: <4366616B.2070402@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: none (maggie.w3.org: domain of fluffy@cisco.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: maggie.w3.org 1EWeuR-0004sv-Ct a9da73d4ab6c1eb021e63bd74f57cc84 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/BF8BAA04.5D939%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10289 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 19:01:34 +0000 Content-Transfer-Encoding: 7bit Ok, I will take this as we have consensus that the next version of the draft will contain the text as Lisa proposed and at that point we will look at it and decide if we need to make changes. On 10/31/05 10:24 AM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> Julian, in the above paragraph, if we replaced '"DAV:" namespace' with >> something like '"DAV:" namespace hierarchy' would that be correct? I don't >> know how to say this by do you have some text that you think would correctly >> say the essence of what the above paragraph is trying to get at? > > Not really. XML namespaces do not have hierarchy. I'd really see the > full paragraph, compare with RFC2518, and the make suggestions. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 31 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 1EWev9-0002ZO-Qb for webdav-archive@megatron.ietf.org; Mon, 31 Oct 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 OAA29470 for ; Mon, 31 Oct 2005 14:01:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWeuc-0007Or-29 for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 19:01:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWeub-0007OI-M0 for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 19:01:41 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1EWeuU-0002Ud-Vy for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 19:01:41 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 31 Oct 2005 10:57:07 -0800 X-IronPort-AV: i="3.97,270,1125903600"; d="scan'208,217"; a="358998749:sNHT1006701296" 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 j9VItRbC025778; Mon, 31 Oct 2005 10:57:03 -0800 (PST) Received: from 10.21.123.51 ([10.21.123.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Oct 2005 18:57:15 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 31 Oct 2005 10:56:40 -0800 From: Cullen Jennings To: Jim Whitehead , Geoffrey M Clemm CC: WebDav Message-ID: Thread-Topic: [Bug 18] no record of consensus for force-authenticate Thread-Index: AcXeTNOqEjOAgEpAEdqDDgARJEEJ/A== In-Reply-To: <7D5A74E7-84E3-4938-98CB-643BE2804789@cs.ucsc.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3213601000_4079134" Received-SPF: pass (lisa.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: lisa.w3.org 1EWeuU-0002Ud-Vy 1e06af3c2d2a84f91deeb7384c88aa92 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/BF8BA8E8.5D935%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10290 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 19:01:42 +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_3213601000_4079134 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Unless more than one person objects in the next week, I'm going to invoke one of my rare Chair privileges and claim that looks like consensus to me too. On 10/31/05 10:05 AM, "Jim Whitehead" wrote: > However, I still think the right action here is: >=20 > * 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 approac= h, > and discuss on HTTP-WG list. >=20 > Julian seems to think this is an OK approach. Geoff seems to think this i= s OK. > Jim Luther agrees with the separate draft part. >=20 > Dang=A0if that doesn't seem like something approaching rough consensus to m= e. >=20 > - Jim --B_3213601000_4079134 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Bug 18] no record of consensus for force-authenticate
Unless more than one person objects in the next week, I'm going to invoke o= ne of my rare Chair privileges and claim that looks like consensus to me too= .

On 10/31/05 10:05 AM, "Jim Whitehead" <ejw@soe.ucsc.edu> wr= ote:

However, I still think the right action here is:

* Create a new appendix in 2518bis
* In this appendix, document the problem
* Describe the known approaches for addressing the problem (If approach, 10= 0-continue approach) and their issues
* Create a separate draft focusing just on the Force-Authenticate approach,= and discuss on HTTP-WG list.

Julian seems to think this is an OK approach. Geoff seems to think this is = OK. Jim Luther agrees with the separate draft part.

Dang=A0if that doesn't seem like something approaching rough consensus to me.=

- Jim

 --B_3213601000_4079134-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 14:40:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfWG-00059U-5c for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 14:40: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 OAA02882 for ; Mon, 31 Oct 2005 14:40:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWfV6-0006hU-PY for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 19:39:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWfV3-0006gw-70 for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 19:39:21 +0000 Received: from e36.co.us.ibm.com ([32.97.110.154]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWfUr-0002wY-Pw for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 19:39:20 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9VJd7VH006498 for ; Mon, 31 Oct 2005 14:39:07 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id j9VJe9v3544440 for ; Mon, 31 Oct 2005 12:40:10 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j9VJd65D004194 for ; Mon, 31 Oct 2005 12:39:06 -0700 Received: from f16n241e (d03nmc07h.boulder.ibm.com [9.17.195.22]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j9VJd4Qs004027; Mon, 31 Oct 2005 12:39:06 -0700 In-Reply-To: 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: Mon, 31 Oct 2005 08:57:04 -0500 X-MIMETrack: Serialize by Router on D03NMC07/03/M/IBM(Release 6.53HF655 | July 22, 2005) at 10/31/2005 12:40:35, Serialize complete at 10/31/2005 12:40:35 Content-Type: multipart/alternative; boundary="=_alternative 0045C26D852570AB_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.110.154 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EWfUr-0002wY-Pw af497e5e31821a209657405a355b1d02 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/OFA16CC6EB.BCF5C9F9-ON852570AB.00454675-852570AB.004CA4F6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10291 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 19:39:24 +0000 This is a multipart message in MIME format. --=_alternative 0045C26D852570AB_= Content-Type: text/plain; charset="US-ASCII" I agree that one needs to deal with the problem of failed clients, but the correct way for the client to do so is with an UNLOCK/LOCK sequence, and not by using a lock token that it obtains from a PROPFIND. This handles the case where it turns out that the original client hadn't failed, but was just suspended. With an UNLOCK/LOCK sequence, the original client will get a failure on PUT because its lock token is no longer valid. With a re-use of the lock token obtained with a PROPFIND, the original client's PUT will succeed and overwrite changes made by the client that stole the lock token. Cheers, Geoff Lisa Dusseault wrote on 10/30/2005 10:51:58 AM: > I mostly agree with this, except with the problem of failed clients. > If I use a WebDAV client that crashes and loses its locks, or has a bug > and fails to unlock -- or if I'm testing client or server software -- I > need a way to get the lock token to remove it as a last resort. > > So yes, while clients SHOULD get the lock token on LOCK response and > remember it, there needs to be a way to recover without administrator > intervention. > > Lisa > > On Oct 29, 2005, at 8:55 PM, Geoffrey M Clemm wrote: > > > > > To be clear, I am completely in favor of a server exposing all of > > the locks on a resource to an authorized user ... I am only against > > revealing the lock-token in the information on the lock. > > > > As for clients that use lock-discovery instead of keeping track of > > lock tokens, their implementor clearly didn't understand the purpose > > of a lock token (preventing a user from overwriting his own changes > > from > > another of his clients), and the specification should make this mistake > > clear, and not encourage it. > > > > So I agree with Julian's final suggestion that this issue merits a > > paragraph guiding clients on how to use lock tokens properly, and > > guiding servers on how to deal with poorly implemented clients. > > > > Cheers, > > Geoff > > > > > > Julian wrote on 10/29/2005 09:12:06 AM: > > > > > > > > Geoffrey M Clemm wrote: > > > > > > > > The likelihood of damage from lock stealing can be decreased by > > > > only allowing a given user/principal to steal his own locks, but > > > > (as indicated in my original message below :-) it does not prevent > > > > two clients of a given user/principal from overwriting each others > > > > changes. Since there is a completely safe way of handling this > > > > > > Partly correct. Some clients put stuff into DAV:owner in order to > > ensure > > > that they can recognize the locks they created, but of course that's > > > lame compared to just remembering which locks one created in the > > first > > > place. > > > > > > > scenario (i.e., streaming an UNLOCK/LOCK sequence to the server), > > > > I maintain my position that a client should never "steal" > > > > a lock by discovering the lock-token via PROPFIND, even if that > > > > lock was held by another client of that same user, and therefore > > > > lock tokens should never be exposed in a PROPFIND. > > > > > > Well, from a purely theoretical point of view, I agree. In practice, > > > clients do lock discovery instead of keeping track of their locks on > > > their own, so these clients wouldn't work in this case. > > > > > > BTW: if a server does not want to expose lock tokens, it can also > > show > > > the locks, but leave out the DAV:locktoken child element. Anyway, > > this > > > is certainly a topic where on coherent paragraph would make a lot > > of sense. > > > > > > Best regards, Julian > > > --=_alternative 0045C26D852570AB_= Content-Type: text/html; charset="US-ASCII"
I agree that one needs to deal with the problem of failed clients,
but the correct way for the client to do so is with an
UNLOCK/LOCK sequence, and not by using a lock token that it obtains
from a PROPFIND.  This handles the case where it turns out that the
original client hadn't failed, but was just suspended.  With an UNLOCK/LOCK
sequence, the original client will get a failure on PUT because
its lock token is no longer valid.  With a re-use of the lock token
obtained with a PROPFIND, the original client's PUT will succeed
and overwrite changes made by the client that stole the lock token.

Cheers,
Geoff

Lisa Dusseault <lisa@osafoundation.org> wrote on 10/30/2005 10:51:58 AM:

> I mostly agree with this, except with the problem of failed clients.  
> If I use a WebDAV client that crashes and loses its locks, or has a bug
> and fails to unlock -- or if I'm testing client or server software -- I
> need a way to get the lock token to remove it as a last resort.
>
> So yes, while clients SHOULD get the lock token on LOCK response and
> remember it, there needs to be a way to recover without administrator
> intervention.
>
> Lisa
>
> On Oct 29, 2005, at 8:55 PM, Geoffrey M Clemm wrote:
>
> >
> > To be clear, I am completely in favor of a server exposing all of
> > the locks on a resource to an authorized user ... I am only against
> > revealing the lock-token in the information on the lock.
> >
> > As for clients that use lock-discovery instead of keeping track of
> > lock tokens, their implementor clearly didn't understand the purpose
> > of a lock token (preventing a user from overwriting his own changes
> > from
> > another of his clients), and the specification should make this mistake
> > clear, and not encourage it.
> >
> > So I agree with Julian's final suggestion that this issue merits a
> > paragraph guiding clients on how to use lock tokens properly, and
> > guiding servers on how to deal with poorly implemented clients.
> >
> > Cheers,
> > Geoff
> >
> >
> > Julian wrote on 10/29/2005 09:12:06 AM:
> >
> >  >
> >  > Geoffrey M Clemm wrote:
> >  > >
> >  > > The likelihood of damage from lock stealing can be decreased by
> >  > > only allowing a given user/principal to steal his own locks, but
> >  > > (as indicated in my original message below :-) it does not prevent
> >  > > two clients of a given user/principal from overwriting each others
> >  > > changes.  Since there is a completely safe way of handling this
> >  >
> >  > Partly correct. Some clients put stuff into DAV:owner in order to
> > ensure
> >  > that they can recognize the locks they created, but of course that's
> >  > lame compared to just remembering which locks one created in the
> > first
> >  > place.
> >  >
> >  > > scenario (i.e., streaming an UNLOCK/LOCK sequence to the server),
> >  > > I maintain my position that a client should never "steal"
> >  > > a lock by discovering the lock-token via PROPFIND, even if that
> >  > > lock was held by another client of that same user, and therefore
> >  > > lock tokens should never be exposed in a PROPFIND.
> >  >
> >  > Well, from a purely theoretical point of view, I agree. In practice,
> >  > clients do lock discovery instead of keeping track of their locks on
> >  > their own, so these clients wouldn't work in this case.
> >  >
> >  > BTW: if a server does not want to expose lock tokens, it can also
> > show
> >  > the locks, but leave out the DAV:locktoken child element. Anyway,
> > this
> >  > is certainly a topic where on coherent paragraph would make a lot
> > of sense.
> >  >
> >  > Best regards, Julian
> >  >
 --=_alternative 0045C26D852570AB_=-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 15:00:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfpZ-0001Ay-1H for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:00: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 PAA03982 for ; Mon, 31 Oct 2005 15:00:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWfol-0002Ln-If for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 19:59:43 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EWfoj-0002L8-Aj for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 19:59:41 +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 1EWfoa-0000Px-Cy for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 19:59:40 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 31 Oct 2005 11:59:27 -0800 X-IronPort-AV: i="3.97,270,1125903600"; d="scan'208"; a="670705395:sNHT31906744" 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 j9VJxPUw000945 for ; Mon, 31 Oct 2005 11:59:25 -0800 (PST) Received: from 10.21.123.51 ([10.21.123.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Oct 2005 19:59:57 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 31 Oct 2005 11:59:23 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: [Inquiry #83038] Publication requested for draft-ietf-webdav-redirectref-protocol-13 Thread-Index: AcXeVZaX1PZv4kpIEdqDDgARJEEJ/A== In-Reply-To: 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=-1.9 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EWfoa-0000Px-Cy f98ceea3245f4aded8f4087db035ee59 X-Original-To: w3c-dist-auth@w3.org Subject: FW: [Inquiry #83038] Publication requested for draft-ietf-webdav-redirectref-protocol-13 X-Archived-At: http://www.w3.org/mid/BF8BB79B.5D971%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10292 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 19:59:43 +0000 Content-Transfer-Encoding: 7bit ------ Forwarded Message From: via RT Reply-To: Date: Mon, 31 Oct 2005 14:55:23 -0500 To: Subject: [Inquiry #83038] Publication requested for draft-ietf-webdav-redirectref-protocol-13 Your request to publish I-D draft-ietf-webdav-redirectref-protocol as an Experimental RFC has been received. Please use the I-D Tracker (https://datatracker.ietf.org/public/pidtracker.cgi) to check the status of the document. Please note that once a request to publish an I-D as an RFC has been submitted, the I-D must not be revised without the explicit advance approval of the shepherding Area Director (AD). ------ End of Forwarded Message From w3c-dist-auth-request@frink.w3.org Mon Oct 31 15:34:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgLy-0000eM-1D for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:34: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 PAA06177 for ; Mon, 31 Oct 2005 15:33:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWgLF-0004fK-Bx for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 20:33:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWgLB-0004ea-Mp for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 20:33:13 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EWgL8-0003a7-Rx for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 20:33:13 +0000 Received: (qmail invoked by alias); 31 Oct 2005 20:33:09 -0000 Received: from p508FA531.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.165.49] by mail.gmx.net (mp014) with SMTP; 31 Oct 2005 21:33:09 +0100 X-Authenticated: #1915285 Message-ID: <43667F68.6070904@gmx.de> Date: Mon, 31 Oct 2005 21:32:40 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , Jim Whitehead , 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 1EWgL8-0003a7-Rx 8ea03a99f4f54e1c82e24114ba816ef6 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/43667F68.6070904@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10293 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 20:33:17 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Ok, I will take this as we have consensus that the next version of the draft > will contain the text as Lisa proposed and at that point we will look at it > and decide if we need to make changes. Ahem. I'd actually like to see the proposed text in context, and then comment on it. Lisa, could you please post the full paragraph for review? Thanks, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 31 16:07:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgsf-0001w1-O3 for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 16:07: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 QAA09951 for ; Mon, 31 Oct 2005 16:07:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWgrM-0003Wk-3Y for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 21:06:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWgrI-0003W7-Bt for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 21:06:24 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWgrF-0000En-63 for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 21:06:23 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6C9B01422A9; Mon, 31 Oct 2005 13:06:19 -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 22391-09; Mon, 31 Oct 2005 13:06:19 -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 097351422A7; Mon, 31 Oct 2005 13:06:19 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-2-14228025 Message-Id: Cc: Geoffrey M Clemm , WebDav From: Lisa Dusseault Date: Mon, 31 Oct 2005 13:06:06 -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.5 X-W3C-Scan-Sig: maggie.w3.org 1EWgrF-0000En-63 fb5624d1bf1171435329ca2d99b7e821 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/d66e878be77b9f4884003c1bb8152acd@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10294 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 21:06:28 +0000 --Apple-Mail-2-14228025 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The original question that brought up this issue was how to interpret the URLs inside the body of the Multi-Status if there was a Location header. It was unclear to some client implementors - should the URLs in the body be relative to the Location header - should they be relative to the Request-URI - should they be absolute URLs, always, and if so, should they be consistent with the Location header or the Request-URI There was an actual interoperability problem that uncovered this. Some server returned a Location header and a bunch of URLs in the body, that used the new location. The client errored because the client never expected to query a Collection for its children and find a bunch of URLs that didn't begin with the URL used in the request URI. Lisa On Oct 31, 2005, at 10:53 AM, Cullen Jennings wrote: > > Thanks - Well if that's the case, seem like an argument that > everything that needs saying has already been said. > > > On 10/31/05 4:16 AM, "Geoffrey M Clemm" > wrote: > >> >> You would do the same as what you would always do with a Location >> header in a response, i.e., use the URL specified in the Location >> header >> the next time you wanted to apply a method to the resource. >> >> Cheers, >> Geoff >> >> Cullen Jennings wrote on 10/30/2005 02:53:15 PM: >> >> > On 10/28/05 8:24 PM, "Geoffrey M Clemm" >> wrote: >> > >> > > >> > > +1 for either Jim's suggested text or saying nothing, >> > > and +1 that we then close this issue. >> > > >> > > Cheers, >> > > Geoff >> > >> > So I am a client implementer, should I do anything with the >> Location header >> > in a 207 or should I just always ignore it? >> > >> > > --Apple-Mail-2-14228025 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit The original question that brought up this issue was how to interpret the URLs inside the body of the Multi-Status if there was a Location header. It was unclear to some client implementors - should the URLs in the body be relative to the Location header - should they be relative to the Request-URI - should they be absolute URLs, always, and if so, should they be consistent with the Location header or the Request-URI There was an actual interoperability problem that uncovered this. Some server returned a Location header and a bunch of URLs in the body, that used the new location. The client errored because the client never expected to query a Collection for its children and find a bunch of URLs that didn't begin with the URL used in the request URI. Lisa On Oct 31, 2005, at 10:53 AM, Cullen Jennings wrote: Verdana Thanks - Well if that's the case, seem like an argument that everything that needs saying has already been said. Verdana On 10/31/05 4:16 AM, "Geoffrey M Clemm" < wrote: You would do the same as what you would always do with a LocationVerdana header in a response, i.e., use the URL specified in the Location headerVerdana the next time you wanted to apply a method to the resource.Verdana Cheers,Verdana GeoffVerdana Cullen Jennings < wrote on 10/30/2005 02:53:15 PM: > On 10/28/05 8:24 PM, "Geoffrey M Clemm" < wrote: > > > > > +1 for either Jim's suggested text or saying nothing, > > and +1 that we then close this issue. > > > > Cheers, > > Geoff > > So I am a client implementer, should I do anything with the Location header > in a 207 or should I just always ignore it? > --Apple-Mail-2-14228025-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 16:08:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgtC-00023j-VW for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 16:08: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 QAA09982 for ; Mon, 31 Oct 2005 16:08:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWgse-0003ev-QR for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 21:07:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWgse-0003eC-6R for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 21:07:48 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EWgsb-0007nM-1t for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 21:07:48 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 08FC71422A9; Mon, 31 Oct 2005 13:07:44 -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 25990-08; Mon, 31 Oct 2005 13:07:43 -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 B81A51422A7; Mon, 31 Oct 2005 13:07:38 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-3-14302669 Message-Id: Cc: Jim Whitehead , Geoffrey M Clemm , WebDav From: Lisa Dusseault Date: Mon, 31 Oct 2005 13:07:21 -0800 To: Cullen Jennings 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 1EWgsb-0007nM-1t 97a527dd63b156615b2c4338947ff1fb 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/e35063789fe1be201d0a1e3e34de2bb5@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10295 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 21:07:48 +0000 --Apple-Mail-3-14302669 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable To clarify, would the Authorization header hacks I mentioned last week=20= count as one of the known approaches? Lisa On Oct 31, 2005, at 10:56 AM, Cullen Jennings wrote: > > Unless more than one person objects in the next week, I'm going to=20 > invoke one of my rare Chair privileges and claim that looks like=20 > consensus to me too. > > On 10/31/05 10:05 AM, "Jim Whitehead" wrote: > >> However, I still think the right action here is: >> >> * Create a new appendix in 2518bis >> * In this appendix, document the problem >> * Describe the known approaches for addressing the problem (If=20 >> approach, 100-continue approach) and their issues >> * Create a separate draft focusing just on the Force-Authenticate=20 >> approach, and discuss on HTTP-WG list. >> >> Julian seems to think this is an OK approach. Geoff seems to think=20= >> this is OK. Jim Luther agrees with the separate draft part. >> >> Dang=A0if that doesn't seem like something approaching rough = consensus=20 >> to me. >> >> - Jim > > =20= --Apple-Mail-3-14302669 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To clarify, would the Authorization header hacks I mentioned last week count as one of the known approaches? =20 Lisa On Oct 31, 2005, at 10:56 AM, Cullen Jennings wrote: Verdana Unless more than one person objects in the next week, I'm going to invoke one of my rare Chair privileges and claim that looks like consensus to me too. Verdana On 10/31/05 10:05 AM, "Jim Whitehead" < wrote: VerdanaHowever, I still think the right action here is: Verdana * Create a new appendix in = 2518bis Verdana * In this appendix, document the problem Verdana * Describe the known approaches for addressing the problem (If approach, 100-continue approach) and their issues Verdana * Create a separate draft focusing just on the Force-Authenticate approach, and discuss on HTTP-WG = list. Verdana Julian seems to think this is an OK approach. Geoff seems to think this is OK. Jim Luther agrees with the separate draft part. Verdana Dang=A0if that doesn't seem like something approaching rough consensus to me. Verdana - Jim = --Apple-Mail-3-14302669-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 16:19:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWh3j-0004Vv-HB for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 16:19: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 QAA10607 for ; Mon, 31 Oct 2005 16:18:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWh39-0007Zh-2C for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 21:18:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EWh38-0007Z9-GX for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 21:18:38 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EWh35-00024K-Gv for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 21:18:38 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A822E1422A7; Mon, 31 Oct 2005 13:18: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 18640-06; Mon, 31 Oct 2005 13:18:34 -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 5A75C14229A; Mon, 31 Oct 2005 13:18:34 -0800 (PST) In-Reply-To: <43667F68.6070904@gmx.de> References: <43667F68.6070904@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1e1259203fa74a1fa86f011e540118e7@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Jim Whitehead , WebDav , Cullen Jennings From: Lisa Dusseault Date: Mon, 31 Oct 2005 13:18:21 -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 1EWh35-00024K-Gv 573c59c59f9f129f16d57eef4b75aa0f 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/1e1259203fa74a1fa86f011e540118e7@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10297 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 21:18:39 +0000 Content-Transfer-Encoding: 7bit That was the full paragraph. Here's the entire section of proposed text: IANA Considerations WebDAV uses XML-based identifiers with XML namespaces. The use of XML namespaces means that unique WebDAV property names and XML elements can be quickly defined by any WebDAV user or application, without requiring IANA action. The property names and XML elements in this specification are all in the "DAV:" namespace. Creation of identifiers in the "DAV:" namespace is controlled by the IETF. The URI registrations for opaquelocktoken and DAV URI schemes made in RFC 2518 should still be considered active. Lisa On Oct 31, 2005, at 12:32 PM, Julian Reschke wrote: > Cullen Jennings wrote: >> Ok, I will take this as we have consensus that the next version of >> the draft >> will contain the text as Lisa proposed and at that point we will look >> at it >> and decide if we need to make changes. > > Ahem. I'd actually like to see the proposed text in context, and then > comment on it. > > Lisa, could you please post the full paragraph for review? > > Thanks, > > Julian From pwg-announce-owner@pwg.org Mon Oct 31 16:19:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWh3n-0004XN-Ft; Mon, 31 Oct 2005 16:19:20 -0500 Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10609; Mon, 31 Oct 2005 16:18:59 -0500 (EST) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id j9VLIjPu019412; Mon, 31 Oct 2005 16:18:47 -0500 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id j9VLIjMS019409; Mon, 31 Oct 2005 16:18:45 -0500 Received: by pwg.org (bulk_mailer v1.13); Mon, 31 Oct 2005 16:16:31 -0500 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id j9VLGRxJ018685 for ; Mon, 31 Oct 2005 16:16:29 -0500 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id j9VLGRk0018682 for pwg-announce-out; Mon, 31 Oct 2005 16:16:27 -0500 Message-ID: From: "McDonald, Ira" To: "'pwg-announce@pwg.org'" Subject: PWG-ANNOUNCE> FW: P2600/PWG Meeting Schedule for 2006 Date: Mon, 31 Oct 2005 13:17:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DE60.71C89F8E" Sender: owner-pwg-announce@pwg.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5DE60.71C89F8E Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FYI, - Ira =20 Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com=20 -----Original Message----- From: Don Wright [mailto:don@LEXMARK.COM] Sent: Monday, October 31, 2005 3:46 PM To: STDS-2600@listserv.ieee.org Subject: [2600] 2006 Meeting Schedule After our meeting last week, the PWG, who has graciously hosted us for several meetings this year and will again in 2006, swapped the = locations of the June and September meetings. As such, here are the dates and = locations for us in 2006. I will update the web page accordingly.=20 * January 16-17 with the PWG in Las Vegas=20 * March 2-3 open=20 * April 3-4 with PWG in Mount Laurel, NJ (near Philly) @ Okidata=20 * May 23-24 (Oc=E9 checking on Paris)=20 * June 19-20 with PWG (Portland - Sharp - tentative)=20 * July 26-27 (Rochester, NY - Xerox)=20 * September 6-7 (Boulder - IBM - tentative)=20 * October 23-24 with PWG in Lexington KY @ Lexmark=20 * December 11-12 (Canon, Orange County - tentative)=20 After some checking, Ricoh is unable to host us in Atlanta in March. = Anyone else have something available in the southern US (Georgia, Texas, = Florida, etc.)?=20 ************************************************************************= ***=20 Don Wright don@lexmark.com=20 f.wright@ieee.org / = f.wright@computer.org=20 Director of Standards=20 Lexmark International Past Chair, IEEE SA Standards Board=20 740 New Circle Rd Chair, Patent Committee IEEE SASB=20 Lexington, Ky 40550 Member-at-large, IEEE CS SAB=20 859-825-4808 (phone) Member, IEEE-ISTO Board of Directors=20 603-963-8352 (fax) Member, W3C Advisory Committee=20 ************************************************************************= ***=20 ------_=_NextPart_001_01C5DE60.71C89F8E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
FYI,
-=20 Ira
 

Ira McDonald (Musician / Software Architect)
Blue = Roof Music=20 / High North Inc
PO Box 221  Grand Marais, MI  = 49839
phone:=20 +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: Don Wright=20 [mailto:don@LEXMARK.COM]
Sent: Monday, October 31, 2005 3:46=20 PM
To: STDS-2600@listserv.ieee.org
Subject: [2600] = 2006=20 Meeting Schedule


After our = meeting last=20 week, the PWG, who has graciously hosted us for several meetings this = year and=20 will again in 2006, swapped the locations of the June and September = meetings.=20  As such, here are the dates and locations for us in 2006.  I = will=20 update the web page accordingly.

* = January 16-17=20 with the PWG in = Las=20 Vegas
* March 2-3 open
* April=20 3-4 with PWG in = Mount Laurel,=20 NJ (near Philly) @ Okidata
* May 23-24 (Oc=E9 = checking on=20 Paris)
* June 19-20 with PWG (Portland - Sharp - tentative) =
* July 26-27 (Rochester, NY - Xerox)
* September=20 6-7 (Boulder - IBM - tentative)
* October = 23-24 with=20 PWG in = Lexington KY @=20 Lexmark
* December 11-12 (Canon, Orange = County -=20 tentative)

After some=20 checking, Ricoh is unable to host us in Atlanta in March.  Anyone = else have=20 something available in the southern US (Georgia, Texas, Florida, = etc.)?=20

***************************************************************= ************=20
 Don Wright     =    =20              don@lexmark.com =
            =  =20                  =20  f.wright@ieee.org / f.wright@computer.org
 Director of Standards =
 Lexmark International     =  =20     Past Chair, IEEE SA Standards Board
 740 New Circle Rd     =    =20       Chair, Patent Committee IEEE SASB
 Lexington, Ky 40550     =    =20     Member-at-large, IEEE CS SAB
 859-825-4808 (phone)          =20  Member, IEEE-ISTO Board of Directors
 603-963-8352 (fax)           =  =20  Member, W3C Advisory Committee
***************************************************************= ************=20
------_=_NextPart_001_01C5DE60.71C89F8E-- From w3c-dist-auth-request@frink.w3.org Mon Oct 31 16:17:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWh2J-00046R-Ga for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 16:17: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 QAA10522 for ; Mon, 31 Oct 2005 16:17:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWh1g-0007NA-1Y for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 21:17:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWh1c-0007Mb-AN for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 21:17:04 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EWh1a-0000wU-6z for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 21:17:04 +0000 Received: (qmail invoked by alias); 31 Oct 2005 21:16:59 -0000 Received: from p508FA531.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.165.49] by mail.gmx.net (mp023) with SMTP; 31 Oct 2005 22:16:59 +0100 X-Authenticated: #1915285 Message-ID: <436689A9.4060304@gmx.de> Date: Mon, 31 Oct 2005 22:16:25 +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: Cullen Jennings , 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 1EWh1a-0000wU-6z 630841fe8ac48911d978f10f4e6864e4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/436689A9.4060304@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10296 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 21:17:08 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > The original question that brought up this issue was how to interpret > the URLs inside the body of the Multi-Status if there was a Location Is there any record on the mailing list of this issue? Has anybody ever *seen* a 207 with a Location header? That is, why was this question asked in the first place? > header. It was unclear to some client implementors > - should the URLs in the body be relative to the Location header > - should they be relative to the Request-URI > - should they be absolute URLs, always, and if so, should they be They should be either absolute, or need to be resolved relative to the Reuqest-URI. If this is not clear from RFC2518, let's fix that. > consistent with the Location header or the Request-URI What does "consistent" mean here? Note that this is the original reason why I raised this issue. > There was an actual interoperability problem that uncovered this. Some > server returned a Location header and a bunch of URLs in the body, that > used the new location. The client errored because the client never > expected to query a Collection for its children and find a bunch of URLs > that didn't begin with the URL used in the request URI. As far as I can tell, that's a server bug. Clients aren't expected to handle PROPFIND responses with URLs that identify resources are then the one identified by the Request-URI (and its descendants). If a server wants to redirect clients, it will have to use a 3xx status code (as defined in RFC2616). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 31 16:30:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhEA-00084H-No for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 16:30: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 QAA11831 for ; Mon, 31 Oct 2005 16:29:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWhDV-0000mA-D6 for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 21:29:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWhDU-0000lV-Qy for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 21:29:20 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EWhDN-0002mK-Ti for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 21:29:20 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 635B914229A; Mon, 31 Oct 2005 13:29:13 -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 13618-03; Mon, 31 Oct 2005 13:29:13 -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 04F09142295; Mon, 31 Oct 2005 13:29:13 -0800 (PST) In-Reply-To: <436689A9.4060304@gmx.de> References: <436689A9.4060304@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8d2dc10867f989a1244c5ee4fe5672cd@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , WebDav , Cullen Jennings From: Lisa Dusseault Date: Mon, 31 Oct 2005 13:29:00 -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 1EWhDN-0002mK-Ti a28e0dd3639a0a4a39e207087e6e3d25 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/8d2dc10867f989a1244c5ee4fe5672cd@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10298 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 21:29:21 +0000 Content-Transfer-Encoding: 7bit On Oct 31, 2005, at 1:16 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> The original question that brought up this issue was how to interpret >> the URLs inside the body of the Multi-Status if there was a Location > > Is there any record on the mailing list of this issue? Has anybody > ever *seen* a 207 with a Location header? That is, why was this > question asked in the first place? Yes. At an Interop event. ... > >> consistent with the Location header or the Request-URI > > What does "consistent" mean here? Note that this is the original > reason why I raised this issue. What I meant by "consistent" (and maybe somebody can find a better way to word this or we can just define it) was: In a PROPFIND or PROPPATCH response, for the URLs in the body to be consistent with the Request-URI, all URLs would all begin with the exact URL used in the Request-URI. I believe the same would be true for MOVE and COPY responses -- the URLs would be consistent with the Request URI, not with the Destination request header or the Location reply header. >> There was an actual interoperability problem that uncovered this. >> Some server returned a Location header and a bunch of URLs in the >> body, that used the new location. The client errored because the >> client never expected to query a Collection for its children and find >> a bunch of URLs that didn't begin with the URL used in the request >> URI. > > As far as I can tell, that's a server bug. Clients aren't expected to > handle PROPFIND responses with URLs that identify resources are then > the one identified by the Request-URI (and its descendants). If a > server wants to redirect clients, it will have to use a 3xx status > code (as defined in RFC2616). > It may be a server bug under some models or readings of RFC2518. The server implementor certainly would have a case for interpreting RFC2518 as allowing their "solution". This past week, Geoff seemed to be arguing for allowing Location with 207 and not only with 3xx. Lisa From w3c-dist-auth-request@frink.w3.org Mon Oct 31 16:53:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhb5-0004IE-Vk for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 16:53: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 QAA13140 for ; Mon, 31 Oct 2005 16:53:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWhaH-0007ZR-Ip for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 21:52:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWhaD-0007Yr-Rr for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 21:52:49 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EWha9-0006Qq-Lz for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 21:52:49 +0000 Received: (qmail invoked by alias); 31 Oct 2005 21:52:44 -0000 Received: from p508FA531.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.165.49] by mail.gmx.net (mp030) with SMTP; 31 Oct 2005 22:52:44 +0100 X-Authenticated: #1915285 Message-ID: <4366920A.40808@gmx.de> Date: Mon, 31 Oct 2005 22:52:10 +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: Jim Whitehead , WebDav , Cullen Jennings References: <43667F68.6070904@gmx.de> <1e1259203fa74a1fa86f011e540118e7@osafoundation.org> In-Reply-To: <1e1259203fa74a1fa86f011e540118e7@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 1EWha9-0006Qq-Lz b771f45923bfd2ddda4da9ccf002419b 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/4366920A.40808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10299 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 21:52:53 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > That was the full paragraph. Here's the entire section of proposed text: Sorry, I should have said "the full section". > IANA Considerations > > WebDAV uses XML-based identifiers with XML namespaces. > The use of XML namespaces means that unique WebDAV property names > and XML elements can be quickly defined by any WebDAV user or > application, without requiring IANA action. > The property names and XML elements in this specification > are all in the "DAV:" namespace. Creation of identifiers > in the "DAV:" namespace is controlled by the IETF. > > The URI registrations for opaquelocktoken and DAV URI schemes made in > RFC 2518 should still be considered active. Let's see what we have in RFC2518: -- 18. IANA Considerations This document defines two namespaces, the namespace of property names, and the namespace of WebDAV-specific XML elements used within property values. URIs are used for both names, for several reasons. Assignment of a URI does not require a request to a central naming authority, and hence allow WebDAV property names and XML elements to be quickly defined by any WebDAV user or application. URIs also provide a unique address space, ensuring that the distributed users of WebDAV will not have collisions among the property names and XML elements they create. This specification defines a distinguished set of property names and XML elements that are understood by all WebDAV applications. The property names and XML elements in this specification are all derived from the base URI DAV: by adding a suffix to this URI, for example, DAV:creationdate for the "creationdate" property. This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in Section 6.4. 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. -- This certainly can be simplified, but we need to be careful here. Going back to the current proposal: > WebDAV uses XML-based identifiers with XML namespaces. Well, it uses identifiers consisting of namespace names and local names (as defined per XML-Infoset). > The use of XML namespaces means that unique WebDAV property names > and XML elements can be quickly defined by any WebDAV user or > application, without requiring IANA action. That's true, but I think the IANA section should be clear about what IANA needs to do with/for this spec, so I'd re-arrange the text to say what IANA needs to do first. > The property names and XML elements in this specification > are all in the "DAV:" namespace. Creation of identifiers > in the "DAV:" namespace is controlled by the IETF. > > The URI registrations for opaquelocktoken and DAV URI schemes made in > RFC 2518 should still be considered active. Sorry? That would mean that these two namespaces are still defined as per RFC2518. Is this really intended???? Here's a proposal for rewriting the section, based on the original text and ideas from the current proposal: -- 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. -- Feedback appreciated, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 31 17: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 1EWhnz-0007kK-03 for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 17: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 RAA14981 for ; Mon, 31 Oct 2005 17:06:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWhnG-00026B-Fh for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 22:06:18 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EWhnC-00025E-9a for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 22:06:14 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EWhn5-0006yW-3d for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 22:06:13 +0000 Received: (qmail invoked by alias); 31 Oct 2005 22:05:56 -0000 Received: from p508FA531.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.165.49] by mail.gmx.net (mp014) with SMTP; 31 Oct 2005 23:05:56 +0100 X-Authenticated: #1915285 Message-ID: <43669523.2010708@gmx.de> Date: Mon, 31 Oct 2005 23:05:23 +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> In-Reply-To: <8d2dc10867f989a1244c5ee4fe5672cd@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 1EWhn5-0006yW-3d 780a5d62b7d1ad33a2c30af5d0f70e9d X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/43669523.2010708@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10300 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 22:06:18 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > On Oct 31, 2005, at 1:16 PM, Julian Reschke wrote: > >> Lisa Dusseault wrote: >> >>> The original question that brought up this issue was how to interpret >>> the URLs inside the body of the Multi-Status if there was a Location >> >> >> Is there any record on the mailing list of this issue? Has anybody >> ever *seen* a 207 with a Location header? That is, why was this >> question asked in the first place? > > Yes. At an Interop event. Is there any record on the mailing list of this issue? >>> consistent with the Location header or the Request-URI >> >> >> What does "consistent" mean here? Note that this is the original >> reason why I raised this issue. > > > What I meant by "consistent" (and maybe somebody can find a better way > to word this or we can just define it) was: In a PROPFIND or PROPPATCH > response, for the URLs in the body to be consistent with the > Request-URI, all URLs would all begin with the exact URL used in the > Request-URI. I believe the same would be true for MOVE and COPY > responses -- the URLs would be consistent with the Request URI, not with > the Destination request header or the Location reply header. I still don't see what problem this solves. The URIs appearing in multistatus responses should be either absolute, or relative to the Request-URI. If, for instance, in a PROPFIND response, a response element comes with a URI that after resolving is not descendant of the Request-URI, then the server made a mistake. We can of course discuss how a client should handle this. Skipping it is one answer, failing the whole request is another. In practice it's unlikely to make a difference because if a server get's one response element wrong, it's likely to get *all of them* wrong. >>> There was an actual interoperability problem that uncovered this. >>> Some server returned a Location header and a bunch of URLs in the >>> body, that used the new location. The client errored because the >>> client never expected to query a Collection for its children and find >>> a bunch of URLs that didn't begin with the URL used in the request URI. >> >> >> As far as I can tell, that's a server bug. Clients aren't expected to >> handle PROPFIND responses with URLs that identify resources are then >> the one identified by the Request-URI (and its descendants). If a >> server wants to redirect clients, it will have to use a 3xx status >> code (as defined in RFC2616). >> > It may be a server bug under some models or readings of RFC2518. The > server implementor certainly would have a case for interpreting RFC2518 > as allowing their "solution". This past week, Geoff seemed to be > arguing for allowing Location with 207 and not only with 3xx. HTTP defines a range of response codes (3xx) for redirects, and defines how the Location header can be used to specify new URIs for subsequent requests. I think this feature is completely well-defined, and I'm not aware of any problems with that. If a server implementor chooses to use non-3xx response code for a redirect, than that's simply outside what HTTP currently defines; and it escapes me why somebody would want to invent something new for a feature that already exists. And finally, Geoff wasn't recommending to use 207 with Location, he just made a guess about what a client could conceivably do once it get's a response like that. If this was an interop problem at one point of time, I'd like to see the details published, or -- if this isn't possible -- hear from client implementors who suffered from that problem. Maybe the servers have been fixed since then, and the whole issue has gone away. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 31 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 1EWhsF-0000VH-9M for webdav-archive@megatron.ietf.org; Mon, 31 Oct 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 RAA15252 for ; Mon, 31 Oct 2005 17:11:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWhrI-0002o7-4K for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 22:10:28 +0000 Received: from aji.w3.mag.keio.ac.jp ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EWhrH-0002nW-Bf for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 22:10:27 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EWhrD-0007d2-N7 for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 22:10:26 +0000 Received: (qmail invoked by alias); 31 Oct 2005 22:10:21 -0000 Received: from p508FA531.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.165.49] by mail.gmx.net (mp005) with SMTP; 31 Oct 2005 23:10:21 +0100 X-Authenticated: #1915285 Message-ID: <4366962B.3030504@gmx.de> Date: Mon, 31 Oct 2005 23:09:47 +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: Cullen Jennings , Jim Whitehead , 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 (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 1EWhrD-0007d2-N7 852b4fb4e056daf0581fac2231ecfd18 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/4366962B.3030504@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10301 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 22:10:28 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > To clarify, would the Authorization header hacks I mentioned last week > count as one of the known approaches? Are you talking about the stuff in ? If this works and is compliant with the base specs (2616/2617), why not? Otherwise, why bother? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Oct 31 18:33:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWj9R-0001OS-0o for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 18:33: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 SAA19986 for ; Mon, 31 Oct 2005 18:32:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWj82-0001lO-IX for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Oct 2005 23:31:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWj7y-0001gg-Dc for w3c-dist-auth@listhub.w3.org; Mon, 31 Oct 2005 23:31:46 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lisa.w3.org with esmtp (Exim 4.50) id 1EWj7x-0002tZ-2i for w3c-dist-auth@w3.org; Mon, 31 Oct 2005 23:31:46 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 31 Oct 2005 15:31:44 -0800 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 j9VNVfUw002327; Mon, 31 Oct 2005 15:31:41 -0800 (PST) Received: from 10.21.123.51 ([10.21.123.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Oct 2005 23:32:14 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 31 Oct 2005 15:31:39 -0800 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: Geoffrey M Clemm , WebDav Message-ID: Thread-Topic: [Bug 12] Destination header "consistent" Thread-Index: AcXecz3WfE6ppkpmEdqDDgARJEEJ/A== In-Reply-To: <43669523.2010708@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.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EWj7x-0002tZ-2i 23afe2a6a5a00234210582e8c2ae0984 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/BF8BE95B.5DA3C%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10302 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Oct 2005 23:31:50 +0000 Content-Transfer-Encoding: 7bit On 10/31/05 2:05 PM, "Julian Reschke" wrote: >>> Is there any record on the mailing list of this issue? Has anybody >>> ever *seen* a 207 with a Location header? That is, why was this >>> question asked in the first place? >> >> Yes. At an Interop event. > > Is there any record on the mailing list of this issue? There is now :-) Sorry, the recursive self referential possibility was just too good to pass up. This email was definitely not sent with my Chair hat on. From w3c-dist-auth-request@frink.w3.org Mon Oct 31 19:21:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWjts-0002s8-FR for webdav-archive@megatron.ietf.org; Mon, 31 Oct 2005 19:21: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 TAA23091 for ; Mon, 31 Oct 2005 19:20:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EWjt4-0002MT-Gl for w3c-dist-auth-dist@listhub.w3.org; Tue, 01 Nov 2005 00:20:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EWjt1-0002Ls-2l for w3c-dist-auth@listhub.w3.org; Tue, 01 Nov 2005 00:20:23 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EWjsw-0000Mr-BH for w3c-dist-auth@w3.org; Tue, 01 Nov 2005 00:20:23 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8243514229E; Mon, 31 Oct 2005 16:20: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 04874-03; Mon, 31 Oct 2005 16:20:17 -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 B934714229A; Mon, 31 Oct 2005 16:20:04 -0800 (PST) In-Reply-To: <43669523.2010708@gmx.de> References: <436689A9.4060304@gmx.de> <8d2dc10867f989a1244c5ee4fe5672cd@osafoundation.org> <43669523.2010708@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-4-25852713 Message-Id: Cc: Geoffrey M Clemm , WebDav , Cullen Jennings From: Lisa Dusseault Date: Mon, 31 Oct 2005 16:19: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 (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 1EWjsw-0000Mr-BH e7662fcf86fa0a2ae13267f26d263db0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 12] Destination header "consistent" X-Archived-At: http://www.w3.org/mid/d361d4217b27fa582ea7d84875fc626c@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10303 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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 00:20:26 +0000 --Apple-Mail-4-25852713 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 31, 2005, at 2:05 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> On Oct 31, 2005, at 1:16 PM, Julian Reschke wrote: >>> Lisa Dusseault wrote: >>> >>>> The original question that brought up this issue was how to >>>> interpret the URLs inside the body of the Multi-Status if there was >>>> a Location >>> >>> >>> Is there any record on the mailing list of this issue? Has anybody >>> ever *seen* a 207 with a Location header? That is, why was this >>> question asked in the first place? >> Yes. At an Interop event. > > Is there any record on the mailing list of this issue? 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 --Apple-Mail-4-25852713 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Oct 31, 2005, at 2:05 PM, Julian Reschke wrote: Lisa Dusseault wrote: On Oct 31, 2005, at 1:16 PM, Julian Reschke wrote: Lisa Dusseault wrote: The original question that brought up this issue was how to interpret the URLs inside the body of the Multi-Status if there was a Location Is there any record on the mailing list of this issue? Has anybody ever *seen* a 207 with a Location header? That is, why was this question asked in the first place? Yes. At an Interop event. Is there any record on the mailing list of this issue? 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 --Apple-Mail-4-25852713--