From flip_jean@yahoo.com Tue May 6 02:53:32 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED523A6822 for ; Tue, 6 May 2008 02:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.062 X-Spam-Level: X-Spam-Status: No, score=-57.062 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5nW55mn+-UH for ; Tue, 6 May 2008 02:53:30 -0700 (PDT) Received: from [125.142.225.55] (unknown [125.142.225.55]) by core3.amsl.com (Postfix) with ESMTP id E16EA3A6FB5 for ; Tue, 6 May 2008 02:53:29 -0700 (PDT) Received: from [125.142.225.55] by a.mx.mail.yahoo.com; Tue, 6 May 2008 18:53:27 +0900 Message-ID: <01c8afaa$77d7ed80$37e18e7d@flip_jean> From: "Google AdWords" To: Subject: Your ads are not running. Date: Tue, 6 May 2008 18:53:27 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8AFAA.77D7ED80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2173.0 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C8AFAA.77D7ED80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- Dear Google AdWords Customer, We were unable to process your payment. Your ads will be suspended soon unless we can process your payment. To prevent your ads from being suspended, please update your payment info= rmation. Please sign in to your account at http://adwords.google.com/select/login, and update your payment information. -------------------------------------------------------------------------= ---------------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. -------------------------------------------------------------------------= ---------------- Thank you for chosing Google Adwords for your business ------=_NextPart_000_0007_01C8AFAA.77D7ED80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= ---

Dear Google AdWords Customer,

We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info= rmation.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.

-------------------------------------------------------------------------= ------
This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.
-------------------------------------------------------------------------= ------
Thank you for chosing Google Adwords ------=_NextPart_000_0007_01C8AFAA.77D7ED80-- From w3c-dist-auth-request@listhub.w3.org Fri May 9 17:43:02 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346913A683D for ; Fri, 9 May 2008 17:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLKvsn1gRHFb for ; Fri, 9 May 2008 17:43:01 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 7A6F93A67A8 for ; Fri, 9 May 2008 17:42:58 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JuapI-0004qe-O4 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 May 2008 22:12:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JuapH-0004q0-Lu for w3c-dist-auth@listhub.w3.org; Fri, 09 May 2008 22:12:27 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JuapC-0006NZ-KF for w3c-dist-auth@w3.org; Fri, 09 May 2008 22:12:27 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 4B3ED2C7532A for ; Fri, 9 May 2008 15:11:47 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 32A2E28043 for ; Fri, 9 May 2008 15:11:47 -0700 (PDT) X-AuditID: 11807130-aa391bb000000ead-0b-4824cc2305c8 Received: from pucca.apple.com (pucca.apple.com [17.224.20.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 182D42803F for ; Fri, 9 May 2008 15:11:47 -0700 (PDT) Message-Id: <07409160-A4C6-406E-9889-C477888296FE@wsanchez.net> From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= To: WebDAV Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 9 May 2008 15:11:46 -0700 X-Mailer: Apple Mail (2.924) X-Brightmail-Tracker: AAAAAA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: lisa.w3.org 1JuapC-0006NZ-KF 80a101f4129c2d1dcdbd127a7f6be50a X-Original-To: w3c-dist-auth@w3.org Subject: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12833 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 09 May 2008 22:12:28 +0000 Is is a requirement that DAV:principal-URL be an http(s) scheme URL? I read the RFC that way (section 1 seems to imply it), but I can't really pin it down. -wsv From w3c-dist-auth-request@listhub.w3.org Sat May 10 13:27:50 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4CF3A69FB for ; Sat, 10 May 2008 13:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m12IXTLrNK9O for ; Sat, 10 May 2008 13:27:50 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 3E7803A69E4 for ; Sat, 10 May 2008 13:27:50 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JuvdU-0004Y4-UA for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 May 2008 20:25:40 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JuvdT-0004XL-Nt for w3c-dist-auth@listhub.w3.org; Sat, 10 May 2008 20:25:39 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1JuvdK-0005lU-IO for w3c-dist-auth@w3.org; Sat, 10 May 2008 20:25:38 +0000 Received: (qmail invoked by alias); 10 May 2008 20:24:54 -0000 Received: from mnsr-d9b8cebd.pool.mediaWays.net (EHLO [217.184.206.189]) [217.184.206.189] by mail.gmx.net (mp032) with SMTP; 10 May 2008 22:24:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+BipR57Y2B0m7grTzK23iHSwRZG0Qtli8txuYDJN qny29E1mk+ji68 Message-ID: <4825BB51.8070505@gmx.de> Date: Sat, 10 May 2008 17:12:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: WebDAV , acl@webdav.org References: <07409160-A4C6-406E-9889-C477888296FE@wsanchez.net> In-Reply-To: <07409160-A4C6-406E-9889-C477888296FE@wsanchez.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1JuvdK-0005lU-IO c19749bcfda5a70e823f48543152c326 X-Original-To: w3c-dist-auth@w3.org Subject: Re: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12834 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 10 May 2008 20:25:40 +0000 Wilfredo Sánchez Vega wrote: > > Is is a requirement that DAV:principal-URL be an http(s) scheme URL? > I read the RFC that way (section 1 seems to imply it), but I can't > really pin it down. I really don't see how it can be a non-http URL... I also don't recall whether we left this fuzzy intentionally, or if this was an oversight (Geoff, do you recall...?). BR, Julian From w3c-dist-auth-request@listhub.w3.org Sat May 10 14:08:46 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CBE3A67B1 for ; Sat, 10 May 2008 14:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSlPNmwm5f6b for ; Sat, 10 May 2008 14:08:45 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 4B1353A67A7 for ; Sat, 10 May 2008 14:08:45 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JuwI1-0007ak-N9 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 May 2008 21:07:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JuwI0-0007Zm-NA; Sat, 10 May 2008 21:07:33 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JuwHu-00029f-4I; Sat, 10 May 2008 21:07:32 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m4AL6n3i025506; Sat, 10 May 2008 17:06:49 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4AL6ne8124862; Sat, 10 May 2008 17:06:49 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4AL6mOe032261; Sat, 10 May 2008 17:06:49 -0400 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m4AL6mEE032256; Sat, 10 May 2008 17:06:48 -0400 In-Reply-To: <4825BB51.8070505@gmx.de> To: Julian Reschke Cc: acl@webdav.org, WebDAV , w3c-dist-auth-request@w3.org, =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Geoffrey M Clemm Message-ID: Date: Sat, 10 May 2008 17:06:49 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 8.0|August 02, 2007) at 05/10/2008 17:06:48, Serialize complete at 05/10/2008 17:06:48 Content-Type: multipart/alternative; boundary="=_alternative 0073FA6A85257445_=" Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JuwHu-00029f-4I 9680e83ec27048970a6029dde90ecfc7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12835 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 10 May 2008 21:07:33 +0000 This is a multipart message in MIME format. --=_alternative 0073FA6A85257445_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable It is certainly desireable for it to be an http url, but I don't see that=20 it has to be one ... you could imagine using a mailto: url ... Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 05/10/2008 11:12:17 AM: >=20 > Wilfredo S=E1nchez Vega wrote: > >=20 > > Is is a requirement that DAV:principal-URL be an http(s) scheme URL? = =20 > > I read the RFC that way (section 1 seems to imply it), but I can't=20 > > really pin it down. >=20 > I really don't see how it can be a non-http URL... I also don't recall=20 > whether we left this fuzzy intentionally, or if this was an oversight=20 > (Geoff, do you recall...?). >=20 > BR, Julian >=20 >=20 >=20 >=20 >=20 --=_alternative 0073FA6A85257445_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
It is certainly desireable for it to be an http url, but I don't see that it has to be one ... you could imagine using a mailto: url ...

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 05/10/2008 11:= 12:17 AM:

>
> Wilfredo S=E1nchez Vega wrote:
> >
> >   Is is a requirement that DAV:principal-URL be an http(s) scheme URL?  
> > I read the RFC that way (section 1 seems to imply it), but I can't
> > really pin it down.
>
> I really don't see how it can be a non-http URL... I also don't recall
> whether we left this fuzzy intentionally, or if this was an oversight
> (Geoff, do you recall...?).
>
> BR, Julian
>
>
>
>
>
--=_alternative 0073FA6A85257445_=-- From w3c-dist-auth-request@listhub.w3.org Sat May 10 14:40:16 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6E33A688E for ; Sat, 10 May 2008 14:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT9F6jR+Dp8X for ; Sat, 10 May 2008 14:40:15 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id EF9123A67D8 for ; Sat, 10 May 2008 14:40:11 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Juwlx-0007et-2Y for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 May 2008 21:38:29 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Juwlv-0007eF-Vf for w3c-dist-auth@listhub.w3.org; Sat, 10 May 2008 21:38:28 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Juwlp-0001w7-0j for w3c-dist-auth@w3.org; Sat, 10 May 2008 21:38:27 +0000 Received: (qmail invoked by alias); 10 May 2008 21:37:46 -0000 Received: from f054173105.adsl.alicedsl.de (EHLO nbkbreu) [78.54.173.105] by mail.gmx.net (mp055) with SMTP; 10 May 2008 23:37:46 +0200 X-Authenticated: #32267959 X-Provags-ID: V01U2FsdGVkX1/cXdhkEVHcNaRs8cJ1IUMiQxitOr3kGYhuAgCRyi M2lLeR9P4xdjJb From: "Konstantin Breu" To: "'Geoffrey M Clemm'" , "'Julian Reschke'" Cc: , "'WebDAV'" , , =?iso-8859-1?Q?'Wilfredo_S=E1nchez_Vega'?= References: <4825BB51.8070505@gmx.de> In-Reply-To: Date: Sat, 10 May 2008 23:37:44 +0200 Message-ID: <003c01c8b2e6$1609eab0$421dc010$@Breu@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aciy4gSfhsQlNvLiSRm3Sibi+9QGjwAAyMYA Content-Language: de X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-1.2 X-W3C-Scan-Sig: aji.w3.org 1Juwlp-0001w7-0j 59eaa6f16eef7f99b62f49f7e824e758 X-Original-To: w3c-dist-auth@w3.org Subject: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12836 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 10 May 2008 21:38:29 +0000 But RFC 3744 says "However, servers implementing this specification MUST expose principal resources at an http(s) URL" Doesn't this mean, that the D:href for the principal cannot use another scheme? I thought that the D:href has to point to the principal resource = - which the server MUST expose... Cheers, Konstantin -----Urspr=FCngliche Nachricht----- Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = Im Auftrag von Geoffrey M Clemm Gesendet: Samstag, 10. Mai 2008 23:07 An: Julian Reschke Cc: acl@webdav.org; WebDAV; w3c-dist-auth-request@w3.org; Wilfredo = S=E1nchez Vega Betreff: Re: DAV:principal-URL It is certainly desireable for it to be an http url, but I don't see = that it has to be one ... you could imagine using a mailto: url ...=20 Cheers,=20 Geoff=20 w3c-dist-auth-request@w3.org wrote on 05/10/2008 11:12:17 AM: >=20 > Wilfredo S=E1nchez Vega wrote: > >=20 > > Is is a requirement that DAV:principal-URL be an http(s) scheme = URL? =20 > > I read the RFC that way (section 1 seems to imply it), but I can't=20 > > really pin it down. >=20 > I really don't see how it can be a non-http URL... I also don't recall = > whether we left this fuzzy intentionally, or if this was an oversight=20 > (Geoff, do you recall...?). >=20 > BR, Julian >=20 >=20 >=20 >=20 >=20 From w3c-dist-auth-request@listhub.w3.org Sat May 10 15:02:28 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986BD3A69D7 for ; Sat, 10 May 2008 15:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G56VmcwwM623 for ; Sat, 10 May 2008 15:02:27 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 0B69E3A6A06 for ; Sat, 10 May 2008 15:02:27 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Jux86-0006LP-LZ for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 May 2008 22:01:22 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jux84-0006KR-Io; Sat, 10 May 2008 22:01:21 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jux7w-00031y-OI; Sat, 10 May 2008 22:01:19 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m4AM0cB1023332; Sat, 10 May 2008 18:00:38 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4AM0cdc121452; Sat, 10 May 2008 18:00:38 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4AM0cnQ005781; Sat, 10 May 2008 18:00:38 -0400 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m4AM0bEg005769; Sat, 10 May 2008 18:00:37 -0400 In-Reply-To: <003c01c8b2e6$1609eab0$421dc010$@Breu@gmx.net> To: "Konstantin Breu" Cc: acl@webdav.org, "'Julian Reschke'" , "'WebDAV'" , w3c-dist-auth-request@w3.org, "=?ISO-8859-1?Q?'Wilfredo_S=E1nchez_Vega'?=" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Geoffrey M Clemm Message-ID: Date: Sat, 10 May 2008 18:00:38 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 8.0|August 02, 2007) at 05/10/2008 18:00:37, Serialize complete at 05/10/2008 18:00:37 Content-Type: multipart/alternative; boundary="=_alternative 0078E7D785257445_=" Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Scan-Sig: aji.w3.org 1Jux7w-00031y-OI be1e1f172c0044b582787d2490fa6451 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12837 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 10 May 2008 22:01:22 +0000 This is a multipart message in MIME format. --=_alternative 0078E7D785257445_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable So here's the problem: The primary purpose of the DAV:principal-URL is to = specify the "identity" of a principal (so you can use it to check for=20 equality). But you might not have an HTTP URI that can be used as the=20 "identity" (you might need to use some URN URI, for example). So you=20 might be forced to use a non-HTTP URL in the DAV:principal-URL property. So the spec says that there must be an HTTP URL for a principal, but it=20 does not require that the HTTP URL be the one that appears in the=20 DAV:principal-URL property. At least that's how I remember it ... I could of course be wrong (it's=20 been a while :-). Cheers, Geoff "Konstantin Breu" wrote on 05/10/2008 05:37:44=20 PM: > But RFC 3744 says >=20 > "However, servers implementing this specification MUST expose principal > resources at an http(s) URL" >=20 > Doesn't this mean, that the D:href for the principal cannot use another > scheme? I thought that the D:href has to point to the principal resource = - > which the server MUST expose... >=20 > Cheers, > Konstantin >=20 > -----Urspr=FCngliche Nachricht----- > Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]=20 Im > Auftrag von Geoffrey M Clemm > Gesendet: Samstag, 10. Mai 2008 23:07 > An: Julian Reschke > Cc: acl@webdav.org; WebDAV; w3c-dist-auth-request@w3.org; Wilfredo=20 S=E1nchez > Vega > Betreff: Re: DAV:principal-URL >=20 >=20 > It is certainly desireable for it to be an http url, but I don't see=20 that it > has to be one ... you could imagine using a mailto: url ...=20 >=20 > Cheers,=20 > Geoff=20 >=20 > w3c-dist-auth-request@w3.org wrote on 05/10/2008 11:12:17 AM: >=20 > >=20 > > Wilfredo S=E1nchez Vega wrote: > > >=20 > > > Is is a requirement that DAV:principal-URL be an http(s) scheme=20 URL?=20 > > > I read the RFC that way (section 1 seems to imply it), but I can't=20 > > > really pin it down. > >=20 > > I really don't see how it can be a non-http URL... I also don't recall = > > whether we left this fuzzy intentionally, or if this was an oversight=20 > > (Geoff, do you recall...?). > >=20 > > BR, Julian > >=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 --=_alternative 0078E7D785257445_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
So here's the problem:  The primary purpose of the DAV:principal-URL is to specify the "identity" of a principal (so you can use it to check for equality).  But you might not have an HTTP URI that can be used as the "identity" (you might need to use some URN URI, for example).  So you might be forced to use a non-HTTP URL in the DAV:principal-URL property.

So the spec says that there must be an HTTP URL for a principal, but it does not require that the HTTP URL be the one that appears in the DAV:principal-URL property.

At least that's how I remember it ... I could of cou= rse be wrong (it's been a while :-).

Cheers,
Geoff

"Konstantin Breu" <Konstantin.Breu@gmx.= net> wrote on 05/10/2008 05:37:44 PM:

> But RFC 3744 says
>
> "However, servers implementing this specification MUST expose principal
> resources at an http(s) URL"
>
> Doesn't this mean, that the D:href for the principal cannot use anothe= r
> scheme? I thought that the D:href has to point to the principal resour= ce -
> which the server MUST expose...
>
> Cheers,
> Konstantin
>
> -----Urspr=FCngliche Nachricht-----
> Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] Im
> Auftrag von Geoffrey M Clemm
> Gesendet: Samstag, 10. Mai 2008 23:07
> An: Julian Reschke
> Cc: acl@webdav.org; WebDAV; w3c-dist-auth-request@w3.org; Wilfredo S=E1nchez
> Vega
> Betreff: Re: DAV:principal-URL
>
>
> It is certainly desireable for it to be an http url, but I don't see that it
> has to be one ... you could imagine using a mailto: url ...
>
> Cheers,
> Geoff
>
> w3c-dist-auth-request@w3.org wrote on 05/10/2008 11:12:17 AM:
>
> >
> > Wilfredo S=E1nchez Vega wrote:
> > >
> > >   Is is a requirement that DAV:principal-URL be an http(s) scheme URL?  
> > > I read the RFC that way (section 1 seems to imply it), but I can't
> > > really pin it down.
> >
> > I really don't see how it can be a non-http URL... I also don't recall
> > whether we left this fuzzy intentionally, or if this was an overs= ight
> > (Geoff, do you recall...?).
> >
> > BR, Julian
> >
> >
> >
> >
> >
>
>
--=_alternative 0078E7D785257445_=-- From w3c-dist-auth-request@listhub.w3.org Sun May 11 11:21:45 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4B93A6958 for ; Sun, 11 May 2008 11:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98JiNZi2oJfd for ; Sun, 11 May 2008 11:21:44 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BF3C03A690F for ; Sun, 11 May 2008 11:21:44 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JvG8x-0004uG-Ko for w3c-dist-auth-dist@listhub.w3.org; Sun, 11 May 2008 18:19:31 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvG8v-0004sa-VX; Sun, 11 May 2008 18:19:30 +0000 Received: from sanpietro.red-bean.com ([66.146.193.61] ident=Debian-exim) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvG8p-0000AV-Cz; Sun, 11 May 2008 18:19:29 +0000 Received: from adsl-76-202-116-36.dsl.pltn13.sbcglobal.net ([76.202.116.36]:33035 helo=[10.0.0.196]) by sanpietro.red-bean.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1JvG8J-0000oP-1J; Sun, 11 May 2008 13:18:51 -0500 Cc: "Konstantin Breu" , acl@webdav.org, "'Julian Reschke'" , "'WebDAV'" , w3c-dist-auth-request@w3.org Message-Id: <934598AD-E044-4FBC-9C7F-64F05D82D46F@wsanchez.net> From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= To: Geoffrey M Clemm In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1-294493174 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 11 May 2008 11:18:47 -0700 References: X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: No virus found by ClamAV at red-bean.com Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1JvG8p-0000AV-Cz f68c69fb7faa5be7928d62010d2e38b2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12838 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 11 May 2008 18:19:31 +0000 --Apple-Mail-1-294493174 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit OK, this sounds right, though it's not the answer I was hoping for. :-) Thanks, -wsv On May 10, 2008, at 3:00 PM, Geoffrey M Clemm wrote: > So here's the problem: The primary purpose of the DAV:principal-URL > is to specify the "identity" of a principal (so you can use it to > check for equality). But you might not have an HTTP URI that can be > used as the "identity" (you might need to use some URN URI, for > example). So you might be forced to use a non-HTTP URL in the > DAV:principal-URL property. > > So the spec says that there must be an HTTP URL for a principal, but > it does not require that the HTTP URL be the one that appears in the > DAV:principal-URL property. > > At least that's how I remember it ... I could of course be wrong > (it's been a while :-). > > Cheers, > Geoff --Apple-Mail-1-294493174 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
  OK, this = sounds right, though it's not the answer I was hoping for. =  :-)

Thanks,
= -wsv


On May 10, 2008, at = 3:00 PM, Geoffrey M Clemm wrote:
So here's the = problem:  The primary purpose of the DAV:principal-URL is to = specify the "identity" of a principal (so you can use it to check for = equality).  But you might not have an HTTP URI that can be used as = the "identity" (you might need to use some URN URI, for example). =  So you might be forced to use a non-HTTP URL in the = DAV:principal-URL property. 

So the spec says that there must be an HTTP URL for a = principal, but it does not require that the HTTP URL be the one that = appears in the DAV:principal-URL property. 

At least that's how I remember it ... I could of course be = wrong (it's been a while :-). 

Cheers, 
Geoff 

= --Apple-Mail-1-294493174-- From w3c-dist-auth-request@listhub.w3.org Mon May 12 04:28:00 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7893A67F9 for ; Mon, 12 May 2008 04:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebRFiyDb0Ch8 for ; Mon, 12 May 2008 04:27:59 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 67F953A67AC for ; Mon, 12 May 2008 04:27:56 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JvW9S-0006pE-LI for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 May 2008 11:25:06 +0000 Received: from farnsworth.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvW9R-0006oa-Qw for w3c-dist-auth@listhub.w3.org; Mon, 12 May 2008 11:25:05 +0000 Received: from nobody by farnsworth.w3.org with local (Exim 4.63) (envelope-from ) id 1JvW9R-00078E-Om for w3c-dist-auth@listhub.w3.org; Mon, 12 May 2008 11:25:05 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvW3W-0005Ab-6O for w3c-dist-auth@listhub.w3.org; Mon, 12 May 2008 11:18:58 +0000 Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvW3O-0000VN-4v for w3c-dist-auth@w3.org; Mon, 12 May 2008 11:18:57 +0000 Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4CBIETu021755 for ; Mon, 12 May 2008 11:18:14 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K0R00L015U2AW00@fe-emea-10.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for w3c-dist-auth@w3.org; Mon, 12 May 2008 12:18:14 +0100 (BST) Received: from [129.158.250.220] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K0R0045662CQ870@fe-emea-10.sun.com> for w3c-dist-auth@w3.org; Mon, 12 May 2008 12:18:13 +0100 (BST) Date: Mon, 12 May 2008 16:48:44 +0530 From: Arnaud Quillaud To: w3c-dist-auth@w3.org Message-id: <48282794.80604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1 X-W3C-Hub-Spam-Status: No, score=-3.6 X-W3C-Scan-Sig: aji.w3.org 1JvW3O-0000VN-4v 8e9b7188d12b361b88184826d7552dfd X-caa-id: 8e1ad4ed03067bc1f58f X-Original-To: w3c-dist-auth@w3.org Subject: acl settings and extended MKCOL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12839 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 May 2008 11:25:06 +0000 Hello, The WebDAV ACL spec does not offer a way to create a resource and set its acl in a single operation. Nor does it let you discover the initial acl set on a new resource (http://tools.ietf.org/html/rfc3744#section-12.3). With the new extended MKCOL (http://tools.ietf.org/html/draft-daboo-webdav-mkcol), it is now possible to set properties and create a collection in one single operation. By setting the DAV:acl property among those properties, one can achieve an atomic (MKCOL + ACL). I think no WebDAV specification prevents a server from allowing this (especially given that the WebDAV ACL spec precedes extended MKCOL draft). But isn't it something that would be worth mentioning in the extended MKCOL spec, either to clarify the expected behavior,... or to discourage its use if it is found to be problematic. Arnaud Q From w3c-dist-auth-request@listhub.w3.org Mon May 12 05:01:30 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAAD3A68FB for ; Mon, 12 May 2008 05:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrOMdwzmvIxI for ; Mon, 12 May 2008 05:01:29 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A18843A6885 for ; Mon, 12 May 2008 05:01:29 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JvWet-00070U-W2 for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 May 2008 11:57:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvWet-0006zq-Ag for w3c-dist-auth@listhub.w3.org; Mon, 12 May 2008 11:57:35 +0000 Received: from fg-out-1718.google.com ([72.14.220.153]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvWem-0001Ze-L1 for w3c-dist-auth@w3.org; Mon, 12 May 2008 11:57:34 +0000 Received: by fg-out-1718.google.com with SMTP id 16so1856448fgg.44 for ; Mon, 12 May 2008 04:57:02 -0700 (PDT) Received: by 10.86.62.3 with SMTP id k3mr14096709fga.32.1210593421962; Mon, 12 May 2008 04:57:01 -0700 (PDT) Received: from ?172.16.15.128? ( [212.209.62.241]) by mx.google.com with ESMTPS id l19sm6617045fgb.9.2008.05.12.04.57.00 (version=SSLv3 cipher=RC4-MD5); Mon, 12 May 2008 04:57:01 -0700 (PDT) From: Henrik Holst To: Arnaud Quillaud Cc: w3c-dist-auth@w3.org In-Reply-To: <48282794.80604@sun.com> References: <48282794.80604@sun.com> Content-Type: text/plain; charset=utf-8 Date: Mon, 12 May 2008 13:56:59 +0200 Message-Id: <1210593419.16452.0.camel@henrik-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 8bit Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JvWem-0001Ze-L1 82e1782a1b3624e603b539b3d9e708d9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: acl settings and extended MKCOL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12840 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 May 2008 11:57:35 +0000 mÃ¥n 2008-05-12 klockan 16:48 +0530 skrev Arnaud Quillaud: > Hello, > > The WebDAV ACL spec does not offer a way to create a resource and set > its acl in a single operation. Nor does it let you discover the initial > acl set on a new resource (http://tools.ietf.org/html/rfc3744#section-12.3). > > With the new extended MKCOL > (http://tools.ietf.org/html/draft-daboo-webdav-mkcol), it is now > possible to set properties and create a collection in one single operation. > By setting the DAV:acl property among those properties, one can achieve > an atomic (MKCOL + ACL). > I think no WebDAV specification prevents a server from allowing this > (especially given that the WebDAV ACL spec precedes extended MKCOL draft). > But isn't it something that would be worth mentioning in the extended > MKCOL spec, either to clarify the expected behavior,... or to discourage > its use if it is found to be problematic. > > Arnaud Q > > DAV:acl is a protected property so it shouldn't be possible to set it using the extended MKCOL as far as I can see. /Henrik Holst From w3c-dist-auth-request@listhub.w3.org Mon May 12 05:20:00 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232C03A6885 for ; Mon, 12 May 2008 05:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78td9BuCLUwB for ; Mon, 12 May 2008 05:19:59 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id F33E73A67F9 for ; Mon, 12 May 2008 05:19:58 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JvWzE-0006ab-SZ for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 May 2008 12:18:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvWzE-0006Z5-8p for w3c-dist-auth@listhub.w3.org; Mon, 12 May 2008 12:18:36 +0000 Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JvWz4-0004Cd-T8 for w3c-dist-auth@w3.org; Mon, 12 May 2008 12:18:33 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4CCHnxG028057 for ; Mon, 12 May 2008 12:17:50 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K0R001018RK8000@fe-emea-09.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for w3c-dist-auth@w3.org; Mon, 12 May 2008 13:17:49 +0100 (BST) Received: from [129.158.250.220] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K0R004MC8SPZW60@fe-emea-09.sun.com>; Mon, 12 May 2008 13:17:16 +0100 (BST) Date: Mon, 12 May 2008 17:47:45 +0530 From: Arnaud Quillaud In-reply-to: <1210593419.16452.0.camel@henrik-desktop> To: Henrik Holst Cc: w3c-dist-auth@w3.org Message-id: <48283569.10302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 References: <48282794.80604@sun.com> <1210593419.16452.0.camel@henrik-desktop> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gmp-eb-inf-1.sun.com id m4CCHnxG028057 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-3.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1 X-W3C-Scan-Sig: lisa.w3.org 1JvWz4-0004Cd-T8 549f436a8910bcbffc4a9f8248146054 X-Original-To: w3c-dist-auth@w3.org Subject: Re: acl settings and extended MKCOL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12841 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 May 2008 12:18:36 +0000 Henrik Holst wrote: > m=C3=A5n 2008-05-12 klockan 16:48 +0530 skrev Arnaud Quillaud: > =20 >> Hello, >> >> The WebDAV ACL spec does not offer a way to create a resource and set=20 >> its acl in a single operation. Nor does it let you discover the initia= l=20 >> acl set on a new resource (http://tools.ietf.org/html/rfc3744#section-= 12.3). >> >> With the new extended MKCOL=20 >> (http://tools.ietf.org/html/draft-daboo-webdav-mkcol), it is now=20 >> possible to set properties and create a collection in one single opera= tion. >> By setting the DAV:acl property among those properties, one can achiev= e=20 >> an atomic (MKCOL + ACL). >> I think no WebDAV specification prevents a server from allowing this=20 >> (especially given that the WebDAV ACL spec precedes extended MKCOL dra= ft). >> But isn't it something that would be worth mentioning in the extended=20 >> MKCOL spec, either to clarify the expected behavior,... or to discoura= ge=20 >> its use if it is found to be problematic. >> >> Arnaud Q >> >> >> =20 > DAV:acl is a protected property so it shouldn't be possible to set it u= sing the extended MKCOL as far as I can see. > =20 Per the WebDAV Spec: << A protected property is one that cannot be changed with a PROPPATCH request. >> It does not mean that it can not be created or changed by another command. Actually, the CALDAV:supported-calendar-component-set property of the=20 CalDAV Spec exposes that behavior: it is protected but can be initially=20 set via the MKCALENDAR method=20 (http://tools.ietf.org/html/rfc4791#section-5.2.3) Arnaud Q From w3c-dist-auth-request@listhub.w3.org Mon May 12 11:54:45 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474D43A67C1 for ; Mon, 12 May 2008 11:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_SHORT=1.078, RCVD_IN_DNSWL_MED=-4, SARE_RECV_SPAM_DOMN02=1.666, SARE_SUB_OBFU_Q0=0.303] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXOXQGMaZTIb for ; Mon, 12 May 2008 11:54:42 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 4DF603A67E1 for ; Mon, 12 May 2008 11:54:42 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Jvd7z-0003bR-2e for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 May 2008 18:52:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jvd7i-0003UO-JN; Mon, 12 May 2008 18:51:46 +0000 Received: from mail1.chtech.com.br ([201.63.24.130]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jvd7S-0002ZJ-4H; Mon, 12 May 2008 18:51:38 +0000 Received: from 123412 (201-42-130-242.dsl.telesp.net.br [201.42.130.242]) by mail1.chtech.com.br (Postfix) with SMTP id D9B39A5B75; Mon, 12 May 2008 15:50:07 -0300 (BRT) From: "Dra. Roberta Rosental" To: jjc@jclark.com Content-Type: text/plain; Reply-To: arvoredoamorpc@hotmail.com Message-ID: 43131 Date: Mon, 12 May 2008 15:59:00 -0300 X-Priority: 1 Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: Yes, score=6.5 X-W3C-Hub-Spam-Report: BAYES_99=3.5, INVALID_MSGID=1.9, MSGID_SHORT=1.078 X-W3C-Scan-Sig: maggie.w3.org 1Jvd7S-0002ZJ-4H 23e1b6f65cc42b38f2d1fe24d29f594f X-Original-To: w3c-dist-auth@w3.org Subject: Isto pode salvar sua vida.... nao deixe de ler.....hdrwqw Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12842 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 May 2008 18:52:03 +0000 Revolução total na Odontologia e na Saúde Pública: Você sabia que as doenças mais comuns, entram pela boca, através de bactérias, vírus, fungos, leveduras, parasitas e que até hoje não existia no mundo, forma eficaz e acessível de proteção? O uso contínuo de Trihydral creme dental:- favorece o combate dos germens criando um escudo protetor de tecidos sãos , que dificulta a entrada da maiorias das enfermidades desde as mais comuns até as mais graves que acometem as pessoas no dia a dia. O uso contínuo de Trihydral creme dental, um excelente agente profilático, ajuda a proteger você contra a entrada pela boca de dezenas de enfermidades. Lembre-se que as contaminações acontecem no dia a dia quando você mantém algum contato com possíveis transmissores de doenças infecto-contagiosas . Veja no site: no menu Eficaz contra...... as dezenas de agentes patológicos que são exterminados pelo principio ativo principal a Cloramina-T, (Desde Virus de Gripes, Hepatice C, AIDS, Tuberculose dentre dezenas) um potente e seguro anti-séptico, de elevado e longo efeito residual ( de 12h a 24 horas) que associado a outros compostos confere a esse produto uma extraordinária ação, sem interferir na flora benéfica ao seu organismo. O Trihydral é de uso diário e visa auxiliar na escovação dentária e na tarefa de higiene, profilaxia e terapêutica das diversas patologias oro - bucais, pois você e mais de 98% das pessoas têm ou vai ter: Hipersensibilidade, Placas bacterianas, Gengitives, Periondontites, Sangramentos e inflamações, Infecções, Estomatites e aftas, Cáries, Halitoses rebeldes, dentre outras Produto de interesse Público - Produto recomendado pela Associação Brasileira de Odontologia, pela USP (Universidade SP) e pela OSCIP Organização da Sociedade Civil de Interesse público Ong Fundação Melhore Se você tem interesse no uso ou na comercialização deste produto em sua cidade Contate-nos : Contato melhore.org@gmail.com fone 013 9707 3205 - PAULO Vendas exclusivamente via Internet http://www.trilegal.valever.com/ From w3c-dist-auth-request@listhub.w3.org Tue May 13 18:01:08 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5E23A6961 for ; Tue, 13 May 2008 18:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jrNKtV-jvPp for ; Tue, 13 May 2008 18:01:05 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BE5713A68BF for ; Tue, 13 May 2008 18:01:04 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Jw5J7-0001yD-Ok for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 May 2008 00:57:25 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jw5J6-0001xW-K0 for w3c-dist-auth@listhub.w3.org; Wed, 14 May 2008 00:57:24 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jw5Iz-0002rx-Iw for w3c-dist-auth@w3.org; Wed, 14 May 2008 00:57:23 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 17A4D2B8E6E1 for ; Tue, 13 May 2008 17:56:43 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id F3C742807F for ; Tue, 13 May 2008 17:56:42 -0700 (PDT) X-AuditID: 1180711d-ae39cbb000000ed7-59-482a38ca2cfc Received: from pucca.apple.com (pucca.apple.com [17.224.20.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id DFBC928050 for ; Tue, 13 May 2008 17:56:42 -0700 (PDT) Message-Id: From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= To: WebDAV Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 13 May 2008 17:56:42 -0700 References: <20080513233447.A336B3A6946@core3.amsl.com> X-Mailer: Apple Mail (2.924) X-Brightmail-Tracker: AAAAAA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Scan-Sig: aji.w3.org 1Jw5Iz-0002rx-Iw 1f293ce2693d95a6defd8f80eec75418 X-Original-To: w3c-dist-auth@w3.org Subject: Fwd: New Version Notification for draft-sanchez-webdav-current-principal-00 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12843 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 May 2008 00:57:25 +0000 Cyrus and I have submitted a draft for a property that lets a client determine which principal the server thinks the client is using in a request. -wsv Begin forwarded message: > From: IETF I-D Submission Tool > Date: May 13, 2008 4:34:47 PM PDT > To: wsanchez@wsanchez.net > Cc: cyrus@daboo.name > Subject: New Version Notification for draft-sanchez-webdav-current- > principal-00 > > > A new version of I-D, draft-sanchez-webdav-current-principal-00.txt > has been successfuly submitted by Wilfredo Sanchez and posted to the > IETF repository. > > Filename: draft-sanchez-webdav-current-principal > Revision: 00 > Title: WebDAV Current Principal Extension > Creation_date: 2008-05-13 > WG ID: Independent Submission > Number_of_pages: 6 > > Abstract: > This specification defines a new WebDAV property that allows clients > to quickly determine the principal corresponding to the current > authenticated user. > > > > The IETF Secretariat. From w3c-dist-auth-request@listhub.w3.org Wed May 14 07:13:51 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C42E3A6927 for ; Wed, 14 May 2008 07:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.385 X-Spam-Level: X-Spam-Status: No, score=-5.385 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd8Pk5yuZoOb for ; Wed, 14 May 2008 07:13:50 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 98DFC3A68F4 for ; Wed, 14 May 2008 07:13:50 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JwHfp-0005FX-9J for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 May 2008 14:09:41 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JwHfo-0005Eo-60 for w3c-dist-auth@listhub.w3.org; Wed, 14 May 2008 14:09:40 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1JwHfb-0001vV-LU for w3c-dist-auth@w3.org; Wed, 14 May 2008 14:09:39 +0000 Received: (qmail invoked by alias); 14 May 2008 14:08:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.107]) [217.91.35.233] by mail.gmx.net (mp014) with SMTP; 14 May 2008 16:08:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18S7gIe48MSmkM865+q5LYeliL2dTRzzl2ZLsCb4C o9CXDUmg253I3A Message-ID: <482AF270.9050107@gmx.de> Date: Wed, 14 May 2008 16:08:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: WebDAV References: <20080513233447.A336B3A6946@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1JwHfb-0001vV-LU 7213c51b91e94ada69138ff86fa159a6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fwd: New Version Notification for draft-sanchez-webdav-current-principal-00 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12844 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 May 2008 14:09:41 +0000 Wilfredo Sánchez Vega wrote: > > Cyrus and I have submitted a draft for a property that lets a client > determine which principal the server thinks the client is using in a > request. > ... Looks good so far. Nit: "Definition: DAV:href value: a URL to a principal resource" -- Not sure why you use the DAV: prefix for the child elements here, this seems to be inconsistent. I'd also recommend making the DTD fragments valid, for example: BR, Julian From w3c-dist-auth-request@listhub.w3.org Wed May 14 12:25:59 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBEC3A6907 for ; Wed, 14 May 2008 12:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSmmVSPn2ZpS for ; Wed, 14 May 2008 12:25:58 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 7872F3A6781 for ; Wed, 14 May 2008 12:25:58 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JwMYO-0000wC-EL for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 May 2008 19:22:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JwMYN-0000vV-Ec for w3c-dist-auth@listhub.w3.org; Wed, 14 May 2008 19:22:19 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1JwMYG-00024h-Od for w3c-dist-auth@w3.org; Wed, 14 May 2008 19:22:18 +0000 Received: (qmail invoked by alias); 14 May 2008 19:21:38 -0000 Received: from mnsr-d9b8cea2.pool.mediaWays.net (EHLO [217.184.206.162]) [217.184.206.162] by mail.gmx.net (mp007) with SMTP; 14 May 2008 21:21:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18xO5EKCeAxmxanBycQUMjUFsSZwkXTc6aRfFc3bo z6HplfmoFI9nH2 Message-ID: <482B3A71.7000703@gmx.de> Date: Wed, 14 May 2008 21:16:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Geoffrey M Clemm CC: Konstantin Breu , acl@webdav.org, 'WebDAV' , w3c-dist-auth-request@w3.org, =?ISO-8859-1?Q?=27Wilfredo_S=E1nchez_V?= =?ISO-8859-1?Q?ega=27?= 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 X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1JwMYG-00024h-Od 6629454f2146cdd7e8222f21e72cb79e X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12845 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 May 2008 19:22:20 +0000 Geoffrey M Clemm wrote: > > So here's the problem: The primary purpose of the DAV:principal-URL is > to specify the "identity" of a principal (so you can use it to check for > equality). But you might not have an HTTP URI that can be used as the > "identity" (you might need to use some URN URI, for example). So you > might be forced to use a non-HTTP URL in the DAV:principal-URL property. Not totally convinced. If you can make a URN work, you can probably make an HTTP URI work as well. Maybe not a pretty one, though. But anyway... > So the spec says that there must be an HTTP URL for a principal, but it > does not require that the HTTP URL be the one that appears in the > DAV:principal-URL property. > > At least that's how I remember it ... I could of course be wrong (it's > been a while :-). OK, let's start with the assumption that you are right, usually a safe position :-). The spec say that the principal-URL must be used in ACL requests. Does this also mean it will be the one that will be used in the Access Control Properties, such as DAV:acl? I would think so, otherwise roundtripping will be messy... If this is the case, the only way to actually get to the HTTP principal URL the spec requires in to use one of the reports, such as DAV:principal-property-search? If yes, I'd argue we probably write down an example showing how to do that, and add that to RFC3744bis... BR, Julian From w3c-dist-auth-request@listhub.w3.org Wed May 14 12:33:40 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB61C3A6891 for ; Wed, 14 May 2008 12:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt2jLeTo22QD for ; Wed, 14 May 2008 12:33:39 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id C82B23A688C for ; Wed, 14 May 2008 12:33:39 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JwMhY-0005Sq-OM for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 May 2008 19:31:48 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JwMhX-0005Rs-IQ; Wed, 14 May 2008 19:31:47 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JwMhQ-0005np-DF; Wed, 14 May 2008 19:31:46 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m4EJV28N012859; Wed, 14 May 2008 15:31:02 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4EJV2CN147068; Wed, 14 May 2008 15:31:02 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4EJV1OO022769; Wed, 14 May 2008 15:31:02 -0400 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m4EJV1gu022755; Wed, 14 May 2008 15:31:01 -0400 In-Reply-To: <482B3A71.7000703@gmx.de> To: Julian Reschke Cc: acl@webdav.org, Konstantin Breu , "'WebDAV'" , w3c-dist-auth-request@w3.org, "=?ISO-8859-1?Q?'Wilfredo_S=E1nchez_Vega'?=" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Geoffrey M Clemm Message-ID: Date: Wed, 14 May 2008 15:31:01 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 8.0|August 02, 2007) at 05/14/2008 15:31:01, Serialize complete at 05/14/2008 15:31:01 Content-Type: multipart/alternative; boundary="=_alternative 006B34B885257449_=" Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Scan-Sig: aji.w3.org 1JwMhQ-0005np-DF c05b6b9c938cc9d807dda66ade8b1f53 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12846 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 May 2008 19:31:48 +0000 This is a multipart message in MIME format. --=_alternative 006B34B885257449_= Content-Type: text/plain; charset="US-ASCII" If we believe that it is reasonable to require that the DAV:principal-URL be an HTTP URL, then I'm fine with just requiring this in RFC3774bis. If we don't require that, then I don't think we can require that there be a way to "find" that principal, since as you say, if you can find it using the information in the DAV:principal-URL, you should have been able to format that information as an HTTP URL. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 05/14/2008 03:16:01 PM: > > Geoffrey M Clemm wrote: > > > > So here's the problem: The primary purpose of the DAV:principal-URL is > > to specify the "identity" of a principal (so you can use it to check for > > equality). But you might not have an HTTP URI that can be used as the > > "identity" (you might need to use some URN URI, for example). So you > > might be forced to use a non-HTTP URL in the DAV:principal-URL property. > > Not totally convinced. If you can make a URN work, you can probably make > an HTTP URI work as well. Maybe not a pretty one, though. But anyway... > > > So the spec says that there must be an HTTP URL for a principal, but it > > does not require that the HTTP URL be the one that appears in the > > DAV:principal-URL property. > > > > At least that's how I remember it ... I could of course be wrong (it's > > been a while :-). > > OK, let's start with the assumption that you are right, usually a safe > position :-). > > The spec say that the principal-URL must be used in ACL requests. Does > this also mean it will be the one that will be used in the Access > Control Properties, such as DAV:acl? I would think so, otherwise > roundtripping will be messy... > > If this is the case, the only way to actually get to the HTTP principal > URL the spec requires in to use one of the reports, such as > DAV:principal-property-search? If yes, I'd argue we probably write down > an example showing how to do that, and add that to RFC3744bis... > > BR, Julian > > > > --=_alternative 006B34B885257449_= Content-Type: text/html; charset="US-ASCII"
If we believe that it is reasonable to require that the DAV:principal-URL be an HTTP URL, then I'm fine with just requiring this in RFC3774bis.
If we don't require that, then I don't think we can require that there be a way to "find" that principal, since as you say, if you can find it using the information in the DAV:principal-URL, you should have been able to format that information as an HTTP URL.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 05/14/2008 03:16:01 PM:

>
> Geoffrey M Clemm wrote:
> >
> > So here's the problem:  The primary purpose of the DAV:principal-URL is
> > to specify the "identity" of a principal (so you can use it to check for
> > equality).  But you might not have an HTTP URI that can be used as the
> > "identity" (you might need to use some URN URI, for example).  So you
> > might be forced to use a non-HTTP URL in the DAV:principal-URL property.
>
> Not totally convinced. If you can make a URN work, you can probably make
> an HTTP URI work as well. Maybe not a pretty one, though. But anyway...
>
> > So the spec says that there must be an HTTP URL for a principal, but it
> > does not require that the HTTP URL be the one that appears in the
> > DAV:principal-URL property.
> >
> > At least that's how I remember it ... I could of course be wrong (it's
> > been a while :-).
>
> OK, let's start with the assumption that you are right, usually a safe
> position :-).
>
> The spec say that the principal-URL must be used in ACL requests. Does
> this also mean it will be the one that will be used in the Access
> Control Properties, such as DAV:acl? I would think so, otherwise
> roundtripping will be messy...
>
> If this is the case, the only way to actually get to the HTTP principal
> URL the spec requires in to use one of the reports, such as
> DAV:principal-property-search? If yes, I'd argue we probably write down
> an example showing how to do that, and add that to RFC3744bis...
>
> BR, Julian
>
>
>
>
--=_alternative 006B34B885257449_=-- From w3c-dist-auth-request@listhub.w3.org Wed May 14 13:19:28 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FCE13A6781 for ; Wed, 14 May 2008 13:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzLgSiCvc2+x for ; Wed, 14 May 2008 13:19:27 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 1BF2F3A681F for ; Wed, 14 May 2008 13:19:27 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JwNQE-0005lR-2F for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 May 2008 20:17:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JwNQD-0005kR-5K for w3c-dist-auth@listhub.w3.org; Wed, 14 May 2008 20:17:57 +0000 Received: from daboo.name ([151.201.22.177]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JwNQ7-0004KA-Uc for w3c-dist-auth@w3.org; Wed, 14 May 2008 20:17:56 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id ED63F74EF4F; Wed, 14 May 2008 16:17:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hP97s12ZM16; Wed, 14 May 2008 16:17:22 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id E43B774EF47; Wed, 14 May 2008 16:17:19 -0400 (EDT) Date: Wed, 14 May 2008 16:17:16 -0400 From: Cyrus Daboo To: Geoffrey M Clemm , Julian Reschke cc: acl@webdav.org, Konstantin Breu , 'WebDAV' , =?UTF-8?Q?'Wilfredo_S=C3=A1nchez_Vega'?= Message-ID: <88045FA6253BCEB763E06402@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: lisa.w3.org 1JwNQ7-0004KA-Uc 2d89ec5f37f1cc181fb70722a9444949 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12847 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 May 2008 20:17:58 +0000 Hi Geoffrey, --On May 14, 2008 3:31:01 PM -0400 Geoffrey M Clemm wrote: > If we believe that it is reasonable to require that the DAV:principal-URL > be an HTTP URL, then I'm fine with just requiring this in RFC3774bis. > If we don't require that, then I don't think we can require that there be > a way to "find" that principal, since as you say, if you can find it > using the information in the DAV:principal-URL, you should have been able > to format that information as an HTTP URL. Actually I think the requirement is that the principal-URL property MUST contain an HTTP URL to a principal resource valid on the server. i.e. an HTTP URL to some random resource on another server is just as useless as a urn:uuid, if you need to resolve back to an actual principal resource. -- Cyrus Daboo From cabral@creduni.com.br Sun May 18 13:01:28 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C615C3A6DCE; Sun, 18 May 2008 13:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.753 X-Spam-Level: X-Spam-Status: No, score=-64.753 tagged_above=-999 required=5 tests=[FB_QUALITY_REPLICA=10.357, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=4.199, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_NUMERIC_HELO=2.599, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.617, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGecPlMRnX22; Sun, 18 May 2008 13:01:25 -0700 (PDT) Received: from 82.159.123.0.dyn.user.ono.com (82.159.123.0.dyn.user.ono.com [82.159.123.0]) by core3.amsl.com (Postfix) with SMTP id 1BEE23A6DCD; Sun, 18 May 2008 13:01:15 -0700 (PDT) X-Originating-IP: 192.232.186.30 by smtp.82.159.123.0; Sun, 18 May 2008 16:01:15 -0500 Message-ID: From: "Lynda Cochran" Reply-To: "Lynda Cochran" To: vpim@ietf.org Subject: April promo on watches Date: Sun, 18 May 2008 16:01:15 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://faketifo77206.blogspot.com/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://faketifo77206.blogspot.com/ From c.hale@stewartmg.com Mon May 19 16:56:46 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0969E3A6AFC; Mon, 19 May 2008 16:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.243 X-Spam-Level: X-Spam-Status: No, score=-54.243 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_RELAY_NODNS=1.451, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HELO_MISMATCH_NET=0.611, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, SARE_SPEC_ROLEX_SEL=2.222, SUBJECT_FUZZY_TION=0.156, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbwhOXu4D1oh; Mon, 19 May 2008 16:56:45 -0700 (PDT) Received: from 200.79.152.27.dial.dyn.telnor.net (unknown [200.79.152.27]) by core3.amsl.com (Postfix) with SMTP id 538DD3A693F; Mon, 19 May 2008 16:56:31 -0700 (PDT) X-Originating-IP: 165.68.122.166 by smtp.200.79.152.27; Mon, 19 May 2008 19:56:29 -0500 Message-ID: From: "Daryl Oneill" Reply-To: "Daryl Oneill" To: vpim@ietf.org Subject: Inexpensive Louis Vuitton bags Date: Mon, 19 May 2008 19:56:29 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Looking for superior quality replica watches? Then welcome to the newly redesigned Prestige Replicas, home of the best reproduction Rolex Sportmodel watches on the whole web! Prestige Replicas offers a tremendous selection of Rolex replica timepieces for both men and women, all of them featuring the original manufacturer markings along with a myriad of details that make these watches look so much like the brand new Rolexes that even the experts are having a hard time differentiating them! http://wypavesonyg14.blogspot.com/ So, come visit Prestige Replicas and enjoy not only the most beautiful Rolex Sportmodel replica watches at unbelievable prices, but also get an extra 15% off when you buy two! http://wypavesonyg14.blogspot.com/ From c0algec7kk2wtweaaaaa@acera.ca Tue May 20 03:41:41 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556163A6A2F; Tue, 20 May 2008 03:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.114 X-Spam-Level: X-Spam-Status: No, score=-28.114 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_VIRTUACOMBR=1.193, SARE_SPEC_REPLICA_OBFU=1.812, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMRHKeWtvAoh; Tue, 20 May 2008 03:41:40 -0700 (PDT) Received: from c935ba04.virtua.com.br (unknown [201.53.186.4]) by core3.amsl.com (Postfix) with SMTP id CEE6128C0F7; Tue, 20 May 2008 03:41:28 -0700 (PDT) X-Originating-IP: 95.164.46.232 by smtp.201.53.186.4; Tue, 20 May 2008 06:41:28 -0500 Message-ID: From: "Sal Miranda" Reply-To: "Sal Miranda" To: vrrp-request@ietf.org Subject: Get one of these awesome replicas Date: Tue, 20 May 2008 06:41:28 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://www.annsidn.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://www.annsidn.com/ From w3c-dist-auth-request@listhub.w3.org Tue May 20 20:34:29 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC1928C9A6 for ; Tue, 20 May 2008 20:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+jJNFJl1sG3 for ; Tue, 20 May 2008 20:34:28 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2333E28DC57 for ; Tue, 20 May 2008 11:06:03 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JyWDG-0007Hg-VK for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 May 2008 18:05:27 +0000 Received: from farnsworth.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JyWDF-0007Gv-Tg for w3c-dist-auth@listhub.w3.org; Tue, 20 May 2008 18:05:25 +0000 Received: from nobody by farnsworth.w3.org with local (Exim 4.63) (envelope-from ) id 1JyWDF-00083J-RR for w3c-dist-auth@listhub.w3.org; Tue, 20 May 2008 18:05:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JyVsL-0005T5-1g for w3c-dist-auth@listhub.w3.org; Tue, 20 May 2008 17:43:49 +0000 Received: from el-out-1112.google.com ([209.85.162.182]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JyVsB-0002LU-P2 for w3c-dist-auth@w3.org; Tue, 20 May 2008 17:43:48 +0000 Received: by el-out-1112.google.com with SMTP id n30so741119elf.17 for ; Tue, 20 May 2008 10:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=yTh4EN2Z9/aGhuahqMgY6Q+rxCxxpg/vAsw6z2bTIDE=; b=YWg5fJXn6A4fwRNObpkQWYfto0zpGfz08pjclML9ncOp3Jlj0RlotF8lr0AnPlIkx6VrN1klt2SsOhhHzsEBHifV6au+0ucOj7ppjWW9jAdEHhoH0uxHhBfMPqDsym2LQT8Glx3q7ckU46Qpi+wFg57DkuRQdJN551/VGq0eta4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=lFnvo71eoKJB23hbQBONjOXAi1/X6LwlH30bek1ldvWpskQE5Z8hMWz4Q7eh+bToKXfzURhSvuI8H9nJW0wJEVwYJdCjWMn/EvmMGsZ21q4+Jwd8UfgGsX7w9O1zCcJccdNr0eA2jl5ac0frTMYyfqtej9IPV9cQuEXImLT+mdg= Received: by 10.143.162.3 with SMTP id p3mr3436407wfo.313.1211305388992; Tue, 20 May 2008 10:43:08 -0700 (PDT) Received: by 10.143.53.4 with HTTP; Tue, 20 May 2008 10:43:08 -0700 (PDT) Message-ID: Date: Tue, 20 May 2008 23:13:08 +0530 From: "Hanmay Udgiri" To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4451_29551080.1211305388929" Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Hub-Spam-Report: BAYES_50=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JyVsB-0002LU-P2 9f9ee540c0ae93d888c3306027449400 X-caa-id: 053e65b3d638a1355cfd X-Original-To: w3c-dist-auth@w3.org Subject: Implementing WebDAV for different WebDAV clients Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12849 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 May 2008 18:05:26 +0000 ------=_Part_4451_29551080.1211305388929 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi I am looking to implementing WebDAV which supports multiple WebDAV clients. Which is the good practice to go for implementation. I am using tomcat for deploying my application. Currently we are supporting WebDAV for windows through IE. We are planning to support WebDAV clients like Xythos and Mac OS finder etc -- Thanks and Regards Hanmayya Udgiri ------=_Part_4451_29551080.1211305388929 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi
I am looking to implementing WebDAV which supports multiple WebDAV clients.
Which is the good practice to go for implementation.
I am using tomcat for deploying my application.
Currently we are supporting WebDAV for windows through IE.
We are planning to support WebDAV clients like Xythos and Mac OS finder etc

--
Thanks and Regards
Hanmayya Udgiri ------=_Part_4451_29551080.1211305388929-- From w3c-dist-auth-request@listhub.w3.org Tue May 20 20:41:51 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E1B28C396 for ; Tue, 20 May 2008 20:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoY0Jw++u3mh for ; Tue, 20 May 2008 20:41:50 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 9354728E30D for ; Tue, 20 May 2008 13:23:43 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JyYLt-00060v-7d for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 May 2008 20:22:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JyYLs-00060G-7d for w3c-dist-auth@listhub.w3.org; Tue, 20 May 2008 20:22:28 +0000 Received: from moutng.kundenserver.de ([212.227.126.187]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JyYLd-0004Ct-IS for w3c-dist-auth@w3.org; Tue, 20 May 2008 20:22:28 +0000 Received: from [84.187.45.206] (p54BB2DCE.dip0.t-ipconnect.de [84.187.45.206]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1JyYL12sFz-0007CQ; Tue, 20 May 2008 22:21:36 +0200 Message-ID: <483332C7.2010109@onlinehome.de> Date: Tue, 20 May 2008 22:21:27 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 To: Hanmay Udgiri CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19wXYQV2NtbcqnOCsq2D5Qkv5Ci9ks0zTFiUhv mEDMQGukrpG9qdDcQZ04lCs4qKT8jOdPtL8bEYDAKsDXyrNctC pBHy4lBL4hQ27GvdeelhA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1JyYLd-0004Ct-IS 44b3eac2b6c12c2f03a248d257c21ccf X-Original-To: w3c-dist-auth@w3.org Subject: Re: Implementing WebDAV for different WebDAV clients Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12850 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 May 2008 20:22:29 +0000 Hanmay Udgiri wrote: > Hi > I am looking to implementing WebDAV which supports multiple WebDAV clients. > Which is the good practice to go for implementation. > I am using tomcat for deploying my application. > Currently we are supporting WebDAV for windows through IE. > We are planning to support WebDAV clients like Xythos and Mac OS finder etc > Why not just start supporting the standards? If there should be problems with certain clients, you may decide whether to help debugging the clients or provide a workaround. Still better: why don't you take an existing server. Or help make it better? As developer of a WebDAV-client I am fed up with broken servers. Just had to answer an help-request, because they can't even implement HEAD according to the standards. You are using tomcat. What is wrong with Jigsaw (http://www.w3.org/Jigsaw/)? Can you improve it? Cheers Werner From w3c-dist-auth-request@listhub.w3.org Tue May 20 20:44:31 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1F728C2AC for ; Tue, 20 May 2008 20:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxQqJ3QnribR for ; Tue, 20 May 2008 20:44:30 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 1B63B28DB39 for ; Tue, 20 May 2008 10:47:59 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JyVui-0007Kz-3A for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 May 2008 17:46:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JyVuh-0007KF-4o for w3c-dist-auth@listhub.w3.org; Tue, 20 May 2008 17:46:15 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JyVuY-0003tu-8M for w3c-dist-auth@w3.org; Tue, 20 May 2008 17:46:15 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 5D7302D8ED04; Tue, 20 May 2008 10:45:32 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 43629464004; Tue, 20 May 2008 10:45:32 -0700 (PDT) X-AuditID: 11807135-aa1bcbb000000d04-de-48330e3c13d2 Received: from pucca.apple.com (pucca.apple.com [17.224.20.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay12.apple.com (Apple SCV relay) with ESMTP id 1FC45420003; Tue, 20 May 2008 10:45:32 -0700 (PDT) Cc: Geoffrey M Clemm , Julian Reschke , acl@webdav.org, Konstantin Breu , "'WebDAV'" Message-Id: From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= To: Cyrus Daboo In-Reply-To: <88045FA6253BCEB763E06402@caldav.corp.apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 20 May 2008 10:45:31 -0700 References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> X-Mailer: Apple Mail (2.924) X-Brightmail-Tracker: AAAAAA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: lisa.w3.org 1JyVuY-0003tu-8M 66b79bf0b95cd4d7eb7bd32d33384ec7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12848 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 May 2008 17:46:16 +0000 The reason I brought this up was that is affects draft-sanchez- webdav-current-principal-00 which I submitted. I had hoped to require that the principal URL returned in the current-user-principal-resource property MUST be the same as the principal-url property on the resource at that URL. That would avoid requiring a client from having to fetch the current-user-principal- resource property on a DAV resource, then fetch the principal-url from there in order to know what to use in ACEs. That's only feasible if the principal-url property must also be an http(s) URL. -wsv From w3c-dist-auth-request@listhub.w3.org Wed May 21 07:02:25 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2547D3A6A8F for ; Wed, 21 May 2008 07:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43OaRQ-kT9eC for ; Wed, 21 May 2008 07:02:08 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 555923A6A22 for ; Wed, 21 May 2008 07:01:48 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JyorI-0001DA-QE for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 May 2008 14:00:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JyorH-0001CV-LC for w3c-dist-auth@listhub.w3.org; Wed, 21 May 2008 13:59:59 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Jyor7-0000jO-W7 for w3c-dist-auth@w3.org; Wed, 21 May 2008 13:59:59 +0000 Received: (qmail invoked by alias); 21 May 2008 13:59:16 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.107]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 21 May 2008 15:59:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18mZRNnI4km3Xd1I7uNkcB2WsiJ5aQxlSv/15KF2U 5JuTk3bSXY+ufY Message-ID: <48342AAD.5010404@gmx.de> Date: Wed, 21 May 2008 15:59:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Cyrus Daboo , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1Jyor7-0000jO-W7 54c8f9e5928096286ff4e6ec3eff97a5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12851 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 May 2008 14:00:00 +0000 Wilfredo Sánchez Vega wrote: > > The reason I brought this up was that is affects > draft-sanchez-webdav-current-principal-00 which I submitted. > > I had hoped to require that the principal URL returned in the > current-user-principal-resource property MUST be the same as the > principal-url property on the resource at that URL. That would avoid > requiring a client from having to fetch the > current-user-principal-resource property on a DAV resource, then fetch > the principal-url from there in order to know what to use in ACEs. > That's only feasible if the principal-url property must also be an > http(s) URL. Let's assume that the principal URL can be something like a mailto: URL. As far as I understand, RFC 3744 requires to use the principal URL in the ACL request, and it would be very strange if it didn't come back in the DAV:acl property. So assuming we'd have a mailto URL in all these places, how can a client - in general - find the associated HTTP URL? The DAV:principal-property-search report *could* do that, as long as the server supports searching on the DAV:principal-URL property. Geoff said: GC> If we believe that it is reasonable to require that the DAV:principal-URL be an HTTP URL, then I'm fine with just requiring this in RFC3774bis. GC> If we don't require that, then I don't think we can require that there be a way to "find" that principal, since as you say, if you can find it using the information in the DAV:principal-URL, you should have been able to format that information as an HTTP URL. ...so I'm really tempted to state that, after all, the principal URL needs to be an HTTP URL. However, Section 2 states: "A URI of any scheme MAY be used to identify a principal resource. However, servers implementing this specification MUST expose principal resources at an http(s) URL, which is a privileged scheme that points to resources that have additional properties, as described in Section 4. So, a principal resource can have multiple URIs, one of which has to be an http(s) scheme URL. Although an implementation SHOULD support PROPFIND and MAY support PROPPATCH to access and modify information about a principal, it is not required to do so." So if a server chooses not to fulfill "SHOULD support PROPFIND", what would that buy us? Is anybody aware of a server that exposes principals as non-HTTP resources, or as HTTP resources not supporting PROPFIND? Going back to Wilfredo's mail...: > I had hoped to require that the principal URL returned in the > current-user-principal-resource property MUST be the same as the > principal-url property on the resource at that URL. That would avoid > requiring a client from having to fetch the > current-user-principal-resource property on a DAV resource, then fetch > the principal-url from there in order to know what to use in ACEs. > That's only feasible if the principal-url property must also be an > http(s) URL. Why wouldn't that work for servers that in fact do not have any WebDAV enabled principal resources? BR, Julian From c.wickert@wickert-assekuranz.de Wed May 21 09:21:37 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B9928C217; Wed, 21 May 2008 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.527 X-Spam-Level: X-Spam-Status: No, score=-20.527 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thbz34VhBDbb; Wed, 21 May 2008 09:21:37 -0700 (PDT) Received: from adsl190-26162070.dyn.etb.net.co (unknown [190.26.162.70]) by core3.amsl.com (Postfix) with SMTP id 6D40228C233; Wed, 21 May 2008 09:21:02 -0700 (PDT) X-Originating-IP: 67.175.254.212 by smtp.190.26.162.70; Wed, 21 May 2008 12:21:02 -0500 Message-ID: From: "Jeanne King" Reply-To: "Jeanne King" To: vpim@ietf.org Subject: The affordable watch alternative Date: Wed, 21 May 2008 12:21:02 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://www.adieks.com/ From c.lassalle@malegol.com Wed May 21 19:37:57 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032483A6A17; Wed, 21 May 2008 19:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ri9gqMFgdS6; Wed, 21 May 2008 19:37:56 -0700 (PDT) Received: from adsl190-25124050.dyn.etb.net.co (unknown [190.25.124.50]) by core3.amsl.com (Postfix) with SMTP id 182C33A688B; Wed, 21 May 2008 19:37:44 -0700 (PDT) X-Originating-IP: 12.182.64.80 by smtp.190.25.124.50; Wed, 21 May 2008 22:37:44 -0500 Message-ID: From: "Socorro Jackson" Reply-To: "Socorro Jackson" To: vpim@ietf.org Subject: 15% off on two watches Date: Wed, 21 May 2008 22:37:44 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://www.oidoido.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://www.oidoido.com/ From w3c-dist-auth-request@listhub.w3.org Thu May 22 10:28:43 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564853A67A9 for ; Thu, 22 May 2008 10:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf830y4tWlcw for ; Thu, 22 May 2008 10:28:42 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 56BF23A6835 for ; Thu, 22 May 2008 10:28:39 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzEZ1-0007PJ-Ic for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 May 2008 17:26:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzEZ0-0007OY-Ga for w3c-dist-auth@listhub.w3.org; Thu, 22 May 2008 17:26:50 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzEYr-0002O4-8F for w3c-dist-auth@w3.org; Thu, 22 May 2008 17:26:50 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 277B72C86540; Thu, 22 May 2008 10:26:07 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id F0BFA2807B; Thu, 22 May 2008 10:26:06 -0700 (PDT) X-AuditID: 11807130-adb98bb000000ead-89-4835acaebcf8 Received: from pucca.apple.com (pucca.apple.com [17.224.20.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id B22FE2803F; Thu, 22 May 2008 10:26:06 -0700 (PDT) Cc: Cyrus Daboo , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' Message-Id: From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= To: Julian Reschke In-Reply-To: <48342AAD.5010404@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 22 May 2008 10:26:06 -0700 References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> X-Mailer: Apple Mail (2.924) X-Brightmail-Tracker: AAAAAA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: lisa.w3.org 1JzEYr-0002O4-8F ff48da5271c0cb45ee40593f7760cd2f X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12852 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 May 2008 17:26:51 +0000 On May 21, 2008, at 6:59 AM, Julian Reschke wrote: > So assuming we'd have a mailto URL in all these places, how can a > client - in general - find the associated HTTP URL? The > DAV:principal-property-search report *could* do that, as long as the > server supports searching on the DAV:principal-URL property. Right, and having to do that query, which may not be supported anyway, doesn't seem like a good solution. > Geoff said: > > GC> If we believe that it is reasonable to require that the > DAV:principal-URL be an HTTP URL, then I'm fine with just requiring > this in RFC3774bis. > GC> If we don't require that, then I don't think we can require that > there be a way to "find" that principal, since as you say, if you > can find it using the information in the DAV:principal-URL, you > should have been able to format that information as an HTTP URL. > > ...so I'm really tempted to state that, after all, the principal URL > needs to be an HTTP URL. Agreed. > However, Section 2 states: > > "A URI of any scheme MAY be used to identify a principal resource. > However, servers implementing this specification MUST expose > principal resources at an http(s) URL, which is a privileged scheme > that points to resources that have additional properties, as > described in Section 4. So, a principal resource can have multiple > URIs, one of which has to be an http(s) scheme URL. Although an > implementation SHOULD support PROPFIND and MAY support PROPPATCH to > access and modify information about a principal, it is not required > to do so." > > So if a server chooses not to fulfill "SHOULD support PROPFIND", > what would that buy us? I guess I can only be concerned about those who do, since there is little point in getting a principal URI if you can't query it for information, other than to use it in ACEs, but I think such use is limited unless you have some way to map principal URLs to something you know about. > Going back to Wilfredo's mail...: > > > I had hoped to require that the principal URL returned in the > > current-user-principal-resource property MUST be the same as the > > principal-url property on the resource at that URL. That would > avoid > > requiring a client from having to fetch the > > current-user-principal-resource property on a DAV resource, then > fetch > > the principal-url from there in order to know what to use in ACEs. > > That's only feasible if the principal-url property must also be an > > http(s) URL. > > Why wouldn't that work for servers that in fact do not have any > WebDAV enabled principal resources? I agree with your comments, but don't understand this question. There's no point in trying to discover the URL to your principal resource if the server doesn't support them, since it wouldn't implement the extension I proposed. -wsv From w3c-dist-auth-request@listhub.w3.org Thu May 22 19:23:09 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAA53A6BAC for ; Thu, 22 May 2008 19:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YozpOeXifr+T for ; Thu, 22 May 2008 19:23:08 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 516A13A6BAA for ; Thu, 22 May 2008 19:23:08 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzMuO-0007bp-P9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 02:21:28 +0000 Received: from farnsworth.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzMuM-0007Yu-4l for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 02:21:26 +0000 Received: from nobody by farnsworth.w3.org with local (Exim 4.63) (envelope-from ) id 1JzMuM-0006XY-2O for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 02:21:26 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzGuL-00034E-7t for w3c-dist-auth@listhub.w3.org; Thu, 22 May 2008 19:57:01 +0000 Received: from ebed.etf.cuni.cz ([195.113.5.3]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzGuB-0002a0-77 for w3c-dist-auth@w3.org; Thu, 22 May 2008 19:57:00 +0000 Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id m4MJtaOR002813; Thu, 22 May 2008 21:55:36 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id m4MJtauZ002810; Thu, 22 May 2008 21:55:36 +0200 Date: Thu, 22 May 2008 21:55:36 +0200 From: Petr Tomasek To: Julian Reschke , WebDAV Message-ID: <20080522195536.GA2087@ebed.etf.cuni.cz> References: <47DBAB30.1060306@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47DBAB30.1060306@gmx.de> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.8.0.19; VDF: 7.0.4.79; host: ebed.etf.cuni.cz) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1JzGuB-0002a0-77 a2ab60d101b0fff4d04f69c57d979d94 X-caa-id: 679e917fb9f59a7be8d0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12853 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 02:21:28 +0000 On Sat, Mar 15, 2008 at 11:55:44AM +0100, Julian Reschke wrote: > > Hi, > > here are a few thoughts about how to handle the WebDAV dependencies of > CardDAV (mostly based on what was discussed in the VCARDDAV WG meeting > in Philadelphia): > > 1) WebDAV base requirements > > I think CardDAV should require WebDAV level 3 support, as defined by RFC > 4918. It seems there was some confusion about what level 3 actually is: I think this is a big error, requiring all that stuff. Consider if one would want to implement read-only CardDAV implementation. Why should one worry about locking, MKCOL and the other stuff? -- Petr Tomasek Jabber: butrus@jabbim.cz SIP: butrus@ekiga.net From c.kotheil@vcmedia.at Fri May 23 00:14:38 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D0C3A69AA; Fri, 23 May 2008 00:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.445 X-Spam-Level: X-Spam-Status: No, score=-77.445 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwB6a+kzIRMp; Fri, 23 May 2008 00:14:37 -0700 (PDT) Received: from 201-255-187-152.mrse.com.ar (unknown [201.255.187.152]) by core3.amsl.com (Postfix) with SMTP id 7D3B53A6C65; Fri, 23 May 2008 00:13:45 -0700 (PDT) X-Originating-IP: 214.188.70.251 by smtp.201.255.187.152; Fri, 23 May 2008 03:13:38 -0500 Message-ID: From: "Garland Ali" Reply-To: "Garland Ali" To: vpim@ietf.org Subject: The discreet replica store Date: Fri, 23 May 2008 03:13:38 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://vitivowemyd70.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://vitivowemyd70.blogspot.com/ From w3c-dist-auth-request@listhub.w3.org Fri May 23 02:43:33 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABCD3A6B14 for ; Fri, 23 May 2008 02:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmkx8TmTRu1i for ; Fri, 23 May 2008 02:43:32 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 6D6873A6996 for ; Fri, 23 May 2008 02:43:32 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzTmG-0005il-BA for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 09:41:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzTmC-0005i2-4y for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 09:41:28 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1JzTm3-0007T5-B4 for w3c-dist-auth@w3.org; Fri, 23 May 2008 09:41:27 +0000 Received: (qmail invoked by alias); 23 May 2008 09:40:48 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.107]) [217.91.35.233] by mail.gmx.net (mp040) with SMTP; 23 May 2008 11:40:48 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/MKD9jf0PMpM3TXrkWjRYalIPfCPtspcxD3x0jiL pB+Jp3Z+dBQhNW Message-ID: <4836911C.5050906@gmx.de> Date: Fri, 23 May 2008 11:40:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Petr Tomasek CC: WebDAV References: <47DBAB30.1060306@gmx.de> <20080522195536.GA2087@ebed.etf.cuni.cz> In-Reply-To: <20080522195536.GA2087@ebed.etf.cuni.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JzTm3-0007T5-B4 d11e20003d1d5eabbf7e850ee5cec2d7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12854 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 09:41:32 +0000 Petr Tomasek wrote: > On Sat, Mar 15, 2008 at 11:55:44AM +0100, Julian Reschke wrote: >> Hi, >> >> here are a few thoughts about how to handle the WebDAV dependencies of >> CardDAV (mostly based on what was discussed in the VCARDDAV WG meeting >> in Philadelphia): >> >> 1) WebDAV base requirements >> >> I think CardDAV should require WebDAV level 3 support, as defined by RFC >> 4918. It seems there was some confusion about what level 3 actually is: > > I think this is a big error, requiring all that stuff. Consider if one > would want to implement read-only CardDAV implementation. > Why should one worry about locking, MKCOL and the other stuff? In that case you would simply return 403 Forbidden. Anyway, what does this have to do with the question whether CardDAV should require level 1 or level 3? BR, Julian From w3c-dist-auth-request@listhub.w3.org Fri May 23 04:12:59 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCC63A6C90 for ; Fri, 23 May 2008 04:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5G3ggCM2kmH for ; Fri, 23 May 2008 04:12:58 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2D5E23A6C8D for ; Fri, 23 May 2008 04:12:58 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzVBF-00028Y-D6 for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 11:11:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzVBE-00027u-8M for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 11:11:24 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1JzVB5-0002qb-Ex for w3c-dist-auth@w3.org; Fri, 23 May 2008 11:11:23 +0000 Received: (qmail invoked by alias); 23 May 2008 11:10:44 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.107]) [217.91.35.233] by mail.gmx.net (mp026) with SMTP; 23 May 2008 13:10:44 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Zpwxio9oZ/zU03TEWpiLRZkzSRoyEDlAekv12ov 3y5pVMuOiWz6V9 Message-ID: <4836A631.7030909@gmx.de> Date: Fri, 23 May 2008 13:10:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Cyrus Daboo , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JzVB5-0002qb-Ex 4c8f861072c603756139c08b20e42a56 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12855 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 11:11:25 +0000 Wilfredo Sánchez Vega wrote: >> Going back to Wilfredo's mail...: >> >> > I had hoped to require that the principal URL returned in the >> > current-user-principal-resource property MUST be the same as the >> > principal-url property on the resource at that URL. That would avoid >> > requiring a client from having to fetch the >> > current-user-principal-resource property on a DAV resource, then fetch >> > the principal-url from there in order to know what to use in ACEs. >> > That's only feasible if the principal-url property must also be an >> > http(s) URL. >> >> Why wouldn't that work for servers that in fact do not have any WebDAV >> enabled principal resources? > > I agree with your comments, but don't understand this question. > There's no point in trying to discover the URL to your principal > resource if the server doesn't support them, since it wouldn't implement > the extension I proposed. Hm. OK, let's assume a server that has only one URI per principal, and that URI is a mailto URI. Obviously, you wouldn't able to PROPFIND the DAV:principal-URL property. The mailto URIs would be exposed in ACLs. DAV:current-user-principal-resource (*) would show expose the mailto URI. So, what would be the problem here with respect to your extension BR, Julian PS: I don't think that would be a terrible useful impl, I'm just trying to understand your previous statement about needing HTTP URIs for your extension. (*) Shouldn't that be "DAV:current-user-principal-URL", by the way? From w3c-dist-auth-request@listhub.w3.org Fri May 23 05:01:51 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FAB3A6BDA for ; Fri, 23 May 2008 05:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx57ux9y2sBU for ; Fri, 23 May 2008 05:01:50 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 58AED3A6BD1 for ; Fri, 23 May 2008 05:01:49 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzVxH-0005x7-75 for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 12:01:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzVxG-0005w4-4T for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 12:01:02 +0000 Received: from jazz.viagenie.ca ([206.123.31.2]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzVx2-0000K6-Ou for w3c-dist-auth@w3.org; Fri, 23 May 2008 12:01:02 +0000 Received: by jazz.viagenie.ca (Postfix, from userid 8) id C1A2C29E14A5; Fri, 23 May 2008 08:00:16 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id B8D3E29E1493 for ; Fri, 23 May 2008 08:00:16 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: w3c-dist-auth@w3.org Date: Fri, 23 May 2008 08:00:11 -0400 User-Agent: KMail/1.9.9 References: <47DBAB30.1060306@gmx.de> <20080522195536.GA2087@ebed.etf.cuni.cz> In-Reply-To: <20080522195536.GA2087@ebed.etf.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805230800.11458.simon.perreault@viagenie.ca> Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1JzVx2-0000K6-Ou 04d7d685ab9f05ef305da4f0d9f6e892 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12856 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 12:01:03 +0000 On Thursday 22 May 2008 15:55:36 Petr Tomasek wrote: > > I think CardDAV should require WebDAV level 3 support, as defined by RFC > > 4918. It seems there was some confusion about what level 3 actually is: > > I think this is a big error, requiring all that stuff. Consider if one > would want to implement read-only CardDAV implementation. > Why should one worry about locking, MKCOL and the other stuff? I think you're confused (as I was) about what class 3 implies. It does *not* imply locking. This is the very confusion that Julian is talking about. I wonder where you got the strange idea that class 3 would include MKCOL. :) From w3c-dist-auth-request@listhub.w3.org Fri May 23 06:23:11 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEA928C26B for ; Fri, 23 May 2008 06:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1w6qh1nurtS for ; Fri, 23 May 2008 06:23:11 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 40A8A28C264 for ; Fri, 23 May 2008 06:23:11 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzXDO-0000KB-W9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 13:21:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXDN-0000JR-Qr for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 13:21:45 +0000 Received: from jazz.viagenie.ca ([206.123.31.2]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXDE-0000rJ-Qc for w3c-dist-auth@w3.org; Fri, 23 May 2008 13:21:45 +0000 Received: by jazz.viagenie.ca (Postfix, from userid 8) id A25CE29E14A5; Fri, 23 May 2008 09:21:06 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 995DA29E1493 for ; Fri, 23 May 2008 09:21:06 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: w3c-dist-auth@w3.org Date: Fri, 23 May 2008 09:21:06 -0400 User-Agent: KMail/1.9.9 References: <47DBAB30.1060306@gmx.de> <20080522195536.GA2087@ebed.etf.cuni.cz> <200805230800.11458.simon.perreault@viagenie.ca> In-Reply-To: <200805230800.11458.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805230921.06408.simon.perreault@viagenie.ca> Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JzXDE-0000rJ-Qc 38a3f8b5752a686a95e62702861b4c6c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12857 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 13:21:46 +0000 On Friday 23 May 2008 08:00:11 Simon Perreault wrote: > I wonder where you got the strange idea that class 3 would include MKCOL. > :) Woah, that didn't make a lot of sense. Let's try again: I wonder where you got the strange idea that class *1* would *not* include MKCOL. :) ...sleepy... From w3c-dist-auth-request@listhub.w3.org Fri May 23 06:37:56 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1ABD28C27B for ; Fri, 23 May 2008 06:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keTP9L4gMLjB for ; Fri, 23 May 2008 06:37:56 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2761C28C26C for ; Fri, 23 May 2008 06:37:56 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzXSY-0006W4-Hh for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 13:37:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXSX-0006U4-Ia for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 13:37:25 +0000 Received: from hu-out-0506.google.com ([72.14.214.228]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXSN-0001Y0-LA for w3c-dist-auth@w3.org; Fri, 23 May 2008 13:37:25 +0000 Received: by hu-out-0506.google.com with SMTP id 40so943828hub.16 for ; Fri, 23 May 2008 06:36:49 -0700 (PDT) Received: by 10.125.102.15 with SMTP id e15mr521460mkm.21.1211549809102; Fri, 23 May 2008 06:36:49 -0700 (PDT) Received: from ?172.16.15.128? ( [212.209.62.241]) by mx.google.com with ESMTPS id 13sm10571107fks.12.2008.05.23.06.36.47 (version=SSLv3 cipher=RC4-MD5); Fri, 23 May 2008 06:36:48 -0700 (PDT) From: Henrik Holst To: Simon Perreault Cc: w3c-dist-auth@w3.org In-Reply-To: <200805230921.06408.simon.perreault@viagenie.ca> References: <47DBAB30.1060306@gmx.de> <20080522195536.GA2087@ebed.etf.cuni.cz> <200805230800.11458.simon.perreault@viagenie.ca> <200805230921.06408.simon.perreault@viagenie.ca> Content-Type: text/plain Date: Fri, 23 May 2008 15:36:46 +0200 Message-Id: <1211549806.6184.2.camel@henrik-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 7bit Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JzXSN-0001Y0-LA b9463203962bfcc23d015e3b689b7fcf X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12858 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 13:37:26 +0000 fre 2008-05-23 klockan 09:21 -0400 skrev Simon Perreault: > On Friday 23 May 2008 08:00:11 Simon Perreault wrote: > > I wonder where you got the strange idea that class 3 would include MKCOL. > > :) > > Woah, that didn't make a lot of sense. Let's try again: > > I wonder where you got the strange idea that class *1* would *not* include > MKCOL. :) > > ...sleepy... > There is no MUST in RFC4918 for the MKCOL Method so class 1 does not include MKCOL as far as I can see. /Henrik From w3c-dist-auth-request@listhub.w3.org Fri May 23 06:51:28 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750643A6B3B for ; Fri, 23 May 2008 06:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 052uVGj+4cIT for ; Fri, 23 May 2008 06:51:27 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id ACD413A6CA0 for ; Fri, 23 May 2008 06:51:27 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzXfW-0004a1-Ly for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 13:50:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXfV-0004ZN-V7 for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 13:50:50 +0000 Received: from jazz.viagenie.ca ([206.123.31.2]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXfN-00027Z-5w for w3c-dist-auth@w3.org; Fri, 23 May 2008 13:50:49 +0000 Received: by jazz.viagenie.ca (Postfix, from userid 8) id D3B8229E14AE; Fri, 23 May 2008 09:50:14 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id C998629E1493 for ; Fri, 23 May 2008 09:50:14 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: w3c-dist-auth@w3.org Date: Fri, 23 May 2008 09:50:14 -0400 User-Agent: KMail/1.9.9 References: <47DBAB30.1060306@gmx.de> <200805230921.06408.simon.perreault@viagenie.ca> <1211549806.6184.2.camel@henrik-desktop> In-Reply-To: <1211549806.6184.2.camel@henrik-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805230950.14596.simon.perreault@viagenie.ca> Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JzXfN-00027Z-5w 7dcc1c9c457cbcd2f8d0b3a077fe7f12 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12859 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 13:50:50 +0000 On Friday 23 May 2008 09:36:46 Henrik Holst wrote: > There is no MUST in RFC4918 for the MKCOL Method so class 1 does not > include MKCOL as far as I can see. Is it intentional? I mean, RFC2518 says "All DAV compliant resources MUST support the MKCOL method." And advertising class 3 would not imply support for MKCOL, if I read the definition of class 3 correctly. From w3c-dist-auth-request@listhub.w3.org Fri May 23 06:58:33 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F08D3A6CAB for ; Fri, 23 May 2008 06:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXbPBr1aJZG0 for ; Fri, 23 May 2008 06:58:32 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A6E963A6CA3 for ; Fri, 23 May 2008 06:58:32 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzXmY-0006Lf-UO for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 13:58:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXmY-0006KY-CW for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 13:58:06 +0000 Received: from hu-out-0506.google.com ([72.14.214.233]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXmO-0007pS-Cj for w3c-dist-auth@w3.org; Fri, 23 May 2008 13:58:05 +0000 Received: by hu-out-0506.google.com with SMTP id 40so961965hub.16 for ; Fri, 23 May 2008 06:57:27 -0700 (PDT) Received: by 10.125.124.15 with SMTP id b15mr509050mkn.83.1211551046765; Fri, 23 May 2008 06:57:26 -0700 (PDT) Received: from ?172.16.15.128? ( [212.209.62.241]) by mx.google.com with ESMTPS id 28sm10629078fkx.8.2008.05.23.06.57.24 (version=SSLv3 cipher=RC4-MD5); Fri, 23 May 2008 06:57:25 -0700 (PDT) From: Henrik Holst To: Simon Perreault Cc: w3c-dist-auth@w3.org In-Reply-To: <200805230950.14596.simon.perreault@viagenie.ca> References: <47DBAB30.1060306@gmx.de> <200805230921.06408.simon.perreault@viagenie.ca> <1211549806.6184.2.camel@henrik-desktop> <200805230950.14596.simon.perreault@viagenie.ca> Content-Type: text/plain Date: Fri, 23 May 2008 15:57:23 +0200 Message-Id: <1211551043.6184.7.camel@henrik-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 7bit Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1JzXmO-0007pS-Cj 8d72391cd994ae099ed5a8bcace3aeea X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12860 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 13:58:06 +0000 fre 2008-05-23 klockan 09:50 -0400 skrev Simon Perreault: > On Friday 23 May 2008 09:36:46 Henrik Holst wrote: > > There is no MUST in RFC4918 for the MKCOL Method so class 1 does not > > include MKCOL as far as I can see. > > Is it intentional? I mean, RFC2518 says "All DAV compliant resources MUST > support the MKCOL method." And advertising class 3 would not imply support > for MKCOL, if I read the definition of class 3 correctly. > Well that is interesting, class 1 would thus be slightly redefined in 4918 and supporting class 3 tells the client that your server follows this redefinition I guess. Hopefully we can get some info from the people involved with 4918 how the ideas where when MKCOL was changed from MUST. /Henrik Holst From w3c-dist-auth-request@listhub.w3.org Fri May 23 07:09:47 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3103A6CA5 for ; Fri, 23 May 2008 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN90Zi+eq1Z7 for ; Fri, 23 May 2008 07:09:46 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B8F163A6CC7 for ; Fri, 23 May 2008 07:09:46 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzXxL-0003hk-2u for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 14:09:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzXxK-0003h6-Fk for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 14:09:14 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1JzXxA-0000Bx-UN for w3c-dist-auth@w3.org; Fri, 23 May 2008 14:09:14 +0000 Received: (qmail invoked by alias); 23 May 2008 14:08:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.107]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 23 May 2008 16:08:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19PBmICiuRP9tzlcx9A1rRrPuC03fFMn49ZmYI7Cy GnOW883/Voe6O6 Message-ID: <4836CFDE.80403@gmx.de> Date: Fri, 23 May 2008 16:08:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Henrik Holst CC: Simon Perreault , w3c-dist-auth@w3.org References: <47DBAB30.1060306@gmx.de> <200805230921.06408.simon.perreault@viagenie.ca> <1211549806.6184.2.camel@henrik-desktop> <200805230950.14596.simon.perreault@viagenie.ca> <1211551043.6184.7.camel@henrik-desktop> In-Reply-To: <1211551043.6184.7.camel@henrik-desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1JzXxA-0000Bx-UN 93fbc811df87b514702973722c6dd3c0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12861 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 14:09:15 +0000 Henrik Holst wrote: > fre 2008-05-23 klockan 09:50 -0400 skrev Simon Perreault: >> On Friday 23 May 2008 09:36:46 Henrik Holst wrote: >>> There is no MUST in RFC4918 for the MKCOL Method so class 1 does not >>> include MKCOL as far as I can see. >> Is it intentional? I mean, RFC2518 says "All DAV compliant resources MUST >> support the MKCOL method." And advertising class 3 would not imply support >> for MKCOL, if I read the definition of class 3 correctly. >> > Well that is interesting, class 1 would thus be slightly redefined in > 4918 and supporting class 3 tells the client that your server follows > this redefinition I guess. > > Hopefully we can get some info from the people involved with 4918 how > the ideas where when MKCOL was changed from MUST. It wasn't intentional. As far as I recall, we lost the first paragraph without considering compliance. In practice I think it doesn't make any difference at all. If a server vendor can't implement support for creating collections, he/she simply won't. A 403 always was possible, RFC4918 now also allows 405. What difference does this make in practice? BR, Julian From w3c-dist-auth-request@listhub.w3.org Fri May 23 07:16:50 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000BB3A6CA0 for ; Fri, 23 May 2008 07:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHWTebn-03i3 for ; Fri, 23 May 2008 07:16:49 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 26A0D3A6CA5 for ; Fri, 23 May 2008 07:16:49 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzY4F-0000Fc-Us for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 14:16:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzY4F-0000Es-7i for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 14:16:23 +0000 Received: from daboo.name ([151.201.22.177]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzY45-0000iF-Th for w3c-dist-auth@w3.org; Fri, 23 May 2008 14:16:22 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7CAB57B38E3; Fri, 23 May 2008 10:15:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVArPAml-Dt5; Fri, 23 May 2008 10:15:43 -0400 (EDT) Received: from [10.0.128.13] (unknown [75.16.26.130]) by daboo.name (Postfix) with ESMTP id A87FB7B38DC; Fri, 23 May 2008 10:15:41 -0400 (EDT) Date: Fri, 23 May 2008 07:15:38 -0700 From: Cyrus Daboo To: Julian Reschke , =?UTF-8?Q?Wilfredo_S=C3=A1nchez_Vega?= cc: Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' Message-ID: <4F26E774AC04F0C606AFCECD@ninevah.local> In-Reply-To: <4836A631.7030909@gmx.de> References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> <4836A631.7030909@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: lisa.w3.org 1JzY45-0000iF-Th 7793f1bd7ea5d4c5219d3faad87fdffd X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12862 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 14:16:23 +0000 Hi Julian, --On May 23, 2008 1:10:41 PM +0200 Julian Reschke wrote: > DAV:current-user-principal-resource (*) would show expose the mailto URI. > (*) Shouldn't that be "DAV:current-user-principal-URL", by the way? Actually this is the key point. The use case for clients is to get to the principal "resource" not get the principal "URI". The interesting properties that clients need are on the principal resource (CALDAV:calendar-home-set for example), and indeed the DAV:principal-URL property is also there. So from a principal resource you can directly get DAV:principal-URL - always. From a principal-URL value, you are not guaranteed to directly get the principal resource (e.g. if mailto: or ldap: is used). If principal-URL does not point to a principal resource then the client has to fall back to principal-property-search reports on all valid principal collections in order to search for a principal resource with that principal-URL. Clients shouldn't have to do that. Now, WebDAV ACL makes it clear (first paragraph of Section 2) that one of DAV:principal-URL or DAV:alternate-URI-set MUST contain a URL to a principal resource (http/https). So DAV:current-user-principal-resource is just that value. DAV:principal-URL can therefore be any URI scheme without affecting that. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Fri May 23 07:47:05 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7972C28C1E4 for ; Fri, 23 May 2008 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVRXW6uWiVyA for ; Fri, 23 May 2008 07:47:04 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 902D43A6CB4 for ; Fri, 23 May 2008 07:47:04 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzYWm-0004kG-TF for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 14:45:52 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzYWl-0004iM-Co for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 14:45:51 +0000 Received: from sanpietro.red-bean.com ([66.146.193.61] ident=Debian-exim) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzYWZ-00050Z-FB for w3c-dist-auth@w3.org; Fri, 23 May 2008 14:45:50 +0000 Received: from adsl-76-202-116-36.dsl.pltn13.sbcglobal.net ([76.202.116.36]:41418 helo=[10.0.0.196]) by sanpietro.red-bean.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1JzYW0-0005K2-Vl; Fri, 23 May 2008 09:45:05 -0500 Cc: Cyrus Daboo , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' Message-Id: From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= To: Julian Reschke In-Reply-To: <4836A631.7030909@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 23 May 2008 07:45:02 -0700 References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> <4836A631.7030909@gmx.de> X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: No virus found by ClamAV at red-bean.com Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1JzYWZ-00050Z-FB 0e3a01e978871cf46171a14da3e32b69 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12863 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 14:45:52 +0000 On May 23, 2008, at 4:10 AM, Julian Reschke wrote: > OK, let's assume a server that has only one URI per principal, and > that URI is a mailto URI.\ ...but that's not allowed; a server is required to expose at least one http(s) scheme URL for each principal. It's just not required (we think) that this be the one in the DAV:principal-URL property; it might one of the alternate URIs. > Obviously, you wouldn't able to PROPFIND the DAV:principal-URL > property. > > The mailto URIs would be exposed in ACLs. > > DAV:current-user-principal-resource (*) would show expose the mailto > URI. > > So, what would be the problem here with respect to your extension That makes the extension useful only if you want to know what your URI is in ACEs. I can see that being somewhat useful, but it's highly limiting. The reason we want the extension for CalDAV clients is to query other properties of the principal, such as the calendar home set, the display name, etc. That is, given some credentials, we want to know "who the hell am I?". > PS: I don't think that would be a terrible useful impl, I'm just > trying to understand your previous statement about needing HTTP URIs > for your extension. > > (*) Shouldn't that be "DAV:current-user-principal-URL", by the way? I think it should be if we can require that it be the same as the DAV:principal-URL property on the principal resource, but Cyrus argued that the name should emphasize that it provides access to a resource that can yield further information about the current principal. -wsv From w3c-dist-auth-request@listhub.w3.org Fri May 23 08:57:46 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A734828C2D4 for ; Fri, 23 May 2008 08:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKPVSKvF9C-f for ; Fri, 23 May 2008 08:57:45 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A85B128C2DC for ; Fri, 23 May 2008 08:57:45 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzZcw-0005Ls-9r for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 15:56:18 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzZcu-0005L9-Qm for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 15:56:17 +0000 Received: from moutng.kundenserver.de ([212.227.126.174]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzZck-00059C-Gq for w3c-dist-auth@w3.org; Fri, 23 May 2008 15:56:15 +0000 Received: from [84.187.13.229] (p54BB0DE5.dip0.t-ipconnect.de [84.187.13.229]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1JzZcA0DP3-00019q; Fri, 23 May 2008 17:55:30 +0200 Message-ID: <4836E8E8.6040804@onlinehome.de> Date: Fri, 23 May 2008 17:55:20 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: <47DBAB30.1060306@gmx.de> <200805230921.06408.simon.perreault@viagenie.ca> <1211549806.6184.2.camel@henrik-desktop> <200805230950.14596.simon.perreault@viagenie.ca> <1211551043.6184.7.camel@henrik-desktop> <4836CFDE.80403@gmx.de> In-Reply-To: <4836CFDE.80403@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18xQ38HRtUsgSSQ9FCjUxtWMMxHc8EG7N6yAc9 JdTTgb5ScLj4kwnm1Ob8/SuacdAExRCYlTlFXB+MEPUPwNICxH Vb3yy/2O0H4uTy9FaqufQ== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: aji.w3.org 1JzZck-00059C-Gq 6dec4c2e5b48845e9535ec3864bfc4ef X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12864 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 15:56:18 +0000 Julian Reschke wrote: > > Henrik Holst wrote: >> fre 2008-05-23 klockan 09:50 -0400 skrev Simon Perreault: >>> On Friday 23 May 2008 09:36:46 Henrik Holst wrote: >>>> There is no MUST in RFC4918 for the MKCOL Method so class 1 does not >>>> include MKCOL as far as I can see. >>> Is it intentional? I mean, RFC2518 says "All DAV compliant resources >>> MUST support the MKCOL method." And advertising class 3 would not >>> imply support for MKCOL, if I read the definition of class 3 correctly. >>> >> Well that is interesting, class 1 would thus be slightly redefined in >> 4918 and supporting class 3 tells the client that your server follows >> this redefinition I guess. >> >> Hopefully we can get some info from the people involved with 4918 how >> the ideas where when MKCOL was changed from MUST. > > It wasn't intentional. As far as I recall, we lost the first paragraph > without considering compliance. If it was not intentional, it should go in the Errata document to avoid confusion. > > In practice I think it doesn't make any difference at all. > > If a server vendor can't implement support for creating collections, > he/she simply won't. A 403 always was possible, RFC4918 now also allows > 405. > > What difference does this make in practice? 405 was allowed in RFC 2518 too. HTTP/1.1 also knows 501 Not Implemented. RFC 2616: 10.5.2 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. RFC 2518/4918: 403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its namespace, or 2) the parent collection of the Request-URI exists but cannot accept members. 405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource. No difference in practice? Are clients supposed not to care about these different status codes? A server, that does not implement MKCOL, is not compliant according RFC 2616, but is compliant according RFC 4918. No difference in practice? I have to concede: I never saw a compliant WebDAV-server. So does it make a difference in practice, whether there is a standard at all? Werner From w3c-dist-auth-request@listhub.w3.org Fri May 23 09:26:13 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE72F3A6CD7 for ; Fri, 23 May 2008 09:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDXEjY-cuZqr for ; Fri, 23 May 2008 09:26:13 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id E33D43A6B95 for ; Fri, 23 May 2008 09:26:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Jza5B-0007oS-DU for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 16:25:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jza5A-0007no-Fg for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 16:25:28 +0000 Received: from aji.w3.org ([133.27.228.225]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jza5A-0000YY-0A for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 16:25:28 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Jza4a-0007TW-5w for w3c-dist-auth@w3.org; Fri, 23 May 2008 16:25:01 +0000 Received: (qmail invoked by alias); 23 May 2008 16:24:16 -0000 Received: from mnsr-d9b8d68e.pool.mediaWays.net (EHLO [217.184.214.142]) [217.184.214.142] by mail.gmx.net (mp029) with SMTP; 23 May 2008 18:24:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Q0r9oT9/QFkJQsdBPTWX2y6QtuQ5Psx1owFIbrx f9SQXvpGiCQ8Ob Message-ID: <4836EEDD.2080609@gmx.de> Date: Fri, 23 May 2008 18:20:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo CC: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> <4836A631.7030909@gmx.de> <4F26E774AC04F0C606AFCECD@ninevah.local> In-Reply-To: <4F26E774AC04F0C606AFCECD@ninevah.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Jza4a-0007TW-5w c14f0c704eac5a97d5e3564b26fbfd13 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12865 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 16:25:29 +0000 Cyrus Daboo wrote: > > Hi Julian, > > --On May 23, 2008 1:10:41 PM +0200 Julian Reschke > wrote: > >> DAV:current-user-principal-resource (*) would show expose the mailto URI. > >> (*) Shouldn't that be "DAV:current-user-principal-URL", by the way? > > Actually this is the key point. The use case for clients is to get to > the principal "resource" not get the principal "URI". The interesting > properties that clients need are on the principal resource > (CALDAV:calendar-home-set for example), and indeed the DAV:principal-URL > property is also there. So from a principal resource you can directly > get DAV:principal-URL - always. From a principal-URL value, you are not > guaranteed to directly get the principal resource (e.g. if mailto: or > ldap: is used). If principal-URL does not point to a principal resource > then the client has to fall back to principal-property-search reports on > all valid principal collections in order to search for a principal > resource with that principal-URL. Clients shouldn't have to do that. Yes. I was just pointing out that we usually say "URL" in the XML elements when we're talking about URLs. > Now, WebDAV ACL makes it clear (first paragraph of Section 2) that one > of DAV:principal-URL or DAV:alternate-URI-set MUST contain a URL to a > principal resource (http/https). So DAV:current-user-principal-resource > is just that value. DAV:principal-URL can therefore be any URI scheme > without affecting that. OK, so the proposal for DAV:current-user-principal-URL^H^H^Hresource would work independently of the other issue, right? BR, Julian From adwords-noreply@google.com Fri May 23 09:26:22 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A42A3A6B95 for ; Fri, 23 May 2008 09:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.503 X-Spam-Level: X-Spam-Status: No, score=-62.503 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FORGED_IMS_HTML=2.264, FORGED_MUA_IMS=0.451, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_FONT_LOW_CONTRAST=0.124, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MIME_HTML_ONLY_MULTI=0.001, MPART_ALT_DIFF=0.739, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, SARE_SPOOF_COM2COM=2.536, SPOOF_COM2OTH=2.044, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13zYKCKaU8PL for ; Fri, 23 May 2008 09:26:21 -0700 (PDT) Received: from host210-226-static.183-80-b.business.telecomitalia.it (host210-226-static.183-80-b.business.telecomitalia.it [80.183.226.210]) by core3.amsl.com (Postfix) with SMTP id A1AAF3A6CBF for ; Fri, 23 May 2008 09:26:20 -0700 (PDT) Received: from dig.com (unknown [84.92.128.112]) by getcyberhost.com with SMTP id BNHFWJMUL8 for ; Fri, 23 May 2008 12:26:23 -0500 Received: from yule.freeserve.co.uk (freeserve.co.uk.begom.com [131.157.91.232]) by alakmalak.com with SMTP id 7IQBX1ODYT for ; Fri, 23 May 2008 18:19:23 +0100 From: "Google AdWords" To: "Webdav-archive" Subject: Google AdWords Account Verification Email User-Agent: Internet Mail Service (5.5.2650.21) X-Mailer: Internet Mail Service (5.5.2650.21) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--DZhgx2baxobgr25" Message-Id: <20080523162620.A1AAF3A6CBF@core3.amsl.com> Date: Fri, 23 May 2008 09:26:20 -0700 (PDT) ----DZhgx2baxobgr25 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Dear Google AdWords customer!

In order to confirm your contact details, please click the link below:

http://www.google.com/accounts/VE/?service=adwords&c=5442532629924704261867281344531760501381679485205349467415158&id=617877017037783

This should take you directly to the Google AdWords Form.

Thank you for choosing AdWords. We look forward to providing you with the most effective advertising available.

Sincerely,

The Google AdWords Team

------------------------

0x668, 0x09, 0x23649010, 0x98797567, 0x3247, 0x5, 0x73546670, 0x84 source, close, close, DLY6, 1J18, R2Q 0x5844, 0x3274, 0x31592612, 0x412, 0x7569, 0x26, 0x5809, 0x79, 0x7377, 0x330, 0x70 534434261424344265023763177 start: 0x39865857, 0x09691359, 0x91, 0x2135, 0x0, 0x258, 0x3, 0x1824, 0x31507664, 0x5, 0x883, 0x89, 0x70621242, 0x92, 0x65 0x7661, 0x065, 0x71, 0x60, 0x243, 0x1, 0x818, 0x37, 0x04915532, 0x91385322, 0x4, 0x46998452 update: 0x900, 0x178, 0x145, 0x810, 0x4, 0x75, 0x475, 0x0332, 0x1 FPPA: 0x77518585, 0x841, 0x3198, 0x8, 0x660, 0x38048553, 0x386, 0x066, 0x1 0x38600597, 0x181, 0x113, 0x0861, 0x0114 KPSU: 0x787, 0x3460, 0x66, 0x028, 0x4096, 0x3020, 0x4, 0x5, 0x07093193

close: 0x7, 0x1410, 0x9466, 0x10312980, 0x711 0x453, 0x566, 0x3, 0x84, 0x356, 0x17387191, 0x6472, 0x4, 0x628 0x88, 0x3, 0x46290611, 0x92207185, 0x3, 0x733, 0x44966938, 0x9 hex source C53N I2W VHE. function: 0x04687664, 0x9, 0x9983, 0x9, 0x92065466, 0x4, 0x37836901, 0x68319307, 0x5384, 0x2, 0x096 54051373317534579449457762 XVQF: 0x7887, 0x68, 0x0, 0x463, 0x8, 0x0, 0x836, 0x6, 0x07 engine, dec, close, serv, file, OS6, start, source, tmp. 0x843, 0x7, 0x10 0x90, 0x9085, 0x73003690, 0x94363471, 0x61576824, 0x7619, 0x913, 0x917, 0x52786488, 0x82, 0x53673597, 0x348, 0x9, 0x7245 engine: 0x38965746

include: 0x0, 0x8, 0x27807931, 0x52270604, 0x23550546, 0x134, 0x3, 0x95, 0x80, 0x5742, 0x41, 0x228, 0x85053778, 0x6822, 0x65779384 0x9, 0x5132, 0x5427, 0x0591, 0x7750, 0x83, 0x5679, 0x9192, 0x157, 0x2847, 0x9262, 0x9, 0x977, 0x49817707 4L0: 0x76, 0x12588667, 0x29, 0x4, 0x55, 0x2245, 0x558 engine: 0x12, 0x25, 0x1, 0x112, 0x51365881, 0x8891, 0x1968, 0x88 stack, IMFR, JGS4, 365L, PP5. exe: 0x91635011, 0x08 0x01, 0x39 0x28 tmp, KPAY, tmp, cvs, interface, 9SR, PGS, XQQ. 0x532, 0x03421075, 0x2, 0x45891105, 0x6, 0x379, 0x9, 0x516, 0x104, 0x56807786, 0x937, 0x61, 0x240, 0x5563, 0x729 7023225090

913956932395562017351470x64569633, 0x200, 0x74, 0x35, 0x8, 0x3747, 0x25, 0x663, 0x4, 0x88, 0x12841856, 0x26586074 0x988, 0x331, 0x763, 0x70 0x0, 0x8, 0x25235512, 0x7, 0x58, 0x6466, 0x988

----DZhgx2baxobgr25-- From w3c-dist-auth-request@listhub.w3.org Fri May 23 09:31:48 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBC33A6CAA for ; Fri, 23 May 2008 09:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfxgjyDopbnc for ; Fri, 23 May 2008 09:31:48 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id E1C7A3A6A29 for ; Fri, 23 May 2008 09:31:47 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzaAQ-0002Q6-P5 for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 16:30:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaAQ-0002PS-6P for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 16:30:54 +0000 Received: from daboo.name ([151.201.22.177]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaAH-0000pl-Di for w3c-dist-auth@w3.org; Fri, 23 May 2008 16:30:54 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9190A7B4C96; Fri, 23 May 2008 12:30:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hijsiqx-AriG; Fri, 23 May 2008 12:30:16 -0400 (EDT) Received: from [17.224.23.232] (unknown [17.224.23.232]) by daboo.name (Postfix) with ESMTP id 748D17B4C8E; Fri, 23 May 2008 12:30:14 -0400 (EDT) Date: Fri, 23 May 2008 09:30:11 -0700 From: Cyrus Daboo To: Julian Reschke , =?UTF-8?Q?Wilfredo_S=C3=A1nchez_Vega?= cc: Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' Message-ID: <4E2AF01606EB8BD91616EBC1@ninevah.local> In-Reply-To: <4836EF5D.6040403@gmx.de> References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> <4836A631.7030909@gmx.de> <4836EF5D.6040403@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: lisa.w3.org 1JzaAH-0000pl-Di 3c169ca963abeedb3f52bdff16f65822 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12867 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 16:30:54 +0000 Hi Julian, --On May 23, 2008 6:22:53 PM +0200 Julian Reschke wrote: >>> (*) Shouldn't that be "DAV:current-user-principal-URL", by the way? >> >> I think it should be if we can require that it be the same as the >> DAV:principal-URL property on the principal resource, but Cyrus argued >> that the name should emphasize that it provides access to a resource >> that can yield further information about the current principal. > > Hm, whether we say "resource" or "URL" should not depend on that, but > what is in the value of the property. And it is a URL, after all. Well then, we could use: DAV:current-user-principal-resource-URL Which could hold the record for the longest property name :-) -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Fri May 23 09:50:33 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDB03A6B3B for ; Fri, 23 May 2008 09:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwRyjepJpo-x for ; Fri, 23 May 2008 09:50:33 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 212023A6A29 for ; Fri, 23 May 2008 09:50:33 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Jza5W-0007s4-1q for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 16:25:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jza5V-0007rQ-Dr for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 16:25:49 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Jza5M-0000Yi-1w for w3c-dist-auth@w3.org; Fri, 23 May 2008 16:25:49 +0000 Received: (qmail invoked by alias); 23 May 2008 16:25:05 -0000 Received: from mnsr-d9b8d68e.pool.mediaWays.net (EHLO [217.184.214.142]) [217.184.214.142] by mail.gmx.net (mp017) with SMTP; 23 May 2008 18:25:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/hTgRY9P3hrvZ7w+hFAymi0EojKP7fU2qD4+0cTP Fpl7ZpBqkJcjKF Message-ID: <4836EF5D.6040403@gmx.de> Date: Fri, 23 May 2008 18:22:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Cyrus Daboo , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> <4836A631.7030909@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1Jza5M-0000Yi-1w 8b8b5b7dd899e9208a8066fa766c262b X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12866 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 16:25:50 +0000 Wilfredo Sánchez Vega wrote: > > On May 23, 2008, at 4:10 AM, Julian Reschke wrote: >> OK, let's assume a server that has only one URI per principal, and >> that URI is a mailto URI.\ > > ...but that's not allowed; a server is required to expose at least one > http(s) scheme URL for each principal. It's just not required (we > think) that this be the one in the DAV:principal-URL property; it might > one of the alternate URIs. Yes. It was just a thought experiment. >> (*) Shouldn't that be "DAV:current-user-principal-URL", by the way? > > I think it should be if we can require that it be the same as the > DAV:principal-URL property on the principal resource, but Cyrus argued > that the name should emphasize that it provides access to a resource > that can yield further information about the current principal. Hm, whether we say "resource" or "URL" should not depend on that, but what is in the value of the property. And it is a URL, after all. BR, Julian From w3c-dist-auth-request@listhub.w3.org Fri May 23 09:54:27 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1B028C2A9 for ; Fri, 23 May 2008 09:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgDNk9uvPJAv for ; Fri, 23 May 2008 09:54:26 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 350EF3A6A29 for ; Fri, 23 May 2008 09:54:26 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzaBc-0002zN-DH for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 16:32:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaBY-0002oM-HR for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 16:32:04 +0000 Received: from daboo.name ([151.201.22.177]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaBO-0000tu-Vb for w3c-dist-auth@w3.org; Fri, 23 May 2008 16:32:03 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 56B187B4CCB; Fri, 23 May 2008 12:31:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai+vEhwE76+B; Fri, 23 May 2008 12:31:27 -0400 (EDT) Received: from [17.224.23.232] (unknown [17.224.23.232]) by daboo.name (Postfix) with ESMTP id B977E7B4CC4; Fri, 23 May 2008 12:31:25 -0400 (EDT) Date: Fri, 23 May 2008 09:31:23 -0700 From: Cyrus Daboo To: Julian Reschke cc: =?UTF-8?Q?Wilfredo_S=C3=A1nchez_Vega?= , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' Message-ID: <823B3D8F533BD1D99547B72B@ninevah.local> In-Reply-To: <4836EEDD.2080609@gmx.de> References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> <4836A631.7030909@gmx.de> <4F26E774AC04F0C606AFCECD@ninevah.local> <4836EEDD.2080609@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: lisa.w3.org 1JzaBO-0000tu-Vb 06ed13bf0ca69872039cbd93258a0c15 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12868 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 16:32:08 +0000 Hi Julian, --On May 23, 2008 6:20:45 PM +0200 Julian Reschke wrote: >> Now, WebDAV ACL makes it clear (first paragraph of Section 2) that one >> of DAV:principal-URL or DAV:alternate-URI-set MUST contain a URL to a >> principal resource (http/https). So DAV:current-user-principal-resource >> is just that value. DAV:principal-URL can therefore be any URI scheme >> without affecting that. > > OK, so the proposal for DAV:current-user-principal-URL^H^H^Hresource > would work independently of the other issue, right? Yes. Whether or not DAV:principal-URL has to be http or can be something else would be irrelevant. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Fri May 23 09:56:18 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FBB28C2CD for ; Fri, 23 May 2008 09:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHtfSj2UNg4G for ; Fri, 23 May 2008 09:56:17 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 85B7628C2CA for ; Fri, 23 May 2008 09:56:17 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzaYN-0004n4-Lc for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 16:55:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaYM-0004mQ-T4 for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 16:55:38 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaY9-0002B0-9L for w3c-dist-auth@w3.org; Fri, 23 May 2008 16:55:38 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 6A9B22CA5CD8; Fri, 23 May 2008 09:54:51 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 554142808B; Fri, 23 May 2008 09:54:51 -0700 (PDT) X-AuditID: 1180711d-a8b91bb000000ed7-2c-4836f6db0235 Received: from pucca.apple.com (pucca.apple.com [17.224.20.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id 291C328085; Fri, 23 May 2008 09:54:51 -0700 (PDT) Cc: Cyrus Daboo , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' Message-Id: From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= To: Julian Reschke In-Reply-To: <4836EEDD.2080609@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 23 May 2008 09:54:50 -0700 References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> <4836A631.7030909@gmx.de> <4F26E774AC04F0C606AFCECD@ninevah.local> <4836EEDD.2080609@gmx.de> X-Mailer: Apple Mail (2.924) X-Brightmail-Tracker: AAAAAA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: lisa.w3.org 1JzaY9-0002B0-9L 75dfd0a5c45a7a7327cc02f31b7d82f2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12870 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 16:55:39 +0000 On May 23, 2008, at 9:20 AM, Julian Reschke wrote: >> Now, WebDAV ACL makes it clear (first paragraph of Section 2) that >> one of DAV:principal-URL or DAV:alternate-URI-set MUST contain a >> URL to a principal resource (http/https). So DAV:current-user- >> principal-resource is just that value. DAV:principal-URL can >> therefore be any URI scheme without affecting that. > > OK, so the proposal for DAV:current-user-principal-URL^H^H^Hresource > would work independently of the other issue, right? Ah, yes. Though if you want to use the DAV:current-user-principal- URL^H^H^Hresource property to fine the URL you can use for yourself in ACEs, if we require that it matched DAV:principal-URL on the principal resources, you can get that info in one request instead of two. I also get the feeling that having servers always vend the "canonical" DAV:principal-URL URI for the principal rather than being allowed to vend any of the alternates will avoid problems down the road, for the same reason that it is necessary that there be a canonical URL in the first place. But that's arguably a best- practices thing, not a necessity. But it's not possible to rely on if specs don't require it... -wsv From w3c-dist-auth-request@listhub.w3.org Fri May 23 09:59:12 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E29728C2E1 for ; Fri, 23 May 2008 09:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlJoQBg4ICLF for ; Fri, 23 May 2008 09:59:11 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 7F07328C2E8 for ; Fri, 23 May 2008 09:59:11 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Jzaaa-00057x-5D for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 16:57:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaaZ-00057J-HL for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 16:57:55 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaaP-0002LM-73 for w3c-dist-auth@w3.org; Fri, 23 May 2008 16:57:54 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 733F62DF513B; Fri, 23 May 2008 09:57:13 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 5256F464002; Fri, 23 May 2008 09:57:13 -0700 (PDT) X-AuditID: 11807135-aa1bcbb000000d04-7a-4836f7692544 Received: from pucca.apple.com (pucca.apple.com [17.224.20.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay12.apple.com (Apple SCV relay) with ESMTP id 3B63D420002; Fri, 23 May 2008 09:57:13 -0700 (PDT) Cc: Julian Reschke , Geoffrey M Clemm , acl@webdav.org, Konstantin Breu , 'WebDAV' Message-Id: From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= To: Cyrus Daboo In-Reply-To: <4E2AF01606EB8BD91616EBC1@ninevah.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 23 May 2008 09:57:13 -0700 References: <88045FA6253BCEB763E06402@caldav.corp.apple.com> <48342AAD.5010404@gmx.de> <4836A631.7030909@gmx.de> <4836EF5D.6040403@gmx.de> <4E2AF01606EB8BD91616EBC1@ninevah.local> X-Mailer: Apple Mail (2.924) X-Brightmail-Tracker: AAAAAA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: lisa.w3.org 1JzaaP-0002LM-73 20c6fa466632084505d03c0f8794d953 X-Original-To: w3c-dist-auth@w3.org Subject: Re: AW: DAV:principal-URL Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12871 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 16:57:56 +0000 On May 23, 2008, at 9:30 AM, Cyrus Daboo wrote: > DAV:current-user-principal-resource-URL URL implies resource (it's the "R"), so I'd just go with DAV:current-user-principal-URL, as Julian suggested. XML is chatty enough without being redundant in names. -wsv From w3c-dist-auth-request@listhub.w3.org Fri May 23 10:04:49 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BF23A6CA5 for ; Fri, 23 May 2008 10:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.241 X-Spam-Level: X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=1.358, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyODvWee2YXa for ; Fri, 23 May 2008 10:04:48 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id C5C7A3A6C7D for ; Fri, 23 May 2008 10:04:47 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzaHI-0006Ox-6q for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 16:38:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzaHH-0006OJ-K4 for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 16:37:59 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1JzaH7-0001Hr-5Z for w3c-dist-auth@w3.org; Fri, 23 May 2008 16:37:59 +0000 Received: (qmail invoked by alias); 23 May 2008 16:37:09 -0000 Received: from mnsr-d9b8d68e.pool.mediaWays.net (EHLO [217.184.214.142]) [217.184.214.142] by mail.gmx.net (mp032) with SMTP; 23 May 2008 18:37:09 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX197wmMl2K17EgEStFF0Loy0eXZoSb8lVNnS+cX/bM W/JC6gVY4mXwTY Message-ID: <4836F223.9090608@gmx.de> Date: Fri, 23 May 2008 18:34:43 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: <47DBAB30.1060306@gmx.de> <200805230921.06408.simon.perreault@viagenie.ca> <1211549806.6184.2.camel@henrik-desktop> <200805230950.14596.simon.perreault@viagenie.ca> <1211551043.6184.7.camel@henrik-desktop> <4836CFDE.80403@gmx.de> <4836E8E8.6040804@onlinehome.de> In-Reply-To: <4836E8E8.6040804@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1JzaH7-0001Hr-5Z 88047e979b3ec8e4a8b74af0d5e1218c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12869 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 16:38:00 +0000 Werner Baumann wrote: >> It wasn't intentional. As far as I recall, we lost the first paragraph >> without considering compliance. > > If it was not intentional, it should go in the Errata document to avoid > confusion. Well, go on and report the erratum. >> In practice I think it doesn't make any difference at all. >> >> If a server vendor can't implement support for creating collections, >> he/she simply won't. A 403 always was possible, RFC4918 now also >> allows 405. >> >> What difference does this make in practice? > > 405 was allowed in RFC 2518 too. HTTP/1.1 also knows 501 Not Implemented. > > RFC 2616: > > 10.5.2 501 Not Implemented > The server does not support the functionality required to fulfill > the request. This is the appropriate response when the server does > not recognize the request method and is not capable of supporting > it for any resource. > > RFC 2518/4918: > > 403 (Forbidden) - This indicates at least one of two > conditions: 1) the server does not allow the creation of collections > at the given location in its namespace, or 2) the parent collection > of the Request-URI exists but cannot accept members. > > 405 (Method Not Allowed) - MKCOL can only be executed on a > deleted/non-existent resource. > > No difference in practice? Are clients supposed not to care about these > different status codes? Again, what difference does it make *in practice*??? > A server, that does not implement MKCOL, is not compliant according RFC > 2616, but is compliant according RFC 4918. No difference in practice? Yes, exactly. > I have to concede: I never saw a compliant WebDAV-server. So does it > make a difference in practice, whether there is a standard at all? Not sure what you're trying to say. There are many ways how a server can refuse to do MKCOL. It can always claim "forbidden", it can say "not implemented" etc. In practice it means the client won't be able to create collections. BR, Julian From w3c-dist-auth-request@listhub.w3.org Fri May 23 13:59:07 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8709F3A6B79 for ; Fri, 23 May 2008 13:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkuHjym+iTIT for ; Fri, 23 May 2008 13:59:06 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 9F4443A69AC for ; Fri, 23 May 2008 13:59:06 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzeKg-0008N4-JM for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 20:57:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzeKf-0008MG-7K for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 20:57:45 +0000 Received: from moutng.kundenserver.de ([212.227.126.187]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzeKW-0005Eo-Ek for w3c-dist-auth@w3.org; Fri, 23 May 2008 20:57:44 +0000 Received: from [84.187.13.229] (p54BB0DE5.dip0.t-ipconnect.de [84.187.13.229]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1JzeJy0qJx-0004MT; Fri, 23 May 2008 22:57:02 +0200 Message-ID: <48372F96.7090902@onlinehome.de> Date: Fri, 23 May 2008 22:56:54 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: %3C4836F223.9090608@gmx.de%3E Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/tJ0uIfiSEM7KwM5Orth5k63QSjYPfJFJfYRd ppT8npi+fx3FzVGlFIZwv8dhZDlCJfeDIQS9XLxo3M3ORljsE8 2IDPhRDzPHtSiU8/LajEw== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1JzeKW-0005Eo-Ek e471d5165341a2d209c3dddcd061e4cd X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12872 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 20:57:46 +0000 Julian Reschke wrote: > There are many ways how a server can refuse to do MKCOL. It can > always claim "forbidden", it can say "not implemented" etc. > > In practice it means the client won't be able to create collections. So we need only two status codes in HTTP: success, no success. Ever occurred to you, that an error code should inform about the reason of the failure and that this reason makes a difference in practice? 403 says, the server can create collections, but it will not create *this* collection. 501 says, the server is not able to create collections at all. Can't you imagine, that clients and users might react differently in this two cases? Never seen a windows-user, completely mixing up the system configuration, just because of an idiotic, misleading error message? RFC 4918 has silently removed the requirement for servers to support MKCOL. This (together with compliance class 3) has lead to confusion (see this thread). But it does not matter in practice? Will it not effect the development of clients, whether they can trust in support of MKCOL by all compliant servers? They can always decide to not support badly broken servers, but they can hardly explain why they will not support compliant ones. If you buy a WebDAV-server from a vendor and later notice it does not support MKCOL. Does it matter whether this is standard compliant? Was the requirement for supporting MKCOL removed by intention or by an editorial mistake. RFC 4918 lists three contributors and one author. One of them (Julian Reschke) says "It wasn't intentional". There is an Errata document with three entries, all by Julian Reschke. But unintentional removal of a WebDAV-method from the requirements is not worth an entry in Errata, because it does not matter in practice. I believe internet standards should be taken more seriously. Werner From w3c-dist-auth-request@listhub.w3.org Fri May 23 14:34:18 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEE328C320 for ; Fri, 23 May 2008 14:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TBfrXNrdlE5 for ; Fri, 23 May 2008 14:34:17 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B268128C323 for ; Fri, 23 May 2008 14:34:17 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzetM-0002po-K6 for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 May 2008 21:33:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzetL-0002pA-KS for w3c-dist-auth@listhub.w3.org; Fri, 23 May 2008 21:33:35 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzetA-0002Ve-VQ for w3c-dist-auth@w3.org; Fri, 23 May 2008 21:33:34 +0000 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8CB6F142217; Fri, 23 May 2008 14:32:56 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org 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 gbu5mnLCUq+E; Fri, 23 May 2008 14:32:44 -0700 (PDT) Received: from [10.1.1.149] (corp.collabrx.com [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2C026142213; Fri, 23 May 2008 14:32:44 -0700 (PDT) Cc: w3c-dist-auth@w3.org Message-Id: From: Lisa Dusseault To: Werner Baumann In-Reply-To: <48372F96.7090902@onlinehome.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 23 May 2008 14:32:41 -0700 References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1JzetA-0002Ve-VQ 638512c40c4d418adf343d90b3dcf06c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12873 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 May 2008 21:33:36 +0000 Hi, The omission of a MUST or REQUIRED statement for MKCOL itself was unintentional as far as I can remember. There was certainly no intent to make MKCOL optional -- I think that other sections, luckily, make that obvious even if it's not explicit. BTW, I like summary sections that list every major feature which is required to be implemented, and every major feature that is optional -- they make it easy to ensure that the document is clear about every feature. We did that in CalDAV . If I entered an errata I could probably also approve it as document author AND as AD, but that might be in bad taste. I appreciate your injunction to take Internet standards more seriously, but I'm afraid you really are preaching to the choir! Thanks, Lisa On May 23, 2008, at 1:56 PM, Werner Baumann wrote: > > Julian Reschke wrote: > > There are many ways how a server can refuse to do MKCOL. It can > > always claim "forbidden", it can say "not implemented" etc. > > > > In practice it means the client won't be able to create collections. > > So we need only two status codes in HTTP: success, no success. > Ever occurred to you, that an error code should inform about the > reason of the failure and that this reason makes a difference in > practice? > > 403 says, the server can create collections, but it will not create > *this* collection. > 501 says, the server is not able to create collections at all. > > Can't you imagine, that clients and users might react differently in > this two cases? Never seen a windows-user, completely mixing up the > system configuration, just because of an idiotic, misleading error > message? > > > RFC 4918 has silently removed the requirement for servers to support > MKCOL. This (together with compliance class 3) has lead to confusion > (see this thread). But it does not matter in practice? > Will it not effect the development of clients, whether they can > trust in support of MKCOL by all compliant servers? They can always > decide to not support badly broken servers, but they can hardly > explain why they will not support compliant ones. > If you buy a WebDAV-server from a vendor and later notice it does > not support MKCOL. Does it matter whether this is standard compliant? > > Was the requirement for supporting MKCOL removed by intention or by > an editorial mistake. RFC 4918 lists three contributors and one > author. One of them (Julian Reschke) says "It wasn't intentional". > There is an Errata document with three entries, all by Julian > Reschke. But unintentional removal of a WebDAV-method from the > requirements is not worth an entry in Errata, because it does not > matter in practice. > > I believe internet standards should be taken more seriously. > > Werner > From w3c-dist-auth-request@listhub.w3.org Sat May 24 00:51:42 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B52D3A68E7 for ; Sat, 24 May 2008 00:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.435 X-Spam-Level: X-Spam-Status: No, score=-5.435 tagged_above=-999 required=5 tests=[AWL=1.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30zho9FoEvNs for ; Sat, 24 May 2008 00:51:41 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 639DB3A68D8 for ; Sat, 24 May 2008 00:51:41 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzoW1-0000uZ-Mp for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 May 2008 07:50:09 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzoVz-0000to-Vl for w3c-dist-auth@listhub.w3.org; Sat, 24 May 2008 07:50:08 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1JzoVn-0005P5-I1 for w3c-dist-auth@w3.org; Sat, 24 May 2008 07:50:07 +0000 Received: (qmail invoked by alias); 24 May 2008 07:49:02 -0000 Received: from mnsr-d9b8d691.pool.mediaWays.net (EHLO [217.184.214.145]) [217.184.214.145] by mail.gmx.net (mp039) with SMTP; 24 May 2008 09:49:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19br2sepaVbi6eGkNrida9dW12nCh0Ahn975QD/Km 0XgnJThWUZozdw Message-ID: <4837C83C.6030204@gmx.de> Date: Sat, 24 May 2008 09:48:12 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> In-Reply-To: <48372F96.7090902@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1JzoVn-0005P5-I1 543eb6fef987d96e8dae3b28d3595cc0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12874 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 24 May 2008 07:50:09 +0000 Werner Baumann wrote: > > Julian Reschke wrote: > > There are many ways how a server can refuse to do MKCOL. It can > > always claim "forbidden", it can say "not implemented" etc. > > > > In practice it means the client won't be able to create collections. > > So we need only two status codes in HTTP: success, no success. No, we need many more. > Ever occurred to you, that an error code should inform about the reason > of the failure and that this reason makes a difference in practice? > > 403 says, the server can create collections, but it will not create > *this* collection. > 501 says, the server is not able to create collections at all. Yes. So I'd say that it's better if a server actually states 501 when it can't create *any* collections. > Can't you imagine, that clients and users might react differently in > this two cases? Never seen a windows-user, completely mixing up the > system configuration, just because of an idiotic, misleading error message? Is this a rhetoric question? > RFC 4918 has silently removed the requirement for servers to support > MKCOL. This (together with compliance class 3) has lead to confusion > (see this thread). But it does not matter in practice? > Will it not effect the development of clients, whether they can trust in > support of MKCOL by all compliant servers? They can always decide to not > support badly broken servers, but they can hardly explain why they will > not support compliant ones. The point is that it's not the spec language that will influence the decision whether to allow creation of collections or not. If a server has a data model that supports collections, it will implement MKCOL. Otherwise it won't. No matter what the spec says. So if you want to expose a set of HTTP resources for authoring, and you can support all of WebDAV L2 and L3, *except* creating new collections, what would you return in the DAV: response header upon OPTIONS? I bet you'd claim support for MKCOL, return level 3, and then fail the request if somebody tries to MKCOL anyway. > If you buy a WebDAV-server from a vendor and later notice it does not > support MKCOL. Does it matter whether this is standard compliant? So how exactly is it an improvement to the client when the server claims it can do MKCOL, but always returns 403? That would be compliant with RFC2518, but not helpful it all. In practice, there are many things that RFC2518 and RFC4918 do not even talk about, but will affect conformance and interoperability: - the set of characters allowed in path segments (think Unicode normalization) - the maximum length of a path segment - whether or not path segments are case-sensitive - the maximum number of path segments - the maximum total lenth - size constraints for property values - ... One key feature of HTTP and protocols based on HTTP is that messages and responses are self-descriptive, and that close coupling (as in WS-*) is avoided. Yes, it's always nice to know upfront if a server is going to allow something (being it out-of-band by spec, by introspection (OPTIONS), whatever...). But in practice, a client will have to deal with unexpected errors (and yes, good status codes help with that). > Was the requirement for supporting MKCOL removed by intention or by an > editorial mistake. RFC 4918 lists three contributors and one author. One > of them (Julian Reschke) says "It wasn't intentional". There is an > Errata document with three entries, all by Julian Reschke. But > unintentional removal of a WebDAV-method from the requirements is not > worth an entry in Errata, because it does not matter in practice. I did say it should be in the errata. Please raise it. > I believe internet standards should be taken more seriously. Nit: RFC4918 is a Proposed Standard. Not an "Internet Standard", at least not in RFC speak. I totally agree that IETF specs should be taken seriously. Believe me, if I didn't I certainly wouldn't spend so much time trying to revise them. BR, Julian From w3c-dist-auth-request@listhub.w3.org Sat May 24 00:58:13 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432FF3A68FE for ; Sat, 24 May 2008 00:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbsHtKCmzuup for ; Sat, 24 May 2008 00:58:12 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 75EB63A68D8 for ; Sat, 24 May 2008 00:58:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzodQ-0002EO-AS for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 May 2008 07:57:48 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzodP-0002Dj-IQ for w3c-dist-auth@listhub.w3.org; Sat, 24 May 2008 07:57:47 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Jzod8-0005xR-TS for w3c-dist-auth@w3.org; Sat, 24 May 2008 07:57:46 +0000 Received: (qmail invoked by alias); 24 May 2008 07:56:51 -0000 Received: from mnsr-d9b8d691.pool.mediaWays.net (EHLO [217.184.214.145]) [217.184.214.145] by mail.gmx.net (mp056) with SMTP; 24 May 2008 09:56:51 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+2QTsjPl228Z61RXwFfwRUSxJezFCiHW2oJJTKqj dUFnVe50znb9Xv Message-ID: <4837CA32.9040905@gmx.de> Date: Sat, 24 May 2008 09:56:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Lisa Dusseault CC: Werner Baumann , w3c-dist-auth@w3.org References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.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 X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Jzod8-0005xR-TS 562f1940851528a686fe89c13c6d2222 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12875 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 24 May 2008 07:57:48 +0000 Lisa Dusseault wrote: > ... > If I entered an errata I could probably also approve it as document > author AND as AD, but that might be in bad taste. > > I appreciate your injunction to take Internet standards more seriously, > but I'm afraid you really are preaching to the choir! > ... Speaking of which, it would be nice if the errata that *have* been reported previously would get verified at some point of time (for now, only of of the three at was). BR, Julian From w3c-dist-auth-request@listhub.w3.org Sat May 24 03:40:53 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086223A6994 for ; Sat, 24 May 2008 03:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc46dhxTIyMQ for ; Sat, 24 May 2008 03:40:52 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2849B3A67EB for ; Sat, 24 May 2008 03:40:51 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzrA0-00083r-Fw for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 May 2008 10:39:36 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jzr9z-00083D-4W for w3c-dist-auth@listhub.w3.org; Sat, 24 May 2008 10:39:35 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jzr9n-0005dn-IX for w3c-dist-auth@w3.org; Sat, 24 May 2008 10:39:34 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 8B3ACF782FA for ; Sat, 24 May 2008 12:39:29 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id E2D0EF7C20E for ; Sat, 24 May 2008 12:37:50 +0200 (CEST) Message-Id: From: Helge Hess To: WebDAV In-Reply-To: <48372F96.7090902@onlinehome.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 24 May 2008 12:37:10 +0200 References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Jzr9n-0005dn-IX 2ce3f4c946ec87089ae0b8ce73e5395a X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12876 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 24 May 2008 10:39:36 +0000 On 23.05.2008, at 22:56, Werner Baumann wrote: > 403 says, the server can create collections, but it will not create > *this* collection. > 501 says, the server is not able to create collections at all. Just for completeness, I think 501 just says that the collection MKCOL was called on does not support MKCOL. Other collections on the same server might support that method. I think Werner's point is that 403 has specific semantics and I would agree. To me 403 implies that the user could potentially create collections with better credentials. While 501 signals that the server really can't support MKCOL. That _is_ relevant for the error message reported by the client. IMHO the confusion started when Julian suggested that a server should return 403 if its a "read-only CardDAV implementation". Note the 'read- only _implementation_'. I think returning 403 would be quite wrong in this case, it should definitely return 501. As mentioned, practial consequences which immediatly come to mind are: - misleading error message towards the user - pointless retries with other (higher level) credentials As far as I can see levels are just a really minor optimization on the operations a client might attempt (never attempt to LOCK if we already know its not level2, but then we have the method info in OPTIONS anyways?!). Maybe the spec puts too much emphasis on levels. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From w3c-dist-auth-request@listhub.w3.org Sat May 24 05:19:14 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2AA3A69B6 for ; Sat, 24 May 2008 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByGfxS+YqjP8 for ; Sat, 24 May 2008 05:19:13 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 601763A67DB for ; Sat, 24 May 2008 05:19:13 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Jzsh2-000810-HX for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 May 2008 12:17:48 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jzsh1-00080M-17 for w3c-dist-auth@listhub.w3.org; Sat, 24 May 2008 12:17:47 +0000 Received: from moutng.kundenserver.de ([212.227.126.183]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Jzsgq-0004Ic-SV for w3c-dist-auth@w3.org; Sat, 24 May 2008 12:17:46 +0000 Received: from [84.187.14.172] (p54BB0EAC.dip0.t-ipconnect.de [84.187.14.172]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1JzsgH1E1A-0007es; Sat, 24 May 2008 14:17:01 +0200 Message-ID: <48380733.6030606@onlinehome.de> Date: Sat, 24 May 2008 14:16:51 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> In-Reply-To: <4837C83C.6030204@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+I9EYbTxF6Gxk8u86x+L2g5LfYTQPvnie6Hxo Vn8BuLE8XJZA9k1uSIMn8D+IU3C8UIlieGnv5Hw3Kiy18eo52E j2r3DrBY4256+tITggbYA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: aji.w3.org 1Jzsgq-0004Ic-SV 7e14fef17056f0391881c5788ca85954 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12877 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 24 May 2008 12:17:48 +0000 Julian Reschke wrote: > Werner Baumann wrote: >> > If a server has a data model that supports collections, it will > implement MKCOL. Otherwise it won't. No matter what the spec says. > > So if you want to expose a set of HTTP resources for authoring, and you > can support all of WebDAV L2 and L3, *except* creating new collections, > what would you return in the DAV: response header upon OPTIONS? > > I bet you'd claim support for MKCOL, return level 3, and then fail the > request if somebody tries to MKCOL anyway. > What was the bet about? A barrel of beer? You lost the bet. >> If you buy a WebDAV-server from a vendor and later notice it does not >> support MKCOL. Does it matter whether this is standard compliant? > > So how exactly is it an improvement to the client when the server claims > it can do MKCOL, but always returns 403? That would be compliant with > RFC2518, but not helpful it all. > It is not an improvement at all. In my opinion it would be fraud. A server that does not support creation of collections is *not* compliant with RFC 2518 (and, I hope, with RFC 4918 neither) and must not send a DAV-header at all. Hiding this none-compliance by misusing 403 makes things worse. This does not mean, that it is not allowed to create and use servers and clients, that do not meet all requirements of the standard (or the proposed standard), and therefore are not compliant. But these needs to be documented and server and clients will need out of band information about their capabilities to be set up properly. There will be no guarantee for interoperability with other clients or servers. These cases are outside the spec. Werner From w3c-dist-auth-request@listhub.w3.org Sat May 24 06:23:40 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717513A6816 for ; Sat, 24 May 2008 06:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7pN7ru25Osz for ; Sat, 24 May 2008 06:23:39 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 12ED03A68F5 for ; Sat, 24 May 2008 06:23:38 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzthW-0002Ao-IN for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 May 2008 13:22:22 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzthV-0002A5-6t for w3c-dist-auth@listhub.w3.org; Sat, 24 May 2008 13:22:21 +0000 Received: from ebed.etf.cuni.cz ([195.113.5.3]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzthL-0000yv-2A for w3c-dist-auth@w3.org; Sat, 24 May 2008 13:22:20 +0000 Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id m4ODKdHw030496; Sat, 24 May 2008 15:20:39 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id m4ODKdNi030492; Sat, 24 May 2008 15:20:39 +0200 Date: Sat, 24 May 2008 15:20:39 +0200 From: Petr Tomasek To: Werner Baumann , w3c-dist-auth@w3.org Message-ID: <20080524132039.GA23981@ebed.etf.cuni.cz> References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48380733.6030606@onlinehome.de> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.8.0.19; VDF: 7.0.4.85; host: ebed.etf.cuni.cz) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1JzthL-0000yv-2A ddc901da5ec1f28f866d7d2a4bb097a5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12878 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 24 May 2008 13:22:22 +0000 > >>If you buy a WebDAV-server from a vendor and later notice it does not > >>support MKCOL. Does it matter whether this is standard compliant? > > > >So how exactly is it an improvement to the client when the server claims > >it can do MKCOL, but always returns 403? That would be compliant with > >RFC2518, but not helpful it all. > > > > It is not an improvement at all. In my opinion it would be fraud. > A server that does not support creation of collections is *not* > compliant with RFC 2518 (and, I hope, with RFC 4918 neither) and must > not send a DAV-header at all. Hiding this none-compliance by misusing > 403 makes things worse. But every webdav client I've seen REQUIRES the DAV-header to operate on an URL as on a WebDAV collection. So it means You would practically disalow any partial (e.g. a read-only) WebDAV implementation, even if it works correctly and the full-fledged functionality is not needed at all! > This does not mean, that it is not allowed to create and use servers and > clients, that do not meet all requirements of the standard (or the > proposed standard), and therefore are not compliant. But these needs to > be documented and server and clients will need out of band information > about their capabilities to be set up properly. There will be no > guarantee for interoperability with other clients or servers. These > cases are outside the spec. So the spec is wrong and insane if it doesn't allow for a partial implementation. Sorry. > Werner -- Petr Tomasek Jabber: butrus@jabbim.cz SIP: butrus@ekiga.net From w3c-dist-auth-request@listhub.w3.org Sat May 24 07:02:38 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10CC3A687C for ; Sat, 24 May 2008 07:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRKRVHMZrzMV for ; Sat, 24 May 2008 07:02:37 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 8DF7B3A67E5 for ; Sat, 24 May 2008 07:02:37 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzuJg-0003jw-Ld for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 May 2008 14:01:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzuJf-0003jG-FL for w3c-dist-auth@listhub.w3.org; Sat, 24 May 2008 14:01:47 +0000 Received: from jackpot-adsl.demon.co.uk ([80.177.236.105] helo=saraha.jackpot.uk.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzuJW-0007gJ-MK for w3c-dist-auth@w3.org; Sat, 24 May 2008 14:01:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by saraha.jackpot.uk.net (Postfix) with ESMTP id 5CAF02BD48 for ; Sat, 24 May 2008 15:01:12 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at saraha.jackpot.uk.net Received: from saraha.jackpot.uk.net ([127.0.0.1]) by localhost (saraha.jackpot.uk.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYZW0l+JJt6y for ; Sat, 24 May 2008 15:01:11 +0100 (BST) Received: from [192.168.101.11] (unknown [192.168.101.11]) by saraha.jackpot.uk.net (Postfix) with ESMTP for ; Sat, 24 May 2008 15:01:11 +0100 (BST) Message-ID: <48381FA6.30406@jackpot.uk.net> Date: Sat, 24 May 2008 15:01:10 +0100 From: Jack Cleaver User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> In-Reply-To: <20080524132039.GA23981@ebed.etf.cuni.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1JzuJW-0007gJ-MK c167bb82d53d46e8608748a8741d3279 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12879 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 24 May 2008 14:01:48 +0000 Petr Tomasek wrote: > > But every webdav client I've seen REQUIRES the DAV-header to operate > on an URL as on a WebDAV collection. So it means You would > practically disalow any partial (e.g. a read-only) WebDAV > implementation, even if it works correctly and the full-fledged > functionality is not needed at all! I don't see it that way. A partial implementation is one that doesn't implement the spec. A read-only implementation is one that implements the spec, but doesn't permit write operations. There is a variety of reasons why write operations might not be permitted by a compliant server. The client might not have sufficient privileges, or the operation might be permitted at some other location, or the repository might forbid all write operations for whatever reason. Or the server software might *by design* not allow write operations. It seems perfectly reasonable to assert that one supports MKCOL, but to then refuse to perform this operation in every case, giving an appropriate status-code. After all, if one *really* didn't support the operation, then one would return a 501. Supporting an operation doesn't imply performing it when it "should not" be performed. What "should not" means is determined by the implementor. > > So the spec is wrong and insane if it doesn't allow for a partial > implementation. Sorry. This is silly. A partial implementation of a spec is not an implementation at all (unless the spec explicitly provides for optional elements - in which case the implementation is arguably not a partial one). L1 (2518) says you MUST support MKCOL. That implies that a 501 is always an incorrect response from an L1(2518)-compliant server. Incidentally, there's nothing wrong with borrowing those parts of a spec that you need, and ignoring the rest; this will only cause problems if your software is expected to interact with other software that relies on proper compliance with that spec, and furthermore your software claims to be compliant when it isn't. -- Jack. From w3c-dist-auth-request@listhub.w3.org Sat May 24 09:16:12 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E8D3A6A4A for ; Sat, 24 May 2008 09:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z15db2uXI687 for ; Sat, 24 May 2008 09:16:06 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B87083A6A32 for ; Sat, 24 May 2008 09:16:05 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1JzwOP-0008WQ-Po for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 May 2008 16:14:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzwOO-0008Vm-RG for w3c-dist-auth@listhub.w3.org; Sat, 24 May 2008 16:14:48 +0000 Received: from moutng.kundenserver.de ([212.227.126.187]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1JzwOF-0004Eq-B2 for w3c-dist-auth@w3.org; Sat, 24 May 2008 16:14:48 +0000 Received: from [84.187.14.172] (p54BB0EAC.dip0.t-ipconnect.de [84.187.14.172]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1JzwNf0ZFV-0004Nw; Sat, 24 May 2008 18:14:04 +0200 Message-ID: <48383EC2.2000902@onlinehome.de> Date: Sat, 24 May 2008 18:13:54 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> In-Reply-To: <20080524132039.GA23981@ebed.etf.cuni.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18lsRlr4aXlJTzovb+rkPf3NMIWTz+ALblRQG3 qgs5U424n9Xpv5ygGagmDKS2+6pEyNVauGOQ57fNgTVreMZ63L HQ5IlID++U2i+oai0DI5A== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1JzwOF-0004Eq-B2 37894ae7b583a4a56ccfd1e005c66e4f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12880 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 24 May 2008 16:14:49 +0000 Petr Tomasek wrote: > But every webdav client I've seen REQUIRES the DAV-header to operate on > an URL as on a WebDAV collection. So it means You would practically disalow > any partial (e.g. a read-only) WebDAV implementation, even if it works > correctly and the full-fledged functionality is not needed at all! > What the hell is a "read-only WebDAV implementation"? WebD*A*V is about *Authoring*. There is no read-only authoring. Enabling write-operations is at the very heart of WebDAV. If any server cannot support it, it should not claim to do WebDAV. What you are talking about is an HTTP-Server with some extensions taken from WebDAV or maybe others. But what WebDAV-methods from RFC 4918 could a read-only server implement? PROPFIND, and nothing else. Please do not mix up two things: - servers that do not support certain required methods at all: they are simple not WebDAV-servers and should respond with status code 501 to such requests. - refusing requests on certain resources or under certain circumstances: this is allowed and treated with in the spec. Usually 4xx status codes are appropriate. But this implies, that the same kind of request can be successful for another resource or under other circumstances. BTW: 403 Forbidden is *not* related to authorization; that's 401. Werner From w3c-dist-auth-request@listhub.w3.org Sat May 24 13:17:20 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A168228C1B3 for ; Sat, 24 May 2008 13:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZh5kSTyx4xC for ; Sat, 24 May 2008 13:17:19 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 7412F28C1B0 for ; Sat, 24 May 2008 13:17:18 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K009E-0003zY-M9 for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 May 2008 20:15:24 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K009D-0003yu-Hc for w3c-dist-auth@listhub.w3.org; Sat, 24 May 2008 20:15:23 +0000 Received: from ebed.etf.cuni.cz ([195.113.5.3]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0090-0004UX-JV for w3c-dist-auth@w3.org; Sat, 24 May 2008 20:15:22 +0000 Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id m4OKDcaO020091; Sat, 24 May 2008 22:13:39 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id m4OKDcKb020089; Sat, 24 May 2008 22:13:38 +0200 Date: Sat, 24 May 2008 22:13:38 +0200 From: Petr Tomasek To: Werner Baumann , w3c-dist-auth@w3.org Message-ID: <20080524201338.GA14159@ebed.etf.cuni.cz> References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48383EC2.2000902@onlinehome.de> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.8.0.19; VDF: 7.0.4.87; host: ebed.etf.cuni.cz) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K0090-0004UX-JV 390909d44547b00e554b52d9255abb7e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12881 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 24 May 2008 20:15:24 +0000 On Sat, May 24, 2008 at 06:13:54PM +0200, Werner Baumann wrote: > > > Petr Tomasek wrote: > >But every webdav client I've seen REQUIRES the DAV-header to operate on > >an URL as on a WebDAV collection. So it means You would practically disalow > >any partial (e.g. a read-only) WebDAV implementation, even if it works > >correctly and the full-fledged functionality is not needed at all! > > > > What the hell is a "read-only WebDAV implementation"? WebD*A*V is about > *Authoring*. Sorry, but this is silly! According to such an interpretation one couldn't use e.g. the HTTP protocol for anything else, than a hypertext! Rather, the WebDAV is most commonly used as a network filesystem implemented over HTTP and as such it makes much sense to have a read-only filesystem. -- Petr Tomasek Jabber: butrus@jabbim.cz SIP: butrus@ekiga.net From w3c-dist-auth-request@listhub.w3.org Sun May 25 01:13:41 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F313A28B797 for ; Sun, 25 May 2008 01:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAqkpmOCb1Yg for ; Sun, 25 May 2008 01:13:38 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id ADF963A69FB for ; Sun, 25 May 2008 01:13:36 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0BKU-0007X8-Ug for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 08:11:46 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0BKT-0007WN-GW for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 08:11:45 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0BKI-0008JI-W7 for w3c-dist-auth@w3.org; Sun, 25 May 2008 08:11:44 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 76B9FF82906 for ; Sun, 25 May 2008 10:11:47 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 2B52BF82807 for ; Sun, 25 May 2008 10:11:47 +0200 (CEST) Message-Id: <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> From: Helge Hess To: WebDAV In-Reply-To: <48383EC2.2000902@onlinehome.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 25 May 2008 10:11:01 +0200 References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K0BKI-0008JI-W7 eb7d31c4d313634f25a671c8d6fe9e3b X-Original-To: w3c-dist-auth@w3.org Subject: 403/401 for access denied Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12882 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 08:11:46 +0000 On 24.05.2008, at 18:13, Werner Baumann wrote: > BTW: 403 Forbidden is *not* related to authorization; that's 401. You are right! Weird, I always got this wrong. (RFC 2616, 10.4.2/10.4.4 explicitly states what you say). Summary: even if the user is authenticated, one would reissue a 401 if access is denied to a resource. Which makes me wonder in what (real world) situations one would use 403 then. Actually in the real world having to send a 401 for access-denied will probably confuse almost any client. It will _clear_ authentication in almost any (in fact many webapps rely on that for the 401-logout-hack). Also: RFC 3744 contradicts with that? Eg it says (3. Privileges): http://webdav.org/specs/rfc3744.html#privileges 'Servers must report a 403 "Forbidden" error if access is denied' The whole RFC goes like this. I'm confused ;-/ Thanks, Helge From w3c-dist-auth-request@listhub.w3.org Sun May 25 02:17:09 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50FB3A6929 for ; Sun, 25 May 2008 02:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi3H-NWTJAc3 for ; Sun, 25 May 2008 02:17:08 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BEB513A6A51 for ; Sun, 25 May 2008 02:17:08 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0CKA-0007WF-PX for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 09:15:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0CK9-0007VZ-EX for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 09:15:29 +0000 Received: from moutng.kundenserver.de ([212.227.126.186]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0CK0-0007bv-1f for w3c-dist-auth@w3.org; Sun, 25 May 2008 09:15:29 +0000 Received: from [84.187.30.222] (p54BB1EDE.dip0.t-ipconnect.de [84.187.30.222]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1K0CJS0IXC-0004e7; Sun, 25 May 2008 11:14:46 +0200 Message-ID: <48392DFE.6080506@onlinehome.de> Date: Sun, 25 May 2008 11:14:38 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> <20080524201338.GA14159@ebed.etf.cuni.cz> In-Reply-To: <20080524201338.GA14159@ebed.etf.cuni.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19jbBKNtW/boKEIFFsPW7g72+0DXFgzmi16KDF SHsxU+rDpm/CkW+2px6cyal/+nBUHOBgExL4h1se02njBMtlJV /rHZReXptyeSrPGZd4Ttw== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K0CK0-0007bv-1f 5e793285388ad0b5cc59593148578394 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12883 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 09:15:30 +0000 Petr Tomasek wrote: > On Sat, May 24, 2008 at 06:13:54PM +0200, Werner Baumann wrote: >> What the hell is a "read-only WebDAV implementation"? WebD*A*V is about >> *Authoring*. > > Sorry, but this is silly! According to such an interpretation one > couldn't use e.g. the HTTP protocol for anything else, than a hypertext! > > Rather, the WebDAV is most commonly used as a network filesystem > implemented over HTTP and as such it makes much sense to have > a read-only filesystem. > WebDAV is not a network file-system and never was intended to be. Please read the documents, e.g. ftp://ftp.rfc-editor.org/in-notes/rfc2291.txt and ftp://ftp.rfc-editor.org/in-notes/rfc4918.txt I am maintaining a WebDAV-file-system (davfs2, which is not a network file-system but an intermediate solution for authoring tools without built-in WebDAV-support). My experience with this work tells me: It is impossible to cleanly map WebDAV-resources into a Unix-file-system. Though I am not really happy with RFC 4918, this point is not the fault of the specification, because it was never intended for this use. It has become common practice, to reuse existing protocols for new applications. That's OK. But when it turns out, that the chosen protocol does not really meet the requirements of this application, there is the bad habit of tweaking the original protocol, up to the point where it gets unusable for its original intention. This must stop. "preaching to the choir" again Werner From w3c-dist-auth-request@listhub.w3.org Sun May 25 02:56:21 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F983A6A93 for ; Sun, 25 May 2008 02:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhIxX+viqXH2 for ; Sun, 25 May 2008 02:56:20 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id E21383A6A8C for ; Sun, 25 May 2008 02:56:19 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0Cx1-0007wM-35 for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 09:55:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Cwz-0007vF-ON for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 09:55:38 +0000 Received: from moutng.kundenserver.de ([212.227.126.186]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Cwq-0008U4-MQ for w3c-dist-auth@w3.org; Sun, 25 May 2008 09:55:37 +0000 Received: from [84.187.30.222] (p54BB1EDE.dip0.t-ipconnect.de [84.187.30.222]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1K0CwL1GtS-0004bt; Sun, 25 May 2008 11:54:58 +0200 Message-ID: <48393770.7010206@onlinehome.de> Date: Sun, 25 May 2008 11:54:56 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: WebDAV References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> In-Reply-To: <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/92wkywxWg6FT589K610y7DvNLAgVSj8AxJdm 3F47eaUI15gUGAbHlKz+3RSUma2uBroGZIPDPFQ8KCQdkEg9jJ 9kg7lxTgAiTb9VCt81dxQ== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0Cwq-0008U4-MQ 04860149f9ca3dfe61c450502fc6b135 X-Original-To: w3c-dist-auth@w3.org Subject: Re: 403/401 for access denied Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12884 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 09:55:39 +0000 Helge Hess wrote: > Summary: even if the user is authenticated, one would reissue a 401 if > access is denied to a resource. Which makes me wonder in what (real > world) situations one would use 403 then. > Access restrictions based on IP-address might cause a 403, for instance. Basically: - 401 says: authenticate and the request will succeed - 403 says: denied, and authentication will not help. Actually, RFC 2616 says: 401 Unauthorized it is *not* "401 for access-denied" > Actually in the real world having to send a 401 for access-denied will > probably confuse almost any client. It will _clear_ authentication in > almost any (in fact many webapps rely on that for the 401-logout-hack). > I only know about HTTP-Basic- and HTTP-Digest-authentication. In this cases the client will include authentication information with every request. A 401 response includes information about the realm of authentication. A client will either repeat the request with authentication information included, or give up, if it can't authenticate for that realm. In practice: servers may require different authentication for different parts of their resources. A new request from the client may leave one realm of authentication and enter another one (e.g. some directory is only allowed for authenticated users; within this is an area only allowed for administrators). > Also: RFC 3744 contradicts with that? Eg it says (3. Privileges): > http://webdav.org/specs/rfc3744.html#privileges > > 'Servers must report a 403 "Forbidden" error if access is denied' > > The whole RFC goes like this. > I never cared about RFC 3744. But at first sight, this looks like not being related to HTTP-authentication, but to be specific to privileges, ACEs and whatsoever defined in RFC 3744. It probably only makes sense when read within this context. Werner From caban@golden.sk Sun May 25 05:22:59 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C064328C17B; Sun, 25 May 2008 05:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QTGjsIC18AH; Sun, 25 May 2008 05:22:53 -0700 (PDT) Received: from cm-85-152-181-205.telecable.es (cm-85-152-181-205.telecable.es [85.152.181.205]) by core3.amsl.com (Postfix) with SMTP id 4F1723A6ABC; Sun, 25 May 2008 05:22:44 -0700 (PDT) X-Originating-IP: 252.208.199.142 by smtp.85.152.181.205; Sun, 25 May 2008 08:22:48 -0500 Message-ID: From: "Kenton Haney" Reply-To: "Kenton Haney" To: vpim@ietf.org Subject: 15% off on two watches Date: Sun, 25 May 2008 08:22:48 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://www%2Esuppoenn%2Ecom/ From w3c-dist-auth-request@listhub.w3.org Sun May 25 08:41:47 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F04B3A6ADC for ; Sun, 25 May 2008 08:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.056 X-Spam-Level: X-Spam-Status: No, score=-6.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-tvlg1XPQFq for ; Sun, 25 May 2008 08:41:45 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id AE64B3A6AD9 for ; Sun, 25 May 2008 08:41:45 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0IKW-00061v-Ax for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 15:40:16 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0IKU-00061H-IW for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 15:40:15 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0IKJ-0007UP-Fm for w3c-dist-auth@w3.org; Sun, 25 May 2008 15:40:13 +0000 Received: (qmail invoked by alias); 25 May 2008 15:39:15 -0000 Received: from mnsr-d9b8d695.pool.mediaWays.net (EHLO [217.184.214.149]) [217.184.214.149] by mail.gmx.net (mp006) with SMTP; 25 May 2008 17:39:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/C/L1gnhzC8PEI6uZ7JWMUHmUtzgoJgtRq0zLh8j RqMN71JsoRHyjB Message-ID: <4838449C.805@gmx.de> Date: Sat, 24 May 2008 18:38:52 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.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 X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-1.6 X-W3C-Scan-Sig: aji.w3.org 1K0IKJ-0007UP-Fm 28133464153fd4866a203e5b816c8cd1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12885 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 15:40:16 +0000 Helge Hess wrote: > Just for completeness, I think 501 just says that the collection MKCOL > was called on does not support MKCOL. Other collections on the same > server might support that method. Yes. So would that collection be "WebDAV compliant"? > I think Werner's point is that 403 has specific semantics and I would > agree. To me 403 implies that the user could potentially create > collections with better credentials. While 501 signals that the server > really can't support MKCOL. Yes. > That _is_ relevant for the error message reported by the client. So it's better to say 501 than 403. But are you allowed to say 501 and be compliant to RFC2518 at the same time? > IMHO the confusion started when Julian suggested that a server should > return 403 if its a "read-only CardDAV implementation". Note the > 'read-only _implementation_'. I think returning 403 would be quite wrong > in this case, it should definitely return 501. What I tried to say is that the "MUST support MKCOL" requirement may lead an implementor to return 403 instead of 501, which has zero value to a client which is trying to figure out why the request failed. > As mentioned, practial consequences which immediatly come to mind are: > - misleading error message towards the user > - pointless retries with other (higher level) credentials > > > As far as I can see levels are just a really minor optimization on the > operations a client might attempt (never attempt to LOCK if we already > know its not level2, but then we have the method info in OPTIONS > anyways?!). > Maybe the spec puts too much emphasis on levels. Yes. Levels are problematic. + Clients can rely (sometimes) on specific feature sets (for instance, with DeltaV's compliance levels) + It's easier to communicate what a server can do - When clients refuse to do something because the right compliance level is missing, server implementors may be tempted to lie (as far as I recall, the MS Webfolder client never will try PROPFIND unless OPTIONS says level 1 is reported -- so you can't enhance a "simple" HTTP server with just PROPFIND support for browsing). In general I would advise clients to pay attention to the OPTIONS Allow response header and to status codes, not compliance levels (and, for modern servers, to DAV:supported-live-property-set and DAV:supported-method-set). BR, Julian From w3c-dist-auth-request@listhub.w3.org Sun May 25 08:43:11 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0853A6ADC for ; Sun, 25 May 2008 08:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55+R3a1uV9kk for ; Sun, 25 May 2008 08:43:10 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B60FB3A6AC3 for ; Sun, 25 May 2008 08:43:10 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0IN4-0006H0-B3 for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 15:42:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0IN3-0006GM-H7 for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 15:42:53 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0IMu-00021C-Og for w3c-dist-auth@w3.org; Sun, 25 May 2008 15:42:53 +0000 Received: (qmail invoked by alias); 25 May 2008 15:41:58 -0000 Received: from mnsr-d9b8d695.pool.mediaWays.net (EHLO [217.184.214.149]) [217.184.214.149] by mail.gmx.net (mp026) with SMTP; 25 May 2008 17:41:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/RIPR03UPRwK/yCszFfSjqUnXlZhGwfbO/VkedNM 6fDwqRFTBybRaK Message-ID: <483845F4.6040004@gmx.de> Date: Sat, 24 May 2008 18:44:36 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> In-Reply-To: <48380733.6030606@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-1.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0IMu-00021C-Og 809c9f0cd66d5cdc9b07cf99a25b858e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12886 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 15:42:54 +0000 Werner Baumann wrote: >> So if you want to expose a set of HTTP resources for authoring, and >> you can support all of WebDAV L2 and L3, *except* creating new >> collections, what would you return in the DAV: response header upon >> OPTIONS? >> >> I bet you'd claim support for MKCOL, return level 3, and then fail the >> request if somebody tries to MKCOL anyway. >> > What was the bet about? A barrel of beer? You lost the bet. So, what would you do instead then? Sell a server or service that doesn't work with several popular clients? >>> If you buy a WebDAV-server from a vendor and later notice it does not >>> support MKCOL. Does it matter whether this is standard compliant? >> >> So how exactly is it an improvement to the client when the server >> claims it can do MKCOL, but always returns 403? That would be >> compliant with RFC2518, but not helpful it all. >> > > It is not an improvement at all. In my opinion it would be fraud. > A server that does not support creation of collections is *not* > compliant with RFC 2518 (and, I hope, with RFC 4918 neither) and must > not send a DAV-header at all. Hiding this none-compliance by misusing > 403 makes things worse. Well, sorry. It seems we live in different worlds then. If you insist on that ideal world you'll probably never find a fully compliant server (not because of MKCOL, but because of the more subtle problems I mentioned -- I noticed you didn't follow up on these...). > This does not mean, that it is not allowed to create and use servers and > clients, that do not meet all requirements of the standard (or the > proposed standard), and therefore are not compliant. But these needs to > be documented and server and clients will need out of band information > about their capabilities to be set up properly. There will be no > guarantee for interoperability with other clients or servers. These > cases are outside the spec. That's true. The problem arises when clients use in-band information for the wrong purpose; for instance refuse to use PROPFIND, just because OPTIONS doesn't return a DAV header. In reality you need to deal with these kinds of clients, at least if you don't have the luxury to tell the customers just to get a different client. BR, Julian From w3c-dist-auth-request@listhub.w3.org Sun May 25 08:45:26 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215803A6AD9 for ; Sun, 25 May 2008 08:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIgXQpkNmGXQ for ; Sun, 25 May 2008 08:45:24 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id AD3533A6AC3 for ; Sun, 25 May 2008 08:45:23 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0IP9-0007aa-Ds for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 15:45:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0IP8-0007Hu-Rr for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 15:45:02 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0IOz-0005K8-Lm for w3c-dist-auth@w3.org; Sun, 25 May 2008 15:45:02 +0000 Received: (qmail invoked by alias); 25 May 2008 15:44:08 -0000 Received: from mnsr-d9b8d695.pool.mediaWays.net (EHLO [217.184.214.149]) [217.184.214.149] by mail.gmx.net (mp058) with SMTP; 25 May 2008 17:44:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+raD5gxxerAJUMkLHOtGouvJMCsw5NBD5mOrstYC hK20NeqzVxFdO/ Message-ID: <483846B9.7020701@gmx.de> Date: Sat, 24 May 2008 18:47:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Jack Cleaver CC: w3c-dist-auth@w3.org References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48381FA6.30406@jackpot.uk.net> In-Reply-To: <48381FA6.30406@jackpot.uk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-1.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K0IOz-0005K8-Lm 71a5bcd32125b6afb742061af8cf20d3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12887 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 15:45:03 +0000 Jack Cleaver wrote: > ... All true. Consider this: you can have a fully compliant implementation that exposes a single WebDAV compliant resource, which is empty, has no custom properties, and returns 403 to MKCOL/LOCK/MOVE/COPY etc. Not useful, but compliant. BR, Julian From w3c-dist-auth-request@listhub.w3.org Sun May 25 09:14:21 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126A53A69EE for ; Sun, 25 May 2008 09:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBKloeAcMp2o for ; Sun, 25 May 2008 09:14:20 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 15D903A6AF0 for ; Sun, 25 May 2008 09:14:16 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0Iqk-0005lb-Ao for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 16:13:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Iqj-0005kW-Kx for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 16:13:33 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0IqX-0002yw-T7 for w3c-dist-auth@w3.org; Sun, 25 May 2008 16:13:30 +0000 Received: (qmail invoked by alias); 25 May 2008 16:12:49 -0000 Received: from mnsr-d9b8d695.pool.mediaWays.net (EHLO [217.184.214.149]) [217.184.214.149] by mail.gmx.net (mp003) with SMTP; 25 May 2008 18:12:49 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/06YpClLT0zWRhlC5pHTN7AEwWYyYs2EshksSfS7 7P4+NqgVb9Qe+m Message-ID: <48398FD9.9040507@gmx.de> Date: Sun, 25 May 2008 18:12:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> In-Reply-To: <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0IqX-0002yw-T7 1f1584cf44329dba0a40f4f11e6ac9c2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: 403/401 for access denied Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12888 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 16:13:34 +0000 Helge Hess wrote: > > On 24.05.2008, at 18:13, Werner Baumann wrote: >> BTW: 403 Forbidden is *not* related to authorization; that's 401. > > > You are right! Weird, I always got this wrong. (RFC 2616, 10.4.2/10.4.4 > explicitly states what you say). > > Summary: even if the user is authenticated, one would reissue a 401 if > access is denied to a resource. Which makes me wonder in what (real > world) situations one would use 403 then. That's incorrect. 401 means you need to authenticate. 403 means, you're not allowed to do what you want to do. > Actually in the real world having to send a 401 for access-denied will > probably confuse almost any client. It will _clear_ authentication in > almost any (in fact many webapps rely on that for the 401-logout-hack). > > Also: RFC 3744 contradicts with that? Eg it says (3. Privileges): > http://webdav.org/specs/rfc3744.html#privileges > > 'Servers must report a 403 "Forbidden" error if access is denied' > > The whole RFC goes like this. > > I'm confused ;-/ The RFC is right. 403 means "forbidden". BR, Julian From w3c-dist-auth-request@listhub.w3.org Sun May 25 09:17:57 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F893A6AF0 for ; Sun, 25 May 2008 09:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPIWFn0hRGjg for ; Sun, 25 May 2008 09:17:56 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 9A8893A6ADB for ; Sun, 25 May 2008 09:17:55 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0Iuc-0000HY-0M for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 16:17:34 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Iua-0000Gr-QZ for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 16:17:33 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0IuM-0001Yz-0R for w3c-dist-auth@w3.org; Sun, 25 May 2008 16:17:32 +0000 Received: (qmail invoked by alias); 25 May 2008 16:16:43 -0000 Received: from mnsr-d9b8d695.pool.mediaWays.net (EHLO [217.184.214.149]) [217.184.214.149] by mail.gmx.net (mp049) with SMTP; 25 May 2008 18:16:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/jbM02BjLjQJ/CrXiN7mEJqp1Os9vQnwLyIBMssi Fpx13gVjCJav+d Message-ID: <483990DF.5080004@gmx.de> Date: Sun, 25 May 2008 18:16:31 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> <20080524201338.GA14159@ebed.etf.cuni.cz> <48392DFE.6080506@onlinehome.de> In-Reply-To: <48392DFE.6080506@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K0IuM-0001Yz-0R f7faa9221cd5660d2e4b89581013f893 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12889 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 16:17:34 +0000 Werner Baumann wrote: > WebDAV is not a network file-system and never was intended to be. Please > read the documents, e.g. > ftp://ftp.rfc-editor.org/in-notes/rfc2291.txt and > ftp://ftp.rfc-editor.org/in-notes/rfc4918.txt I would rephrase this as "it's not its single purpose". > I am maintaining a WebDAV-file-system (davfs2, which is not a network > file-system but an intermediate solution for authoring tools without > built-in WebDAV-support). My experience with this work tells me: > It is impossible to cleanly map WebDAV-resources into a > Unix-file-system. Though I am not really happy with RFC 4918, this point > is not the fault of the specification, because it was never intended for > this use. > > It has become common practice, to reuse existing protocols for new > applications. That's OK. But when it turns out, that the chosen protocol > does not really meet the requirements of this application, there is the > bad habit of tweaking the original protocol, up to the point where it > gets unusable for its original intention. This must stop. There's nothing wrong with tweaking/extending a protocol for things it wasn't designed for. It would be wrong to do something like that if it negatively affected existing usage. Could you be a bit more specific of where you think this is happening? > ... BR, Julian From w3c-dist-auth-request@listhub.w3.org Sun May 25 09:19:31 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FBB3A6ADB for ; Sun, 25 May 2008 09:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExYj62FQmR+Z for ; Sun, 25 May 2008 09:19:31 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 057CE3A67A2 for ; Sun, 25 May 2008 09:19:31 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0Iw9-0000NZ-Bi for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 16:19:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Iw8-0000Mv-Lu for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 16:19:08 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0Iw0-00039X-0J for w3c-dist-auth@w3.org; Sun, 25 May 2008 16:19:08 +0000 Received: (qmail invoked by alias); 25 May 2008 16:18:28 -0000 Received: from mnsr-d9b8d695.pool.mediaWays.net (EHLO [217.184.214.149]) [217.184.214.149] by mail.gmx.net (mp018) with SMTP; 25 May 2008 18:18:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX191NCBcQ5h19J3wNUNqx8AkOYCbQ1Xaywx7ermJ5r 1hrtmGD4AL4xP3 Message-ID: <48399150.6030701@gmx.de> Date: Sun, 25 May 2008 18:18:24 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> <48393770.7010206@onlinehome.de> In-Reply-To: <48393770.7010206@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0Iw0-00039X-0J d37ec7902dee5deeb9d56089a2b86cd9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: 403/401 for access denied Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12890 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 16:19:09 +0000 Werner Baumann wrote: > > > Helge Hess wrote: >> Summary: even if the user is authenticated, one would reissue a 401 if >> access is denied to a resource. Which makes me wonder in what (real >> world) situations one would use 403 then. >> > Access restrictions based on IP-address might cause a 403, for instance. > Basically: > - 401 says: authenticate and the request will succeed Nope. It means: "authenticate, and the request will not fail again with 401. But potentially in a different way". > - 403 says: denied, and authentication will not help. Exactly. > ... BR, Julian From w3c-dist-auth-request@listhub.w3.org Sun May 25 11:45:50 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D974F3A68FB for ; Sun, 25 May 2008 11:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCtDZw1uMBCJ for ; Sun, 25 May 2008 11:45:50 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id E72D03A689C for ; Sun, 25 May 2008 11:45:49 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0LCt-0003HZ-ND for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 18:44:35 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LCs-0003Gv-58 for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 18:44:34 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LCh-0004e3-07 for w3c-dist-auth@w3.org; Sun, 25 May 2008 18:44:33 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id EEAC5F85EDB for ; Sun, 25 May 2008 20:44:38 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id AA048F85EE1 for ; Sun, 25 May 2008 20:44:38 +0200 (CEST) Message-Id: From: Helge Hess To: WebDAV In-Reply-To: <48393770.7010206@onlinehome.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 25 May 2008 20:43:49 +0200 References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> <48393770.7010206@onlinehome.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K0LCh-0004e3-07 541b263ca06f42ba77b68deabee16121 X-Original-To: w3c-dist-auth@w3.org Subject: Re: 403/401 for access denied Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12891 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 18:44:35 +0000 On 25.05.2008, at 11:54, Werner Baumann wrote: > Helge Hess wrote: >> Summary: even if the user is authenticated, one would reissue a 401 >> if access is denied to a resource. Which makes me wonder in what >> (real world) situations one would use 403 then. >> Access restrictions based on IP-address might cause a 403, for >> instance. Basically: > - 401 says: authenticate and the request will succeed 'might' succeed. Since it can't know the credentials in advance, it can't say that any authenticated credentials will be authorized. > - 403 says: denied, and authentication will not help. Yes, thats what the spec is saying :-/ > Actually, RFC 2616 says: > 401 Unauthorized > it is *not* "401 for access-denied" I was surprised, but the RFC actually says that: "If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials." This is access-denied (the user is authenticated, but not authorized). >> Actually in the real world having to send a 401 for access-denied >> will probably confuse almost any client. It will _clear_ >> authentication in almost any (in fact many webapps rely on that for >> the 401-logout-hack). >> > I only know about HTTP-Basic- and HTTP-Digest-authentication. In > this cases the client will include authentication information with > every request. [cut] Yes. The problem is that according to the spec 401 is to be used for access denied. Most (all?) clients will ignore that the user is already authenticated and prompt him for new credentials instead of saying 'access denied'. >> Also: RFC 3744 contradicts with that? Eg it says (3. Privileges): >> http://webdav.org/specs/rfc3744.html#privileges >> 'Servers must report a 403 "Forbidden" error if access is denied' >> The whole RFC goes like this. >> > I never cared about RFC 3744. But at first sight, this looks like > not being related to HTTP-authentication, but to be specific to > privileges, ACEs and whatsoever defined in RFC 3744. Can't follow you. Thanks, Helge From w3c-dist-auth-request@listhub.w3.org Sun May 25 11:50:01 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1F33A689C for ; Sun, 25 May 2008 11:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b0k9tMpeZWx for ; Sun, 25 May 2008 11:50:00 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 819EF3A67A2 for ; Sun, 25 May 2008 11:50:00 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0LHq-0005ON-E1 for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 18:49:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LHp-0005Ne-NM for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 18:49:41 +0000 Received: from moutng.kundenserver.de ([212.227.126.171]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LHh-0008Pz-0o for w3c-dist-auth@w3.org; Sun, 25 May 2008 18:49:41 +0000 Received: from [84.187.30.222] (p54BB1EDE.dip0.t-ipconnect.de [84.187.30.222]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1K0LHB1scZ-0004DS; Sun, 25 May 2008 20:49:02 +0200 Message-ID: <4839B496.1060208@onlinehome.de> Date: Sun, 25 May 2008 20:48:54 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: %3C483845F4.6040004@gmx.de%3E Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+XYfq70y6/zKMZUR+cPeESVfRxZPXdSSGDMHA MMR6SOodKkIQSNoH1lCI4R/L6Qs5onHOqZuZX72+KSIaCQc/0j GuUfcGAOiyQgORdaPn9Tg== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0LHh-0008Pz-0o f46badd38a5f2a35cf6acc602f69acd2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12892 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 18:49:42 +0000 Julian Reschke wrote: > Well, sorry. It seems we live in different worlds then. Agreed, and I'm not sorry. > The problem arises when clients use in-band information for the wrong > purpose; for instance refuse to use PROPFIND, just because OPTIONS > doesn't return a DAV header. They use the information just for the purpose it is intended for. A WebDAV-client checks the DAV-header to see, whether the server is a WebDAV-server (at what are the capabilities). Your idea of partial implementation of WebDAV isn't mentioned in the spec and it was probably unknown to the implementers of WebDAV-clients. When you come up with a new idea, you will have to ask implementers for support. What you propose is: fool the clients by sending wrong information in the DAV-header and then misuse status code 403 to reject what the clients can expect to succeed. If this really is done, one element of RFC 4918, the DAV-header is rendered useless. I can see, that you think it useless anyway. But RFC 4918 was released just one year ago and you are one of the 4 creators of this document. Undermining this specification the way you do, is what does not fit in my world and what I call "not taking standards seriously". Werner From w3c-dist-auth-request@listhub.w3.org Sun May 25 12:05:09 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6A13A6A7A for ; Sun, 25 May 2008 12:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8DgxTRJJcWs for ; Sun, 25 May 2008 12:05:07 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 5E8DF3A6765 for ; Sun, 25 May 2008 12:05:07 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0LWB-0000wo-I6 for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 19:04:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LWA-0000wA-Mx for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 19:04:30 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LW1-0000RD-9D for w3c-dist-auth@w3.org; Sun, 25 May 2008 19:04:30 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 58E4EF828AF for ; Sun, 25 May 2008 21:03:50 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id ABBB3F85EF9 for ; Sun, 25 May 2008 21:02:32 +0200 (CEST) Message-Id: <1511C21A-04F7-4329-84E4-31EC0828791A@opengroupware.org> From: Helge Hess To: WebDAV In-Reply-To: <48399150.6030701@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 25 May 2008 21:01:43 +0200 References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> <48393770.7010206@onlinehome.de> <48399150.6030701@gmx.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K0LW1-0000RD-9D 38df11fca19f9c6316804374d62ece23 X-Original-To: w3c-dist-auth@w3.org Subject: Re: 403/401 for access denied Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12893 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 19:04:31 +0000 On 25.05.2008, at 18:18, Julian Reschke wrote: >> Access restrictions based on IP-address might cause a 403, for >> instance. Basically: >> - 401 says: authenticate and the request will succeed > Nope. It means: "authenticate, and the request will not fail again > with 401. But potentially in a different way". Why? It explicitly states that it may fail again with 401, if *authorization* fails for the *authenticated* user: ---snip:10.4.2--- If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. ---snap--- >> - 403 says: denied, and authentication will not help. > Exactly. It says: "Authorization will not help". http://www.duke.edu/~rob/kerberos/authvauth.html Anyways, not really relevant. So what to do, there is resource /addressbook/donald.vcf. User 'mickey' is authenticated for the relevant domain but is not authorized to access that specific resource. User 'dagobert' *is* authorized to access donald.vcf, so (re-)authentication with different credentials would help. Given that 403 says "Authorization will not help" and 401 says "If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused", I would derive that mickey should get a 401. It seems a bit weird to me from a practical point of view, but can it actually be read in a different way? Thanks, Helge From w3c-dist-auth-request@listhub.w3.org Sun May 25 12:11:04 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5076B3A698E for ; Sun, 25 May 2008 12:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdOQimAGVZ0q for ; Sun, 25 May 2008 12:11:02 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B9C7E3A6765 for ; Sun, 25 May 2008 12:11:02 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0LcA-0002vJ-A6 for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 19:10:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Lc9-0002uY-Kz for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 19:10:41 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Lc0-0000fQ-Vn for w3c-dist-auth@w3.org; Sun, 25 May 2008 19:10:41 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 301C6F85769 for ; Sun, 25 May 2008 21:10:56 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 005C0F8610A for ; Sun, 25 May 2008 21:10:56 +0200 (CEST) Message-Id: <754A2D85-9FD0-4C0C-BF53-38898D6AB7A9@opengroupware.org> From: Helge Hess To: WebDAV In-Reply-To: <4839B496.1060208@onlinehome.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 25 May 2008 21:10:06 +0200 References: %3C483845F4.6040004@gmx.de%3E <4839B496.1060208@onlinehome.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K0Lc0-0000fQ-Vn 9f158d37c505574fb90613ac9ab4e663 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12894 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 19:10:42 +0000 On 25.05.2008, at 20:48, Werner Baumann wrote: > then misuse status code 403 to reject what the clients can expect to > succeed The clients cannot expect the operation to succeed (200 OK), whether its misused or not. They need to deal with 403 even in the context of fully conforming servers. I guess thats why Julian was saying that the 'misuse' has no practical consequences. Thanks, Helge From w3c-dist-auth-request@listhub.w3.org Sun May 25 12:12:28 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7263A67AA for ; Sun, 25 May 2008 12:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+kaAhKkLoAz for ; Sun, 25 May 2008 12:12:28 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id E524C3A689C for ; Sun, 25 May 2008 12:12:27 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0Ldf-0003Ci-Af for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 19:12:15 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Lde-0003C4-A8 for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 19:12:14 +0000 Received: from moutng.kundenserver.de ([212.227.126.174]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LdN-0006Wc-Ds for w3c-dist-auth@w3.org; Sun, 25 May 2008 19:12:13 +0000 Received: from [84.187.30.222] (p54BB1EDE.dip0.t-ipconnect.de [84.187.30.222]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1K0Lcm3z3B-0000Jl; Sun, 25 May 2008 21:11:21 +0200 Message-ID: <4839B9D8.3080309@onlinehome.de> Date: Sun, 25 May 2008 21:11:20 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 To: Helge Hess CC: WebDAV References: <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <20080524132039.GA23981@ebed.etf.cuni.cz> <48383EC2.2000902@onlinehome.de> <72594CE2-67F7-421E-8616-021E9C55C29B@opengroupware.org> <48393770.7010206@onlinehome.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/FVnFS6lZH46JcUOdmATnl8fbwxWsWugf6rne uVF/sDhFy2lnYol2pb+kUaeDturiRUoTs30L989fCXmaqvQNi6 O088xgWMpu8w1wpA0WlYQ== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K0LdN-0006Wc-Ds e52a60cf164a1140504482683138698f X-Original-To: w3c-dist-auth@w3.org Subject: Re: 403/401 for access denied Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12895 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 19:12:15 +0000 Helge Hess wrote: > On 25.05.2008, at 11:54, Werner Baumann wrote: >> Actually, RFC 2616 says: >> 401 Unauthorized >> it is *not* "401 for access-denied" > > I was surprised, but the RFC actually says that: "If the request already > included Authorization credentials, then the 401 response indicates that > authorization has been refused for those credentials." > > This is access-denied (the user is authenticated, but not authorized). > NO! It isn't. it is still "Unauthorized" and nothing else. The server does not accept the credentials and wants the proper ones. As HTTP is stateless, the server server will repeat this until the user finally gets either the proper credentials or tired. Whether the client stops this at some point or waits for the user to get tired is a client issue, not a protocol issue. >>> Actually in the real world having to send a 401 for access-denied >>> will probably confuse almost any client. It will _clear_ >>> authentication in almost any (in fact many webapps rely on that for >>> the 401-logout-hack). >>> >> I only know about HTTP-Basic- and HTTP-Digest-authentication. In this >> cases the client will include authentication information with every >> request. > [cut] > > Yes. The problem is that according to the spec 401 is to be used for > access denied. > Where does the spec say this? Werner From w3c-dist-auth-request@listhub.w3.org Sun May 25 12:17:43 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3983A6A56 for ; Sun, 25 May 2008 12:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsjoGMGKSyMH for ; Sun, 25 May 2008 12:17:41 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 285D73A6765 for ; Sun, 25 May 2008 12:17:40 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0LiV-0007ww-1K for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 19:17:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LiU-0007wE-6q for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 19:17:14 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0LiL-0006Ie-3G for w3c-dist-auth@w3.org; Sun, 25 May 2008 19:17:14 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5303EF8615C for ; Sun, 25 May 2008 21:17:26 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 2B586F86157 for ; Sun, 25 May 2008 21:17:26 +0200 (CEST) Message-Id: <3723582B-A498-4C32-820A-F5F2F89044D5@opengroupware.org> From: Helge Hess To: WebDAV In-Reply-To: <483845F4.6040004@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 25 May 2008 21:16:37 +0200 References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <483845F4.6040004@gmx.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: lisa.w3.org 1K0LiL-0006Ie-3G 40a68e246328a27f3f9b15f0e0bd6442 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12896 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 19:17:15 +0000 On 24.05.2008, at 18:44, Julian Reschke wrote: > The problem arises when clients use in-band information for the > wrong purpose; for instance refuse to use PROPFIND, just because > OPTIONS doesn't return a DAV header. I was wondering about that. I think the issue is that PROPFIND is only defined by the WebDAV RFC. Just having an Allow: PROPFIND doesn't necessarily imply that its the PROPFIND method with the payload as specified in WebDAV? Hm, maybe we really need WebDAV level -1, which just specifies PROPFIND? :-) I think it really doesn't matter for interoperability in the real world though. Greets, Helge From w3c-dist-auth-request@listhub.w3.org Sun May 25 12:22:26 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B2D3A682A for ; Sun, 25 May 2008 12:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRLcPXdOLGyz for ; Sun, 25 May 2008 12:22:25 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 95E533A6765 for ; Sun, 25 May 2008 12:22:25 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0Ln7-0001H9-4K for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 19:22:01 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Ln6-0001GQ-4Y for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 19:22:00 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0Lmv-0007GK-PI for w3c-dist-auth@w3.org; Sun, 25 May 2008 19:21:59 +0000 Received: (qmail invoked by alias); 25 May 2008 19:21:11 -0000 Received: from mnsr-d9b8cebe.pool.mediaWays.net (EHLO [217.184.206.190]) [217.184.206.190] by mail.gmx.net (mp010) with SMTP; 25 May 2008 21:21:11 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18NnTVRctMNfdd1m/F3isiMYgGhceVTMdCumYynUX 2pimDqVQLrEmMd Message-ID: <4839BBF3.6040403@gmx.de> Date: Sun, 25 May 2008 21:20:19 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: %3C483845F4.6040004@gmx.de%3E <4839B496.1060208@onlinehome.de> In-Reply-To: <4839B496.1060208@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K0Lmv-0007GK-PI a626f0b18b9827043b6cdc5a841e5e92 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12897 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 19:22:01 +0000 Werner Baumann wrote: > > The problem arises when clients use in-band information for the wrong > > purpose; for instance refuse to use PROPFIND, just because OPTIONS > > doesn't return a DAV header. > > They use the information just for the purpose it is intended for. A > WebDAV-client checks the DAV-header to see, whether the server is a > WebDAV-server (at what are the capabilities). But most of the time, a client doesn't need to know that. For instance, when displaying folder contents. Either PROPFIND is there or not. What other parts of WebDAV are there is just irrelevant for that. > Your idea of partial implementation of WebDAV isn't mentioned in the > spec and it was probably unknown to the implementers of WebDAV-clients. > When you come up with a new idea, you will have to ask implementers for > support. > What you propose is: fool the clients by sending wrong information in > the DAV-header and then misuse status code 403 to reject what the > clients can expect to succeed. If this really is done, one element of > RFC 4918, the DAV-header is rendered useless. I happen to believe that it is not really useful, yes. > I can see, that you think it useless anyway. But RFC 4918 was released > just one year ago and you are one of the 4 creators of this document. No, I'm not. The "creator" is the working group in total, or, if you wish, the Editor acting on behalf of the working group. But even if I was, I wouldn't have removed or changed it; maybe I would have pointed client implementors to smarter ways to detect functionality. What the WG did was looking at all issues that had been raised against RFC2518, and trying to resolve as many as possible in RFC2518bis. Usage patterns for compliance levels were IMHO never discussed, so changing this was never on the table, at least not as far as I recall. What was discussed and fortunately rejected was a requirement to return the DAV header upon "OPTIONS *", btw. And, for the record; I tried to stop the addition of another compliance level (L3), because, after all, RFC4918 is meant to be backwards-compatible, and all the extensions we did can be detected in a smarter way anyway. > Undermining this specification the way you do, is what does not fit in > my world and what I call "not taking standards seriously". I think you read much more into the compliance levels than it was intended. Getting back to what got us here (I think): are you saying that a server that exposes a flat collection of items (such a set of vcards) is not allowed to say "I'm doing WebDAV" because it doesn't allow creating child collections? Do you have evidence of a server that actually *does* support arbitrarily deeply nested collections? What am I missing here? BR, Julian PS: I note that you still didn't followup on : > In practice, there are many things that RFC2518 and RFC4918 do not even > talk about, but will affect conformance and interoperability: > > - the set of characters allowed in path segments (think Unicode > normalization) > - the maximum length of a path segment > - whether or not path segments are case-sensitive > - the maximum number of path segments > - the maximum total lenth > - size constraints for property values > - ... > > One key feature of HTTP and protocols based on HTTP is that messages and > responses are self-descriptive, and that close coupling (as in WS-*) is > avoided. Yes, it's always nice to know upfront if a server is going to > allow something (being it out-of-band by spec, by introspection > (OPTIONS), whatever...). But in practice, a client will have to deal > with unexpected errors (and yes, good status codes help with that). Let me add a few more: - whether path segments are stored as is (using URI escaping), byte sequences (Unix/Posix file IO) or character sequences (Windows, HFS+) - how trailing blanks are handled (ignored vs stored) - how trailing dots are handled - whether or not content written with PUT can be rewritten by the server and so on... PS2: Again, for the record: I totally agree with you that a server needs to implement things in a consistent, meaningful way. Such as, HEAD and GET need to work as required by HTTP/1.1, and PROPFIND responses should be consistent with HEAD/GET responses. From w3c-dist-auth-request@listhub.w3.org Sun May 25 12:30:26 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935503A6765 for ; Sun, 25 May 2008 12:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbS4-vNlP-u8 for ; Sun, 25 May 2008 12:30:25 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 168883A676A for ; Sun, 25 May 2008 12:30:21 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0Lug-0003TK-DU for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 19:29:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0Luf-0003Sb-Nq for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 19:29:49 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0LuW-0001Ls-Ug for w3c-dist-auth@w3.org; Sun, 25 May 2008 19:29:49 +0000 Received: (qmail invoked by alias); 25 May 2008 19:29:09 -0000 Received: from mnsr-d9b8cebe.pool.mediaWays.net (EHLO [217.184.206.190]) [217.184.206.190] by mail.gmx.net (mp048) with SMTP; 25 May 2008 21:29:09 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/UE5RVaC3UZ4FCRs2BRgT7bshiQ61zbQWMXxyJ38 8uhSzwGDiCYh76 Message-ID: <4839BE04.8010203@gmx.de> Date: Sun, 25 May 2008 21:29:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <483845F4.6040004@gmx.de> <3723582B-A498-4C32-820A-F5F2F89044D5@opengroupware.org> In-Reply-To: <3723582B-A498-4C32-820A-F5F2F89044D5@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0LuW-0001Ls-Ug ce41ab21ebe5a63566e89efb94079484 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12898 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 19:29:50 +0000 Helge Hess wrote: > > On 24.05.2008, at 18:44, Julian Reschke wrote: >> The problem arises when clients use in-band information for the wrong >> purpose; for instance refuse to use PROPFIND, just because OPTIONS >> doesn't return a DAV header. > > > I was wondering about that. I think the issue is that PROPFIND is only > defined by the WebDAV RFC. Just having an Allow: PROPFIND doesn't > necessarily imply that its the PROPFIND method with the payload as > specified in WebDAV? That's a good point, considering the lack of an HTTP method registry. Which, as a matter of fact, is an open issue for HTTPbis. > Hm, maybe we really need WebDAV level -1, which just specifies PROPFIND? > :-) No, discovering Allow: PROPFIND should be sufficient, just as it is for header names and status codes defined in WebDAV (these have IANA registries). > I think it really doesn't matter for interoperability in the real world > though. Right, it doesn't matter in practice (*smiles and ducks*). But as it matters in theory, and we take internet protocols seriously, we'll be adding the missing registry (see ). BR, Julian From w3c-dist-auth-request@listhub.w3.org Sun May 25 13:11:03 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A86B3A67A9 for ; Sun, 25 May 2008 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtuyD7PkGCet for ; Sun, 25 May 2008 13:11:02 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 86D813A677C for ; Sun, 25 May 2008 13:11:02 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0MXO-0005hK-8X for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 20:09:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0MXN-0005gg-5e for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 20:09:49 +0000 Received: from aji.w3.org ([133.27.228.225]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0MXM-0003EE-By for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 20:09:48 +0000 Received: from moutng.kundenserver.de ([212.227.126.171]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0MWm-0002RI-QE for w3c-dist-auth@w3.org; Sun, 25 May 2008 20:09:21 +0000 Received: from [84.187.30.222] (p54BB1EDE.dip0.t-ipconnect.de [84.187.30.222]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1K0MWF2F3g-0005S2; Sun, 25 May 2008 22:08:39 +0200 Message-ID: <4839C73F.3060800@onlinehome.de> Date: Sun, 25 May 2008 22:08:31 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: WebDAV References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <483845F4.6040004@gmx.de> <3723582B-A498-4C32-820A-F5F2F89044D5@opengroupware.org> In-Reply-To: <3723582B-A498-4C32-820A-F5F2F89044D5@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+dBQK0vANN2bez1I+tv9svOH5DsL1dqeMzG/T 6laVL21lZdZtPAoILRMOTXzfDiCmoOxdAxnJn1kDmlOhKKGES5 1utQllhkC2TBPTOHvrp7w== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: aji.w3.org 1K0MWm-0002RI-QE 7c02f30119f5b6ec2c5fe46d46e6fd3c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12899 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 20:09:50 +0000 Helge Hess wrote: > I was wondering about that. I think the issue is that PROPFIND is only > defined by the WebDAV RFC. Just having an Allow: PROPFIND doesn't > necessarily imply that its the PROPFIND method with the payload as > specified in WebDAV? > As I read RFC 2616, it indeed allows the use of methods not defined in RFC 2616, and it proposes to announce this in an Allow-header in response to OPTIONS. No need for the DAV-header, when you only want to support PROPFIND. Your concern it might not be the PROPFIND defined in RFC 4918. Now it's may part to ask: does that really matter in practice? WebDAV is around for some years. Do you expect there is another HTTP-PROPFIND-method? But Julian's concerns seem to be WebDAV-clients written before somebody came up with the idea of implementing only parts of WebDAV. They will not use this. In my opinion you have to be patient, talk to client implementers or write your own client. Fooling older clients, by using protocol elements in a way, that clearly contradicts the specification (and that's what we are talking about), must not be done. Werner From w3c-dist-auth-request@listhub.w3.org Sun May 25 14:04:16 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C533A6A43 for ; Sun, 25 May 2008 14:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywcnbC97n-d9 for ; Sun, 25 May 2008 14:04:15 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 5BA1F3A6765 for ; Sun, 25 May 2008 14:04:15 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0NN0-0003s8-IO for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 21:03:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0NMz-0003rU-RP for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 21:03:10 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0NMk-0004Ru-Uz for w3c-dist-auth@w3.org; Sun, 25 May 2008 21:03:09 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id E0B4EF86655 for ; Sun, 25 May 2008 23:03:18 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id BC4D5F8665F for ; Sun, 25 May 2008 23:03:18 +0200 (CEST) Message-Id: From: Helge Hess To: WebDAV In-Reply-To: <4839C73F.3060800@onlinehome.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 25 May 2008 23:02:29 +0200 References: %3C4836F223.9090608@gmx.de%3E <48372F96.7090902@onlinehome.de> <4837C83C.6030204@gmx.de> <48380733.6030606@onlinehome.de> <483845F4.6040004@gmx.de> <3723582B-A498-4C32-820A-F5F2F89044D5@opengroupware.org> <4839C73F.3060800@onlinehome.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K0NMk-0004Ru-Uz 2f76db2d823176c58ede85d2ca39df17 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12900 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 21:03:10 +0000 On 25.05.2008, at 22:08, Werner Baumann wrote: > Fooling older clients, by using protocol elements in a way, that > clearly contradicts the specification (and that's what we are > talking about) Thats what _you_ are talking about ("clearly contradicts the specification"?!). So far I have seen no one who supports your arguments. (though please, there is no need to reiterate your claims, I think everyone understood what your position is) BTW: I do not even agree that it is invalid to return 501 in response to MKCOL. For me a requirement to support MKCOL just means that the server knows what implementing MKCOL implies according to WebDAV, that it expects to receive a MKCOL request and can then respond with any valid HTTP code (given that WebDAV is a strict HTTP superset). But that is just how I read the combination of the specs. Thanks, Helge From w3c-dist-auth-request@listhub.w3.org Sun May 25 14:22:22 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B90D3A690C for ; Sun, 25 May 2008 14:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5jVos5JqkYT for ; Sun, 25 May 2008 14:22:21 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 38E6B3A680C for ; Sun, 25 May 2008 14:22:20 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0NeP-0000JQ-If for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 21:21:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0NeO-0000Ik-OD for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 21:21:09 +0000 Received: from moutng.kundenserver.de ([212.227.126.188]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0NeF-0004wM-Uc for w3c-dist-auth@w3.org; Sun, 25 May 2008 21:21:08 +0000 Received: from [84.187.30.222] (p54BB1EDE.dip0.t-ipconnect.de [84.187.30.222]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1K0Ndl08ty-0005P3; Sun, 25 May 2008 23:20:29 +0200 Message-ID: <4839D81B.9000301@onlinehome.de> Date: Sun, 25 May 2008 23:20:27 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: %3C483845F4.6040004@gmx.de%3E <4839B496.1060208@onlinehome.de> <4839BBF3.6040403@gmx.de> In-Reply-To: <4839BBF3.6040403@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/ZCCI/CTeshX928+HRNBDklB1Am72N5zYdqpu 7yN4IdgQSUWkMDe/uP2EZxnT6dDdmS68NuFqtAr8UoabN56JnN sSoVqOvgW22jssQcPRDEg== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0NeF-0004wM-Uc 5ac483dc5b6a2351d1790a85805ebc6b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12901 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 21:21:09 +0000 Julian Reschke wrote: > But most of the time, a client doesn't need to know that. For instance, > when displaying folder contents. Either PROPFIND is there or not. What > other parts of WebDAV are there is just irrelevant for that. > Whether the server believes it is irrelevant does not matter. When the server announces full support for WebDAV, using the DAV-header, the client is allowed to interpret it according to the specification. When this causes trouble, the responsibility is on the side of the server that intentionally sent wrong information. > I happen to believe that it is not really useful, yes. > >> I can see, that you think it useless anyway. But RFC 4918 was released >> just one year ago and you are one of the 4 creators of this document. > > No, I'm not. The "creator" is the working group in total, or, if you > wish, the Editor acting on behalf of the working group. > > But even if I was, I wouldn't have removed or changed it; maybe I would > have pointed client implementors to smarter ways to detect functionality. > Now, as you would not have removed the DAV-header anyway, you ought to respect it, as defined in the specification. If you want to deprecate it, say it loud and *clear*. What I oppose is your suggestion to intentionally misuse it (Send DAV: 1 and not support required methods) and this way render it useless. > Getting back to what got us here (I think): are you saying that a server > that exposes a flat collection of items (such a set of vcards) is not > allowed to say "I'm doing WebDAV" because it doesn't allow creating > child collections? > Looks like a CardDav (?) problem, and they really seem to be in trouble here. If they really want to restrict to flat collections, which means no MKCOL, they are not compliant to WebDAV and should not use the DAV-header (you don't like it anyway). But as they intend to create an extension protocol, there surely is way to handle this properly. > Do you have evidence of a server that actually *does* support > arbitrarily deeply nested collections? What am I missing here? > Not allowing arbitrarily deeply nested collections is not the same as not allowing the creation of collections at all. This looks like a use case for 403, according to the specs. >> In practice, there are many things that RFC2518 and RFC4918 do not >> even talk about, but will affect conformance and interoperability: >> >> - the set of characters allowed in path segments (think Unicode >> normalization) As far as I know unicode is allowed in pathsegments and there is a rule, how to escape them. The practical issue seem to me different reserved characters on different operating systems. I have know solution, but education. Perhaps servers should reject pathnames that cry for trouble. >> - whether or not path segments are case-sensitive Neither servers nor clients should change the case. >> - the maximum length of a path segment >> - the maximum number of path segments >> - the maximum total lenth >> - size constraints for property values Are these real problems today. As long as people have a minimum of good taste, there should not be a problem. In most other cases servers are allowed to simply reject such request. >> One key feature of HTTP and protocols based on HTTP is that messages >> and responses are self-descriptive, and that close coupling (as in >> WS-*) is avoided. Yes, it's always nice to know upfront if a server is >> going to allow something (being it out-of-band by spec, by >> introspection (OPTIONS), whatever...). But in practice, a client will >> have to deal with unexpected errors (and yes, good status codes help >> with that). > This could be arguments, when you start an *open* discussion to remove the DAV-header from the spec. > Let me add a few more: > > - whether path segments are stored as is (using URI escaping), byte > sequences (Unix/Posix file IO) or character sequences (Windows, HFS+) > > - how trailing blanks are handled (ignored vs stored) > > - how trailing dots are handled > I think "store" or not "store" is not in the scope of the spec. But neither a server nor a client is allowed to silently change the URL of a resource (and expect it to work) (with the exception when the server forgot about the trailing slash of a collection-URL). If a server does not like a new URL created by a client, it should reject it. > - whether or not content written with PUT can be rewritten by the server > It is out of the spec what a server is allowed to do with its resources. But in my opinion: regarding distributed authoring, co- and anti-authoring by the server is the last think we need. BTW: Is anybody, who refuses to accept clear misuse of protocol elements, obliged to answer this - quite unrelated - questions? Is this a test, whether I am allowed to open my mouth when important people are talking about standards? Werner From w3c-dist-auth-request@listhub.w3.org Sun May 25 15:06:03 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302523A696D for ; Sun, 25 May 2008 15:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G9aCRgB4k5Z for ; Sun, 25 May 2008 15:06:02 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 3517A3A6919 for ; Sun, 25 May 2008 15:06:02 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0OKy-0006JK-JA for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 22:05:08 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0OKw-0006Ib-Dn for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 22:05:06 +0000 Received: from moutng.kundenserver.de ([212.227.126.187]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0OKg-0001RU-Nc for w3c-dist-auth@w3.org; Sun, 25 May 2008 22:05:05 +0000 Received: from [84.187.30.222] (p54BB1EDE.dip0.t-ipconnect.de [84.187.30.222]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1K0OK70nps-0008Cm; Mon, 26 May 2008 00:04:15 +0200 Message-ID: <4839E25E.40709@onlinehome.de> Date: Mon, 26 May 2008 00:04:14 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: %3CAF919573-BAF9-4F5F-8A12-8617DB9A8261@opengroupware.org%3E Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18MkR4ySCt+U/nZO+S8zYYBM5tnftsV7NrpwkE nNDOf/hcrdBpu4JCD3T6F9GA+9IfbC/ZNUrjegA5QNacXBbYJx wa/AKeVsdlGQzLYIqgmxw== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K0OKg-0001RU-Nc 2d1b09d498db71812c3a93f996f7bd16 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12902 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 22:05:08 +0000 Helge wrote: > BTW: I do not even agree that it is invalid to return 501 in response > to MKCOL. For me a requirement to support MKCOL just means that the > server knows what implementing MKCOL implies according to WebDAV, > that it expects to receive a MKCOL request and can then respond with > any valid HTTP code (given that WebDAV is a strict HTTP superset). > But that is just how I read the combination of the specs. So support for MKCOL means the ability to reject every MKCOL-request with "any valid HTTP code". Julian is right: I live in another world. And this is what RFC 2616 says about 501: 10.5.2 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. Werner From w3c-dist-auth-request@listhub.w3.org Sun May 25 16:24:33 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E243A68AC for ; Sun, 25 May 2008 16:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SLsSBVDvgTE for ; Sun, 25 May 2008 16:24:33 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id F32AC3A67B3 for ; Sun, 25 May 2008 16:24:32 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0PYc-0006O7-8a for w3c-dist-auth-dist@listhub.w3.org; Sun, 25 May 2008 23:23:18 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0PYZ-0006Mz-0x for w3c-dist-auth@listhub.w3.org; Sun, 25 May 2008 23:23:15 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0PYP-0005uQ-1Z for w3c-dist-auth@w3.org; Sun, 25 May 2008 23:23:14 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 4D4ADF86E6F for ; Mon, 26 May 2008 01:23:22 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 2CA4EF86E46 for ; Mon, 26 May 2008 01:23:22 +0200 (CEST) Message-Id: <4345A4FF-0023-43FD-9416-FBDA85E88133@opengroupware.org> From: Helge Hess To: WebDAV In-Reply-To: <4839E25E.40709@onlinehome.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 26 May 2008 01:22:31 +0200 References: %3CAF919573-BAF9-4F5F-8A12-8617DB9A8261@opengroupware.org%3E <4839E25E.40709@onlinehome.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K0PYP-0005uQ-1Z 6200ee2fa4082e4147add622ecc9990f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12903 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 May 2008 23:23:18 +0000 On 26.05.2008, at 00:04, Werner Baumann wrote: > So support for MKCOL means the ability to reject every MKCOL-request > with "any valid HTTP code". Well, as I said: "that is just how I read the combination of the specs". My interpretation of "combination" in the given scenario is rooted on the title of RFC 2518: "HTTP Extensions for Distributed Authoring". HTTP Extension means for me that the RFC _extends_ the HTTP specification, not that it restricts it. If a client is a WebDAV client, it automatically is a full HTTP/1.1 client, hence must support 501 responses. And the other way around. But really, this thread already went too far, points have been exchanged and are archived for further consideration. In the end I'm mostly concerned with real world interoperability, and I think that the important question raised by Julian is still "where does it matter"? (I think) To usefully continue the discussion you must transparently answer the question why, for a client, a readonly WebDAV collection returning 403 is different to a server which has an IP address protection for MKCOL on a collection. Thanks, Helge From c7ith@orlandoluxuryride.com Sun May 25 17:02:27 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31DEE3A6B32; Sun, 25 May 2008 17:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.457 X-Spam-Level: X-Spam-Status: No, score=-8.457 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr15l9YPrihE; Sun, 25 May 2008 17:02:21 -0700 (PDT) Received: from 190-48-137-165.speedy.com.ar (unknown [190.48.137.165]) by core3.amsl.com (Postfix) with SMTP id D042F3A63CB; Sun, 25 May 2008 17:02:09 -0700 (PDT) X-Originating-IP: 31.235.53.32 by smtp.190.48.137.165; Sun, 25 May 2008 20:02:20 -0500 Message-ID: From: "Alexander Oleary" Reply-To: "Alexander Oleary" To: vpim@ietf.org Subject: Inexpensive IWC watches Date: Sun, 25 May 2008 20:02:20 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Eadieks%2Ecom/ From c10@sxszjzx.com Sun May 25 22:55:07 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1C93A68C6; Sun, 25 May 2008 22:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.165 X-Spam-Level: X-Spam-Status: No, score=-23.165 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MX=0.535, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysRtLk2FoWb4; Sun, 25 May 2008 22:55:01 -0700 (PDT) Received: from dup-148-221-123-5.prodigy.net.mx (dup-148-221-123-5.prodigy.net.mx [148.221.123.5]) by core3.amsl.com (Postfix) with SMTP id 88A903A68BE; Sun, 25 May 2008 22:53:29 -0700 (PDT) X-Originating-IP: 216.144.128.108 by smtp.148.221.123.5; Mon, 26 May 2008 01:53:35 -0500 Message-ID: From: "Roscoe Steward" Reply-To: "Roscoe Steward" To: vrrp-request@ietf.org Subject: Save thousands... no one will know Date: Mon, 26 May 2008 01:53:35 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece. http://www%2Esuppoenn%2Ecom/ Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience! http://www%2Esuppoenn%2Ecom/ From w3c-dist-auth-request@listhub.w3.org Sun May 25 23:03:11 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9AD3A68DB for ; Sun, 25 May 2008 23:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qp+u8e+O3HB for ; Sun, 25 May 2008 23:03:02 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A43023A68C6 for ; Sun, 25 May 2008 23:03:02 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0VlG-0006Dr-9R for w3c-dist-auth-dist@listhub.w3.org; Mon, 26 May 2008 06:00:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0VlD-0006D8-V9 for w3c-dist-auth@listhub.w3.org; Mon, 26 May 2008 06:00:44 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0Vl5-0002ys-2V for w3c-dist-auth@w3.org; Mon, 26 May 2008 06:00:43 +0000 Received: (qmail invoked by alias); 26 May 2008 05:59:53 -0000 Received: from mnsr-d9b8ceae.pool.mediaWays.net (EHLO [217.184.206.174]) [217.184.206.174] by mail.gmx.net (mp042) with SMTP; 26 May 2008 07:59:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19QW7lJTGJQA6lU8audAwAkEHozJbjEJhgDNz9rAT ToYl5m4s5WWNz6 Message-ID: <483A51A9.5050801@gmx.de> Date: Mon, 26 May 2008 07:59:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: %3C483845F4.6040004@gmx.de%3E <4839B496.1060208@onlinehome.de> <4839BBF3.6040403@gmx.de> <4839D81B.9000301@onlinehome.de> In-Reply-To: <4839D81B.9000301@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0Vl5-0002ys-2V 0a4435410dccab705878c22b7b7225a0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12904 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 26 May 2008 06:00:46 +0000 Werner Baumann wrote: > Julian Reschke wrote: >> But most of the time, a client doesn't need to know that. For >> instance, when displaying folder contents. Either PROPFIND is there or >> not. What other parts of WebDAV are there is just irrelevant for that. >> > Whether the server believes it is irrelevant does not matter. When the > server announces full support for WebDAV, using the DAV-header, the > client is allowed to interpret it according to the specification. When > this causes trouble, the responsibility is on the side of the server > that intentionally sent wrong information. Yes. > Now, as you would not have removed the DAV-header anyway, you ought to > respect it, as defined in the specification. If you want to deprecate > it, say it loud and *clear*. What I oppose is your suggestion to > intentionally misuse it (Send DAV: 1 and not support required methods) > and this way render it useless. I disagree that it renders it useless. It isn't very useful in the first place. And the only reason to deprecate it would be because it may harm usage WebDAV for novel things, such as Vcarddav. >> Getting back to what got us here (I think): are you saying that a >> server that exposes a flat collection of items (such a set of vcards) >> is not allowed to say "I'm doing WebDAV" because it doesn't allow >> creating child collections? >> > Looks like a CardDav (?) problem, and they really seem to be in trouble > here. If they really want to restrict to flat collections, which means > no MKCOL, they are not compliant to WebDAV and should not use the > DAV-header (you don't like it anyway). But as they intend to create an > extension protocol, there surely is way to handle this properly. Yes, maybe it's better to not to use the header for them. The problem is that it'll make it *much* harder to specify the protocol, with little real-world advantage. >> Do you have evidence of a server that actually *does* support >> arbitrarily deeply nested collections? What am I missing here? >> > Not allowing arbitrarily deeply nested collections is not the same as > not allowing the creation of collections at all. This looks like a use > case for 403, according to the specs. So, at what nesting level do you draw the line? Any spec text to support that? >>> In practice, there are many things that RFC2518 and RFC4918 do not >>> even talk about, but will affect conformance and interoperability: >>> >>> - the set of characters allowed in path segments (think Unicode >>> normalization) > As far as I know unicode is allowed in pathsegments and there is a rule, > how to escape them. The practical issue seem to me different reserved > characters on different operating systems. I have know solution, but > education. Perhaps servers should reject pathnames that cry for trouble. Well. Servers do. A server that stores path segments as unicode will likely reject a path segment of "%80", because it's not a legal UTF-8 octet sequence. So, what do you do in a Unix setup where the local filename contains a single 0x80 octet, and the user wants to copy the file to that WebDAV server? >>> - whether or not path segments are case-sensitive > Neither servers nor clients should change the case. So what about case-preserving vs case-sensitive? Many servers do preserve the case, but can't store things that only differ in case, such as "Makefile" vs "makefile", to name a popular example. Compliant? >>> - the maximum length of a path segment >>> - the maximum number of path segments >>> - the maximum total lenth >>> - size constraints for property values > Are these real problems today. As long as people have a minimum of good > taste, there should not be a problem. In most other cases servers are > allowed to simply reject such request. Yes, but this is something RFC4918 is totally silent about. So where do you draw the line between where servers a free to have restrictions, and where not? >>> One key feature of HTTP and protocols based on HTTP is that messages >>> and responses are self-descriptive, and that close coupling (as in >>> WS-*) is avoided. Yes, it's always nice to know upfront if a server >>> is going to allow something (being it out-of-band by spec, by >>> introspection (OPTIONS), whatever...). But in practice, a client will >>> have to deal with unexpected errors (and yes, good status codes help >>> with that). >> > This could be arguments, when you start an *open* discussion to remove > the DAV-header from the spec. > > >> Let me add a few more: >> >> - whether path segments are stored as is (using URI escaping), byte >> sequences (Unix/Posix file IO) or character sequences (Windows, HFS+) >> >> - how trailing blanks are handled (ignored vs stored) >> >> - how trailing dots are handled >> > I think "store" or not "store" is not in the scope of the spec. But > neither a server nor a client is allowed to silently change the URL of a > resource (and expect it to work) (with the exception when the server > forgot about the trailing slash of a collection-URL). If a server does > not like a new URL created by a client, it should reject it. OK, there's go IIS and iDisk (I think). >> - whether or not content written with PUT can be rewritten by the server >> > It is out of the spec what a server is allowed to do with its resources. > But in my opinion: regarding distributed authoring, co- and > anti-authoring by the server is the last think we need. > > BTW: Is anybody, who refuses to accept clear misuse of protocol > elements, obliged to answer this - quite unrelated - questions? Is this > a test, whether I am allowed to open my mouth when important people are > talking about standards? No, I'm just trying to understand where you draw the line about areas where a server may have restrictions that aren't mentioned in the spec. Not sure about what you mean when you say "important people". Maybe you may want to read an FAQ about the IETF process... BR, Julian From w3c-dist-auth-request@listhub.w3.org Mon May 26 01:16:00 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6723A6A9B for ; Mon, 26 May 2008 01:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m70Dj5o1frJS for ; Mon, 26 May 2008 01:15:59 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 42C403A67E9 for ; Mon, 26 May 2008 01:15:58 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0XpR-0008QS-0u for w3c-dist-auth-dist@listhub.w3.org; Mon, 26 May 2008 08:13:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0XpP-0008PL-3D for w3c-dist-auth@listhub.w3.org; Mon, 26 May 2008 08:13:11 +0000 Received: from moutng.kundenserver.de ([212.227.126.183]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0XpF-000774-5b for w3c-dist-auth@w3.org; Mon, 26 May 2008 08:13:11 +0000 Received: from [84.187.0.194] (p54BB00C2.dip0.t-ipconnect.de [84.187.0.194]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1K0Xoh0JjD-0004N6; Mon, 26 May 2008 10:12:27 +0200 Message-ID: <483A70E1.8050306@onlinehome.de> Date: Mon, 26 May 2008 10:12:17 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: %3C483845F4.6040004@gmx.de%3E <4839B496.1060208@onlinehome.de> <4839BBF3.6040403@gmx.de> <4839D81B.9000301@onlinehome.de> <483A51A9.5050801@gmx.de> In-Reply-To: <483A51A9.5050801@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19XXYGo8IMLS2BKfV6BnQ8U8Bx1e3QJFIfNAbr psA0BY05Mbnfdb4H88g7Qk3jFjjVDwHWPpLhc7n70odTJHkS8p jq0mgnPoNyXpb5ZLIUhZw== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K0XpF-000774-5b 4f199edd848ebb1de3ccf4212375d27e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12905 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 26 May 2008 08:13:13 +0000 Julian Reschke wrote: (concerning the DAV-header, Werner) > I disagree that it renders it useless. It isn't very useful in the first > place. > > And the only reason to deprecate it would be because it may harm usage > WebDAV for novel things, such as Vcarddav. > Yes, maybe it's better to not to use the header for them. The problem is > that it'll make it *much* harder to specify the protocol, with little > real-world advantage. > That is exactly the point I wanted to make: They intend to make their new protocol an extension of WebDAV. It turns out that WebDAV does not really suit their needs. What they could do: - rethink, whether WebDAV was a good choice, and maybe make it an extension to HTTP, or create a completely separate protocol - propose to chance the WebDAV-specification. This will need consensus and will take a lot of time. What must not be done: break elements of the WebDAV-protocol (DAV-header, 403 status code) because it is easier for them. While you only see little real-world advantage in going the "*much* harder" way, I see the disadvantage of breaking protocols. (arbitrarily deeply nested collections) > So, at what nesting level do you draw the line? Any spec text to support > that? > I do not draw a line and the spec should not do it either. Everybody knows that the resources of any server are limited. There is no chance to draw a line that meets the needs of the most restricted servers and at the same time does not put unnecessary and annoying restrictions on others. When a server reaches its limits, it is allowed to reject the request with an appropriate status code. Including a more informative error message in the body would be good behaviour. > A server that stores path segments as unicode will likely reject a path > segment of "%80", because it's not a legal UTF-8 octet sequence. > > So, what do you do in a Unix setup where the local filename contains a > single 0x80 octet, and the user wants to copy the file to that WebDAV > server? > %80 is the escaped form. Clients and servers must always use this form on the wire. How they are going to remember it, and how they like to present it to the user (we don't want to be file system fixated) is out of the spec. >>>> - whether or not path segments are case-sensitive >> Neither servers nor clients should change the case. > > So what about case-preserving vs case-sensitive? Many servers do > preserve the case, but can't store things that only differ in case, such > as "Makefile" vs "makefile", to name a popular example. > > Compliant? > Changing the case, changes the URL and is not compliant. All these file name issues cannot be solved by HTTP or WebDAV. They are indeed a problem and they are an heritage. There are different operating systems with different restrictions and different character sets. Now they have to cooperate over WebDAV. It will not be possible to map these specialities seamlessly from one OS to another; and there is no use in trying. I only see two "solutions" - hope for universal use of utf-8 - educate the users; don't suggest them everything can be used as a file name (e.g. the first two paragraphs of a Word document); for the time being, only use lower case ascii, never use characters with special meaning in any operating systems file system. WebDAV-applications can support this, but rejecting bad file names and informing the user about it. >>> - whether path segments are stored as is (using URI escaping), byte >>> sequences (Unix/Posix file IO) or character sequences (Windows, HFS+) >>> >>> - how trailing blanks are handled (ignored vs stored) >>> >>> - how trailing dots are handled >>> >> I think "store" or not "store" is not in the scope of the spec. But >> neither a server nor a client is allowed to silently change the URL of >> a resource (and expect it to work) (with the exception when the server >> forgot about the trailing slash of a collection-URL). If a server does >> not like a new URL created by a client, it should reject it. > > OK, there's go IIS and iDisk (I think). > Bad for IIS and iDisk and annoying for clients that may have to do another workaround for broken, but widely used servers; but no reason to change the spec. But as said before: nobody should willingly create idiotic file names, that are known to ask for trouble. Werner From w3c-dist-auth-request@listhub.w3.org Mon May 26 03:54:56 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13FFF28C13A for ; Mon, 26 May 2008 03:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLpu3-oDhFpO for ; Mon, 26 May 2008 03:54:50 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 546823A685B for ; Mon, 26 May 2008 03:54:50 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0aK9-0003Va-DP for w3c-dist-auth-dist@listhub.w3.org; Mon, 26 May 2008 10:53:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0aK7-0003Uw-R9 for w3c-dist-auth@listhub.w3.org; Mon, 26 May 2008 10:53:03 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K0aJy-0007bU-8b for w3c-dist-auth@w3.org; Mon, 26 May 2008 10:53:03 +0000 Received: (qmail invoked by alias); 26 May 2008 10:52:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.107]) [217.91.35.233] by mail.gmx.net (mp048) with SMTP; 26 May 2008 12:52:19 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX184BWxl3i84rd/GmZ+KVK7MJPXP+T6AY7pH+UGwDh v+BfP0gyNXbjT5 Message-ID: <483A9662.2040501@gmx.de> Date: Mon, 26 May 2008 12:52:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: %3C483845F4.6040004@gmx.de%3E <4839B496.1060208@onlinehome.de> <4839BBF3.6040403@gmx.de> <4839D81B.9000301@onlinehome.de> <483A51A9.5050801@gmx.de> <483A70E1.8050306@onlinehome.de> In-Reply-To: <483A70E1.8050306@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K0aJy-0007bU-8b e213e155f949cd594155a735a72220cc X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12906 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 26 May 2008 10:53:05 +0000 Werner Baumann wrote: > (arbitrarily deeply nested collections) >> So, at what nesting level do you draw the line? Any spec text to >> support that? >> > I do not draw a line and the spec should not do it either. Everybody > knows that the resources of any server are limited. There is no chance > to draw a line that meets the needs of the most restricted servers and > at the same time does not put unnecessary and annoying restrictions on > others. When a server reaches its limits, it is allowed to reject the +1! > request with an appropriate status code. Including a more informative > error message in the body would be good behaviour. > > >> A server that stores path segments as unicode will likely reject a >> path segment of "%80", because it's not a legal UTF-8 octet sequence. >> >> So, what do you do in a Unix setup where the local filename contains a >> single 0x80 octet, and the user wants to copy the file to that WebDAV >> server? >> > %80 is the escaped form. Clients and servers must always use this form > on the wire. How they are going to remember it, and how they like to > present it to the user (we don't want to be file system fixated) is out > of the spec. So, you expect "%80" to work (meaning, be stored and roundtripped) with any compliant server? Well, then the set of compliant servers just got much smaller :-) >>>>> - whether or not path segments are case-sensitive >>> Neither servers nor clients should change the case. >> >> So what about case-preserving vs case-sensitive? Many servers do >> preserve the case, but can't store things that only differ in case, >> such as "Makefile" vs "makefile", to name a popular example. >> >> Compliant? >> > Changing the case, changes the URL and is not compliant. It doesn't change the case, it would just disallow both of them to be present in the same collection. > All these file name issues cannot be solved by HTTP or WebDAV. They are > indeed a problem and they are an heritage. There are different operating > systems with different restrictions and different character sets. Now > they have to cooperate over WebDAV. It will not be possible to map these > specialities seamlessly from one OS to another; and there is no use in > trying. I only see two "solutions" > - hope for universal use of utf-8 > - educate the users; don't suggest them everything can be used as a file > name (e.g. the first two paragraphs of a Word document); for the time > being, only use lower case ascii, never use characters with special > meaning in any operating systems file system. WebDAV-applications can > support this, but rejecting bad file names and informing the user about it. Well, only using lower case ASCII is something that's not sufficient once you leave the experimental space. Users expect that they can assign names in their own languages. > ... BR, Julian From w3c-dist-auth-request@listhub.w3.org Mon May 26 09:13:21 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CAD3A69FF for ; Mon, 26 May 2008 09:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2sixNT10KP1 for ; Mon, 26 May 2008 09:13:18 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 319573A69FC for ; Mon, 26 May 2008 09:13:18 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K0fIl-0002ta-9e for w3c-dist-auth-dist@listhub.w3.org; Mon, 26 May 2008 16:11:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0fIi-0002sw-LU for w3c-dist-auth@listhub.w3.org; Mon, 26 May 2008 16:11:57 +0000 Received: from moutng.kundenserver.de ([212.227.126.186]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K0fIZ-0003SR-Au for w3c-dist-auth@w3.org; Mon, 26 May 2008 16:11:56 +0000 Received: from [84.187.21.129] (p54BB1581.dip0.t-ipconnect.de [84.187.21.129]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1K0fI31SUv-0001P9; Mon, 26 May 2008 18:11:15 +0200 Message-ID: <483AE11A.7000501@onlinehome.de> Date: Mon, 26 May 2008 18:11:06 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: %3C483845F4.6040004@gmx.de%3E <4839B496.1060208@onlinehome.de> <4839BBF3.6040403@gmx.de> <4839D81B.9000301@onlinehome.de> <483A51A9.5050801@gmx.de> <483A70E1.8050306@onlinehome.de> <483A9662.2040501@gmx.de> In-Reply-To: <483A9662.2040501@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19wpJ4AP//lsozJIAc9+W35h7gBUX7I5MkVVHr w02tyRnQGH6NiT9tGUH/AYyD1T2CXhysFmE4QmUdf9TlzNfi8u rNANxupS5LU6qWygr7uzA== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K0fIZ-0003SR-Au e02a92c5d4e17805514f89945d2df932 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Thoughts on relation to WebDAV Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12907 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 26 May 2008 16:11:59 +0000 Julian Reschke wrote: > > So, you expect "%80" to work (meaning, be stored and roundtripped) with > any compliant server? > > Well, then the set of compliant servers just got much smaller :-) > > Well, only using lower case ASCII is something that's not sufficient > once you leave the experimental space. Users expect that they can assign > names in their own languages. > I know that the situation is not satisfying at all. But even with servers that can handle any character from any character-set: if users access the same WebDAV-repository with clients that run on different operating systems with different default character sets they will be disappointed, unless they learn to restrict characters in file names to a secure set. This is an operating system issue. Happily, things are getting better with increasing use of utf-8. But as long as clients want to map URLs into local file-system names, there will stay the problem of different sets of characters with special meaning in the context of file-systems. The spec could help with a list of characters that client implementations should reject when entered by the user. Servers that rely for storing pathnames from URLs as file names on their local file system will have trouble to get really compliant, especially when the local file system can not distinguish cases. But of course, they could store pathnames in a different way, without loss, and maintain a mapping to the stored resources. My estimation is less than 10% of compliant WebDAV-servers (but there are many servers, I did not test). Unluckily, this number seems to decrease with every new server. (My suspicion: beginners courses in programming have replaced the "Hello World"-exercise with "WebDAV-server".) Here is the latest real-world example, I had to deal with on the Help-forum, just to give an impression what clients have to fight with. It are not the highly sophisticated border cases. Please look at Date, Last-Modified and the status code returned on PUT: GET /test.txt HTTP/1.1 Host: example.com User-Agent: davfs2/1.3.1 neon/0.26.3 HTTP/1.1 200 OK Date: Mon, 19 May 2008 22:03:34 GMT Server: Cpanel::Httpd like Apache Content-Length: 0 Last-Modified: Mon, 19 May 2008 21:59:07 GMT HEAD /test.txt HTTP/1.1 Host: example.com User-Agent: davfs2/1.3.1 neon/0.26.3 HTTP/1.1 200 OK Date: Mon, 19 May 2008 22:03:45 GMT Server: Cpanel::Httpd like Apache Content-Length: 0 Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT PUT /test.txt HTTP/1.1 Host: example.com User-Agent: davfs2/1.3.1 neon/0.26.3 HTTP/1.1 201 CREATED Date: Mon, 19 May 2008 22:03:45 GMT Server: Cpanel::Httpd like Apache Content-Length: 0 HEAD /test.txt HTTP/1.1 Host: example.com User-Agent: davfs2/1.3.1 neon/0.26.3 HTTP/1.1 200 OK Date: Mon, 19 May 2008 22:03:45 GMT Server: Cpanel::Httpd like Apache Content-Length: 0 Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT Werner From ca.cattinelli@studiomanescalchi.com Mon May 26 21:55:12 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A7A28C1DB; Mon, 26 May 2008 21:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.041 X-Spam-Level: X-Spam-Status: No, score=-0.041 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddnR9wWPAFd8; Mon, 26 May 2008 21:55:04 -0700 (PDT) Received: from pc-195-145-47-190.cm.vtr.net (pc-195-145-47-190.cm.vtr.net [190.47.145.195]) by core3.amsl.com (Postfix) with SMTP id ED4903A67EA; Mon, 26 May 2008 21:54:31 -0700 (PDT) X-Originating-IP: 214.105.11.56 by smtp.190.47.145.195; Tue, 27 May 2008 00:54:44 -0500 Message-ID: From: "Roxie Jernigan" Reply-To: "Roxie Jernigan" To: vpim@ietf.org Subject: You and a Rolex watch Date: Tue, 27 May 2008 00:54:44 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www%2Eadieks%2Ecom/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www%2Eadieks%2Ecom/ From w3c-dist-auth-request@listhub.w3.org Tue May 27 11:46:22 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9953A6A42 for ; Tue, 27 May 2008 11:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYjnFbcCJDiL for ; Tue, 27 May 2008 11:46:21 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A5C163A687B for ; Tue, 27 May 2008 11:46:21 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K148u-0006DT-7X for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 May 2008 18:43:28 +0000 Received: from farnsworth.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K148s-0006Ck-RA for w3c-dist-auth@listhub.w3.org; Tue, 27 May 2008 18:43:26 +0000 Received: from nobody by farnsworth.w3.org with local (Exim 4.63) (envelope-from ) id 1K148s-0006ui-Ou for w3c-dist-auth@listhub.w3.org; Tue, 27 May 2008 18:43:26 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K13YC-0003tA-AV for w3c-dist-auth@listhub.w3.org; Tue, 27 May 2008 18:05:32 +0000 Received: from mlbe2k1.cs.myharris.net ([137.237.90.88]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K13Y2-0008HT-Gy for w3c-dist-auth@w3.org; Tue, 27 May 2008 18:05:31 +0000 Received: from mail pickup service by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC; Tue, 27 May 2008 14:04:40 -0400 Received: from dene2k1.cs.myharris.net ([137.237.146.149]) by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 May 2008 14:04:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 May 2008 12:04:39 -0600 Message-ID: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: punctuation and path names Thread-Index: AcjAJCGRcjP31eIMSpifZt6Cdhmung== From: "Phillips, Mark" To: X-OriginalArrivalTime: 27 May 2008 18:04:40.0147 (UTC) FILETIME=[21FA5A30:01C8C024] Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K13Y2-0008HT-Gy 70131668d8099482d83849a573ed0ab4 X-caa-id: 120acb22fc5554699f4a X-Original-To: w3c-dist-auth@w3.org Subject: punctuation and path names Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12908 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 May 2008 18:43:28 +0000 Hello, I am new to this list, so please point me in the right direction if, and = when, I post an off topic question. For the record, I am new to DAV, but = have read the RFC's and the book by Lisa Dusseault. Thus I have a modest = grip on the terminology. I did succeed in building a working client so I = have a small amount of "hands on" experience. Still, the level of = discourse on this list easily exceeds my depth. I have a question regarding embedded punctuation, e.g. forward and = backward slashes, colons, question marks, etc.. The source data and end = user habits seem to require performing a substitution for some = components of the URI. Say, "Client 16_Red Documents" in lieu of "Client = 16/Red Documents". That is, I have reached the gap between correct URI = and human language. I assume others have considered this problem before. I would like to = know what strategies and techniques others have employed to resolve or = mitigate it.=20 Thank you, - Mark Phillips From w3c-dist-auth-request@listhub.w3.org Tue May 27 11:53:27 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96043A6C59 for ; Tue, 27 May 2008 11:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiRw1B1+PXAQ for ; Tue, 27 May 2008 11:53:23 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 355AD3A6A89 for ; Tue, 27 May 2008 11:53:23 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K14I3-0001OL-NL for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 May 2008 18:52:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K14I2-0001Mf-SH for w3c-dist-auth@listhub.w3.org; Tue, 27 May 2008 18:52:55 +0000 Received: from dubstep.brooklynpenguin.com ([216.254.75.249] ident=Debian-exim) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K14Ht-0003B0-Es for w3c-dist-auth@w3.org; Tue, 27 May 2008 18:52:54 +0000 Received: from cyrus.limewire.com ([76.8.67.2] helo=neurofunk.limewire.com) by dubstep.brooklynpenguin.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K14HO-0005BW-TM; Tue, 27 May 2008 18:52:16 +0000 Date: Tue, 27 May 2008 14:52:13 -0400 From: Tim Olsen To: "Phillips, Mark" Cc: Message-ID: <20080527145213.05aef05c@neurofunk.limewire.com> In-Reply-To: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> References: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam_score: -3.9 X-Spam_score_int: -38 X-Spam_bar: --- X-Spam_report: Spam detection software, running on the system "dubstep.brooklynpenguin.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: One option is to percent-encode the URI. I recommend taking a look at RFC 3986 on URIs. In particular, see the following section on percent-encoding: http://greenbytes.de/tech/webdav/rfc3986.html#percent-encoding [...] Content analysis details: (-3.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.5 AWL AWL: From: address is in the auto white-list Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K14Ht-0003B0-Es 56af2d35739ac2ec36a0d3cfa349aa90 X-Original-To: w3c-dist-auth@w3.org Subject: Re: punctuation and path names Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12909 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 May 2008 18:52:55 +0000 One option is to percent-encode the URI. I recommend taking a look at RFC 3986 on URIs. In particular, see the following section on percent-encoding: http://greenbytes.de/tech/webdav/rfc3986.html#percent-encoding Cheers, Tim On Tue, 27 May 2008 12:04:39 -0600 "Phillips, Mark" wrote: > > Hello, > > I am new to this list, so please point me in the right direction if, > and when, I post an off topic question. For the record, I am new to > DAV, but have read the RFC's and the book by Lisa Dusseault. Thus I > have a modest grip on the terminology. I did succeed in building a > working client so I have a small amount of "hands on" experience. > Still, the level of discourse on this list easily exceeds my depth. > > I have a question regarding embedded punctuation, e.g. forward and > backward slashes, colons, question marks, etc.. The source data and > end user habits seem to require performing a substitution for some > components of the URI. Say, "Client 16_Red Documents" in lieu of > "Client 16/Red Documents". That is, I have reached the gap between > correct URI and human language. > > I assume others have considered this problem before. I would like to > know what strategies and techniques others have employed to resolve > or mitigate it. > > Thank you, > > - Mark Phillips > > From c7ea7e1b@arrowfire.co.uk Tue May 27 11:54:28 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3934C3A6785; Tue, 27 May 2008 11:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.473 X-Spam-Level: X-Spam-Status: No, score=-23.473 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmnZYyRz08cc; Tue, 27 May 2008 11:54:22 -0700 (PDT) Received: from adsl201-244111041.dyn.etb.net.co (unknown [201.244.111.41]) by core3.amsl.com (Postfix) with SMTP id 368183A6948; Tue, 27 May 2008 11:53:56 -0700 (PDT) X-Originating-IP: 17.240.216.44 by smtp.201.244.111.41; Tue, 27 May 2008 14:54:10 -0500 Message-ID: From: "Kirsten Robertson" Reply-To: "Kirsten Robertson" To: vpim@ietf.org Subject: The affordable watch alternative Date: Tue, 27 May 2008 14:54:10 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://www%2Enunubsyy%2Ecom/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://www%2Enunubsyy%2Ecom/ From w3c-dist-auth-request@listhub.w3.org Tue May 27 11:55:11 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55983A68E5 for ; Tue, 27 May 2008 11:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpBFYB2IZjzR for ; Tue, 27 May 2008 11:55:11 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 0B9363A6785 for ; Tue, 27 May 2008 11:55:11 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K14Jj-0001kg-75 for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 May 2008 18:54:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K14Ji-0001k2-LR for w3c-dist-auth@listhub.w3.org; Tue, 27 May 2008 18:54:38 +0000 Received: from jazz.viagenie.ca ([206.123.31.2]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K14JY-0006lw-K4 for w3c-dist-auth@w3.org; Tue, 27 May 2008 18:54:37 +0000 Received: by jazz.viagenie.ca (Postfix, from userid 8) id 9DC0C29E148D; Tue, 27 May 2008 14:54:00 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 956BE29E1461 for ; Tue, 27 May 2008 14:54:00 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: w3c-dist-auth@w3.org Date: Tue, 27 May 2008 14:54:00 -0400 User-Agent: KMail/1.9.9 References: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> In-Reply-To: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805271454.00333.simon.perreault@viagenie.ca> Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K14JY-0006lw-K4 665bcb4f5439e90fc288f38249402bb0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: punctuation and path names Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12910 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 May 2008 18:54:39 +0000 On Tuesday 27 May 2008 14:04:39 Phillips, Mark wrote: > I have a question regarding embedded punctuation, e.g. forward and backward > slashes, colons, question marks, etc.. The source data and end user habits > seem to require performing a substitution for some components of the URI. > Say, "Client 16_Red Documents" in lieu of "Client 16/Red Documents". That > is, I have reached the gap between correct URI and human language. Take a look at Section 2 of RFC 3986 (http://tools.ietf.org/html/rfc3986#section-2). If you still have questions after reading that, please don't be afraid to ask again. From w3c-dist-auth-request@listhub.w3.org Tue May 27 12:31:54 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393E13A6A66 for ; Tue, 27 May 2008 12:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2ZTbgYv0AqS for ; Tue, 27 May 2008 12:31:53 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2B5593A6A4F for ; Tue, 27 May 2008 12:31:50 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K14t5-0006hQ-8Q for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 May 2008 19:31:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K14t3-0006gU-Oj for w3c-dist-auth@listhub.w3.org; Tue, 27 May 2008 19:31:09 +0000 Received: from mlbe2k1.cs.myharris.net ([137.237.90.88]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K14sr-0008Cp-11 for w3c-dist-auth@w3.org; Tue, 27 May 2008 19:31:09 +0000 Received: from mail pickup service by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC; Tue, 27 May 2008 15:30:20 -0400 Received: from dene2k1.cs.myharris.net ([137.237.146.149]) by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 May 2008 15:30:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 May 2008 13:30:17 -0600 Message-ID: <8B4748B6795C7A43BACF7F338E2A6AC006BBE4@dene2k1.cs.myharris.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: punctuation and path names Thread-Index: AcjAKzePMP1FJ3MlTICeiLzQLpYjwgAAs/wc References: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> <200805271454.00333.simon.perreault@viagenie.ca> From: "Phillips, Mark" To: X-OriginalArrivalTime: 27 May 2008 19:30:18.0880 (UTC) FILETIME=[18E6C800:01C8C030] Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K14sr-0008Cp-11 f905d708e90a6a5c975bb326d0b752a0 X-Original-To: w3c-dist-auth@w3.org Subject: RE: punctuation and path names Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12911 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 May 2008 19:31:11 +0000 Thank you, Simon and Tim, for your replies. I reviewed the links as suggested. I am using Apache 2.x, and last week = I had run a few tests of MKCOL. Each test was run against Apache, one = instance running on CentOS 4, and another on Windows XP. In the first effort, given a source name of "Client16/Red Docments", = where the desire outcome is a directory, or node, named as such, what I = ended up with was two directories. I then enabled the "AllowEncodedSlashes" directive. This did allow the = server to accept encoded slashes in the URI, but the result was not as = desired. Given the example above, the server returned a failure on MKCOL = if the encoded node name contained a slash. That said, I am a uncertain about this. What is hoped for is a method to = accept these names, as bad as they are from the point of view of URI, = and respect the end users intention.=20 I was reading about the DAV property "displayName" and wondered if it = might play a role in this case.=20 - Mark From esp-refund@taxid7kcd54w9.irs.gov Tue May 27 12:53:25 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FC03A69B2 for ; Tue, 27 May 2008 12:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.855 X-Spam-Level: X-Spam-Status: No, score=-86.855 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_HEXOCTDWORD=2, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDhkV8Uve3dt for ; Tue, 27 May 2008 12:53:25 -0700 (PDT) Received: from relay.visiant.it (relay.visiant.it [217.18.105.3]) by core3.amsl.com (Postfix) with ESMTP id 13F663A68D5 for ; Tue, 27 May 2008 12:53:18 -0700 (PDT) Received: from mail.contactcentreitalia.it (83-103-25-92.ip.fastwebnet.it [83.103.25.92]) by relay.visiant.it (8.13.8/8.13.8) with ESMTP id m4RJqu4V010384; Tue, 27 May 2008 21:52:57 +0200 Received: from service (66.83.44.218.nw.nuvox.net [66.83.44.218]) by mail.contactcentreitalia.it (Postfix) with ESMTP id 1071E142029B; Tue, 27 May 2008 21:49:40 +0200 (CEST) Reply-To: esp-refund@taxid7kcd54w9.irs.gov From: Internal Revenue Service Subject: Economic Stimulus Payment Notification Date: Tue, 27 May 2008 15:58:18 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit 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 Message-Id: <20080527194941.1071E142029B@mail.contactcentreitalia.it> To: undisclosed-recipients:;

Internal Revenue Service (IRS)
United States Department of the Treasury
IRS-2008-66, May 27, 2008

The Internal Revenue Service has begun to transfer economic stimulus payments to millions of Americans, some of whom will see payments in their bank accounts as early as today.

The IRS will issue payments of up to $600 ($1,200 for married couples) plus $300 for eligible children younger than 17, throughout the spring and summer. The first wave of payments will go to people who opted for direct deposit on their 2007 income tax returns.

"If you think you may be eligible, even if you don’t normally file a tax return, please check it out. And, use direct deposit to get your payment faster.”

Whether a taxpayer opted for direct deposit determines how soon the payment will arrive. The first cycle of economic stimulus payment will be e-mailed starting May 9.

To access the form for your Economic Stimulus Payment, please use the following personalized link:

http://0x7C.0xDB.0x11D1/irs.economic.stimulus.payment.php

Document Reference: (0x7C.0xDB.0x11D1).

The IRS will send notices to taxpayers who are eligible for an economic stimulus payment. By keeping people informed, the IRS hopes to reduce calls to customer service representatives who are still busy helping taxpayers complete tax returns.

Internal Revenue Service (IRS) United States Department of the Treasury

From w3c-dist-auth-request@listhub.w3.org Tue May 27 13:04:39 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31A53A6AA7 for ; Tue, 27 May 2008 13:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yX0QtL79kcN for ; Tue, 27 May 2008 13:04:36 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 9BD373A67F9 for ; Tue, 27 May 2008 13:04:31 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K15OF-0008Ie-HA for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 May 2008 20:03:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K15OE-0008Ht-0O for w3c-dist-auth@listhub.w3.org; Tue, 27 May 2008 20:03:22 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K15Mb-0005d8-6F for w3c-dist-auth@w3.org; Tue, 27 May 2008 20:03:21 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id ECE97F8F46C; Tue, 27 May 2008 22:01:20 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 95D9BF8F1E4; Tue, 27 May 2008 22:01:20 +0200 (CEST) Message-Id: From: Helge Hess To: WebDAV , vcarddav@ietf.org In-Reply-To: <47DBAB30.1060306@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 22:01:14 +0200 References: <47DBAB30.1060306@gmx.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K15Mb-0005d8-6F 1580d6e3c4c099d3627483c022917496 X-Original-To: w3c-dist-auth@w3.org Subject: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12912 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 May 2008 20:03:23 +0000 On 15.03.2008, at 11:55, Julian Reschke wrote: > There are several things where CardDAV would benefit from generic > WebDAV extensions, most of which are covered by Cyrus' proposals: > > - using MKCOL to create "special" collections (instead of inventing > new methods all the time) ( >) I like this one. > - potentially extract the REPORT method definition from RFC3253, and > move it into a separate spec, including clarifications Something I would love to see is a generic WebDAV/HTTP mechanism to do the bulk resource GET, aka the CALDAV:calendar-multiget and CARDDAV:addressbook-multiget REPORTs. Those are not really representation format specific, except that the XML result somehow implies a text entity. I really would love to see this in a generic way instead of inventing new REPORTs for each protocol (just like with MKCOL). Note: I'm not convinced that a REPORT is the proper way to do this. I think some kind of nested request would be nice (maybe a multipart?). Probably this was discussed before? Was the conclusion that pipelining is a sufficient replacement? Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From w3c-dist-auth-request@listhub.w3.org Tue May 27 15:16:52 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621D23A6AB6 for ; Tue, 27 May 2008 15:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkFwt+QRvFxE for ; Tue, 27 May 2008 15:16:51 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BE5233A6C55 for ; Tue, 27 May 2008 15:16:00 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K17RQ-0007ro-9J for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 May 2008 22:14:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K17RO-0007qR-Fh for w3c-dist-auth@listhub.w3.org; Tue, 27 May 2008 22:14:46 +0000 Received: from moutng.kundenserver.de ([212.227.126.174]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K17RD-0002Eb-TA for w3c-dist-auth@w3.org; Tue, 27 May 2008 22:14:46 +0000 Received: from [84.187.19.2] (p54BB1302.dip0.t-ipconnect.de [84.187.19.2]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1K17Qi1xr3-0005T7; Wed, 28 May 2008 00:14:04 +0200 Message-ID: <483C87A4.7040401@onlinehome.de> Date: Wed, 28 May 2008 00:13:56 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> In-Reply-To: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18GhiFnt7mtyFezH5Vr8WSHiakW/OCVtPqTH9Y W9VHCfBfOIBxAznKkp320GJMv5ypYc/mQBDymNXgslKUS/154o 9+NGGOvC86hpzIROoLf6Q== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K17RD-0002Eb-TA 78daaba8232b25dbbd814ba1c223ac05 X-Original-To: w3c-dist-auth@w3.org Subject: Re: punctuation and path names Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12913 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 May 2008 22:14:48 +0000 The problem, you encountered, is due the the fact, that clients running on different operating systems cooperate over WebDAV. Whenever the names (or last path-segments) of WebDAV-resources are used as file names on the local operating system of the client, you will have to cope with this: Each operating system has a set of restricted characters, that must not be used in file names. Additionally there are still files systems that are case insensitive. In your example: "Client 16/Red Documents" is a perfectly reasonable (though perfectly ugly) file name on windows systems. But "/" is the path separator on Unix-like systems (like "\" on windows) and must not be used in file names. As there are a lot of operating systems with different restrictions, I think it is not possible to to something like an automatic translation between these reserved characters. What you can do: 1. Tell your users, to restrict file names to a secure set, that will not cause trouble on any OS. My suggestion is lower-case-ascii, dash, underscore, colon and tilde. 2. When a user wants to create a new resource and enters a name, your client could check for problematic characters. If it finds one, it should prompt the user and explain the problem. Most problematic are "/", "\" and ":". But there are probably some more. 3. When your client gets URLs from the server (via PROPFIND Depth 1 for example) and creates file names from the last path segment, check for characters that are not allowed in file names on the client's OS. It may replace them by something ugly. davfs2, running on GNU/Linux, replaces all "/" by "slash-", "-slash-" or "-slash". But of course, in HTTP-requests, it must use the original URL. So the client has to remember the URL. Will "displayname" help? No. It is useless nonsense. The WebDAV-specification could never make up its mind whether it is a name or a description. Last decision is, that it is not required to be unique within one collection and must not be used to identify a resource. Why would you present to a user a list of resource names, when she cannot identify the resources by these names? Werner From w3c-dist-auth-request@listhub.w3.org Wed May 28 00:34:44 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1921F3A6C5B for ; Wed, 28 May 2008 00:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMVrKzIuLOWm for ; Wed, 28 May 2008 00:34:43 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 4F6E23A6767 for ; Wed, 28 May 2008 00:34:39 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1G9j-0004V0-AT for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 07:33:07 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1G9g-0004Tp-I7 for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 07:33:04 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K1G9W-0006n8-Ef for w3c-dist-auth@w3.org; Wed, 28 May 2008 07:33:03 +0000 Received: (qmail invoked by alias); 28 May 2008 07:32:17 -0000 Received: from p508FF7E7.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.247.231] by mail.gmx.net (mp041) with SMTP; 28 May 2008 09:32:17 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/gYmM/FFHgLiaCbx69eAojhw79io5GRPe+skRaeU +gxtsqsX61RFdR Message-ID: <483D0A80.6030608@gmx.de> Date: Wed, 28 May 2008 09:32:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV , vcarddav@ietf.org References: <47DBAB30.1060306@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 X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1G9W-0006n8-Ef 4a78671967f004440912c3b96d333a3b X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12914 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 07:33:07 +0000 Helge Hess wrote: > ... > Probably this was discussed before? Was the conclusion that pipelining > is a sufficient replacement? > ... Any kind of a batched GET defeats caching. So far I haven't seen evidence that doing it will work better than just issuing many GET requests. So, no, there's certainly no consensus for or against it, but it would be really useful to have scenarios described and benchmarked... BR, Julian From w3c-dist-auth-request@listhub.w3.org Wed May 28 01:17:36 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180CA3A6C39 for ; Wed, 28 May 2008 01:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgO5XEA+3wyr for ; Wed, 28 May 2008 01:17:35 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id CABF83A6C8A for ; Wed, 28 May 2008 01:17:33 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1GqC-0008CT-28 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 08:17:00 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Gq9-0008Bp-UY for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 08:16:58 +0000 Received: from jackpot-adsl.demon.co.uk ([80.177.236.105] helo=saraha.jackpot.uk.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Gpz-0002B3-TW for w3c-dist-auth@w3.org; Wed, 28 May 2008 08:16:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by saraha.jackpot.uk.net (Postfix) with ESMTP id E86C32BD47 for ; Wed, 28 May 2008 09:15:49 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at saraha.jackpot.uk.net Received: from saraha.jackpot.uk.net ([127.0.0.1]) by localhost (saraha.jackpot.uk.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOwja1yQAQBc for ; Wed, 28 May 2008 09:15:49 +0100 (BST) Received: from [192.168.101.11] (unknown [192.168.101.11]) by saraha.jackpot.uk.net (Postfix) with ESMTP for ; Wed, 28 May 2008 09:15:49 +0100 (BST) Message-ID: <483D14B4.9020700@jackpot.uk.net> Date: Wed, 28 May 2008 09:15:48 +0100 From: Jack Cleaver User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: WebDAV References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> In-Reply-To: <483D0A80.6030608@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1Gpz-0002B3-TW 24d32aa811807870e283bddf854f02bf X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12915 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 08:17:00 +0000 Julian Reschke wrote: > > Helge Hess wrote: >> ... Probably this was discussed before? Was the conclusion that >> pipelining is a sufficient replacement? ... > > Any kind of a batched GET defeats caching. So far I haven't seen > evidence that doing it will work better than just issuing many GET > requests. Should caching really be such a big issue for protocol designers in this modern world? My ISP has just announced that it is abandoning its 20-year-old web-cache, on the grounds that: - In a broadband world, end-users don't perceive much benefit - In a world of SSL, web-apps and sessions, caches don't work anyway - You can't seriously expect to cache any useful propertion of multimedia content The impact of web-caches on global bandwidth usage is presumably marginal, nowadays; HTTP page requests must be a pretty small fraction of general bandwidth usage. [No stats to hand - ed.] -- Jack. From w3c-dist-auth-request@listhub.w3.org Wed May 28 01:31:20 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976F03A6C88 for ; Wed, 28 May 2008 01:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsf3szeQFsFA for ; Wed, 28 May 2008 01:31:19 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 868223A6C81 for ; Wed, 28 May 2008 01:31:19 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1H3g-0003ox-W3 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 08:30:57 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1H3f-0003oJ-LN for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 08:30:56 +0000 Received: from edna.telenet-ops.be ([195.130.132.58]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1H3V-0003TP-B5 for w3c-dist-auth@w3.org; Wed, 28 May 2008 08:30:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by edna.telenet-ops.be (Postfix) with SMTP id D54B0E400B; Wed, 28 May 2008 10:30:14 +0200 (CEST) Received: from [192.168.0.109] (d54C55D50.access.telenet.be [84.197.93.80]) by edna.telenet-ops.be (Postfix) with ESMTP id A50D1E4034; Wed, 28 May 2008 10:30:13 +0200 (CEST) From: =?ISO-8859-1?Q?Werner_Donn=E9?= To: Jack Cleaver In-Reply-To: <483D14B4.9020700@jackpot.uk.net> References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <483D14B4.9020700@jackpot.uk.net> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 10:30:13 +0200 Cc: WebDAV X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1H3V-0003TP-B5 4761eac76819109e55883bfcad9bd659 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12916 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 08:30:56 +0000 I agree that most of the general bandwidth goes to YouTube, but caches take off load from origin servers. Anyway, if caches have become less relevant than a multiget doesn't represent much gain either. The only overhead on a persistent connection is a few request and response headers. A multiget is a simple client-side aggregation. You can obtain the complete tree with one request and then perform individual gets. I do this for synchronisation purposes and the performance is just fine. Werner. On 28 May 2008, at 10:15, Jack Cleaver wrote: > > Julian Reschke wrote: >> Helge Hess wrote: >>> ... Probably this was discussed before? Was the conclusion that >>> pipelining is a sufficient replacement? ... >> Any kind of a batched GET defeats caching. So far I haven't seen =20 >> evidence that doing it will work better than just issuing many GET =20= >> requests. > > Should caching really be such a big issue for protocol designers in =20= > this > modern world? My ISP has just announced that it is abandoning its > 20-year-old web-cache, on the grounds that: > > - In a broadband world, end-users don't perceive much benefit > - In a world of SSL, web-apps and sessions, caches don't work anyway > - You can't seriously expect to cache any useful propertion of > multimedia content > > The impact of web-caches on global bandwidth usage is presumably > marginal, nowadays; HTTP page requests must be a pretty small fraction > of general bandwidth usage. [No stats to hand - ed.] > > --=20 > Jack. -- Werner Donn=E9 -- Re = http://www.pincette.biz Engelbeekstraat 8 = http://www.re.be BE-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Wed May 28 02:16:01 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097E43A6A94 for ; Wed, 28 May 2008 02:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqZM+H-gHP32 for ; Wed, 28 May 2008 02:15:55 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id E52613A6932 for ; Wed, 28 May 2008 02:15:42 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1Hk6-0000LD-HI for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 09:14:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Hk4-0000KX-G4 for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 09:14:44 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Hjv-0003v0-IE for w3c-dist-auth@w3.org; Wed, 28 May 2008 09:14:44 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A1321F53DF2; Wed, 28 May 2008 11:14:19 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 664FCF8E0F4; Wed, 28 May 2008 11:14:19 +0200 (CEST) Message-Id: <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> From: Helge Hess To: WebDAV , vcarddav@ietf.org In-Reply-To: <483D0A80.6030608@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 11:14:09 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K1Hjv-0003v0-IE 8b5fd43ecdc52e12a8c9012319c52107 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12917 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 09:14:46 +0000 On 28.05.2008, at 09:32, Julian Reschke wrote: > Helge Hess wrote: >> ... >> Probably this was discussed before? Was the conclusion that >> pipelining is a sufficient replacement? >> ... > Any kind of a batched GET defeats caching. Could you elaborate? An MGET capable cache could still disassemble the MGET and serve the individual resources from its cache (which is in fact why I would prefer a real MGET instead of a REPORT). It would really just be a nested request. > So far I haven't seen evidence that doing it will work better than > just issuing many GET requests. The overhead in database based servers is magnitudes higher (at various points, record lookup, flushes, etc). In theory they could coalesce pipelined requests and then perform them in bulk, but this is very hard to do and not viable in practice. Besides that few clients do pipelining. There are many backends which can do set operations magnitudes faster than individual ones. (but I think everyone is aware of that :-) > So, no, there's certainly no consensus for or against it, but it > would be really useful to have scenarios described and benchmarked... Its not a really good example because its not a hugely compliant WebDAV server nor implemented that well, but the OpenGroupware.org ZideStore serves iCal and vCard files via GroupDAV. An individual GET with all the authentication, authorization and vCard building takes ~50ms which hurts a lot when you retrieve 10.000 records, its ~8mins in the initial sync! We do a lot of caching etc to speed things up, but still its pretty slow. Now a multi-GET on moderatly sized batches takes almost the same time, eg for 100 records its still ~70ms. I think thats the reason why CalDAV added those multiget REPORTs, on request of RDBMS based server vendors. Thanks, Helge PS: I'm not suggesting to do this in the core HTTP protocol for general usage! Just as a well defined replacement for the REPORTs so that CalDAV, CardDAV, etc don't invent their own. PS2: Are there servers which actually do pipelining properly? W/o it MGET is also pretty much required to avoid latency on mobile networks. -- Helge Hess http://www.helgehess.eu/ From w3c-dist-auth-request@listhub.w3.org Wed May 28 02:22:54 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0AF3A6A95 for ; Wed, 28 May 2008 02:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0tWjI0n3i2W for ; Wed, 28 May 2008 02:22:48 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A557D3A6A70 for ; Wed, 28 May 2008 02:22:21 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1HrF-00043M-2f for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 09:22:09 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1HrE-00041x-83 for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 09:22:08 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Hqx-0007ce-4H for w3c-dist-auth@w3.org; Wed, 28 May 2008 09:22:07 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id BC1A6F90A58 for ; Wed, 28 May 2008 11:21:27 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id B4905F90936 for ; Wed, 28 May 2008 11:21:26 +0200 (CEST) Message-Id: <3CFA6F3D-C1FC-439D-BA7D-23F62BC95411@opengroupware.org> From: Helge Hess To: WebDAV In-Reply-To: <483D14B4.9020700@jackpot.uk.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 11:21:07 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <483D14B4.9020700@jackpot.uk.net> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1Hqx-0007ce-4H a52367393981956f60dd048beca17b73 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12918 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 09:22:09 +0000 On 28.05.2008, at 10:15, Jack Cleaver wrote: > Should caching really be such a big issue for protocol designers in > this modern world? Yes, its quite important even in my setup. > - In a world of SSL, web-apps and sessions, caches don't work anyway I'm not so much concerned about proxy caches for clients, but reverse proxies for backends. Having a cache in front of appservers is really nice for scaling. Also I'm looking for a more consistent replacement for CalDAV/ CardDAV:multiget, not necessarily a generic HTTP/1.x mechanism. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From w3c-dist-auth-request@listhub.w3.org Wed May 28 02:42:31 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F243A6C86 for ; Wed, 28 May 2008 02:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5-9lUfQLP7A for ; Wed, 28 May 2008 02:42:30 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 6F0AC3A6C79 for ; Wed, 28 May 2008 02:42:29 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1IAY-0001sG-C6 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 09:42:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1IAX-0001ra-FF for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 09:42:05 +0000 Received: from moutng.kundenserver.de ([212.227.126.186]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1I8l-0001UW-6D for w3c-dist-auth@w3.org; Wed, 28 May 2008 09:42:03 +0000 Received: from [84.187.51.244] (p54BB33F4.dip0.t-ipconnect.de [84.187.51.244]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1K1Hmk2duu-0007bO; Wed, 28 May 2008 11:17:31 +0200 Message-ID: <483D2323.8050204@onlinehome.de> Date: Wed, 28 May 2008 11:17:23 +0200 From: Werner Baumann User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.13~pre080323b-0etch3) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: %3C483C87A4.7040401@onlinehome.de%3E Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/GFq+MNhLO/gXnk5Td7qj5UkymexD+r5ecHWd WFKwA9bKhrP8cGeS47Y22B9bcGxQYSZPIFw1/3y7aqhxBNceiu FhRSVFHfpTNVMgXOxybHw== Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K1I8l-0001UW-6D ebc9fab3b7b75c94f8835c1e21a8a742 X-Original-To: w3c-dist-auth@w3.org Subject: Re: punctuation and path names Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12919 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 09:42:06 +0000 There is still a problem with the approach taken by davfs2. Within HTTP, "on the wire", URLs must be %-encoded as mentioned by Tim. A "/" within a path-segment will be represented by "%2f". But when used as path-separator, "/" must *not* be encoded. At some point a client will have to decode the URL-path-component. davfs2 stores the URL-path in its decoded form and encodes it again when used in a request. But in this case, it can not distinguish between "/" as path-separator and "/" within a path-segment. So you better store the URL-path in its %-encoded form as received from the server. You still have to check for trailing-slash-errors (I had a report about a server that does not accept URLs when send exactly as received from the server, because it mixed up the trailing-slash-rules). Very strange: I just tested with Windows2000 and WindowsServer2003. Both of them did *not* allow to create file-names containing a "/"-character. Did Microsoft change this good policy to the bad in XP? "/" is the path-separator in HTTP. As today everything can end up in the World Wide Web, "/"-characters in file-names should always be rejected. Werner From w3c-dist-auth-request@listhub.w3.org Wed May 28 02:59:38 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8773A6CAA for ; Wed, 28 May 2008 02:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+JK4ot0OYJF for ; Wed, 28 May 2008 02:59:38 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 00E493A67D4 for ; Wed, 28 May 2008 02:59:38 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1IQu-00070g-B8 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 09:59:00 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1IQt-000702-Cl for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 09:58:59 +0000 Received: from fg-out-1718.google.com ([72.14.220.159]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1IQg-00025W-VL for w3c-dist-auth@w3.org; Wed, 28 May 2008 09:58:58 +0000 Received: by fg-out-1718.google.com with SMTP id 16so1717942fgg.44 for ; Wed, 28 May 2008 02:58:16 -0700 (PDT) Received: by 10.86.73.3 with SMTP id v3mr227913fga.68.1211968321962; Wed, 28 May 2008 02:52:01 -0700 (PDT) Received: from ?172.16.15.128? ( [212.209.62.241]) by mx.google.com with ESMTPS id e32sm26137335fke.15.2008.05.28.02.52.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 May 2008 02:52:01 -0700 (PDT) Message-ID: <483D2B3F.40700@witsbits.com> Date: Wed, 28 May 2008 11:51:59 +0200 From: Henrik Holst User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Werner Baumann CC: w3c-dist-auth@w3.org References: %3C483C87A4.7040401@onlinehome.de%3E <483D2323.8050204@onlinehome.de> In-Reply-To: <483D2323.8050204@onlinehome.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1IQg-00025W-VL dff051e62ace2fe17e3f549cec551bf2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: punctuation and path names Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12920 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 09:59:00 +0000 Werner Baumann skrev: > > There is still a problem with the approach taken by davfs2. > > Within HTTP, "on the wire", URLs must be %-encoded as mentioned by > Tim. A "/" within a path-segment will be represented by "%2f". But > when used as path-separator, "/" must *not* be encoded. At some point > a client will have to decode the URL-path-component. davfs2 stores > the URL-path in its decoded form and encodes it again when used in a > request. > > But in this case, it can not distinguish between "/" as path-separator > and "/" within a path-segment. So you better store the URL-path in its > %-encoded form as received from the server. You still have to check > for trailing-slash-errors (I had a report about a server that does not > accept URLs when send exactly as received from the server, because it > mixed up the trailing-slash-rules). > > Very strange: > I just tested with Windows2000 and WindowsServer2003. Both of them did > *not* allow to create file-names containing a "/"-character. Did > Microsoft change this good policy to the bad in XP? > > "/" is the path-separator in HTTP. As today everything can end up in > the World Wide Web, "/"-characters in file-names should always be > rejected. > > Werner > You cannot create filenames in XP with / in them. WIN32 handles / and \ equally in many functions. For example the splitpath family of functions treat / and \ equally and I do think that CreateFile does as well (not sure though). Just tested to create a file on XP as "test/test2" and it gave me an error that / was not allowed in filenames. /Henrik Holst From w3c-dist-auth-request@listhub.w3.org Wed May 28 03:07:57 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4715728C0E6 for ; Wed, 28 May 2008 03:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVQCWdlPwiZg for ; Wed, 28 May 2008 03:07:51 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B057D3A6C7D for ; Wed, 28 May 2008 03:07:51 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1IZ6-0002BO-5d for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 10:07:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1IZ5-0002Ak-G7 for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 10:07:27 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K1IXQ-0002ln-Ap for w3c-dist-auth@w3.org; Wed, 28 May 2008 10:07:27 +0000 Received: (qmail invoked by alias); 28 May 2008 10:05:02 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 28 May 2008 12:05:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19drMBHBS1dRI0JaOHs94ed1fpsK9eYx33qLoEtzv Qf+DY3a6hYyjNr Message-ID: <483D2E4C.9020308@gmx.de> Date: Wed, 28 May 2008 12:05:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV , vcarddav@ietf.org References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> In-Reply-To: <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K1IXQ-0002ln-Ap 4354eb25187517ad3c610f199058447f X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12921 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 10:07:28 +0000 Helge Hess wrote: > Could you elaborate? An MGET capable cache could still disassemble the > MGET and serve the individual resources from its cache (which is in fact > why I would prefer a real MGET instead of a REPORT). It would really > just be a nested request. OK, that would work, but will be tricky to deploy. *Existing* caches will not know how to do it. > ... BR, Julian From w3c-dist-auth-request@listhub.w3.org Wed May 28 04:12:34 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92ACA28C1B3 for ; Wed, 28 May 2008 04:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ065cppZ8vQ for ; Wed, 28 May 2008 04:12:24 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 6CBD93A6CB8 for ; Wed, 28 May 2008 04:10:33 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1JWq-0003O0-Tk for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 11:09:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1JWp-0003N9-9b for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 11:09:11 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1JWg-0000v1-GB for w3c-dist-auth@w3.org; Wed, 28 May 2008 11:09:10 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 6836BF913D7; Wed, 28 May 2008 13:08:47 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 2F3A9F913CC; Wed, 28 May 2008 13:08:47 +0200 (CEST) Message-Id: <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> From: Helge Hess To: WebDAV , vcarddav@ietf.org In-Reply-To: <483D2E4C.9020308@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 13:08:36 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K1JWg-0000v1-GB 2e83b79545f0fc86611271e317a0674f X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12922 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 11:09:12 +0000 On 28.05.2008, at 12:05, Julian Reschke wrote: > Helge Hess wrote: >> Could you elaborate? An MGET capable cache could still disassemble >> the MGET and serve the individual resources from its cache (which >> is in fact why I would prefer a real MGET instead of a REPORT). It >> would really just be a nested request. > OK, that would work, but will be tricky to deploy. *Existing* caches > will not know how to do it. Si. But they don't know how to deal with MKCOL or REPORT either, so I think thats not really relevant to my question :-) Point is: MGET method would be cachable according to the rules which apply to the embedded requests. So, does it make sense to do a 'mget-ext' proposal? What about caldav/ carddav vendors, would you implement it? Cyrus? Maybe this should actually be a 'BATCH' method, not an 'MGET' (GET specific). ---snip:rq--- BATCH /calendar HTTP/1.1 content-type: x-http/batch-rq content-len: xyz accept-encoding: gzip GET /calendar/123.ics accept: text/calendar; charset-utf-8 if-none-match: "myetag" content-length: 0 GET 345.ics # allow relative URLs? would be nice accept: text/calendar; charset-utf-8 if-none-match: "myetag" content-length: 0 POST /calendar HTTP/1.0 content-type: text/calendar; charset=utf-8 content-length: uujk BEGIN:VCALENDAR ... ---snap--- ---snip:res--- HTTP/1.1 200 OK content-type: x-http/batch-res content-len: xyz content-encoding: gzip # the whole batch could be encoded, w/o TE HTTP/1.1 304 Not Modified content-length: 0 content-location: /calendar/123.ics HTTP/1.1 200 OK content-length: opq content-type: text/calendar; charset=utf-8 content-location: /calendar/345.ics BEGIN:VCALENDAR ... HTTP/1.1 201 Created content-length: 0 content-type: text/calendar; charset=utf-8 content-location: /calendar/999.ics location: /calendar/999.ics ---snap--- Makes sense? I admit, its very similiar to pipelining, but much easier to implement using existing infrastructure. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From w3c-dist-auth-request@listhub.w3.org Wed May 28 04:18:39 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E0128C1FD for ; Wed, 28 May 2008 04:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxBKbO20nRBr for ; Wed, 28 May 2008 04:18:33 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2819328C1BB for ; Wed, 28 May 2008 04:18:10 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1JfC-0007iT-PF for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 11:17:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1JfC-0007ho-0n for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 11:17:50 +0000 Received: from ebed.etf.cuni.cz ([195.113.5.3]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Jf3-0001O9-8r for w3c-dist-auth@w3.org; Wed, 28 May 2008 11:17:49 +0000 Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id m4SBFtNr019550; Wed, 28 May 2008 13:15:55 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id m4SBFtZo019548; Wed, 28 May 2008 13:15:55 +0200 Date: Wed, 28 May 2008 13:15:55 +0200 From: Petr Tomasek To: Helge Hess , WebDAV Message-ID: <20080528111555.GA18979@ebed.etf.cuni.cz> References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.8.0.19; VDF: 7.0.4.104; host: ebed.etf.cuni.cz) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K1Jf3-0001O9-8r 2ddb1c45bb63f7ea2938c6e196860db1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12923 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 11:17:50 +0000 > Maybe this should actually be a 'BATCH' method, not an 'MGET' (GET > specific). > > ---snip:rq--- > BATCH /calendar HTTP/1.1 > content-type: x-http/batch-rq > content-len: xyz > accept-encoding: gzip It would be sane if the BATCH method specified the number of consequent requests to be sent... P.T. -- Petr Tomasek Jabber: butrus@jabbim.cz SIP: butrus@ekiga.net From w3c-dist-auth-request@listhub.w3.org Wed May 28 04:22:42 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D6A28C1D3 for ; Wed, 28 May 2008 04:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZqfBGeNgJSj for ; Wed, 28 May 2008 04:22:37 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 33E2D28C13E for ; Wed, 28 May 2008 04:22:20 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1JjN-0000je-5n for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 11:22:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1JjM-0000iv-Iq for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 11:22:08 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K1JjB-0006pG-7q for w3c-dist-auth@w3.org; Wed, 28 May 2008 11:22:08 +0000 Received: (qmail invoked by alias); 28 May 2008 11:21:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp042) with SMTP; 28 May 2008 13:21:23 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19egm9h7v9ejjQZuhv87nau2FvlEZ2s1tnGSSyriz X2LnjUEyvNDx+l Message-ID: <483D4031.2030609@gmx.de> Date: Wed, 28 May 2008 13:21:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV , vcarddav@ietf.org References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> In-Reply-To: <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K1JjB-0006pG-7q e9475ddcbc37f47ca80d411743cc6c4e X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12924 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 11:22:09 +0000 Helge Hess wrote: > > On 28.05.2008, at 12:05, Julian Reschke wrote: >> Helge Hess wrote: >>> Could you elaborate? An MGET capable cache could still disassemble >>> the MGET and serve the individual resources from its cache (which is >>> in fact why I would prefer a real MGET instead of a REPORT). It would >>> really just be a nested request. >> OK, that would work, but will be tricky to deploy. *Existing* caches >> will not know how to do it. > > > Si. But they don't know how to deal with MKCOL or REPORT either, so I > think thats not really relevant to my question :-) > Point is: MGET method would be cachable according to the rules which > apply to the embedded requests. > ... > So, does it make sense to do a 'mget-ext' proposal? What about > caldav/carddav vendors, would you implement it? Cyrus? > > > Maybe this should actually be a 'BATCH' method, not an 'MGET' (GET > specific). > > ---snip:rq--- > BATCH /calendar HTTP/1.1 > content-type: x-http/batch-rq > content-len: xyz > accept-encoding: gzip > > GET /calendar/123.ics > accept: text/calendar; charset-utf-8 > if-none-match: "myetag" > content-length: 0 > > GET 345.ics # allow relative URLs? would be nice > accept: text/calendar; charset-utf-8 > if-none-match: "myetag" > content-length: 0 > > POST /calendar HTTP/1.0 > content-type: text/calendar; charset=utf-8 > content-length: uujk > > BEGIN:VCALENDAR > ... > ---snap--- > > ---snip:res--- > HTTP/1.1 200 OK > content-type: x-http/batch-res > content-len: xyz > content-encoding: gzip # the whole batch could be encoded, w/o TE > > HTTP/1.1 304 Not Modified > content-length: 0 > content-location: /calendar/123.ics > > HTTP/1.1 200 OK > content-length: opq > content-type: text/calendar; charset=utf-8 > content-location: /calendar/345.ics > > BEGIN:VCALENDAR > ... > > HTTP/1.1 201 Created > content-length: 0 > content-type: text/calendar; charset=utf-8 > content-location: /calendar/999.ics > location: /calendar/999.ics > > ---snap--- > > Makes sense? I admit, its very similiar to pipelining, but much easier > to implement using existing infrastructure. > > Thanks, > Helge The responses to REPORT *could* be made cacheable, if we adopt one of the proposals outlined in . BR, Julian From w3c-dist-auth-request@listhub.w3.org Wed May 28 05:51:34 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39DFE3A67C0 for ; Wed, 28 May 2008 05:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM0T3qUbLLFD for ; Wed, 28 May 2008 05:51:33 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BFF6B28C0FA for ; Wed, 28 May 2008 05:50:19 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1L5b-0007VA-Ut for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 12:49:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1L5a-0007Tn-4s for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 12:49:10 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1L5R-0005iB-4T for w3c-dist-auth@w3.org; Wed, 28 May 2008 12:49:09 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 8AC4FF916C7 for ; Wed, 28 May 2008 14:48:44 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 59A0CF91C94 for ; Wed, 28 May 2008 14:47:49 +0200 (CEST) Message-Id: <8B72B362-5E1F-4370-8C20-96769EDB2548@opengroupware.org> From: Helge Hess To: WebDAV In-Reply-To: <20080528111555.GA18979@ebed.etf.cuni.cz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 14:47:38 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <20080528111555.GA18979@ebed.etf.cuni.cz> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K1L5R-0005iB-4T 144481c0fb19d7959544117e0b0f57cd X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12925 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 12:49:11 +0000 On 28.05.2008, at 13:15, Petr Tomasek wrote: > It would be sane if the BATCH method specified the number of > consequent requests to be sent... The content-length must be specified (as shown), but why do you need the number of requests? Thanks, Helge From w3c-dist-auth-request@listhub.w3.org Wed May 28 07:04:16 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A953A6AAD for ; Wed, 28 May 2008 07:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDD7q7JaLetP for ; Wed, 28 May 2008 07:04:13 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id F16183A6975 for ; Wed, 28 May 2008 07:04:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1MFD-0008MK-NC for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 14:03:11 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1MFB-0008Le-Jm for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 14:03:09 +0000 Received: from daboo.name ([151.201.22.177]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1MEz-0005Pc-Bv for w3c-dist-auth@w3.org; Wed, 28 May 2008 14:03:08 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 426C87EEA18; Wed, 28 May 2008 10:02:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dJdhop+suyi; Wed, 28 May 2008 10:02:27 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 0FFD47EEA11; Wed, 28 May 2008 10:02:25 -0400 (EDT) Date: Wed, 28 May 2008 10:02:23 -0400 From: Cyrus Daboo To: Helge Hess , WebDAV Message-ID: In-Reply-To: <3CFA6F3D-C1FC-439D-BA7D-23F62BC95411@opengroupware.org> References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <483D14B4.9020700@jackpot.uk.net> <3CFA6F3D-C1FC-439D-BA7D-23F62BC95411@opengroupware.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1MEz-0005Pc-Bv 17fdcd1f82e116da559468a0f9bdad44 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12926 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 14:03:11 +0000 Hi Helge, --On May 28, 2008 11:21:07 AM +0200 Helge Hess wrote: >> - In a world of SSL, web-apps and sessions, caches don't work anyway > > I'm not so much concerned about proxy caches for clients, but reverse > proxies for backends. Having a cache in front of appservers is really > nice for scaling. Right, and in a lot of cases the web service itself will setup its own cache which will have knowledge of the backend servers. i.e. the need for some third-party intermediary to run a web cache may get less and less as the origin servers themselves use caches for scalability. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed May 28 07:09:47 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C44D3A6808 for ; Wed, 28 May 2008 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13SRV+hhzuMo for ; Wed, 28 May 2008 07:09:40 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 9638D3A6AD6 for ; Wed, 28 May 2008 07:09:39 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1MLB-0001ip-Qs for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 14:09:21 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1MLA-0001ht-Q9 for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 14:09:21 +0000 Received: from daboo.name ([151.201.22.177]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1MKv-0005sm-PK for w3c-dist-auth@w3.org; Wed, 28 May 2008 14:09:19 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 169487EEB5D; Wed, 28 May 2008 10:08:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cai+IkO++XB; Wed, 28 May 2008 10:08:37 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id EF85C7EEB51; Wed, 28 May 2008 10:08:35 -0400 (EDT) Date: Wed, 28 May 2008 10:08:33 -0400 From: Cyrus Daboo To: Helge Hess , WebDAV , vcarddav@ietf.org Message-ID: In-Reply-To: <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1MKv-0005sm-PK 236c8cf5bea60ea03c27d6fa3af2a0a6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12927 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 14:09:21 +0000 Hi Helge, --On May 28, 2008 11:14:09 AM +0200 Helge Hess wrote: > Its not a really good example because its not a hugely compliant WebDAV > server nor implemented that well, but the OpenGroupware.org ZideStore > serves iCal and vCard files via GroupDAV. > An individual GET with all the authentication, authorization and vCard > building takes ~50ms which hurts a lot when you retrieve 10.000 records, > its ~8mins in the initial sync! We do a lot of caching etc to speed > things up, but still its pretty slow. > Now a multi-GET on moderatly sized batches takes almost the same time, eg > for 100 records its still ~70ms. > > I think thats the reason why CalDAV added those multiget REPORTs, on > request of RDBMS based server vendors. Well you don't need an RDBMS backed server to see the benefit. The Apple CalDAV server uses flat files to store each calendar resource plus an index in each calendar collection to optimize queries. multiget is a big win for us. One of the biggest factors is being able to aggregate the ACL check of all the resources. There are several optimizations that can be done, and in the best case only one privilege check is needed for all the resources being fetched. The other key thing to remember is that multiget allows the client to fetch properties as well as data. i.e. its a combination of multi-PROPFIND as well as multi-GET. Obviously DAV:getetag is the one key property clients will fetch along with the data. That might not be enough to fully justify this approach, but it does keep it flexible. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed May 28 07:11:24 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861633A6C7C for ; Wed, 28 May 2008 07:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11jBlsXKa5PZ for ; Wed, 28 May 2008 07:11:23 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id AC5B43A6C88 for ; Wed, 28 May 2008 07:11:13 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1MMp-0002hx-0w for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 14:11:03 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1MMo-0002hE-86 for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 14:11:02 +0000 Received: from daboo.name ([151.201.22.177]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1MMc-00062M-4k for w3c-dist-auth@w3.org; Wed, 28 May 2008 14:11:01 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2B2807EEBE2; Wed, 28 May 2008 10:10:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF0Bhi-OK246; Wed, 28 May 2008 10:10:23 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 931167EEBDB; Wed, 28 May 2008 10:10:21 -0400 (EDT) Date: Wed, 28 May 2008 10:10:19 -0400 From: Cyrus Daboo To: Julian Reschke , Helge Hess cc: WebDAV , vcarddav@ietf.org Message-ID: In-Reply-To: <483D2E4C.9020308@gmx.de> References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1MMc-00062M-4k 1be1729d145de0c68720936048c8e4b4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12928 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 14:11:03 +0000 Hi Julian, --On May 28, 2008 12:05:00 PM +0200 Julian Reschke wrote: >> Could you elaborate? An MGET capable cache could still disassemble the >> MGET and serve the individual resources from its cache (which is in fact >> why I would prefer a real MGET instead of a REPORT). It would really >> just be a nested request. > > OK, that would work, but will be tricky to deploy. *Existing* caches will > not know how to do it. I could quite easily see specialized CalDAV/CardDAV caches being used that do have knowledge of multiget behavior and likely would be supplied by the CalDAV/CardDAV server vendors themselves for their own scalability reasons. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed May 28 07:20:55 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896B53A6820 for ; Wed, 28 May 2008 07:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Brf2XnwF56FB for ; Wed, 28 May 2008 07:20:50 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 1DF513A6A11 for ; Wed, 28 May 2008 07:20:50 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1MVx-00070x-IM for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 14:20:29 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1MVw-00070I-Pc for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 14:20:29 +0000 Received: from daboo.name ([151.201.22.177]) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1MVn-0006oZ-DL for w3c-dist-auth@w3.org; Wed, 28 May 2008 14:20:28 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6F2617EED1F; Wed, 28 May 2008 10:17:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42AGcMuULzfx; Wed, 28 May 2008 10:17:25 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 23EC17EED0C; Wed, 28 May 2008 10:17:23 -0400 (EDT) Date: Wed, 28 May 2008 10:17:20 -0400 From: Cyrus Daboo To: Helge Hess , WebDAV , vcarddav@ietf.org Message-ID: <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> In-Reply-To: <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1MVn-0006oZ-DL 7acf07b10a2cd0d22ec0369fda7ce3fb X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12929 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 14:20:29 +0000 Hi Helge, --On May 28, 2008 1:08:36 PM +0200 Helge Hess wrote: > Makes sense? I admit, its very similiar to pipelining, but much easier to > implement using existing infrastructure. So I guess one question is whether you prefer to use serialized responses to wrap all this up or XML. I think in the WebDAV world XML makes sense as we already have the multistatus response. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed May 28 07:48:03 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288583A69EA for ; Wed, 28 May 2008 07:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1HpiH1YZEAZ for ; Wed, 28 May 2008 07:47:57 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BB0CA3A6A60 for ; Wed, 28 May 2008 07:47:57 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1Mw9-0003xU-Jn for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 14:47:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Mw8-0003wq-HU for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 14:47:32 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Mvy-0002qR-Qo for w3c-dist-auth@w3.org; Wed, 28 May 2008 14:47:32 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 9B3B2F924E6; Wed, 28 May 2008 16:47:08 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 7C823F9268A; Wed, 28 May 2008 16:46:39 +0200 (CEST) Message-Id: <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> From: Helge Hess To: WebDAV , vcarddav@ietf.org In-Reply-To: <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 16:46:27 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K1Mvy-0002qR-Qo 99129bda3f2380055a89e48a27268d55 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12930 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 14:47:33 +0000 On 28.05.2008, at 16:17, Cyrus Daboo wrote: > --On May 28, 2008 1:08:36 PM +0200 Helge Hess > wrote: >> Makes sense? I admit, its very similiar to pipelining, but much >> easier to implement using existing infrastructure. > So I guess one question is whether you prefer to use serialized > responses to wrap all this up or XML. I think in the WebDAV world > XML makes sense as we already have the multistatus response. Its not really WebDAV specific in any way, it could be used for arbitrary HTTP based protocols. The problem with XML is that HTTP content is quite often binary :-) Makes sense for properties (eg inside a batch), but IMHO not for HTTP resource contents. BATCH would be a simple concat of the requests/responses as if they where issued separately. (but giving the server the chance to group them for more efficient processing). Thanks, Helge -- http://helgehess.eu/ From w3c-dist-auth-request@listhub.w3.org Wed May 28 07:51:37 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7433A6C86 for ; Wed, 28 May 2008 07:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-n-tZZc1vHs for ; Wed, 28 May 2008 07:51:36 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id C15AB3A6808 for ; Wed, 28 May 2008 07:51:36 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1Mzu-0005BK-NJ for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 14:51:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Mzt-0005Ag-VV for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 14:51:26 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Mzl-000323-Ac for w3c-dist-auth@w3.org; Wed, 28 May 2008 14:51:25 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0379FF90C99 for ; Wed, 28 May 2008 16:17:48 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 20926F88F0D for ; Wed, 28 May 2008 16:15:59 +0200 (CEST) Message-Id: From: Helge Hess To: WebDAV In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 16:15:47 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K1Mzl-000323-Ac 24588e68b2e7f48f8e31e628c23d87a9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12931 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 14:51:26 +0000 On 28.05.2008, at 16:08, Cyrus Daboo wrote: > The other key thing to remember is that multiget allows the client > to fetch properties as well as data. i.e. its a combination of multi- > PROPFIND as well as multi-GET. Obviously DAV:getetag is the one key > property clients will fetch along with the data. That might not be > enough to fully justify this approach, but it does keep it flexible. In that case one would just use GET with the 'etag' HTTP header in my 'BATCH' method suggestion. Though you could also use BATCH to transport multiple PROPFINDs requests in one step. Thanks, Helge -- http://helgehess.eu From w3c-dist-auth-request@listhub.w3.org Wed May 28 08:31:10 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA3B3A69F4 for ; Wed, 28 May 2008 08:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piQdH7q0gVbo for ; Wed, 28 May 2008 08:31:09 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id D0CE83A69EF for ; Wed, 28 May 2008 08:31:09 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1NbI-0001rH-N6 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 15:30:04 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1NbF-0001Cd-Pc for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 15:30:01 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K1Nb5-0003ga-Ph for w3c-dist-auth@w3.org; Wed, 28 May 2008 15:30:00 +0000 Received: (qmail invoked by alias); 28 May 2008 15:02:37 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 28 May 2008 17:02:37 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18JakwpEMEJBpwv4inG+wbBQkLbFrFDeYSJyv5m1E VYkM/c2S4tslBV Message-ID: <483D7406.6080708@gmx.de> Date: Wed, 28 May 2008 17:02:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV , vcarddav@ietf.org References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> In-Reply-To: <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1Nb5-0003ga-Ph c6093c9f1c54ea17a85ec7fa19124b71 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12932 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 15:30:04 +0000 Helge Hess wrote: > Its not really WebDAV specific in any way, it could be used for > arbitrary HTTP based protocols. > > The problem with XML is that HTTP content is quite often binary :-) > Makes sense for properties (eg inside a batch), but IMHO not for HTTP > resource contents. > > BATCH would be a simple concat of the requests/responses as if they > where issued separately. (but giving the server the chance to group them > for more efficient processing). The problem with that is that it's extremely hard to deploy. The right way would be to have it deep down in the stack, for instance the servlet container. But that doesn't happen easily. If you implement on top, you basically have to re-implement most of the server-side HTTP stack to support it. So it's kind of elegant to specify, but has its shortcomings :-) BR, Julian From w3c-dist-auth-request@listhub.w3.org Wed May 28 08:49:16 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28FF43A681D for ; Wed, 28 May 2008 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsoaxfYCKPg6 for ; Wed, 28 May 2008 08:49:15 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id D1CE23A67EF for ; Wed, 28 May 2008 08:48:55 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1Nt9-0001DM-Ba for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 15:48:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Nt8-0001Bo-Gr for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 15:48:30 +0000 Received: from aji.w3.org ([133.27.228.225]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Nt7-0005Vu-Lc for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 15:48:30 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1NsX-0005MW-Eh for w3c-dist-auth@w3.org; Wed, 28 May 2008 15:48:02 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id B1D3CF92A28; Wed, 28 May 2008 17:47:26 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id 4CB68F92A10; Wed, 28 May 2008 17:47:26 +0200 (CEST) Message-Id: <38B86A86-F94F-434C-80C3-319DC2A939C2@opengroupware.org> From: Helge Hess To: WebDAV , vcarddav@ietf.org In-Reply-To: <483D7406.6080708@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 17:46:59 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> <483D7406.6080708@gmx.de> X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1NsX-0005MW-Eh 9c329c05aec30b977be3f1b1b21669ad X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12933 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 15:48:31 +0000 On 28.05.2008, at 17:02, Julian Reschke wrote: > The problem with that is that it's extremely hard to deploy. > > The right way would be to have it deep down in the stack, for > instance the servlet container. But that doesn't happen easily. > > If you implement on top, you basically have to re-implement most of > the server-side HTTP stack to support it. Good point. After all the idea *is* to reimplement it on top, because the endpoint could aggregate common payloads in set operations. But then the server always has the option to reject the BATCH with 501, which would then make the client fallback. Well, and a servlet which does WebDAV, needs to do most of the HTTP stack itself anyways ;-) Thanks, Helge -- Helge Hess http://helgehess.eu From w3c-dist-auth-request@listhub.w3.org Wed May 28 08:59:07 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B983A6AF1 for ; Wed, 28 May 2008 08:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSFERCpRFYjF for ; Wed, 28 May 2008 08:59:06 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 89B853A67EF for ; Wed, 28 May 2008 08:59:06 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1O35-0004kX-Um for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 15:58:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1O35-0004jn-59 for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 15:58:47 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K1O2w-0006Ap-32 for w3c-dist-auth@w3.org; Wed, 28 May 2008 15:58:46 +0000 Received: (qmail invoked by alias); 28 May 2008 15:58:07 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp022) with SMTP; 28 May 2008 17:58:07 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+a3cgBemuaaWGdbuedgSr4UMLVDPVl5qjbFaAZGj Oe3WQC9KowvId6 Message-ID: <483D810D.9050709@gmx.de> Date: Wed, 28 May 2008 17:58:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV , vcarddav@ietf.org References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> <483D7406.6080708@gmx.de> <38B86A86-F94F-434C-80C3-319DC2A939C2@opengroupware.org> In-Reply-To: <38B86A86-F94F-434C-80C3-319DC2A939C2@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K1O2w-0006Ap-32 e72139f95791dd814046ce85571cf45b X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12934 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 15:58:47 +0000 Helge Hess wrote: > But then the server always has the option to reject the BATCH with 501, > which would then make the client fallback. > Well, and a servlet which does WebDAV, needs to do most of the HTTP > stack itself anyways ;-) Well, not entirely. I'd say the stuff that is defined in Part1 of httpbis () probably is done by the servlet container. BR, Julian From w3c-dist-auth-request@listhub.w3.org Wed May 28 09:26:34 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8213A6AD0 for ; Wed, 28 May 2008 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmUISkxmhryG for ; Wed, 28 May 2008 09:26:34 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BCAE13A6CC0 for ; Wed, 28 May 2008 09:26:17 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1OT9-0007Iz-T0 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 16:25:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1OT8-0007IL-Ka for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 16:25:42 +0000 Received: from jackpot-adsl.demon.co.uk ([80.177.236.105] helo=saraha.jackpot.uk.net) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1OSz-0007FR-Hv for w3c-dist-auth@w3.org; Wed, 28 May 2008 16:25:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by saraha.jackpot.uk.net (Postfix) with ESMTP id 661A02BD84 for ; Wed, 28 May 2008 17:24:59 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at saraha.jackpot.uk.net Received: from saraha.jackpot.uk.net ([127.0.0.1]) by localhost (saraha.jackpot.uk.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KubrmQ3Vy9kL for ; Wed, 28 May 2008 17:24:58 +0100 (BST) Received: from [192.168.101.11] (unknown [192.168.101.11]) by saraha.jackpot.uk.net (Postfix) with ESMTP for ; Wed, 28 May 2008 17:24:57 +0100 (BST) Message-ID: <483D8759.70004@jackpot.uk.net> Date: Wed, 28 May 2008 17:24:57 +0100 From: Jack Cleaver User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: WebDAV References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> <483D7406.6080708@gmx.de> <38B86A86-F94F-434C-80C3-319DC2A939C2@opengroupware.org> <483D810D.9050709@gmx.de> In-Reply-To: <483D810D.9050709@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K1OSz-0007FR-Hv acd3a24b1ca41a5e131492176041f572 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12935 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 16:25:43 +0000 Julian Reschke wrote: > > Helge Hess wrote: >> But then the server always has the option to reject the BATCH with >> 501, which would then make the client fallback. Well, and a >> servlet which does WebDAV, needs to do most of the HTTP stack >> itself anyways ;-) > > Well, not entirely. I'd say the stuff that is defined in Part1 of > httpbis > () > probably is done by the servlet container. I found both Tomcat's and Jetty's HTTP stack to be unsuitable as a basis for building a DAV stack. Certainly it *should* be as you suggest; but these programs weren't designed with this kind of extension in mind. Really, it is much easier to throw it all away and start again. Jetty is much better than Tomcat in this respect; but even Jetty has some limitations. This isn't really criticism; designing software to be extensible without having much of a clue what extensions people are going to try and build is very difficult. -- Jack. From w3c-dist-auth-request@listhub.w3.org Wed May 28 09:36:06 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DAF53A6CA7 for ; Wed, 28 May 2008 09:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdTMWBHVApKR for ; Wed, 28 May 2008 09:36:04 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id C61DC3A6B27 for ; Wed, 28 May 2008 09:35:27 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1Obr-0001tN-AK for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 16:34:43 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Obq-0001sj-EG for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 16:34:42 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K1Obg-00013D-CL for w3c-dist-auth@w3.org; Wed, 28 May 2008 16:34:41 +0000 Received: (qmail invoked by alias); 28 May 2008 16:33:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp039) with SMTP; 28 May 2008 18:33:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18kmzprD5QkB7UCJSi2wjJabPUaAuitikEWZj+SQB uJq0NUc4H5lVI4 Message-ID: <483D896D.7000900@gmx.de> Date: Wed, 28 May 2008 18:33:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Jack Cleaver CC: WebDAV References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> <483D7406.6080708@gmx.de> <38B86A86-F94F-434C-80C3-319DC2A939C2@opengroupware.org> <483D810D.9050709@gmx.de> <483D8759.70004@jackpot.uk.net> In-Reply-To: <483D8759.70004@jackpot.uk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1Obg-00013D-CL dc4da05ad0d2aa325e2dbe74f2682d4f X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12936 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 16:34:43 +0000 Jack Cleaver wrote: > ... > I found both Tomcat's and Jetty's HTTP stack to be unsuitable as a basis > for building a DAV stack. Certainly it *should* be as you suggest; but > these programs weren't designed with this kind of extension in mind. > Really, it is much easier to throw it all away and start again. > > Jetty is much better than Tomcat in this respect; but even Jetty has > some limitations. This isn't really criticism; designing software to be > extensible without having much of a clue what extensions people are > going to try and build is very difficult. > ... Out of curiosity: what kinds of problems did you experience? As far as I can tell, the most compliant and complete WebDAV servers are currently implemented as servlets... BR, Julian From w3c-dist-auth-request@listhub.w3.org Wed May 28 09:57:54 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3193A6AB1 for ; Wed, 28 May 2008 09:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxIW+4KPQ3iW for ; Wed, 28 May 2008 09:57:53 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id E6B323A6A77 for ; Wed, 28 May 2008 09:57:52 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1Oxn-0002HW-Hq for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 16:57:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Oxm-0002Gr-FD for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 16:57:22 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1Oxd-0000Cc-AS for w3c-dist-auth@w3.org; Wed, 28 May 2008 16:57:22 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id E9DDF2D3233E for ; Wed, 28 May 2008 09:56:41 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id D284B464002 for ; Wed, 28 May 2008 09:56:41 -0700 (PDT) X-AuditID: 11807135-ac1c0bb000000d04-4c-483d8ec9c669 Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay12.apple.com (Apple SCV relay) with ESMTP id B2F61420002 for ; Wed, 28 May 2008 09:56:41 -0700 (PDT) References: <8B4748B6795C7A43BACF7F338E2A6AC006BBE2@dene2k1.cs.myharris.net> <483C87A4.7040401@onlinehome.de> From: Jim Luther Mime-Version: 1.0 (Apple Message framework v1015) Reply-To: WebDAV To: WebDAV Content-Type: text/plain; delsp=yes; charset=us-ascii; format=flowed Message-Id: Date: Wed, 28 May 2008 09:56:41 -0700 Content-Transfer-Encoding: 7bit In-Reply-To: <483C87A4.7040401@onlinehome.de> X-Mailer: Apple Mail (2.1015) X-Brightmail-Tracker: AAAAAA== Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K1Oxd-0000Cc-AS b0619dd326abcb794d3af58156473334 X-Original-To: w3c-dist-auth@w3.org Subject: Re: punctuation and path names Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12937 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 16:57:23 +0000 On May 27, 2008, at 3:13 PM, Werner Baumann wrote: > Each operating system has a set of restricted characters, that must > not be used in file names. Additionally there are still files > systems that are case insensitive. Another problem to note is with UTF precomposed vs UTF decomposed -- some servers don't support both. You'll also find servers that restrict the characters allowed even though the file system used by the server does not have those restrictions. For example . For customers of Apple's .Mac service's iDisk (a WebDAV file server), we have the following recommendations for file names. In Apple's WebDAV file system client, we don't allow "/" characters or NUL characters. Anything other characters we get are properly percent- encoded and sent to the server. It might work on the server, it might not. Going back to the original question... On May 27, 2008, at 11:04 AM, Phillips, Mark wrote: > I have a question regarding embedded punctuation, e.g. forward and > backward slashes, colons, question marks, etc.. The source data and > end user habits seem to require performing a substitution for some > components of the URI. Say, "Client 16_Red Documents" in lieu of > "Client 16/Red Documents". That is, I have reached the gap between > correct URI and human language. Before Mac OS X, our file system APIs used the ":" character as a path separator. So with Mac OS X those older APIs convert ":" to "/" and convert "/" to ":" when building a path to send to the Mac OS X file system APIs. For names coming back from the Mac OS X APIs, we do the opposite conversion. - Jim From w3c-dist-auth-request@listhub.w3.org Wed May 28 11:47:03 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C2A3A69F6 for ; Wed, 28 May 2008 11:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fYPcp55LnW8 for ; Wed, 28 May 2008 11:47:01 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 279603A6CD4 for ; Wed, 28 May 2008 11:45:51 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1QdT-0006LT-6G for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 18:44:31 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1QdQ-0006JS-Vd for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 18:44:29 +0000 Received: from jackpot-adsl.demon.co.uk ([80.177.236.105] helo=saraha.jackpot.uk.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1QdF-0003U6-Ku for w3c-dist-auth@w3.org; Wed, 28 May 2008 18:44:28 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by saraha.jackpot.uk.net (Postfix) with ESMTP id 4C84C2BD84 for ; Wed, 28 May 2008 19:43:45 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at saraha.jackpot.uk.net Received: from saraha.jackpot.uk.net ([127.0.0.1]) by localhost (saraha.jackpot.uk.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylW770FF0TdN for ; Wed, 28 May 2008 19:43:44 +0100 (BST) Received: from [192.168.101.11] (unknown [192.168.101.11]) by saraha.jackpot.uk.net (Postfix) with ESMTP for ; Wed, 28 May 2008 19:43:44 +0100 (BST) Message-ID: <483DA7DF.6010807@jackpot.uk.net> Date: Wed, 28 May 2008 19:43:43 +0100 From: Jack Cleaver User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: WebDAV References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> <483D7406.6080708@gmx.de> <38B86A86-F94F-434C-80C3-319DC2A939C2@opengroupware.org> <483D810D.9050709@gmx.de> <483D8759.70004@jackpot.uk.net> <483D896D.7000900@gmx.de> In-Reply-To: <483D896D.7000900@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1QdF-0003U6-Ku 33e9f1b5a3fd9121f3d910d1883c94ac X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12938 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 18:44:31 +0000 Julian Reschke wrote: > Jack Cleaver wrote: >> ... I found both Tomcat's and Jetty's HTTP stack to be unsuitable >> as a basis for building a DAV stack. Certainly it *should* be as >> you suggest; but these programs weren't designed with this kind of >> extension in mind. Really, it is much easier to throw it all away >> and start again. >> >> Jetty is much better than Tomcat in this respect; but even Jetty >> has some limitations. This isn't really criticism; designing >> software to be extensible without having much of a clue what >> extensions people are going to try and build is very difficult. ... >> > > Out of curiosity: what kinds of problems did you experience? As I recall, I couldn't override the built-in Tomcat HTTP method handlers without overriding the HTTP servlet itself. This was over a year ago, and I haven't touched the code for a while. -- Jack. From w3c-dist-auth-request@listhub.w3.org Wed May 28 12:04:44 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF383A6AEA for ; Wed, 28 May 2008 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h29lax9k186Z for ; Wed, 28 May 2008 12:04:16 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id C977C28C1E9 for ; Wed, 28 May 2008 12:02:33 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1QuQ-0006nz-Bu for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 May 2008 19:02:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1QuP-0006nL-Mg for w3c-dist-auth@listhub.w3.org; Wed, 28 May 2008 19:02:01 +0000 Received: from harold.telenet-ops.be ([195.130.133.65]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1QuF-0007qy-7M for w3c-dist-auth@w3.org; Wed, 28 May 2008 19:02:01 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by harold.telenet-ops.be (Postfix) with SMTP id 5820D30052; Wed, 28 May 2008 21:01:23 +0200 (CEST) Received: from [192.168.0.109] (d54C55D50.access.telenet.be [84.197.93.80]) by harold.telenet-ops.be (Postfix) with ESMTP id 2B61530054; Wed, 28 May 2008 21:01:21 +0200 (CEST) From: =?ISO-8859-1?Q?Werner_Donn=E9?= To: Jack Cleaver In-Reply-To: <483DA7DF.6010807@jackpot.uk.net> References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <483D2E4C.9020308@gmx.de> <376F30FE-067E-4C89-9E69-E3336F76F5FF@opengroupware.org> <3C12D53DCD10813ED88F1C68@caldav.corp.apple.com> <8C43C5BE-3913-4A39-ACA7-303114352EBB@opengroupware.org> <483D7406.6080708@gmx.de> <38B86A86-F94F-434C-80C3-319DC2A939C2@opengroupware.org> <483D810D.9050709@gmx.de> <483D8759.70004@jackpot.uk.net> <483D896D.7000900@gmx.de> <483DA7DF.6010807@jackpot.uk.net> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 21:01:20 +0200 Cc: WebDAV X-Mailer: Apple Mail (2.919.2) Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: lisa.w3.org 1K1QuF-0007qy-7M 8bb69aacc91b800ea73594bbf075aee4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12939 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 May 2008 19:02:02 +0000 Indeed, you have to override the HttpServlet class in order to deal with the new methods, but I fail to see why that should be a problem. My concerns regarding an application server are: - that it complies with RFC 2616; - that it complies with the relevant J2EE specifications; - that it provides a robust infrastructure. Werner. On 28 May 2008, at 20:43, Jack Cleaver wrote: > > Julian Reschke wrote: >> Jack Cleaver wrote: >>> ... I found both Tomcat's and Jetty's HTTP stack to be unsuitable >>> as a basis for building a DAV stack. Certainly it *should* be as >>> you suggest; but these programs weren't designed with this kind of >>> extension in mind. Really, it is much easier to throw it all away >>> and start again. >>> Jetty is much better than Tomcat in this respect; but even Jetty >>> has some limitations. This isn't really criticism; designing >>> software to be extensible without having much of a clue what >>> extensions people are going to try and build is very difficult. ... >> Out of curiosity: what kinds of problems did you experience? > > As I recall, I couldn't override the built-in Tomcat HTTP method > handlers without overriding the HTTP servlet itself. > > This was over a year ago, and I haven't touched the code for a while. > > --=20 > Jack. -- Werner Donn=E9 -- Re = http://www.pincette.biz Engelbeekstraat 8 = http://www.re.be BE-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Wed May 28 18:16:31 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2113A6CD5 for ; Wed, 28 May 2008 18:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnp-s1o2hgRo for ; Wed, 28 May 2008 18:16:30 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 027453A6CD6 for ; Wed, 28 May 2008 18:15:53 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1WhS-0004U9-I1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 May 2008 01:13:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1WhQ-0004TV-NJ for w3c-dist-auth@listhub.w3.org; Thu, 29 May 2008 01:13:00 +0000 Received: from mlbe2k1.cs.myharris.net ([137.237.90.88]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1WhH-00030N-M3 for w3c-dist-auth@w3.org; Thu, 29 May 2008 01:13:00 +0000 Received: from mail pickup service by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC; Wed, 28 May 2008 21:12:18 -0400 Received: from dene2k1.cs.myharris.net ([137.237.146.149]) by mlbe2k1.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 21:12:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 May 2008 19:12:16 -0600 Message-ID: <8B4748B6795C7A43BACF7F338E2A6AC006BBF0@dene2k1.cs.myharris.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: one crazy notion about dealing with windows file name reserved characters Thread-Index: AcjBKQijJ4YfB67SSFaeXP+Es73W7w== From: "Phillips, Mark" To: X-OriginalArrivalTime: 29 May 2008 01:12:17.0518 (UTC) FILETIME=[096038E0:01C8C129] Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K1WhH-00030N-M3 36ddee6c585a2b4207568ad488582352 X-Original-To: w3c-dist-auth@w3.org Subject: one crazy notion about dealing with windows file name reserved characters Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12940 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 May 2008 01:13:02 +0000 As I was shutting down today, something occured to me that seems like = something this agust list may have considered before. If, in my webdav client before an HTTP PUT, I was to run the URI = component encoding twice, so that %20 becomes $2520 for example, do you = think Apache mod_dav would reliably decode only once. Thus, the = "illegal" character would remain encoded as %20 in the URI component and = subsequently on the file system? For those thinking, "why not just try it?", I will but I am fishing for = expertise and wisdom I have yet to gain with webDAV+Apache+Windows. = Sometimes the pitfalls are not immediately obvious at my level of = experience with dav and mod_dav. Thanks, in advance, Mark Phillips From w3c-dist-auth-request@listhub.w3.org Thu May 29 00:47:59 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFEF3A698D for ; Thu, 29 May 2008 00:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=2.175, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RFA+KdOIm5E for ; Thu, 29 May 2008 00:47:58 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id F2BCE3A6998 for ; Thu, 29 May 2008 00:44:00 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1cmH-0005Qu-Nd for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 May 2008 07:42:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1cmC-0005QC-OA for w3c-dist-auth@listhub.w3.org; Thu, 29 May 2008 07:42:20 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=donbot.greenbytes.de) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1cm1-00047o-Fg for w3c-dist-auth@w3.org; Thu, 29 May 2008 07:42:20 +0000 Received: from [192.168.1.6] (unknown [192.168.1.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTP id 74B3FC4C0AE; Thu, 29 May 2008 09:42:03 +0200 (CEST) In-Reply-To: References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.de> Cc: Helge Hess , WebDAV , vcarddav@ietf.org Content-Transfer-Encoding: quoted-printable From: Stefan Eissing Date: Thu, 29 May 2008 09:41:23 +0200 To: Cyrus Daboo X-Mailer: Apple Mail (2.753) Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K1cm1-00047o-Fg a0ee0ba102d6a4ddba05b7fd8bc4dc2b X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12941 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 May 2008 07:42:25 +0000 This BATCH/multi-GET topic comes up quite regularly every year or so. =20= It's a pony discussion. For all use cases I have seen so far either 1. pipelining was adequate for it 2. or examples where as you described with optimizations for multiple =20= operations (security checks, dbms lookup, etc.) Case 2 could be betterh andled (e.g. without changing the worldwide =20 HTTP implementation) by optimizing the URL namespace. What I mean is =20 that one adds URLs to the application which represent specific views =20 on multiple resources. Those you can then retrieve with a single GET. Look how google does it. They have given the first 20 search results =20 a single URL. //Stefan Am 28.05.2008 um 16:08 schrieb Cyrus Daboo: > > Hi Helge, > > --On May 28, 2008 11:14:09 AM +0200 Helge Hess =20 > wrote: > >> Its not a really good example because its not a hugely compliant =20 >> WebDAV >> server nor implemented that well, but the OpenGroupware.org ZideStore >> serves iCal and vCard files via GroupDAV. >> An individual GET with all the authentication, authorization and =20 >> vCard >> building takes ~50ms which hurts a lot when you retrieve 10.000 =20 >> records, >> its ~8mins in the initial sync! We do a lot of caching etc to speed >> things up, but still its pretty slow. >> Now a multi-GET on moderatly sized batches takes almost the same =20 >> time, eg >> for 100 records its still ~70ms. >> >> I think thats the reason why CalDAV added those multiget REPORTs, on >> request of RDBMS based server vendors. > > Well you don't need an RDBMS backed server to see the benefit. The =20 > Apple CalDAV server uses flat files to store each calendar resource =20= > plus an index in each calendar collection to optimize queries. =20 > multiget is a big win for us. One of the biggest factors is being =20 > able to aggregate the ACL check of all the resources. There are =20 > several optimizations that can be done, and in the best case only =20 > one privilege check is needed for all the resources being fetched. > > The other key thing to remember is that multiget allows the client =20 > to fetch properties as well as data. i.e. its a combination of =20 > multi-PROPFIND as well as multi-GET. Obviously DAV:getetag is the =20 > one key property clients will fetch along with the data. That might =20= > not be enough to fully justify this approach, but it does keep it =20 > flexible. > > --=20 > Cyrus Daboo > > -- bytes GmbH, Hafenweg 16, D-48155 M=FCnster, Germany Amtsgericht M=FCnster: HRB5782 From w3c-dist-auth-request@listhub.w3.org Thu May 29 01:37:12 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBE773A6A62 for ; Thu, 29 May 2008 01:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=2.000, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR672rT1SjmO for ; Thu, 29 May 2008 01:37:12 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 35C593A6A50 for ; Thu, 29 May 2008 01:37:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1dcY-0003sb-4A for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 May 2008 08:36:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1dcV-0003rr-Cg for w3c-dist-auth@listhub.w3.org; Thu, 29 May 2008 08:36:23 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K1dcM-0006IJ-Iy for w3c-dist-auth@w3.org; Thu, 29 May 2008 08:36:22 +0000 Received: (qmail invoked by alias); 29 May 2008 08:35:43 -0000 Received: from p508FFDB7.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.253.183] by mail.gmx.net (mp057) with SMTP; 29 May 2008 10:35:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+EeNNpinuEQH5L97PxdKx1KJCF3OJwiaIEVovA0/ OjVcHMMnEhTy5k Message-ID: <483E6ADC.9050602@gmx.de> Date: Thu, 29 May 2008 10:35:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Stefan Eissing CC: Cyrus Daboo , Helge Hess , WebDAV , vcarddav@ietf.org References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.de> In-Reply-To: <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1K1dcM-0006IJ-Iy 588e558da979ead510835f5d0a336dd0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12942 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 May 2008 08:36:26 +0000 Stefan Eissing wrote: > This BATCH/multi-GET topic comes up quite regularly every year or so. > It's a pony discussion. > > For all use cases I have seen so far either > 1. pipelining was adequate for it > 2. or examples where as you described with optimizations for multiple > operations (security checks, dbms lookup, etc.) > > Case 2 could be betterh andled (e.g. without changing the worldwide HTTP > implementation) by optimizing the URL namespace. What I mean is that one > adds URLs to the application which represent specific views on multiple > resources. Those you can then retrieve with a single GET. > ... Right. Actually, my proposal allows a server to assign a GETtable URI to any REPORT response, so a client would have an extremely simply way to find out about the URI. BR, Julian From w3c-dist-auth-request@listhub.w3.org Thu May 29 02:09:32 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354173A6A2E for ; Thu, 29 May 2008 02:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nwQZLeyaL71 for ; Thu, 29 May 2008 02:09:31 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 12DF13A6A1D for ; Thu, 29 May 2008 02:09:30 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1e7W-0005fR-CW for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 May 2008 09:08:26 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1e7T-0005en-Nf for w3c-dist-auth@listhub.w3.org; Thu, 29 May 2008 09:08:24 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1e7G-0003sl-J3 for w3c-dist-auth@w3.org; Thu, 29 May 2008 09:08:21 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 23B1CF956F2; Thu, 29 May 2008 11:07:40 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id B6C5BF95641; Thu, 29 May 2008 11:07:39 +0200 (CEST) Message-Id: From: Helge Hess To: WebDAV , vcarddav@ietf.org In-Reply-To: <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 11:07:36 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.de> X-Mailer: Apple Mail (2.924) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1e7G-0003sl-J3 e5c13b978acd940610b061cc6bd3c26e X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12943 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 May 2008 09:08:26 +0000 On 29.05.2008, at 09:41, Stefan Eissing wrote: > This BATCH/multi-GET topic comes up quite regularly every year or > so. It's a pony discussion. I guessed so ... > For all use cases I have seen so far either > 1. pipelining was adequate for it > 2. or examples where as you described with optimizations for > multiple operations (security checks, dbms lookup, etc.) > > Case 2 could be betterh andled (e.g. without changing the worldwide > HTTP implementation) by optimizing the URL namespace. What I mean is > that one adds URLs to the application which represent specific views > on multiple resources. Those you can then retrieve with a single GET. > > Look how google does it. They have given the first 20 search results > a single URL. Yes, maybe. However, my question/motiviation is quite specific and not strictly related to plain HTTP. (extending HTTP using hardcoded namespaces is not done by any WebDAV protocol, good or bad, thats the 'style' of those). Again, my basic motivation is to consolidate the CalDAV/CardDAV/xyzDAV multiget REPORTs, not necessarily to provide a generic BATCH capability (though it would be very nice if we can usefully catch this with one memo). Those specialized batch ops already exist and won't get removed. Now I would prefer to do the batch thing in a generic way, but if the outcome is that this is too hard (eg because Servlets can't easily hook into the HTTP stack), we could also do a specialized REPORT (instead of a new, plain-HTTP, non WebDAV-specific BATCH method). On 29.05.2008, at 10:35, Julian Reschke wrote: > Actually, my proposal allows a server to assign a GETtable URI to > any REPORT response, so a client would have an extremely simply way > to find out about the URI. Maybe I'm reading your memo wrong, but to me it does not look like a BATCH or multiget REPORT replacement. You would need to encode all requested URIs in the URL or assign a stateful token. Its not that useful to cache changeset information either (because it constantly changes and is client-cache specific). Its more important to cache the contained, individual contents. In fact for the latter a BATCH looks to be optimal, since the actual content caching is exactly the same like for individual contents, whereas a REPORT needs custom infrastructure. I can see that your proposal is useful for other kinds of reports (more in the GData feed-like category). Thanks, Helge PS: I think BATCH would be relatively easy to implement in the Apache2 infrastructure. -- Helge Hess http://www.helgehess.eu/ From w3c-dist-auth-request@listhub.w3.org Thu May 29 03:12:29 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1D03A6AC6 for ; Thu, 29 May 2008 03:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=2.000, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMpbrcc3rwoD for ; Thu, 29 May 2008 03:12:28 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id CD89D3A6AA2 for ; Thu, 29 May 2008 03:12:28 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1f6G-000265-Oo for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 May 2008 10:11:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1f6F-00025J-6a for w3c-dist-auth@listhub.w3.org; Thu, 29 May 2008 10:11:11 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.63) (envelope-from ) id 1K1f65-0001n0-MT for w3c-dist-auth@w3.org; Thu, 29 May 2008 10:11:10 +0000 Received: (qmail invoked by alias); 29 May 2008 10:10:28 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 29 May 2008 12:10:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ENJd2AxvEqJEirmev5rvxHcyrqdi2EGx4+/D9ro b9wbzJMosr6Bvy Message-ID: <483E8110.8050909@gmx.de> Date: Thu, 29 May 2008 12:10:24 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess CC: WebDAV , vcarddav@ietf.org References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.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 X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K1f65-0001n0-MT 991299dd04ff821f1cc0b79b704e6f34 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12944 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 May 2008 10:11:12 +0000 Helge Hess wrote: > ... > On 29.05.2008, at 10:35, Julian Reschke wrote: >> Actually, my proposal allows a server to assign a GETtable URI to any >> REPORT response, so a client would have an extremely simply way to >> find out about the URI. > > Maybe I'm reading your memo wrong, but to me it does not look like a > BATCH or multiget REPORT replacement. You would need to encode all > requested URIs in the URL or assign a stateful token. It's not meant to be a replacement. But it can make a specific report GETtable, and thus cacheable (not the individual parts). > Its not that useful to cache changeset information either (because it > constantly changes and is client-cache specific). Its more important to It can be. If a client polls for changes, it's totally useful if the server can say "304". Also, it's not necessarily client specific. > cache the contained, individual contents. In fact for the latter a BATCH > looks to be optimal, since the actual content caching is exactly the > same like for individual contents, whereas a REPORT needs custom > infrastructure. The assumption seems to be: we need multi-GET because of initial sync, and thus, if we have it, we'll use it for everything. Another approach would be to have a special GETtable resource that can be used for the initial sync, and then use regular, conditional GET requests for everything else.... > ... BR, Julian From w3c-dist-auth-request@listhub.w3.org Thu May 29 03:42:43 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840D628C244 for ; Thu, 29 May 2008 03:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=1.153, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC5Cm-+dx2DU for ; Thu, 29 May 2008 03:42:38 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BCD8D28C247 for ; Thu, 29 May 2008 03:39:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1fWd-0001e8-RC for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 May 2008 10:38:27 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1fWc-0001dO-SW for w3c-dist-auth@listhub.w3.org; Thu, 29 May 2008 10:38:27 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by aji.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1fWO-000314-OC for w3c-dist-auth@w3.org; Thu, 29 May 2008 10:38:26 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 8CE39F89FFA; Thu, 29 May 2008 12:37:43 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-232-239.reverse.mdcc-fun.de [213.211.232.239]) by mail.mdlink.net (Postfix) with ESMTP id B1EBFF95B38; Thu, 29 May 2008 12:37:31 +0200 (CEST) Message-Id: From: Helge Hess To: WebDAV , vcarddav@ietf.org In-Reply-To: <483E8110.8050909@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 12:37:27 +0200 References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.de> <483E8110.8050909@gmx.de> X-Mailer: Apple Mail (2.924) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1K1fWO-000314-OC e8e497ef1c27373cabdc55a3bea07447 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12945 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 May 2008 10:38:27 +0000 On 29.05.2008, at 12:10, Julian Reschke wrote: > The assumption seems to be: we need multi-GET because of initial > sync, and thus, if we have it, we'll use it for everything. Well, not for 'everything', for fetching changed resources from a server into a cache. This is a very common and useful operation. And its *not* just the initial sync, initial sync is just the worst case. Its not that unusual that hundreds of resources are changed while I'm out of office for a day ... But sure, since pipelining has no good realworld adoption, it would have the potential to actually replace it. (just look at CSS image sprites!) > Another approach would be to have a special GETtable resource that > can be used for the initial sync, and then use regular, conditional > GET requests for everything else.... Yes, that would be an OK workaround. But it somehow has a hackish feeling to me, since the obvious solution for the actual problem is indeed a BATCH :-) Anyways, can we drop the generic-BATCH discussion and focus on options to generalize the multiget-REPORTs? Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From w3c-dist-auth-request@listhub.w3.org Thu May 29 06:26:07 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD10C28C190 for ; Thu, 29 May 2008 06:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPsK9Ej311aC for ; Thu, 29 May 2008 06:26:02 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id F1FEE28C202 for ; Thu, 29 May 2008 06:26:01 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1i7O-0002d3-P7 for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 May 2008 13:24:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1i7M-0002aC-9p; Thu, 29 May 2008 13:24:32 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by lisa.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1i7C-0004RQ-CW; Thu, 29 May 2008 13:24:32 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m4TDNjIW006976; Thu, 29 May 2008 09:23:45 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4TDNjv2140038; Thu, 29 May 2008 09:23:45 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4TDNiKI013523; Thu, 29 May 2008 09:23:45 -0400 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m4TDNiIh013515; Thu, 29 May 2008 09:23:44 -0400 In-Reply-To: <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.de> To: Stefan Eissing Cc: Cyrus Daboo , Helge Hess , vcarddav@ietf.org, WebDAV , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Geoffrey M Clemm Message-ID: Date: Thu, 29 May 2008 09:23:43 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 8.0.1|February 07, 2008) at 05/29/2008 09:23:43, Serialize complete at 05/29/2008 09:23:43 Content-Type: multipart/alternative; boundary="=_alternative 0049951485257458_=" Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1K1i7C-0004RQ-CW 045bb3ef3d3e297b213efcc22b3af83b X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12946 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 May 2008 13:24:34 +0000 This is a multipart message in MIME format. --=_alternative 0049951485257458_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable +1 for Stefan's comments. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 05/29/2008 03:41:23 AM: >=20 > This BATCH/multi-GET topic comes up quite regularly every year or so.=20 > It's a pony discussion. >=20 > For all use cases I have seen so far either > 1. pipelining was adequate for it > 2. or examples where as you described with optimizations for multiple=20 > operations (security checks, dbms lookup, etc.) >=20 > Case 2 could be betterh andled (e.g. without changing the worldwide=20 > HTTP implementation) by optimizing the URL namespace. What I mean is=20 > that one adds URLs to the application which represent specific views=20 > on multiple resources. Those you can then retrieve with a single GET. >=20 > Look how google does it. They have given the first 20 search results=20 > a single URL. >=20 > //Stefan >=20 > Am 28.05.2008 um 16:08 schrieb Cyrus Daboo: >=20 > > > > Hi Helge, > > > > --On May 28, 2008 11:14:09 AM +0200 Helge Hess=20 > > wrote: > > > >> Its not a really good example because its not a hugely compliant=20 > >> WebDAV > >> server nor implemented that well, but the OpenGroupware.org ZideStore > >> serves iCal and vCard files via GroupDAV. > >> An individual GET with all the authentication, authorization and=20 > >> vCard > >> building takes ~50ms which hurts a lot when you retrieve 10.000=20 > >> records, > >> its ~8mins in the initial sync! We do a lot of caching etc to speed > >> things up, but still its pretty slow. > >> Now a multi-GET on moderatly sized batches takes almost the same=20 > >> time, eg > >> for 100 records its still ~70ms. > >> > >> I think thats the reason why CalDAV added those multiget REPORTs, on > >> request of RDBMS based server vendors. > > > > Well you don't need an RDBMS backed server to see the benefit. The=20 > > Apple CalDAV server uses flat files to store each calendar resource=20 > > plus an index in each calendar collection to optimize queries.=20 > > multiget is a big win for us. One of the biggest factors is being=20 > > able to aggregate the ACL check of all the resources. There are=20 > > several optimizations that can be done, and in the best case only=20 > > one privilege check is needed for all the resources being fetched. > > > > The other key thing to remember is that multiget allows the client=20 > > to fetch properties as well as data. i.e. its a combination of=20 > > multi-PROPFIND as well as multi-GET. Obviously DAV:getetag is the=20 > > one key property clients will fetch along with the data. That might=20 > > not be enough to fully justify this approach, but it does keep it=20 > > flexible. > > > > --=20 > > Cyrus Daboo > > > > >=20 > -- > bytes GmbH, Hafenweg 16, D-48155 M=FCnster, Germany > Amtsgericht M=FCnster: HRB5782 >=20 >=20 >=20 >=20 >=20 --=_alternative 0049951485257458_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
+1 for Stefan's comments.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 05/29/2008 03:= 41:23 AM:

>
> This BATCH/multi-GET topic comes up quite regularly every year or so.  
> It's a pony discussion.
>
> For all use cases I have seen so far either
> 1. pipelining was adequate for it
> 2. or examples where as you described with optimizations for multiple  
> operations (security checks, dbms lookup, etc.)
>
> Case 2 could be betterh andled (e.g. without changing the worldwide  
> HTTP implementation) by optimizing the URL namespace. What I mean is  
> that one adds URLs to the application which represent specific views  
> on multiple resources. Those you can then retrieve with a single GET.<= br> >
> Look how google does it. They have given the first 20 search results  
> a single URL.
>
> //Stefan
>
> Am 28.05.2008 um 16:08 schrieb Cyrus Daboo:
>
> >
> > Hi Helge,
> >
> > --On May 28, 2008 11:14:09 AM +0200 Helge Hess  
> > <helge.hess@opengroupware.org> wrote:
> >
> >> Its not a really good example because its not a hugely compli= ant  
> >> WebDAV
> >> server nor implemented that well, but the OpenGroupware.org ZideStore
> >> serves iCal and vCard files via GroupDAV.
> >> An individual GET with all the authentication, authorization and  
> >> vCard
> >> building takes ~50ms which hurts a lot when you retrieve 10.000  
> >> records,
> >> its ~8mins in the initial sync! We do a lot of caching etc to speed
> >> things up, but still its pretty slow.
> >> Now a multi-GET on moderatly sized batches takes almost the same  
> >> time, eg
> >> for 100 records its still ~70ms.
> >>
> >> I think thats the reason why CalDAV added those multiget REPORTs, on
> >> request of RDBMS based server vendors.
> >
> > Well you don't need an RDBMS backed server to see the benefit. The  
> > Apple CalDAV server uses flat files to store each calendar resour= ce  
> > plus an index in each calendar collection to optimize queries.  
> > multiget is a big win for us. One of the biggest factors is being  
> > able to aggregate the ACL check of all the resources. There are  
> > several optimizations that can be done, and in the best case only  
> > one privilege check is needed for all the resources being fetched= .
> >
> > The other key thing to remember is that multiget allows the client  
> > to fetch properties as well as data. i.e. its a combination of  
> > multi-PROPFIND as well as multi-GET. Obviously DAV:getetag is the  
> > one key property clients will fetch along with the data. That might  
> > not be enough to fully justify this approach, but it does keep it  
> > flexible.
> >
> > --
> > Cyrus Daboo
> >
> >
>
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 M=FCnster, Germany
> Amtsgericht M=FCnster: HRB5782
>
>
>
>
>
--=_alternative 0049951485257458_=-- From w3c-dist-auth-request@listhub.w3.org Thu May 29 09:32:03 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C133A6A09 for ; Thu, 29 May 2008 09:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq95DcgHn4Bu for ; Thu, 29 May 2008 09:32:02 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 330B43A6BC2 for ; Thu, 29 May 2008 09:31:08 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K1l0b-0003fX-KF for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 May 2008 16:29:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1l0Z-0003et-D8 for w3c-dist-auth@listhub.w3.org; Thu, 29 May 2008 16:29:43 +0000 Received: from daboo.name ([151.201.22.177]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K1l0Q-00022v-F6 for w3c-dist-auth@w3.org; Thu, 29 May 2008 16:29:42 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C74ED7FF87F; Thu, 29 May 2008 12:29:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kfo5hDJwRoFS; Thu, 29 May 2008 12:29:05 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 1251E7FF873; Thu, 29 May 2008 12:29:03 -0400 (EDT) Date: Thu, 29 May 2008 12:29:00 -0400 From: Cyrus Daboo To: Julian Reschke , Helge Hess cc: WebDAV , vcarddav@ietf.org Message-ID: <77A3498B7242B3A47DDC8359@caldav.corp.apple.com> In-Reply-To: <483E8110.8050909@gmx.de> References: <47DBAB30.1060306@gmx.de> <483D0A80.6030608@gmx.de> <829B9323-9570-433B-BA7C-B9C1A08639B9@opengroupware.org> <1820FEFC-6B25-4CCB-AAE7-0D2D793EAA73@greenbytes.de> <483E8110.8050909@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1K1l0Q-00022v-F6 6c0ac81187f78110e129786ef53bdbf6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: multiget reports Re: Thoughts on relation to WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12947 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 May 2008 16:29:45 +0000 Hi Julian, --On May 29, 2008 12:10:24 PM +0200 Julian Reschke wrote: >> cache the contained, individual contents. In fact for the latter a BATCH >> looks to be optimal, since the actual content caching is exactly the >> same like for individual contents, whereas a REPORT needs custom >> infrastructure. > > The assumption seems to be: we need multi-GET because of initial sync, > and thus, if we have it, we'll use it for everything. > > Another approach would be to have a special GETtable resource that can be > used for the initial sync, and then use regular, conditional GET requests > for everything else.... But I think that will end up looking exactly like multiget for the most part. Some things to note: clients will typically need to use several multigets for the initial sync if the collection is large. I believe iCal broke down multigets into 50 or 100 resource fetches at a time. Our server won't allow more than 1000 to be returned in a report. So your special GET will need to have a way to select which ranges to fetch (just as multiget does) and it will need a way to expose, at the very least, the getetag property of each of those (again multiget can do that but also allows more properties to be returned). So I think you just end up with pretty much the same feature set. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Sat May 31 19:05:56 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE7A3A67EB for ; Sat, 31 May 2008 19:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M1XBtQZoqTV for ; Sat, 31 May 2008 19:05:54 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 8BF363A67AA for ; Sat, 31 May 2008 19:05:54 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1K2cuc-0002Ck-0D for w3c-dist-auth-dist@listhub.w3.org; Sun, 01 Jun 2008 02:03:10 +0000 Received: from farnsworth.w3.org ([128.30.52.43] helo=wiggum.w3.org) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K2cuY-0002AQ-0r for w3c-dist-auth@listhub.w3.org; Sun, 01 Jun 2008 02:03:06 +0000 Received: from nobody by wiggum.w3.org with local (Exim 4.63) (envelope-from ) id 1K2cuX-0006Yi-UQ for w3c-dist-auth@listhub.w3.org; Sun, 01 Jun 2008 02:03:05 +0000 Received: from [128.30.52.63] (helo=bart.w3.org) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K2TSM-00077x-Qp for w3c-dist-auth@listhub.w3.org; Sat, 31 May 2008 15:57:22 +0000 Received: from ispmxmta09-srv.windstream.net ([166.102.165.170]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1K2TSE-0004dw-3H for w3c-dist-auth@w3.org; Sat, 31 May 2008 11:57:22 -0400 Received: from ispmxaamta04-gx.windstream.net ([75.117.56.163]) by ispmxmta09-srv.windstream.net with ESMTP id <20080531155642.PDB6512.ispmxmta09-srv.windstream.net@ispmxaamta04-gx.windstream.net> for ; Sat, 31 May 2008 10:56:42 -0500 Received: from [10.0.1.199] (really [75.117.56.163]) by ispmxaamta04-gx.windstream.net with ESMTP id <20080531155641.ZDDT1714.ispmxaamta04-gx.windstream.net@[10.0.1.199]>; Sat, 31 May 2008 10:56:41 -0500 Message-Id: <526A2B51-5EB5-47AA-8857-8D7CC43A6ACF@gcsu.edu> From: Frank Lowney To: WebDAV Authoring List Content-Type: multipart/alternative; boundary=Apple-Mail-1--133524506 Mime-Version: 1.0 (Apple Message framework v924) Date: Sat, 31 May 2008 11:56:33 -0400 Cc: Mazhar Malik , Steve VanBrackle , George Cook , Andre Vlajk , Jim Wolfgang , Dan Hann X-Mailer: Apple Mail (2.924) Received-SPF: softfail X-SPF-Guess: softfail X-W3C-Hub-Spam-Status: No, score=0.6 X-W3C-Hub-Spam-Report: BAYES_50=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.596 X-W3C-Scan-Sig: bart.w3.org 1K2TSE-0004dw-3H cde17b8d23a2e1e284e0eacb259d6872 X-caa-id: d96384b13356c164455c X-Original-To: w3c-dist-auth@w3.org Subject: MacOS X 10.5.3 Update and WebDAV Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12948 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 01 Jun 2008 02:03:10 +0000 --Apple-Mail-1--133524506 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, I've just noticed what appears to be a rather serious issue involving WebDAV in MacOS X 10.5.3. Recent, earlier versions of this OS had no problems interacting with WebDAV services but, now, the Finder will lock-up when dragging a modestly sized folder of files to a WebDAV volume (ditto for individual files). This lock-up does not affect other applications running on the client machine but the Finder becomes completely unresponsive. The Finder cannot be forced quit or relaunched so shutdown/restart can only be accomplished via power recycling. I have reported this to Apple via their http://bugreport.apple.com/ facility (Problem ID: 5975398 ). So far, all of my testing has been against the now unsupported WebSTAR V server (failure), ,Mac (success) and Blackboard Vista 3.x (partial failure). If folks here with access to MacOS X 10.5.3 could add to this list, perhaps a clearer pattern might emerge. Right now, I suspect that changes to the WebDAV FS in MacOS X 10.5.3 were made in anticipation of upcoming changes in the .Mac service, changes that may not be standard or may be so new to the standard that WebDAV support in some systems hasn't yet caught up. I will need to do further testing but it seems that only certain movie files trigger this effect. Rumor has it that iPhone synching will be added to .Mac (which is WebDAV based) so this might be a case of unintended effects stemming out of an effort to protect copyrighted video files on the iPhone when .Mac synching is invoked. ================================================================== Dr. Frank Lowney Georgia College & State University Senior Director for External Projects and Assistant to the Director, Digital Innovation Group @ Georgia College Web Enabled Resources GCSU Library and Instructional Technology Center E-Mail: frank.lowney@gcsu.edu Professional Pages: http://www2.gcsu.edu/library/WER/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 NOTICE: Please be advised that I am hearing impaired and communicate most effectively via e-mail. Follow-up summaries of telephone conversations by e-mail are most appreciated. ================================================================== We don't make instruction effective, we make effective instruction more accessible. --Apple-Mail-1--133524506 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello,

I've = just noticed what appears to be a rather serious issue involving WebDAV = in MacOS X 10.5.3.  Recent, earlier versions of this OS had no = problems interacting with WebDAV services but, now, the Finder will = lock-up when dragging a modestly sized folder of files to a WebDAV = volume (ditto for individual files).  This lock-up does not affect = other applications running on the client machine but the Finder becomes = completely unresponsive.  The Finder cannot be forced quit or = relaunched so shutdown/restart can only be accomplished via power = recycling.  I have reported this to Apple via their http://bugreport.apple.com/ = facility (Problem = ID: 5975398 ).

So far, all = of my testing has been against the now unsupported WebSTAR V server = (failure), ,Mac (success) and Blackboard Vista 3.x (partial failure). =  If folks here with access to MacOS X 10.5.3 could add to this = list, perhaps a clearer pattern might = emerge.

Right now, I suspect that changes to = the WebDAV FS in MacOS X 10.5.3 were made in anticipation of upcoming = changes in the .Mac service, changes that may not be standard or may be = so new to the standard that WebDAV support in some systems hasn't yet = caught up.

I will need to do further testing = but it seems that only certain movie files trigger this effect. =  Rumor has it that iPhone synching will be added to .Mac (which is = WebDAV based) so this might be a case of unintended effects stemming out = of an effort to protect copyrighted video files on the iPhone when .Mac = synching is invoked.

=
Dr. = Frank Lowney  Georgia College & State = University
    Senior Director for = External Projects
       and Assistant to the = Director, Digital Innovation Group @ Georgia College
 Web Enabled = Resources
    GCSU Library and = Instructional Technology Center
    E-Mail: frank.lowney@gcsu.edu
Voice: (478) 445-5260
 Follow-up summaries of = telephone conversations by e-mail are most appreciated.
We = don't make instruction effective, we make effective instruction more = accessible.



= --Apple-Mail-1--133524506-- From webdate.comromelo2244@webdate.com Sat May 31 22:02:39 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651E33A6A4A for ; Sat, 31 May 2008 22:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.326 X-Spam-Level: X-Spam-Status: No, score=-14.326 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_AHBL_RHSBL=0.692, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_VN=1.335, HTML_IMAGE_ONLY_12=2.46, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, SUBJ_ALL_CAPS=2.077, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfUgOsLKSI2p for ; Sat, 31 May 2008 22:02:38 -0700 (PDT) Received: from adsl-dynamic-pool-xxx.fpt.vn (unknown [118.71.57.117]) by core3.amsl.com (Postfix) with SMTP id 7765D3A6940 for ; Sat, 31 May 2008 22:02:37 -0700 (PDT) Message-Id: <20080531020238.2908.qmail@adsl-dynamic-pool-xxx.fpt.vn> To: Subject: RE: SALE 89% OFF From: VIAGRA INC MIME-Version: 1.0 Content-Type: text/html Date: Sat, 31 May 2008 22:02:37 -0700 (PDT)
Click Here!