From w3c-dist-auth-request@w3.org Fri Nov 1 07:15:11 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04492 for ; Fri, 1 Nov 2002 07:15:11 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA1CGDL02338; Fri, 1 Nov 2002 07:16:13 -0500 (EST) Resent-Date: Fri, 1 Nov 2002 07:16:13 -0500 (EST) Resent-Message-Id: <200211011216.gA1CGDL02338@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA1CGBB02312 for ; Fri, 1 Nov 2002 07:16:11 -0500 (EST) Received: from ZASBSJNB002.SBSZA.NET ([196.44.70.100]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA29311 for ; Fri, 1 Nov 2002 07:16:05 -0500 Received: by ZASBSJNB002.SBSZA.NET with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 14:13:54 +0200 Message-ID: <377CAE249FD6C247BD5DF6B2DB5C99607481FD@zasbsjnb032.sbsza.net> From: "Verma, Nitin" To: w3c-dist-auth@w3.org Date: Fri, 1 Nov 2002 14:13:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C281A0.2403E260" Subject: Create a Task with Webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7006 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C281A0.2403E260 Content-Type: text/plain Hi, Am trying to create a task in MS Outlook using webdav.... But its not working at all... I can create the task in DOT NET application... but when I use same code in Web Service then it wont work... I can create the appointment using Webdav. Its working very fine... Will you guys provide me any type of help in that... Please help... Thanks and regards, Nitin. ------_=_NextPart_001_01C281A0.2403E260 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi,

Am trying to create a task in MS Outlook using webdav.... But its not = working at all...

I can create the task in DOT NET application... but = when I use same code in Web Service then it wont = work...

I can create the appointment using Webdav. Its working very fine... =

 

 

Will you guys provide me any type of help in that... = Please help...

 

 

Thanks and regards,

Nitin.=

------_=_NextPart_001_01C281A0.2403E260-- From w3c-dist-auth-request@w3.org Fri Nov 1 13:17:40 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27201 for ; Fri, 1 Nov 2002 13:17:40 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA1IIdF25021; Fri, 1 Nov 2002 13:18:39 -0500 (EST) Resent-Date: Fri, 1 Nov 2002 13:18:39 -0500 (EST) Resent-Message-Id: <200211011818.gA1IIdF25021@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA1IIZB24995 for ; Fri, 1 Nov 2002 13:18:35 -0500 (EST) Received: from webmail.tiscali.de (webmail.tiscali.de [62.27.55.1] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26967 for ; Fri, 1 Nov 2002 13:18:35 -0500 Received: from edgarschwarz.de (62.246.154.139) by webmail.tiscali.de (6.0.045) (authenticated as a0281133@addcom.de) id 3C9A891803369BA1; Fri, 1 Nov 2002 19:02:31 +0100 Message-ID: <3DC2C593.5020201@edgarschwarz.de> Date: Fri, 01 Nov 2002 19:18:59 +0100 From: Edgar Schwarz User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Edgar Schwarz References: <3DC2C4C4.7000002@edgarschwarz.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Destroying diamonds Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7007 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Clemm, Geoff > > From: Clemm, Geoff > > A COPY would have to check for any > > resource that has multiple entries in its DAV:parent-set, to see > > if it has already been copied (in which case a second binding to > > the copy is created). > This COPY behaviour makes sense, but can we really require it? > Right now it seems completely legal to just create multiple plain > new resources with same content and dead properties... >If the binding relationships are acyclic, creating multiple >plain new resources with the same content and dead properties >seems reasonable to me (i.e. I don't think the spec should >forbid it), but this would be a somewhat expensive approach if >there are cycles (:-). The server can't avoid to track his inodes on a deep COPY to be aware of cycles. So it also can easily find diamonds which will exist for a reason I guess. I think it's dangerous to destroy these diamonds by duplicating resources. Usecases which depend on the diamonds will break. So at least a means to keep them should be provided. Therefore IMHO disallowing duplication is the clean and also spacesaving solution. Cheers, Edgar From w3c-dist-auth-request@w3.org Fri Nov 1 18:46:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09063 for ; Fri, 1 Nov 2002 18:46:25 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA1NlgH28407; Fri, 1 Nov 2002 18:47:42 -0500 (EST) Resent-Date: Fri, 1 Nov 2002 18:47:42 -0500 (EST) Resent-Message-Id: <200211012347.gA1NlgH28407@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA1NleB28377 for ; Fri, 1 Nov 2002 18:47:40 -0500 (EST) Received: from halon.barra.com (halon.barra.com [144.203.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA00737 for ; Fri, 1 Nov 2002 18:47:08 -0500 Received: from royer.barra.com (royer [144.203.13.201]) by halon.barra.com (8.9.3/8.9.3) with ESMTP id PAA09833 for ; Fri, 1 Nov 2002 15:40:33 -0800 (PST) Received: from cronos.barra.com (exchangebrk.barra.com [144.203.4.99]) by royer.barra.com (8.11.1/8.11.1/royer.mc) with ESMTP id gA1NkwL22644 for ; Fri, 1 Nov 2002 15:46:58 -0800 (PST) Received: by exchangebrk.barra.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 15:31:42 -0800 Message-ID: <1E2A7622FCBB49459C833FE5FFC44A032C2E5F@spartan.win.barra.com> From: Lalit Jairath To: "'w3c-dist-auth@w3.org'" Date: Fri, 1 Nov 2002 15:46:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Re: interop issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7008 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > does anybody know if a plug-in or patch exists for netscape proxy server > that extends HTTP1.1 (propfind etc.) > > Thx. mucho in advance. > > lalit From w3c-dist-auth-request@w3.org Fri Nov 1 19:06:59 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09699 for ; Fri, 1 Nov 2002 19:06:59 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA2084V01001; Fri, 1 Nov 2002 19:08:04 -0500 (EST) Resent-Date: Fri, 1 Nov 2002 19:08:04 -0500 (EST) Resent-Message-Id: <200211020008.gA2084V01001@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA2082B00975 for ; Fri, 1 Nov 2002 19:08:02 -0500 (EST) Received: from epistula.trinity.unimelb.edu.au (postfix@epistula.trinity.unimelb.edu.au [203.28.240.16]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA04879 for ; Fri, 1 Nov 2002 19:08:01 -0500 Received: by epistula.trinity.unimelb.edu.au (Postfix, from userid 105) id 44A621801D; Sat, 2 Nov 2002 11:07:56 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by epistula.trinity.unimelb.edu.au (Postfix) with ESMTP id D0CCE1801E; Sat, 2 Nov 2002 11:07:43 +1100 (EST) Received: from roger.trinity.unimelb.edu.au (roger.trinity.unimelb.edu.au [203.28.240.3]) by epistula.trinity.unimelb.edu.au (Postfix) with ESMTP id E40B51801D; Sat, 2 Nov 2002 11:07:39 +1100 (EST) Received: by roger.trinity.unimelb.edu.au (Postfix, from userid 1280) id C03D317F06; Sat, 2 Nov 2002 11:07:39 +1100 (EST) Date: Sat, 2 Nov 2002 11:07:39 +1100 From: Daniel Stone To: Lalit Jairath Cc: "'w3c-dist-auth@w3.org'" Message-ID: <20021102000739.GA10941@trinity.unimelb.edu.au> References: <1E2A7622FCBB49459C833FE5FFC44A032C2E5F@spartan.win.barra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <1E2A7622FCBB49459C833FE5FFC44A032C2E5F@spartan.win.barra.com> User-Agent: Mutt/1.3.28i X-GnuPG-Key: 3CED7EFD X-Virus-Scanned: by AMaViS snapshot-20020316 Subject: Re: interop issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7009 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 01, 2002 at 03:46:56PM -0800, Lalit Jairath scrawled: > does anybody know if a plug-in or patch exists for netscape proxy server > that extends HTTP1.1 (propfind etc.) Often there is an option that specifies which methods to support; Squid's is "extension_methods" (IIRC). =09 --=20 Daniel Stone Developer - http://kopete.kde.org, http://www.kde.org --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9wxdLcPClnTztfv0RAquTAJ9ogL5pgC9PfBeZIDz895fzTLMhtACfUqVu I/TlGcxlML3nNb7S/dh+OE8= =I2Ro -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From w3c-dist-auth-request@w3.org Fri Nov 1 20:00:54 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11032 for ; Fri, 1 Nov 2002 20:00:54 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA212Mm06481; Fri, 1 Nov 2002 20:02:22 -0500 (EST) Resent-Date: Fri, 1 Nov 2002 20:02:22 -0500 (EST) Resent-Message-Id: <200211020102.gA212Mm06481@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA212KB06453 for ; Fri, 1 Nov 2002 20:02:21 -0500 (EST) Received: from halon.barra.com (halon.barra.com [144.203.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA13323 for ; Fri, 1 Nov 2002 20:01:49 -0500 Received: from royer.barra.com (royer [144.203.13.201]) by halon.barra.com (8.9.3/8.9.3) with ESMTP id QAA12354; Fri, 1 Nov 2002 16:55:20 -0800 (PST) Received: from cronos.barra.com (exchangebrk.barra.com [144.203.4.99]) by royer.barra.com (8.11.1/8.11.1/royer.mc) with ESMTP id gA211iL00556; Fri, 1 Nov 2002 17:01:45 -0800 (PST) Received: by exchangebrk.barra.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 16:46:28 -0800 Message-ID: <1E2A7622FCBB49459C833FE5FFC44A032C2E60@spartan.win.barra.com> From: Lalit Jairath To: "'Daniel Stone'" Cc: "'w3c-dist-auth@w3.org'" Date: Fri, 1 Nov 2002 17:01:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: interop issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7010 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The following is from: http://www.webdav.org/other/proxy.html The last modofied date is Tue Mar 26 13:11:26 PST 2002. Has something happened since then? If yes what, and how I can do it? That's my question. Any pointers are appreciated. Thx. mucho. lalit ============================================================= Proxy WebDAV Support? ============================================================================ Microsoft Proxy 2.0 Supported Apache 1.3 with mod_proxy Supported Netscape Proxy Server No I don't know the particular version tested here. Greg Stein Last modified: Tue Mar 26 13:11:26 PST 2002 ============================================================================ = -----Original Message----- From: Daniel Stone [mailto:dstone@kde.org] Sent: Friday, November 01, 2002 4:08 PM To: Lalit Jairath Cc: 'w3c-dist-auth@w3.org' Subject: Re: interop issue On Fri, Nov 01, 2002 at 03:46:56PM -0800, Lalit Jairath scrawled: > does anybody know if a plug-in or patch exists for netscape proxy server > that extends HTTP1.1 (propfind etc.) Often there is an option that specifies which methods to support; Squid's is "extension_methods" (IIRC). -- Daniel Stone Developer - http://kopete.kde.org, http://www.kde.org From w3c-dist-auth-request@w3.org Tue Nov 5 22:09:12 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07381 for ; Tue, 5 Nov 2002 22:09:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA63AbX02036; Tue, 5 Nov 2002 22:10:37 -0500 (EST) Resent-Date: Tue, 5 Nov 2002 22:10:37 -0500 (EST) Resent-Message-Id: <200211060310.gA63AbX02036@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA63AaB02005 for ; Tue, 5 Nov 2002 22:10:36 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA17358 for ; Tue, 5 Nov 2002 22:10:35 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 189GdT-0000MP-00 for w3c-dist-auth@w3c.org; Wed, 06 Nov 2002 03:13:43 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 189GdT-0000ME-00 for w3c-dist-auth@w3c.org; Wed, 06 Nov 2002 03:13:43 +0000 From: "Lisa Dusseault" To: Date: Tue, 5 Nov 2002 19:10:19 -0800 Message-ID: <000e01c28542$09b3a8a0$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: FW: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7011 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I will put together the Agenda for the Atlanta meeting. Here's some issues that should be discussed. Volunteers are *really needed* ( to drive discussion on their selected topic) this meeting as I'm *really swamped* myself! RFC2518bis - Proposals for client forcing server auth challenge - Ilya? - Required support for ETags - If header evaluation/simplification proposals & compatibility - Geoff? Other drafts - quota draft - Binding issues coming up on DL - allprop/include draft Other issues - Impact of XML namespace changes -- Julian? - ACL submission status I'm sure I've missed items so let me know. --Lisa -----Original Message----- From: Dinara Suleymanova [mailto:dinaras@ietf.org] Sent: Monday, November 04, 2002 8:40 AM To: wgchairs@ietf.org; bofchairs@ietf.org Cc: iesg@ietf.org Subject: WG Agendas for the 55th IETF Please start sending your group meetings' agendas. Thanks, Dinara Suleymanova From w3c-dist-auth-request@w3.org Thu Nov 7 03:00:10 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06491 for ; Thu, 7 Nov 2002 03:00:09 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA7817j10421; Thu, 7 Nov 2002 03:01:07 -0500 (EST) Resent-Date: Thu, 7 Nov 2002 03:01:07 -0500 (EST) Resent-Message-Id: <200211070801.gA7817j10421@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA7815B10389 for ; Thu, 7 Nov 2002 03:01:05 -0500 (EST) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA09709 for ; Thu, 7 Nov 2002 03:01:05 -0500 Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gA780Y107232 for ; Thu, 7 Nov 2002 00:00:34 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gA780Xj07218 for ; Thu, 7 Nov 2002 00:00:33 -0800 (PST) Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id gA780XI08002 for ; Thu, 7 Nov 2002 01:00:33 -0700 (MST) Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum1.us.oracle.com with ESMTP id 1187341036655951; Thu, 07 Nov 2002 00:59:11 -0600 Message-ID: <071401c28633$c37b0a70$51ab2382@us.oracle.com> From: "Eric Sedlar" To: "Julian Reschke" Cc: , "Lisa Dusseault" Date: Thu, 7 Nov 2002 00:00:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: Fw: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7012 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julian-- Should we discuss the property metadata draft: http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-lat est.html at the Atlanta IETF? I'm happy to drive discussion on the topic. --Eric ----- Original Message ----- From: "Lisa Dusseault" To: Sent: Tuesday, November 05, 2002 7:10 PM Subject: FW: WG Agendas for the 55th IETF > > I will put together the Agenda for the Atlanta meeting. Here's some > issues that should be discussed. Volunteers are *really needed* ( to > drive discussion on their selected topic) this meeting as I'm *really > swamped* myself! > > > RFC2518bis > - Proposals for client forcing server auth challenge - Ilya? > - Required support for ETags > - If header evaluation/simplification proposals & compatibility - > Geoff? > Other drafts > - quota draft > - Binding issues coming up on DL > - allprop/include draft > Other issues > - Impact of XML namespace changes -- Julian? > - ACL submission status > > I'm sure I've missed items so let me know. > > --Lisa > > -----Original Message----- > From: Dinara Suleymanova [mailto:dinaras@ietf.org] > Sent: Monday, November 04, 2002 8:40 AM > To: wgchairs@ietf.org; bofchairs@ietf.org > Cc: iesg@ietf.org > Subject: WG Agendas for the 55th IETF > > Please start sending your group meetings' agendas. > > Thanks, > > Dinara Suleymanova > > > > > From w3c-dist-auth-request@w3.org Thu Nov 7 07:29:41 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17883 for ; Thu, 7 Nov 2002 07:29:40 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA7CUtw16286; Thu, 7 Nov 2002 07:30:55 -0500 (EST) Resent-Date: Thu, 7 Nov 2002 07:30:55 -0500 (EST) Resent-Message-Id: <200211071230.gA7CUtw16286@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA7CUrB16260 for ; Thu, 7 Nov 2002 07:30:53 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA27990 for ; Thu, 7 Nov 2002 07:30:52 -0500 Received: (qmail 15364 invoked by uid 0); 7 Nov 2002 12:30:21 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp013-rz3) with SMTP; 7 Nov 2002 12:30:21 -0000 From: "Julian Reschke" To: "Eric Sedlar" Cc: , "Lisa Dusseault" Date: Thu, 7 Nov 2002 13:30:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <071401c28633$c37b0a70$51ab2382@us.oracle.com> Importance: Normal Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7013 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Thursday, November 07, 2002 9:01 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org; Lisa Dusseault > Subject: Fw: WG Agendas for the 55th IETF > > > > Julian-- > > Should we discuss the property metadata draft: > > http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-dat > atypes-lat > est.html > > at the Atlanta IETF? I'm happy to drive discussion on the topic. Eric, that would be great. Let me know if I can/should assist in preparing slides. Note that [1] and [2] are currently (almost) identical, and that [2] is the version that has been submitted as Internet Draft. Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Nov 7 09:35:02 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25954 for ; Thu, 7 Nov 2002 09:35:02 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA7Ea9604114; Thu, 7 Nov 2002 09:36:09 -0500 (EST) Resent-Date: Thu, 7 Nov 2002 09:36:09 -0500 (EST) Resent-Message-Id: <200211071436.gA7Ea9604114@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA7Ea8B04084 for ; Thu, 7 Nov 2002 09:36:08 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA09348 for ; Thu, 7 Nov 2002 09:36:07 -0500 Received: (qmail 13647 invoked by uid 0); 7 Nov 2002 14:36:05 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp014-rz3) with SMTP; 7 Nov 2002 14:36:05 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Thu, 7 Nov 2002 15:36:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000e01c28542$09b3a8a0$620afea9@xythoslap> Importance: Normal Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7014 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, November 06, 2002 4:10 AM > To: w3c-dist-auth@w3c.org > Subject: FW: WG Agendas for the 55th IETF > > > > I will put together the Agenda for the Atlanta meeting. Here's some > issues that should be discussed. Volunteers are *really needed* ( to > drive discussion on their selected topic) this meeting as I'm *really > swamped* myself! > > > RFC2518bis > - Proposals for client forcing server auth challenge - Ilya? > - Required support for ETags > - If header evaluation/simplification proposals & compatibility - > Geoff? > Other drafts > - quota draft > - Binding issues coming up on DL > - allprop/include draft > Other issues > - Impact of XML namespace changes -- Julian? > - ACL submission status > > I'm sure I've missed items so let me know. Lisa, if you need help/assistance in preparing > - allprop/include draft and > - Impact of XML namespace changes -- Julian? (which should be XML 1.1/ XML namespaces 1.1 changes, right?), please let me know. Julian From w3c-dist-auth-request@w3.org Thu Nov 7 14:38:50 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07746 for ; Thu, 7 Nov 2002 14:38:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA7Jdtg21874; Thu, 7 Nov 2002 14:39:55 -0500 (EST) Resent-Date: Thu, 7 Nov 2002 14:39:55 -0500 (EST) Resent-Message-Id: <200211071939.gA7Jdtg21874@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA7JdrB21848 for ; Thu, 7 Nov 2002 14:39:53 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA03860 for ; Thu, 7 Nov 2002 14:39:53 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 189sYo-0006XI-00; Thu, 07 Nov 2002 19:43:26 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 189sYo-0006Ww-01; Thu, 07 Nov 2002 19:43:26 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Thu, 7 Nov 2002 11:39:33 -0800 Message-ID: <000b01c28695$65edfd60$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7015 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes -- I need help not only in preparing these discussions, but also leading them at the WG meeting. I understand you won't be able to make it to Atlanta, Julian. Is somebody who will be there able to work with Julian on understanding and explaining the XML namespace issues and the allprop Include draft? lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, November 07, 2002 6:36 AM > To: Lisa Dusseault; w3c-dist-auth@w3c.org > Subject: RE: WG Agendas for the 55th IETF > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, November 06, 2002 4:10 AM > > To: w3c-dist-auth@w3c.org > > Subject: FW: WG Agendas for the 55th IETF > > > > > > > > I will put together the Agenda for the Atlanta meeting. Here's some > > issues that should be discussed. Volunteers are *really needed* ( to > > drive discussion on their selected topic) this meeting as I'm *really > > swamped* myself! > > > > > > RFC2518bis > > - Proposals for client forcing server auth challenge - Ilya? > > - Required support for ETags > > - If header evaluation/simplification proposals & compatibility - > > Geoff? > > Other drafts > > - quota draft > > - Binding issues coming up on DL > > - allprop/include draft > > Other issues > > - Impact of XML namespace changes -- Julian? > > - ACL submission status > > > > I'm sure I've missed items so let me know. > > Lisa, > > if you need help/assistance in preparing > > > - allprop/include draft > > and > > > - Impact of XML namespace changes -- Julian? > > (which should be XML 1.1/ XML namespaces 1.1 changes, right?), please let > me > know. > > Julian > > From w3c-dist-auth-request@w3.org Thu Nov 7 15:33:15 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10344 for ; Thu, 7 Nov 2002 15:33:14 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA7KYl227760; Thu, 7 Nov 2002 15:34:47 -0500 (EST) Resent-Date: Thu, 7 Nov 2002 15:34:47 -0500 (EST) Resent-Message-Id: <200211072034.gA7KYl227760@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA7KYiB27717 for ; Thu, 7 Nov 2002 15:34:44 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA16939; Thu, 7 Nov 2002 15:34:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: Note Well Statement Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7016 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From w3c-dist-auth-request@w3.org Thu Nov 7 17:23:48 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15757 for ; Thu, 7 Nov 2002 17:23:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA7MPAA11675; Thu, 7 Nov 2002 17:25:10 -0500 (EST) Resent-Date: Thu, 7 Nov 2002 17:25:10 -0500 (EST) Resent-Message-Id: <200211072225.gA7MPAA11675@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA7MP8B11647 for ; Thu, 7 Nov 2002 17:25:08 -0500 (EST) Received: from post.webmailer.de (natsmtp01.webmailer.de [192.67.198.81]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA08161 for ; Thu, 7 Nov 2002 17:25:08 -0500 From: Edgar@edgarschwarz.de Received: from x.oberon.ethz.ch ([212.144.42.72]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id XAA19085; Thu, 7 Nov 2002 23:25:03 +0100 (MET) Date: Thu, 7 Nov 2002 23:25:03 +0100 (MET) Message-Id: <200211072225.XAA19085@post.webmailer.de> X-Mailer: Oberon Mail (ejz) on Aos 25.3.2002 To: w3c-dist-auth@w3c.org Cc: Edgar@edgarschwarz.de Subject: Re (2): WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7017 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Lisa Dusseault" wrote: > leading them at the WG meeting. I understand you won't be able to make > it to Atlanta, Julian. Is somebody who will be there able to work with > Julian on understanding and explaining the XML namespace issues and the > allprop Include draft? Like Julian it seems I won't be able to make it to Atlanta :-) Nevertheless I would like to work a night shift to follow the discussions in the meeting from good old Europe. So, are there any plans to implement the 'jabber' option mentioned in a posting some days ago ? The text conference feature is an experiment but I would be interested to try it. Any other guys not going to Atlanta interested ? Cheers, Edgar -- edgar@edgarschwarz.de http://www.edgarschwarz.de * DOSenfreie Zone. Running Active Oberon. * Make it as simple as possible, but not simpler. Albert Einstein From w3c-dist-auth-request@w3.org Thu Nov 7 21:57:38 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22591 for ; Thu, 7 Nov 2002 21:57:38 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA82wof00493; Thu, 7 Nov 2002 21:58:50 -0500 (EST) Resent-Date: Thu, 7 Nov 2002 21:58:50 -0500 (EST) Resent-Message-Id: <200211080258.gA82wof00493@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA82wmB00463 for ; Thu, 7 Nov 2002 21:58:48 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA05664 for ; Thu, 7 Nov 2002 21:58:48 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 07 Nov 2002 21:46:26 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403ZD7H9>; Thu, 7 Nov 2002 21:58:18 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 7 Nov 2002 21:58:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C286D2.B033E3C0" Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7018 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C286D2.B033E3C0 Content-Type: text/plain I will be at the Atlanta meeting, and would be happy to drive the discussion on any of the topics identified below. I don't think I would raise the XML namespace issues, though, until we have some proposal as to how to address them (I agree they are issues, but like Julian, I have no proposal for how to address them). Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Thursday, November 07, 2002 2:40 PM To: 'Julian Reschke'; w3c-dist-auth@w3c.org Subject: RE: WG Agendas for the 55th IETF Yes -- I need help not only in preparing these discussions, but also leading them at the WG meeting. I understand you won't be able to make it to Atlanta, Julian. Is somebody who will be there able to work with Julian on understanding and explaining the XML namespace issues and the allprop Include draft? lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, November 07, 2002 6:36 AM > To: Lisa Dusseault; w3c-dist-auth@w3c.org > Subject: RE: WG Agendas for the 55th IETF > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, November 06, 2002 4:10 AM > > To: w3c-dist-auth@w3c.org > > Subject: FW: WG Agendas for the 55th IETF > > > > > > > > I will put together the Agenda for the Atlanta meeting. Here's some > > issues that should be discussed. Volunteers are *really needed* ( to > > drive discussion on their selected topic) this meeting as I'm *really > > swamped* myself! > > > > > > RFC2518bis > > - Proposals for client forcing server auth challenge - Ilya? > > - Required support for ETags > > - If header evaluation/simplification proposals & compatibility - > > Geoff? > > Other drafts > > - quota draft > > - Binding issues coming up on DL > > - allprop/include draft > > Other issues > > - Impact of XML namespace changes -- Julian? > > - ACL submission status > > > > I'm sure I've missed items so let me know. > > Lisa, > > if you need help/assistance in preparing > > > - allprop/include draft > > and > > > - Impact of XML namespace changes -- Julian? > > (which should be XML 1.1/ XML namespaces 1.1 changes, right?), please let > me > know. > > Julian > > ------_=_NextPart_001_01C286D2.B033E3C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: WG Agendas for the 55th IETF

I will be at the Atlanta meeting, and would be happy = to drive the
discussion on any of the topics identified = below.  I don't think
I would raise the XML namespace issues, though, = until we have some
proposal as to how to address them (I agree they are = issues, but
like Julian, I have no proposal for how to address = them).

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Thursday, November 07, 2002 2:40 PM
To: 'Julian Reschke'; w3c-dist-auth@w3c.org
Subject: RE: WG Agendas for the 55th IETF



Yes -- I need help not only in preparing these = discussions, but also
leading them at the WG meeting.  I understand = you won't be able to make
it to Atlanta, Julian.  Is somebody who will be = there able to work with
Julian on understanding and explaining the XML = namespace issues and the
allprop Include draft?

lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
> Sent: Thursday, November 07, 2002 6:36 = AM
> To: Lisa Dusseault; = w3c-dist-auth@w3c.org
> Subject: RE: WG Agendas for the 55th = IETF
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-reques= t@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Wednesday, November 06, 2002 4:10 = AM
> > To: w3c-dist-auth@w3c.org
> > Subject: FW: WG Agendas for the 55th = IETF
> >
> >
> >
> > I will put together the Agenda for the = Atlanta meeting.  Here's some
> > issues that should be discussed.  = Volunteers are *really needed* (
to
> > drive discussion on their selected topic) = this meeting as I'm
*really
> > swamped* myself!
> >
> >
> > RFC2518bis
> >  - Proposals for client forcing = server auth challenge - Ilya?
> >  - Required support for ETags
> >  - If header = evaluation/simplification proposals & compatibility -
> > Geoff?
> > Other drafts
> >  - quota draft
> >  - Binding issues coming up on = DL
> >  - allprop/include draft
> > Other issues
> >  - Impact of XML namespace changes -- = Julian?
> >  - ACL submission status
> >
> > I'm sure I've missed items so let me = know.
>
> Lisa,
>
> if you need help/assistance in preparing
>
> >  - allprop/include draft
>
> and
>
> >  - Impact of XML namespace changes -- = Julian?
>
> (which should be XML 1.1/ XML namespaces 1.1 = changes, right?), please
let
> me
> know.
>
> Julian
>
>


------_=_NextPart_001_01C286D2.B033E3C0-- From w3c-dist-auth-request@w3.org Fri Nov 8 06:22:33 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13191 for ; Fri, 8 Nov 2002 06:22:33 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA8BNMH26709; Fri, 8 Nov 2002 06:23:22 -0500 (EST) Resent-Date: Fri, 8 Nov 2002 06:23:22 -0500 (EST) Resent-Message-Id: <200211081123.gA8BNMH26709@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA8BNKB26683 for ; Fri, 8 Nov 2002 06:23:20 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA31026 for ; Fri, 8 Nov 2002 06:23:20 -0500 Received: (qmail 15629 invoked by uid 0); 8 Nov 2002 11:22:49 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp014-rz3) with SMTP; 8 Nov 2002 11:22:49 -0000 From: "Julian Reschke" To: , Date: Fri, 8 Nov 2002 12:22:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211072225.XAA19085@post.webmailer.de> Subject: RE: Re (2): WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7019 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Edgar@edgarschwarz.de > Sent: Thursday, November 07, 2002 11:25 PM > To: w3c-dist-auth@w3c.org > Cc: Edgar@edgarschwarz.de > Subject: Re (2): WG Agendas for the 55th IETF > > > > "Lisa Dusseault" wrote: > > leading them at the WG meeting. I understand you won't be able to make > > it to Atlanta, Julian. Is somebody who will be there able to work with > > Julian on understanding and explaining the XML namespace issues and the > > allprop Include draft? > Like Julian it seems I won't be able to make it to Atlanta :-) > Nevertheless I would like to work a night shift to follow the discussions > in the meeting from good old Europe. > So, are there any plans to implement the 'jabber' option > mentioned in a posting > some days ago ? > The text conference feature is an experiment but I would be > interested to try it. > Any other guys not going to Atlanta interested ? Same for me. From w3c-dist-auth-request@w3.org Fri Nov 8 07:36:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15912 for ; Fri, 8 Nov 2002 07:36:09 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA8Caqf03975; Fri, 8 Nov 2002 07:36:52 -0500 (EST) Resent-Date: Fri, 8 Nov 2002 07:36:52 -0500 (EST) Resent-Message-Id: <200211081236.gA8Caqf03975@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA8CaoB03949 for ; Fri, 8 Nov 2002 07:36:50 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA10744 for ; Fri, 8 Nov 2002 07:36:50 -0500 Received: (qmail 27319 invoked by uid 0); 8 Nov 2002 12:36:19 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp012-rz3) with SMTP; 8 Nov 2002 12:36:19 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 8 Nov 2002 13:36:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7020 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Friday, November 08, 2002 3:58 AM > To: w3c-dist-auth@w3c.org > Subject: RE: WG Agendas for the 55th IETF > > > I will be at the Atlanta meeting, and would be happy to drive the > discussion on any of the topics identified below. I don't think Would you be so kind to handle the allprop/include proposal? > I would raise the XML namespace issues, though, until we have some > proposal as to how to address them (I agree they are issues, but > like Julian, I have no proposal for how to address them). I think there's some misunderstanding here. The namespace issue as defined in Jason's list ([1]), DAV_WITH_COLON_IS_NOT_A_URI, is closed (we don't need to change anything). The XML 1.1 and XML namespaces 1.1 *potential* issues should be at least considered ([2]). Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Nov 8 09:29:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19744 for ; Fri, 8 Nov 2002 09:29:25 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA8EUmu16564; Fri, 8 Nov 2002 09:30:48 -0500 (EST) Resent-Date: Fri, 8 Nov 2002 09:30:48 -0500 (EST) Resent-Message-Id: <200211081430.gA8EUmu16564@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA8EUlB16537 for ; Fri, 8 Nov 2002 09:30:47 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA03427 for ; Fri, 8 Nov 2002 09:30:46 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 08 Nov 2002 09:18:23 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Z1XPH>; Fri, 8 Nov 2002 09:30:15 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 8 Nov 2002 09:30:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28733.5AAC7A50" Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7021 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28733.5AAC7A50 Content-Type: text/plain; charset="iso-8859-1" My point was that I have no particular opinion on which way to go for the XML 1.1 and XML namespace issues that you raised (and in your email that raised the issues, you indicated that you didn't have a proposed resolution either). So although I'd be happy to participate in a discussion on this topic, I wouldn't be able to "drive" it in any particular direction. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, November 08, 2002 7:36 AM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: WG Agendas for the 55th IETF > From: Clemm, Geoff > I would raise the XML namespace issues, though, until we have some > proposal as to how to address them (I agree they are issues, but > like Julian, I have no proposal for how to address them). I think there's some misunderstanding here. The namespace issue as defined in Jason's list ([1]), DAV_WITH_COLON_IS_NOT_A_URI, is closed (we don't need to change anything). The XML 1.1 and XML namespaces 1.1 *potential* issues should be at least considered ([2]). Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C28733.5AAC7A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Agendas for the 55th IETF

My point was that I have no particular opinion = on
which way to go for the XML 1.1 and XML namespace = issues
that you raised (and in your email that = raised
the issues, you indicated that you didn't have = a
proposed resolution either).  So although I'd = be
happy to participate in a discussion on this = topic,
I wouldn't be able to "drive" it in any = particular
direction.

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Friday, November 08, 2002 7:36 AM
To: Clemm, Geoff; w3c-dist-auth@w3c.org
Subject: RE: WG Agendas for the 55th IETF


> From: Clemm, Geoff

> I would raise the XML namespace issues, though, = until we have some
> proposal as to how to address them (I agree = they are issues, but
> like Julian, I have no proposal for how to = address them).

I think there's some misunderstanding here.

The namespace issue as defined in Jason's list = ([1]),
DAV_WITH_COLON_IS_NOT_A_URI, is closed (we don't = need to change anything).

The XML 1.1 and XML namespaces 1.1 *potential* issues = should be at least
considered ([2]).

Julian

[1] <http://www.webdav.org/wg/rfcdev/issues.htm>
[2] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002= OctDec/0148.html>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- = tel:+492512807760

------_=_NextPart_001_01C28733.5AAC7A50-- From w3c-dist-auth-request@w3.org Fri Nov 8 09:34:46 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19924 for ; Fri, 8 Nov 2002 09:34:46 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA8EZx817472; Fri, 8 Nov 2002 09:35:59 -0500 (EST) Resent-Date: Fri, 8 Nov 2002 09:35:59 -0500 (EST) Resent-Message-Id: <200211081435.gA8EZx817472@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA8EZwB17443 for ; Fri, 8 Nov 2002 09:35:58 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA05387 for ; Fri, 8 Nov 2002 09:35:57 -0500 Received: (qmail 27508 invoked by uid 0); 8 Nov 2002 14:35:26 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 8 Nov 2002 14:35:26 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 8 Nov 2002 15:35:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7022 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Friday, November 08, 2002 3:30 PM > To: w3c-dist-auth@w3c.org > Subject: RE: WG Agendas for the 55th IETF > > > My point was that I have no particular opinion on > which way to go for the XML 1.1 and XML namespace issues > that you raised (and in your email that raised > the issues, you indicated that you didn't have a > proposed resolution either). So although I'd be > happy to participate in a discussion on this topic, > I wouldn't be able to "drive" it in any particular > direction. I see. At this point, we should just note that there are potential issues. After all, both specs (XML 1.1 and namespaces 1.1) aren't finished yet. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Nov 8 13:20:45 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04537 for ; Fri, 8 Nov 2002 13:20:45 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA8I6d521884; Fri, 8 Nov 2002 13:06:39 -0500 (EST) Resent-Date: Fri, 8 Nov 2002 13:06:39 -0500 (EST) Resent-Message-Id: <200211081806.gA8I6d521884@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA8I6aB21847 for ; Fri, 8 Nov 2002 13:06:36 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA17471 for ; Fri, 8 Nov 2002 13:06:36 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18ADaJ-00029C-00; Fri, 08 Nov 2002 18:10:23 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18ADaJ-000291-00; Fri, 08 Nov 2002 18:10:23 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , Date: Fri, 8 Nov 2002 10:06:17 -0800 Message-ID: <000101c28751$88711bd0$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id gA8I6aB21847 Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7023 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Driving discussion doesn’t necessarily mean having a resolution in mind. Could you outline the possible ways to address the new XML standards work so that the rest of us could have a framework to start thinking about it? Just an overview of what’s different (that might affect WebDAV) would be helpful. Lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Friday, November 08, 2002 6:30 AM To: w3c-dist-auth@w3c.org Subject: RE: WG Agendas for the 55th IETF My point was that I have no particular opinion on which way to go for the XML 1.1 and XML namespace issues that you raised (and in your email that raised the issues, you indicated that you didn't have a proposed resolution either).  So although I'd be happy to participate in a discussion on this topic, I wouldn't be able to "drive" it in any particular direction. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, November 08, 2002 7:36 AM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: WG Agendas for the 55th IETF > From: Clemm, Geoff > I would raise the XML namespace issues, though, until we have some > proposal as to how to address them (I agree they are issues, but > like Julian, I have no proposal for how to address them). I think there's some misunderstanding here. The namespace issue as defined in Jason's list ([1]), DAV_WITH_COLON_IS_NOT_A_URI, is closed (we don't need to change anything). The XML 1.1 and XML namespaces 1.1 *potential* issues should be at least considered ([2]). Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Nov 8 13:56:10 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08032 for ; Fri, 8 Nov 2002 13:56:10 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA8IgIL26518; Fri, 8 Nov 2002 13:42:18 -0500 (EST) Resent-Date: Fri, 8 Nov 2002 13:42:18 -0500 (EST) Resent-Message-Id: <200211081842.gA8IgIL26518@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA8IgEB26488 for ; Fri, 8 Nov 2002 13:42:14 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA27437 for ; Fri, 8 Nov 2002 13:42:14 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 08 Nov 2002 13:29:47 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403ZFT5P>; Fri, 8 Nov 2002 13:41:40 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 8 Nov 2002 13:41:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28756.78A6CDD0" Subject: RE: WG Agendas for the 55th IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7024 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28756.78A6CDD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That information (what is in the new XML standards that is relevant to WebDAV) is all in Julian's original message. I would be happy to briefly present that information at the working group meeting. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Friday, November 08, 2002 1:06 PM To: 'Clemm, Geoff'; w3c-dist-auth@w3c.org Subject: RE: WG Agendas for the 55th IETF Driving discussion doesn't necessarily mean having a resolution in = mind. Could you outline the possible ways to address the new XML standards work so that the rest of us could have a framework to start thinking about it? Just an overview of what's different (that might affect WebDAV) would be helpful. Lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com]=20 Sent: Friday, November 08, 2002 6:30 AM To: w3c-dist-auth@w3c.org Subject: RE: WG Agendas for the 55th IETF My point was that I have no particular opinion on which way to go for the XML 1.1 and XML namespace issues that you raised (and in your email that raised the issues, you indicated that you didn't have a proposed resolution either).=A0 So although I'd be happy to participate in a discussion on this topic, I wouldn't be able to "drive" it in any particular direction. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, November 08, 2002 7:36 AM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: WG Agendas for the 55th IETF > From: Clemm, Geoff > I would raise the XML namespace issues, though, until we have some > proposal as to how to address them (I agree they are issues, but > like Julian, I have no proposal for how to address them). I think there's some misunderstanding here. The namespace issue as defined in Jason's list ([1]), DAV_WITH_COLON_IS_NOT_A_URI, is closed (we don't need to change anything). The XML 1.1 and XML namespaces 1.1 *potential* issues should be at = least considered ([2]). Julian [1] [2] = -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C28756.78A6CDD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Agendas for the 55th IETF

That information (what is in the new XML standards = that is relevant
to WebDAV) is all in Julian's original = message.  I would be happy to
briefly present that information at the working = group meeting.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Friday, November 08, 2002 1:06 PM
To: 'Clemm, Geoff'; w3c-dist-auth@w3c.org
Subject: RE: WG Agendas for the 55th IETF



Driving discussion doesn't necessarily mean having a = resolution in mind.
Could you outline the possible ways to address the = new XML standards
work so that the rest of us could have a framework = to start thinking
about it?  Just an overview of what's different = (that might affect
WebDAV) would be helpful.

Lisa

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com] =
Sent: Friday, November 08, 2002 6:30 AM
To: w3c-dist-auth@w3c.org
Subject: RE: WG Agendas for the 55th IETF

My point was that I have no particular opinion = on
which way to go for the XML 1.1 and XML namespace = issues
that you raised (and in your email that = raised
the issues, you indicated that you didn't have = a
proposed resolution either).=A0 So although I'd = be
happy to participate in a discussion on this = topic,
I wouldn't be able to "drive" it in any = particular
direction.
Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Friday, November 08, 2002 7:36 AM
To: Clemm, Geoff; w3c-dist-auth@w3c.org
Subject: RE: WG Agendas for the 55th IETF

> From: Clemm, Geoff
> I would raise the XML namespace issues, though, = until we have some
> proposal as to how to address them (I agree = they are issues, but
> like Julian, I have no proposal for how to = address them).
I think there's some misunderstanding here.
The namespace issue as defined in Jason's list = ([1]),
DAV_WITH_COLON_IS_NOT_A_URI, is closed (we don't = need to change
anything).
The XML 1.1 and XML namespaces 1.1 *potential* = issues should be at least
considered ([2]).
Julian
[1] <http://www.webdav.org/wg/rfcdev/issues.htm>
[2]
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002= OctDec/0148.html>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- = tel:+492512807760

------_=_NextPart_001_01C28756.78A6CDD0-- From w3c-dist-auth-request@w3.org Sat Nov 9 16:33:16 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25866 for ; Sat, 9 Nov 2002 16:33:16 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA9LXkC27384; Sat, 9 Nov 2002 16:33:46 -0500 (EST) Resent-Date: Sat, 9 Nov 2002 16:33:46 -0500 (EST) Resent-Message-Id: <200211092133.gA9LXkC27384@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA9LXiB27358 for ; Sat, 9 Nov 2002 16:33:44 -0500 (EST) Received: from mail.dc3.com (dc3.com [68.98.211.142]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA15594 for ; Sat, 9 Nov 2002 16:33:44 -0500 Received: from dc3.com ([68.98.211.147]) by dc3.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.5.1.R) for ; Sat, 09 Nov 2002 14:33:36 -0700 Message-ID: <3DCD7F2F.7030409@dc3.com> Date: Sat, 09 Nov 2002 14:33:35 -0700 From: Bob Denny User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en,pdf MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDRemoteIP: 68.98.211.147 X-Return-Path: rdenny@dc3.com X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Regression test tools? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7025 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, call me late to the party, but I am just now implementing WebDAV (class 2) for the Deerfield "Visnetic WebSite" webserver (formerly known as O'Reilly WebSite Pro). So far so good, thanks to the volumes of second-hand experience I have gleaned by reading this list's archive. Thanks for that!!! I have a couple of test tools (DAV explorer and the Tamino test client) plus various things like GoLive, IE5/6 Web Folders, Dreamweaver MX for interop testing. Testing with full applications is too painful till I reach a "peak" during development (followed by yet another descent into a valley like the one I got into while atomizing PROPPATCH :-)))) So here are my questions: (2) Does anyone have a suite of validation tools for WebDAV? I read posts from several folks that said things like "my test tool reports... and it caught an error in ...". and (2) can I get a copy to use? Don't worry about it being a support burden. If you'll show me how to get the engines started, I can fly it. I wish it were June so I'd be ready for the Sept. interop testing. Sigh... -- Bob From w3c-dist-auth-request@w3.org Sat Nov 9 16:59:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26254 for ; Sat, 9 Nov 2002 16:59:29 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA9M16l02819; Sat, 9 Nov 2002 17:01:06 -0500 (EST) Resent-Date: Sat, 9 Nov 2002 17:01:06 -0500 (EST) Resent-Message-Id: <200211092201.gA9M16l02819@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA9M13B02712 for ; Sat, 9 Nov 2002 17:01:03 -0500 (EST) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA19859 for ; Sat, 9 Nov 2002 17:01:03 -0500 Received: from manyfish.co.uk ([62.253.142.7]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021109220102.ZUKI18329.mta06-svc.ntlworld.com@manyfish.co.uk> for ; Sat, 9 Nov 2002 22:01:02 +0000 Received: from monolith.fishnet (monolith.fishnet [192.168.42.1] (may be forged)) by manyfish.co.uk (8.12.5/8.12.5) with ESMTP id gA9M1atn018108 for ; Sat, 9 Nov 2002 22:01:36 GMT Received: (from joe@localhost) by monolith.fishnet (8.12.5/8.12.5/Submit) id gA9M1aRA018107 for w3c-dist-auth@w3c.org; Sat, 9 Nov 2002 22:01:36 GMT Date: Sat, 9 Nov 2002 22:01:36 +0000 From: Joe Orton To: WebDAV Message-ID: <20021109220135.GA17484@manyfish.co.uk> Mail-Followup-To: WebDAV References: <3DCD7F2F.7030409@dc3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DCD7F2F.7030409@dc3.com> User-Agent: Mutt/1.4i Subject: Re: Regression test tools? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7026 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Sat, Nov 09, 2002 at 02:33:35PM -0700, Bob Denny wrote: > So here are my questions: (2) Does anyone have a suite of validation tools > for WebDAV? I read posts from several folks that said things like "my test > tool reports... and it caught an error in ...". and (2) can I get a copy to > use? Don't worry about it being a support burden. If you'll show me how to > get the engines started, I can fly it. You can try Litmus: http://www.webdav.org/neon/litmus/ Feedback welcome at litmus@webdav.org. Regards, joe From w3c-dist-auth-request@w3.org Sat Nov 9 17:36:54 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26642 for ; Sat, 9 Nov 2002 17:36:54 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA9McYK05122; Sat, 9 Nov 2002 17:38:34 -0500 (EST) Resent-Date: Sat, 9 Nov 2002 17:38:34 -0500 (EST) Resent-Message-Id: <200211092238.gA9McYK05122@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA9McWB05079 for ; Sat, 9 Nov 2002 17:38:32 -0500 (EST) Received: from mail.dc3.com (dc3.com [68.98.211.142]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA24083 for ; Sat, 9 Nov 2002 17:38:32 -0500 Received: from dc3.com ([68.98.211.147]) by dc3.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.5.1.R) for ; Sat, 09 Nov 2002 15:38:21 -0700 Message-ID: <3DCD8E5C.3040505@dc3.com> Date: Sat, 09 Nov 2002 15:38:20 -0700 From: Bob Denny User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Joe Orton CC: WebDAV References: <3DCD7F2F.7030409@dc3.com> <20021109220135.GA17484@manyfish.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDRemoteIP: 68.98.211.147 X-Return-Path: rdenny@dc3.com X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: Regression test tools? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7027 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Joe -- OK, thanks. I'll have a look... -- Bob From w3c-dist-auth-request@w3.org Mon Nov 11 15:42:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00837 for ; Mon, 11 Nov 2002 15:42:03 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gABKgJh12949; Mon, 11 Nov 2002 15:42:19 -0500 (EST) Resent-Date: Mon, 11 Nov 2002 15:42:19 -0500 (EST) Resent-Message-Id: <200211112042.gABKgJh12949@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gABKgHB12918 for ; Mon, 11 Nov 2002 15:42:17 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05255 for ; Mon, 11 Nov 2002 15:42:17 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18BLSN-0007Ix-00 for w3c-dist-auth@w3c.org; Mon, 11 Nov 2002 20:46:51 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18BLSN-0007Im-00 for w3c-dist-auth@w3c.org; Mon, 11 Nov 2002 20:46:51 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Mon, 11 Nov 2002 12:41:54 -0800 Message-ID: <000601c289c2$c704da80$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: Agenda for WebdAV WG meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7028 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is the agenda I plan to submit for the Atlanta mtg. If there's no volunteer to discuss bindings, that draft will be dropped from the agenda. Please let me know how long you need for your item or I will assume each issue requires 15 minutes and each draft 20 minutes. 1. ACL status: Lisa Dusseault 2. RFC 2518 bis issues Client force authentication issue: Brian Korver If header simplification Required Support for ETags: Lisa Dusseault New XML Namespaces: Geoff Clemm 3. Other drafts Allprop Include draft: Geoff Clemm Quota draft: Lisa Dusseault Bindings: * need a volunteer * Lisa From w3c-dist-auth-request@w3.org Mon Nov 11 15:42:35 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00856 for ; Mon, 11 Nov 2002 15:42:34 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gABKh4t12996; Mon, 11 Nov 2002 15:43:04 -0500 (EST) Resent-Date: Mon, 11 Nov 2002 15:43:04 -0500 (EST) Resent-Message-Id: <200211112043.gABKh4t12996@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gABKh3B12970 for ; Mon, 11 Nov 2002 15:43:03 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05350 for ; Mon, 11 Nov 2002 15:43:03 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18BLT7-0007KO-00; Mon, 11 Nov 2002 20:47:37 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18BLT7-0007KC-00; Mon, 11 Nov 2002 20:47:37 +0000 From: "Lisa Dusseault" To: "'Lisa Dusseault'" , "Webdav WG" Date: Mon, 11 Nov 2002 12:42:43 -0800 Message-ID: <000701c289c2$e26dc2a0$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: lisa@xythos.com, w3c-dist-auth@w3c.org Subject: RE: Agenda for WebdAV WG meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7029 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry, I missed one draft: Property data types, Eric Sedlar > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Monday, November 11, 2002 12:42 PM > To: Webdav WG (w3c-dist-auth@w3c.org) > Subject: Agenda for WebdAV WG meeting > > > This is the agenda I plan to submit for the Atlanta mtg. If there's no > volunteer to discuss bindings, that draft will be dropped from the agenda. > Please let me know how long you need for your item or I will assume each > issue requires 15 minutes and each draft 20 minutes. > > 1. ACL status: Lisa Dusseault > > 2. RFC 2518 bis issues > Client force authentication issue: Brian Korver > If header simplification > Required Support for ETags: Lisa Dusseault > New XML Namespaces: Geoff Clemm > > 3. Other drafts > Allprop Include draft: Geoff Clemm > Quota draft: Lisa Dusseault > Bindings: * need a volunteer * Property datatypes: Eric Sedlar > > Lisa From w3c-dist-auth-request@w3.org Mon Nov 11 20:57:23 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08344 for ; Mon, 11 Nov 2002 20:57:23 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAC1vsI20053; Mon, 11 Nov 2002 20:57:54 -0500 (EST) Resent-Date: Mon, 11 Nov 2002 20:57:54 -0500 (EST) Resent-Message-Id: <200211120157.gAC1vsI20053@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAC1vpB20027 for ; Mon, 11 Nov 2002 20:57:51 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA28260 for ; Mon, 11 Nov 2002 20:57:51 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18BQNo-0004pk-00; Tue, 12 Nov 2002 02:02:28 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18BQNo-0004pY-00; Tue, 12 Nov 2002 02:02:28 +0000 From: "Lisa Dusseault" To: "'Dinara Suleymanova'" Cc: "'Webdav WG'" Date: Mon, 11 Nov 2002 17:57:49 -0800 Message-ID: <000101c289ee$e7357fe0$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <5.1.0.14.2.20021105135202.029300b0@odin> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: dinaras@ietf.org, w3c-dist-auth@w3c.org Subject: Agenda for WebDAV WG meeting in Atlanta Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7030 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dinara, Here is the agenda for 'webdav', meeting Tuesday afternoon. 0. Agenda bash, 5 min 1. ACL status: Lisa Dusseault, 5 min 2. RFC 2518 bis issues Client force authentication issue: Brian Korver, 15 min If header simplification: 15 min Required Support for ETags: Lisa Dusseault, 10 min New XML Namespaces: Geoff Clemm, 10 min 3. Other drafts Allprop Include draft: Geoff Clemm, 20 min Quota draft: Lisa Dusseault, 20 min Property datatypes: Eric Sedlar, 20 min Lisa > -----Original Message----- > From: Dinara Suleymanova [mailto:dinaras@ietf.org] > Sent: Tuesday, November 05, 2002 10:54 AM > To: wgchairs@ietf.org; bofchairs@ietf.org > Cc: iesg@ietf.org > Subject: agendas > > We have one week left for agendas submission. > Please send your agendas as they are ready. > Not many of you submitted them. > > Dinara Suleymanova > From w3c-dist-auth-request@w3.org Tue Nov 12 13:07:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08662 for ; Tue, 12 Nov 2002 13:07:03 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gACI8AA29845; Tue, 12 Nov 2002 13:08:10 -0500 (EST) Resent-Date: Tue, 12 Nov 2002 13:08:10 -0500 (EST) Resent-Message-Id: <200211121808.gACI8AA29845@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gACI88B29819 for ; Tue, 12 Nov 2002 13:08:08 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA05889 for ; Tue, 12 Nov 2002 13:08:07 -0500 Received: (qmail 2980 invoked by uid 0); 12 Nov 2002 18:07:31 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 12 Nov 2002 18:07:31 -0000 From: "Julian Reschke" To: "WebDAV \(E-mail\)" Date: Tue, 12 Nov 2002 19:07:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RFC2518 issue: PROPPATCH response codes for protected properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7031 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit In 8.2.1 [1], RFC2518 states: 403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties. 409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. This includes trying to set read-only properties. I think the entry for 409 is just plain wrong -- if a property is read-only ("protected" in deltaV speak), than there's no point in retrying, thus 409 seems to be the wrong choice (it should be 403, possibly with DAV:error in DAV:reponsedescription). Is anybody relying on 409 rather than 403? Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Nov 12 15:01:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12778 for ; Tue, 12 Nov 2002 15:01:17 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gACK2bp12626; Tue, 12 Nov 2002 15:02:37 -0500 (EST) Resent-Date: Tue, 12 Nov 2002 15:02:37 -0500 (EST) Resent-Message-Id: <200211122002.gACK2bp12626@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gACK2ZB12595 for ; Tue, 12 Nov 2002 15:02:35 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA10827 for ; Tue, 12 Nov 2002 15:02:34 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 12 Nov 2002 14:50:01 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403ZLPTW>; Tue, 12 Nov 2002 15:02:04 -0500 Message-ID: From: "Clemm, Geoff" To: Webdav WG Date: Tue, 12 Nov 2002 15:02:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28A86.5E2E2B50" Subject: RE: Agenda for WebdAV WG meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7032 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28A86.5E2E2B50 Content-Type: text/plain I can lead the bindings discussion. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Monday, November 11, 2002 3:42 PM To: Webdav WG Subject: Agenda for WebdAV WG meeting This is the agenda I plan to submit for the Atlanta mtg. If there's no volunteer to discuss bindings, that draft will be dropped from the agenda. Please let me know how long you need for your item or I will assume each issue requires 15 minutes and each draft 20 minutes. 1. ACL status: Lisa Dusseault 2. RFC 2518 bis issues Client force authentication issue: Brian Korver If header simplification Required Support for ETags: Lisa Dusseault New XML Namespaces: Geoff Clemm 3. Other drafts Allprop Include draft: Geoff Clemm Quota draft: Lisa Dusseault Bindings: * need a volunteer * Lisa ------_=_NextPart_001_01C28A86.5E2E2B50 Content-Type: text/html RE: Agenda for WebdAV WG meeting

I can lead the bindings discussion.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Monday, November 11, 2002 3:42 PM
To: Webdav WG
Subject: Agenda for WebdAV WG meeting




This is the agenda I plan to submit for the Atlanta mtg. If there's no
volunteer to discuss bindings, that draft will be dropped from the
agenda.  Please let me know how long you need for your item or I will
assume each issue requires 15 minutes and each draft 20 minutes.

1. ACL status: Lisa Dusseault

2. RFC 2518 bis issues
  Client force authentication issue:  Brian Korver
  If header simplification
  Required Support for ETags: Lisa Dusseault
  New XML Namespaces: Geoff Clemm

3. Other drafts
  Allprop Include draft: Geoff Clemm
  Quota draft: Lisa Dusseault
  Bindings: * need a volunteer *

Lisa

------_=_NextPart_001_01C28A86.5E2E2B50-- From w3c-dist-auth-request@w3.org Tue Nov 12 16:51:29 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17614 for ; Tue, 12 Nov 2002 16:51:29 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gACLqeZ27380; Tue, 12 Nov 2002 16:52:40 -0500 (EST) Resent-Date: Tue, 12 Nov 2002 16:52:40 -0500 (EST) Resent-Message-Id: <200211122152.gACLqeZ27380@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gACLqcB27354 for ; Tue, 12 Nov 2002 16:52:38 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08918 for ; Tue, 12 Nov 2002 16:52:38 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18Bj2G-0000ki-00 for w3c-dist-auth@w3.org; Tue, 12 Nov 2002 21:57:28 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18Bj2G-0000kX-00 for w3c-dist-auth@w3.org; Tue, 12 Nov 2002 21:57:28 +0000 From: "Lisa Dusseault" To: "'WebDAV \(E-mail\)'" Date: Tue, 12 Nov 2002 13:52:36 -0800 Message-ID: <000201c28a95$cff69880$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Informal WebDAVists supper Tuesday evening? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7033 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Who would like to have supper Tuesday evening after the WebDAV WG meeting? There are evening sessions (S/MIME for instance) but we could probably manage to return in time for most of the evening sessions. If you know ahead of time you'll be there, RSVP to me personally because that should make it easier to find a restaurant (I might make a reservation if there's a large group). Let me know if there's some kind of restaurant that would be unacceptable to you. If you don't know ahead of time, well just be there at the WG meeting, & we'll probably take off from the meeting. Or call my cell phone 650 279 7365 to coordinate. Lisa From w3c-dist-auth-request@w3.org Wed Nov 13 11:21:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06992 for ; Wed, 13 Nov 2002 11:21:29 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gADGLiW19023; Wed, 13 Nov 2002 11:21:44 -0500 (EST) Resent-Date: Wed, 13 Nov 2002 11:21:44 -0500 (EST) Resent-Message-Id: <200211131621.gADGLiW19023@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gADGLfB18954 for ; Wed, 13 Nov 2002 11:21:41 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA11860 for ; Wed, 13 Nov 2002 11:21:41 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18C0Li-0007cT-00 for w3c-dist-auth@w3c.org; Wed, 13 Nov 2002 16:26:42 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18C0Li-0007cI-00 for w3c-dist-auth@w3c.org; Wed, 13 Nov 2002 16:26:42 +0000 From: "Lisa Dusseault" To: "'Webdav WG'" Date: Wed, 13 Nov 2002 08:21:39 -0800 Message-ID: <000101c28b30$bef91080$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: IETF process: "draft darwinism" Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7034 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The IETF WG chairs mailing list has been having some interesting discussions about IETF process. There will likely be continued discussions at the IESG Plenary in Atlanta next week, too. Although people are discussing changes, it's way too early to know what, if anything, will change. I got permission to forward some email from Edward Lewis in the discussion, because I thought it describes some aspects of the existing process really clearly. > Harking back to my earliest IETF experience, the thought that got me > in was that this organization had implemented technological > darwinism. By the mere fact that ID's time out, any idea may come > along, but only the good ones prosper. And from another email: > ... If consensus isn't reached it's > best to walk away from declaring any solution. It's happened in > provreg (we've had about 9 documents[0] so far enter the WG - 1 has > gone to RFC, 5 are in front of the IESG, 3 have been dropped and just > 1 still under consideration). I.e. 33% of our documents to date have > been killed because no consensus could be reached. (Whether because > of "I don't like" or "I don't care" sentiments.) > > My rationale is that consensus means that the group has found common > ground. If there is no common ground, then we don't have > interoperability - and that is the single most important feature of > an IETF standard. If interoperability isn't the overriding goal, > then the WG ought to be conforming to some other standards body > anyway. > > As far as "closing the WG" - that's not always the solution. I've > seen individual issues (DNS is loaded with them) that fail to achieve > consensus and then wither away without closing the group. (I suppose > that the intent in school 1 was not to always result in a fatal error > for the WG, but when I first read the message, I didn't recognize #1 > as my solution because of the "closing" phrase.) > > [0] 2 are knocking at the door but haven't been allowed in. > -- The point of this is that the WebDAV WG naturally tries to "complete" each of its drafts, as if they are assignments that must be handed in or we'll get a bad grade. That's not the case. We can also drop work, even work that is in our charter, and it doesn't mean we've failed as a working group. Lisa From w3c-dist-auth-request@w3.org Wed Nov 13 17:58:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21096 for ; Wed, 13 Nov 2002 17:58:09 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gADMwhm09156; Wed, 13 Nov 2002 17:58:43 -0500 (EST) Resent-Date: Wed, 13 Nov 2002 17:58:43 -0500 (EST) Resent-Message-Id: <200211132258.gADMwhm09156@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gADMwgB09128 for ; Wed, 13 Nov 2002 17:58:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA28408 for ; Wed, 13 Nov 2002 17:58:40 -0500 Received: (qmail 16856 invoked by uid 0); 13 Nov 2002 22:58:08 -0000 Received: from p3ee24815.dip.t-dialin.net (HELO lisa) (62.226.72.21) by mail.gmx.net (mp022-rz3) with SMTP; 13 Nov 2002 22:58:08 -0000 From: "Julian Reschke" To: "WebDAV" Date: Wed, 13 Nov 2002 23:58:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: Impact of XML 1.1 and namespaces 1.1 on WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7035 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit (here's a minor update for usage during the IETF meeting) Hi, as the W3C is finishing these specs, I'd like to make the WG aware of the questions we'll have to answer about how these changes impact WebDAV. Changes that are IMHO relevant to WebDAV are: 1) The set of characters that can appear in an XML name has been extended (it now includes more Unicode characters). Infosets using these names can *not* be marshalled as XML 1.0 documents. 2a) The set of characters that can be marshalled as text data has been extended to include the control characters 1..31 (although only as character reference; null is still forbidden). Again: infosets containing these characters can *not* be marshalled as XML 1.0 documents. 2b) The characters 128..159 (Unicode control characters) can not be marshalled as is (only as character references). Infosets containing these characters can be marshalled as XML 1.1 documents, but requires serialization as character references (which will be XML 1.0 compatible as well). 3) XML 1.1 processors may reject documents if they contain non-normalized Unicode (yes, this is optional). 4) Namespaces 1.1 allows IRIs rather than only URIs as namespace names. One possible position would be that we just ignore it. Nothing would change immediately. However we lose the ability to marshall "any" kind of XML through WebDAV properties. Allowing XML 1.1 request bodies for PROPPATCH *will* have a big impact. For instance, properties are identified by QNames, and with XML 1.1 both the valid character sets for the namespace name (can now be a IRI and thus contain non-quoted non-ASCII characters) and the local name (just a bigger subset of Unicode) will change. It may not be possible to marshall these "extended" property names back to a client that only understands XML 1.0. Similar problems appear with control characters in property values -- once they appear in a property value, the property can only be marshalled back to clients with XML-1.1 compliant parsers. At this point, I don't have a recommendation how to treat this, but maybe some more WG members should take a look at the current drafts. XML namespaces 1.1 allowing IRIs is currently under debate on the W3C TAG (Technical Architecture Mailing List) -- people interested in this topic might want to check the mailing list archives. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, October 22, 2002 10:04 AM > To: WebDAV > Subject: Impact of XML 1.1 and namespaces 1.1 on WebDAV > > > Hi, > > as the W3C is finishing these specs, I'd like to make the WG > aware of the questions we'll have to answer about how these > changes impact WebDAV. > > Changes that are IMHO relevant to WebDAV are: > > 1) The set of characters that can appear in an XML name has been > extended (it now includes more Unicode characters). > > 2) The set of characters that can be marshalled as text data has > been extended to include the control characters 1..31 (although > only as character reference; null is still forbidden) > > 3) XML 1.1 processors may reject documents if they contain > non-normalized Unicode (yers, this is optional). > > 4) Namespaces 1.1 allows IRIs rather than only URIs as namespace names. > > One possible position would be that we just ignore it. Nothing > would change immediately. However we lose the ability to marshall > "any" kind of XML through WebDAV properties. > > Allowing XML 1.1 request bodies for PROPPATCH *will* have a big > impact. For instance, properties are identified by QNames, and > with XML 1.1 both the valid character sets for the namespace name > (can now be a IRI and thus contain non.quoted non-ASCII > characters) and the local name (just a bigger subset of Unicode) > will change. It may not be possible to marshall these "extended" > property names back to a client that only understands XML 1.0. > > Similar problems appear with control characters in property > values -- once they appear in a property value, the property can > only be marshalled back to clients with XML-1.1 compliant parsers. > > At this point, I don't have a recommendation how to treat this, > but maybe some more WG members should take a look at the current drafts. > > Julian > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Wed Nov 13 18:34:29 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21766 for ; Wed, 13 Nov 2002 18:34:28 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gADNZow13467; Wed, 13 Nov 2002 18:35:50 -0500 (EST) Resent-Date: Wed, 13 Nov 2002 18:35:50 -0500 (EST) Resent-Message-Id: <200211132335.gADNZow13467@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gADNZnB13441 for ; Wed, 13 Nov 2002 18:35:49 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA04292 for ; Wed, 13 Nov 2002 18:35:48 -0500 Received: from lisa [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 14 Nov 2002 00:35:35 +0100 From: "Julian Reschke" To: Date: Thu, 14 Nov 2002 00:35:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: IETF WebDAV WG meeting -- current status of greenbytes activities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7036 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, 1) Internet Draft "Datatypes for WebDAV properties" [1] Initially, this only covered marshalling of type information for WebDAV properties. It builds on the datatype part of XML schema (not the structure part), and is compatible to what other XML vocabularies do (for instance, SOAP). It's also very similar to the type system in Microsoft IIS, Exhange and Sharepoint -- the main difference being that it's based on W3C recommendations. This part of the draft has been stable since almost a year, and support has been present in shipping SAP Enterpise Portal servers for several months now. Recently, we have started to extend the draft to marshall information that should make it possible for generic clients to treat a resource's properties in a more meaningful way. It includes - flags ("hidden" and "protected") -- this is already in the draft, and - display names (language dependant). This has been published as I-D in October, and hopefully Eric Sedlar will be able to give a summary during the WG meeting. 2) Internet Draft "Computing the CHECKIN URI in WebDAV versioning" [2] This has been stable for several months now and is implemented in shipping SAP Enterprise Portal servers. From the abstract: "In many cases, a versioning-aware client might want to display/include the URI of the version it's editing while it's being edited. For instance, an editor might include this as meta information, or the author of a document might want to know the URI of the version before it's checked in. A well-known example is the W3C way of referring to document versions in recommendations: it contains references to "the current version", to "this version" and to the "previous version". Something like this is currently impossible with WebDAV versioning [RFC3253], as the version URI is determined at the time of CHECKIN." We will probably submit it for publication as Informational RFC soon, unless other WG members file like participating in this activity. 3) Internet Draft "Including additional properties in WebDAV PROPFIND/allprop requests" [3] Again, this has been stable for several months now and is implemented in shipping SAP Enterprise Portal servers. From the abstract: "Recent specifications extending the Web Distributed Authoring Protocol (WebDAV) restrict the set of properties returned automatically upon a PROPFIND/allprop request. This specification defines a method to add specific properties to the set of properties returned upon PROPFIND/allprop." The current draft has been submitted to the RFC editor for publication as Informational RFC in September. It's now up to the WG to decide whether this should be transformed into a WG activity (leading to inclusion into RFC2518bis or to publication as separate Working Group draft), or whether it can be published as informational (and private) RFC. Hopefully, Geoff will be able to say a few words about this during the WG meeting. 4) WebDAV SEARCH [4] This draft is very slowly progressing and is fully supported in the current SAP Enterprise Portal version. The main open issues are: - whether or not the section describing the SEARCH method in general should be rewritten to specify RFC3253-like error response marshalling (needs editorial time and commitment from current implementors to change/upgrade implementations) and - cleanup of DAV:basicsearch, mainly to properly define valid lexical value spaces, and how datatypes relate to the various operators (such as: string collations and so on) At this point, the main reason for the slow progress is the lack of feedback on the mailing list. 5) WebDAV Ordered Collections Protocol [5] We feel that this protocol is stable, and we have volunteered in March to resubmit it after clean up. We still plan to reformat the draft to use RFC3253-based error marshalling. 6) WebDAV Redirect Reference Resources [6] We have implemented this draft, and are *very* interested in getting better client support for it. At a minimum, clients should be able to correctly process a server's 302 response (for instance, the basic MS webfolder client doesn't on PROPFIND, but the newer versions shipping with Sharepoint and Office XP do). Our plan is to update the old Internet Draft as soon as we're done with [5]. Julian [1] [2] [3] [4] [5] [6] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Nov 15 13:28:58 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14864 for ; Fri, 15 Nov 2002 13:28:58 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAFITSj06746; Fri, 15 Nov 2002 13:29:28 -0500 (EST) Resent-Date: Fri, 15 Nov 2002 13:29:28 -0500 (EST) Resent-Message-Id: <200211151829.gAFITSj06746@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAFITPB06720 for ; Fri, 15 Nov 2002 13:29:25 -0500 (EST) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA18221 for ; Fri, 15 Nov 2002 13:29:25 -0500 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id gAFIT1K16120 for ; Fri, 15 Nov 2002 10:29:01 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 15 Nov 2002 10:25:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: Status of ACL specification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7037 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit There is an item on the WG agenda for a brief overview of the ACL specification status. I thought I'd give my brief impression on its current status here, and Lisa can add her sense of its status during the WG meeting as well. The ACL specification has finished its 2 week IETF-wide last call for comments period, with only two comments being registered, one from Ned Freed, and another from IANA. Both can be found in the archives of the ACL discussion list (http://mailman.webdav.org/pipermail/acl/). The ACL specification has been revised based on these comments, as well as other comments received on the ACL discussion list (acl@webdav.org) since the release of the -09 specification (this is the version that went through IETF-wide review). This preliminary -10 version of the specification is now available at (http://www.webdav.org/acl/). Over the next few days we'll be tweaking language in this specification to resolve any final issues. An implication of this is that if you want to review this specification (i.e., if you think you might implement this specification someday), you should do so *immediately*. The intent is to publish a new Internet-Draft, draft-ietf-webdav-acl-10, immediately after the Atlanta IETF meeting (i.e., on or about the 25th of November). This draft will then be sent to the IESG for review, and hopefully approval. Assuming it is approved, publication as an RFC will happen about 1-2 months afterwards. So, we're on track for the ACL specification moving to RFC in early 2003. - Jim From w3c-dist-auth-request@w3.org Fri Nov 15 19:02:21 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24424 for ; Fri, 15 Nov 2002 19:02:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAG03rj27957; Fri, 15 Nov 2002 19:03:53 -0500 (EST) Resent-Date: Fri, 15 Nov 2002 19:03:53 -0500 (EST) Resent-Message-Id: <200211160003.gAG03rj27957@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAG03pB27927 for ; Fri, 15 Nov 2002 19:03:51 -0500 (EST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA18781 for ; Fri, 15 Nov 2002 19:03:51 -0500 Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gAG03HO15645 for ; Fri, 15 Nov 2002 16:03:17 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id gAG03Bk15513 for ; Fri, 15 Nov 2002 16:03:11 -0800 (PST) Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id gAG03BI25595 for ; Fri, 15 Nov 2002 17:03:11 -0700 (MST) Received: from 152.68.17.155 by rgmum4.us.oracle.com with ESMTP id 103391841037404911; Fri, 15 Nov 2002 17:01:51 -0600 Message-ID: <184101c28d02$f1ac09f0$9b114498@esedlar> From: "Eric Sedlar" To: "Julian Reschke" , "WebDAV" References: Date: Fri, 15 Nov 2002 15:58:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: Re: Impact of XML 1.1 and namespaces 1.1 on WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7038 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit In the general theory of being flexible with what you accept and careful with what you generate, it sounds like WebDAV servers should accept XML1.1 input, but only generate XML 1.0 output. I also recommend us looking into the IRI issue. --Eric ----- Original Message ----- From: "Julian Reschke" To: "WebDAV" Sent: Wednesday, November 13, 2002 2:58 PM Subject: RE: Impact of XML 1.1 and namespaces 1.1 on WebDAV > > (here's a minor update for usage during the IETF meeting) > > Hi, > > as the W3C is finishing these specs, I'd like to make the WG aware of the > questions we'll have to answer about how these changes impact WebDAV. > > Changes that are IMHO relevant to WebDAV are: > > 1) The set of characters that can appear in an XML name has been extended > (it now includes more Unicode characters). Infosets using these names can > *not* be marshalled as XML 1.0 documents. > > 2a) The set of characters that can be marshalled as text data has been > extended to include the control characters 1..31 (although only as character > reference; null is still forbidden). Again: infosets containing these > characters can *not* be marshalled as XML 1.0 documents. > > 2b) The characters 128..159 (Unicode control characters) can not be > marshalled as is (only as character references). Infosets containing these > characters can be marshalled as XML 1.1 documents, but requires > serialization as character references (which will be XML 1.0 compatible as > well). > > 3) XML 1.1 processors may reject documents if they contain non-normalized > Unicode (yes, this is optional). > > 4) Namespaces 1.1 allows IRIs rather than only URIs as namespace names. > > One possible position would be that we just ignore it. Nothing would change > immediately. However we lose the ability to marshall "any" kind of XML > through WebDAV properties. > > Allowing XML 1.1 request bodies for PROPPATCH *will* have a big impact. For > instance, properties are identified by QNames, and with XML 1.1 both the > valid character sets for the namespace name (can now be a IRI and thus > contain non-quoted non-ASCII characters) and the local name (just a bigger > subset of Unicode) will change. It may not be possible to marshall these > "extended" property names back to a client that only understands XML 1.0. > > Similar problems appear with control characters in property values -- once > they appear in a property value, the property can only be marshalled back to > clients with XML-1.1 compliant parsers. > > At this point, I don't have a recommendation how to treat this, but maybe > some more WG members should take a look at the current drafts. XML > namespaces 1.1 allowing IRIs is currently under debate on the W3C TAG > (Technical Architecture Mailing List) -- people interested in this topic > might want to check the mailing list archives. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Tuesday, October 22, 2002 10:04 AM > > To: WebDAV > > Subject: Impact of XML 1.1 and namespaces 1.1 on WebDAV > > > > > > Hi, > > > > as the W3C is finishing these specs, I'd like to make the WG > > aware of the questions we'll have to answer about how these > > changes impact WebDAV. > > > > Changes that are IMHO relevant to WebDAV are: > > > > 1) The set of characters that can appear in an XML name has been > > extended (it now includes more Unicode characters). > > > > 2) The set of characters that can be marshalled as text data has > > been extended to include the control characters 1..31 (although > > only as character reference; null is still forbidden) > > > > 3) XML 1.1 processors may reject documents if they contain > > non-normalized Unicode (yers, this is optional). > > > > 4) Namespaces 1.1 allows IRIs rather than only URIs as namespace names. > > > > One possible position would be that we just ignore it. Nothing > > would change immediately. However we lose the ability to marshall > > "any" kind of XML through WebDAV properties. > > > > Allowing XML 1.1 request bodies for PROPPATCH *will* have a big > > impact. For instance, properties are identified by QNames, and > > with XML 1.1 both the valid character sets for the namespace name > > (can now be a IRI and thus contain non.quoted non-ASCII > > characters) and the local name (just a bigger subset of Unicode) > > will change. It may not be possible to marshall these "extended" > > property names back to a client that only understands XML 1.0. > > > > Similar problems appear with control characters in property > > values -- once they appear in a property value, the property can > > only be marshalled back to clients with XML-1.1 compliant parsers. > > > > At this point, I don't have a recommendation how to treat this, > > but maybe some more WG members should take a look at the current drafts. > > > > Julian > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > From w3c-dist-auth-request@w3.org Sat Nov 16 04:56:47 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14584 for ; Sat, 16 Nov 2002 04:56:47 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAG9w7r05705; Sat, 16 Nov 2002 04:58:07 -0500 (EST) Resent-Date: Sat, 16 Nov 2002 04:58:07 -0500 (EST) Resent-Message-Id: <200211160958.gAG9w7r05705@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAG9w5B05679 for ; Sat, 16 Nov 2002 04:58:05 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA17234 for ; Sat, 16 Nov 2002 04:58:03 -0500 Received: (qmail 20421 invoked by uid 0); 16 Nov 2002 09:57:52 -0000 Received: from pd950c3e4.dip.t-dialin.net (HELO lisa) (217.80.195.228) by mail.gmx.net (mp019-rz3) with SMTP; 16 Nov 2002 09:57:52 -0000 From: "Julian Reschke" To: "WebDAV" Date: Sat, 16 Nov 2002 10:57:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <184101c28d02$f1ac09f0$9b114498@esedlar> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Impact of XML 1.1 and namespaces 1.1 on WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7039 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm in violent diasgreement. The principle you mention is one of the biggest factors leading to interoperability. If servers do not reject non-compliant requests, clients do not get fixed. If clients do not get fixed, other server implementors are forced to implement "workarounds" as well. We already see the results of this within WebDAV -- almost everybody has workarounds in the server code to please the most-deployed but worst-supported client (Microsoft webfolders). While doing this sometimes is unavoidable in real life, putting this into the protocol is a completely different story. In this particular case, allowing XML 1.1 in PROPPATCH requests will allow creation of property names/values that can not be sent back using XML 1.0 (*). Furthermore, there's no reliable way how a server can find out whether the client actually *understands* XML 1.1. So supporting XML 1.1 will require new compliance levels or it *will* break communication with older clients. That's why we really need to understand what's going on before making changes in RFC2518bis. Right now RFC2518 normatively refers to XML 1.0, and we may want to clarify that this means that requests marshalled in any other XML version *must* be rejected. Julian (*) Unless we allow XML 1.1 but explicitly forbid property names/values that cannot be marshalled using XML 1.0 (in which case using XML 1.1 in the first place is questionable). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Saturday, November 16, 2002 12:59 AM > To: Julian Reschke; WebDAV > Subject: Re: Impact of XML 1.1 and namespaces 1.1 on WebDAV > > > > In the general theory of being flexible with what you accept and careful > with what you generate, it sounds like WebDAV servers should accept > XML1.1 input, but only generate XML 1.0 output. > > I also recommend us looking into the IRI issue. > > --Eric > > ----- Original Message ----- > From: "Julian Reschke" > To: "WebDAV" > Sent: Wednesday, November 13, 2002 2:58 PM > Subject: RE: Impact of XML 1.1 and namespaces 1.1 on WebDAV > > > > > > (here's a minor update for usage during the IETF meeting) > > > > Hi, > > > > as the W3C is finishing these specs, I'd like to make the WG > aware of the > > questions we'll have to answer about how these changes impact WebDAV. > > > > Changes that are IMHO relevant to WebDAV are: > > > > 1) The set of characters that can appear in an XML name has > been extended > > (it now includes more Unicode characters). Infosets using these > names can > > *not* be marshalled as XML 1.0 documents. > > > > 2a) The set of characters that can be marshalled as text data has been > > extended to include the control characters 1..31 (although only as > character > > reference; null is still forbidden). Again: infosets containing these > > characters can *not* be marshalled as XML 1.0 documents. > > > > 2b) The characters 128..159 (Unicode control characters) can not be > > marshalled as is (only as character references). Infosets > containing these > > characters can be marshalled as XML 1.1 documents, but requires > > serialization as character references (which will be XML 1.0 > compatible as > > well). > > > > 3) XML 1.1 processors may reject documents if they contain > non-normalized > > Unicode (yes, this is optional). > > > > 4) Namespaces 1.1 allows IRIs rather than only URIs as namespace names. > > > > One possible position would be that we just ignore it. Nothing would > change > > immediately. However we lose the ability to marshall "any" kind of XML > > through WebDAV properties. > > > > Allowing XML 1.1 request bodies for PROPPATCH *will* have a big impact. > For > > instance, properties are identified by QNames, and with XML 1.1 both the > > valid character sets for the namespace name (can now be a IRI and thus > > contain non-quoted non-ASCII characters) and the local name > (just a bigger > > subset of Unicode) will change. It may not be possible to marshall these > > "extended" property names back to a client that only > understands XML 1.0. > > > > Similar problems appear with control characters in property > values -- once > > they appear in a property value, the property can only be > marshalled back > to > > clients with XML-1.1 compliant parsers. > > > > At this point, I don't have a recommendation how to treat this, > but maybe > > some more WG members should take a look at the current drafts. XML > > namespaces 1.1 allowing IRIs is currently under debate on the W3C TAG > > (Technical Architecture Mailing List) -- people interested in this topic > > might want to check the mailing list archives. > > > > Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > -----Original Message----- > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > Sent: Tuesday, October 22, 2002 10:04 AM > > > To: WebDAV > > > Subject: Impact of XML 1.1 and namespaces 1.1 on WebDAV > > > > > > > > > Hi, > > > > > > as the W3C is finishing these specs, I'd like to make the WG > > > aware of the questions we'll have to answer about how these > > > changes impact WebDAV. > > > > > > Changes that are IMHO relevant to WebDAV are: > > > > > > 1) The set of characters that can appear in an XML name has been > > > extended (it now includes more Unicode characters). > > > > > > 2) The set of characters that can be marshalled as text data has > > > been extended to include the control characters 1..31 (although > > > only as character reference; null is still forbidden) > > > > > > 3) XML 1.1 processors may reject documents if they contain > > > non-normalized Unicode (yers, this is optional). > > > > > > 4) Namespaces 1.1 allows IRIs rather than only URIs as > namespace names. > > > > > > One possible position would be that we just ignore it. Nothing > > > would change immediately. However we lose the ability to marshall > > > "any" kind of XML through WebDAV properties. > > > > > > Allowing XML 1.1 request bodies for PROPPATCH *will* have a big > > > impact. For instance, properties are identified by QNames, and > > > with XML 1.1 both the valid character sets for the namespace name > > > (can now be a IRI and thus contain non.quoted non-ASCII > > > characters) and the local name (just a bigger subset of Unicode) > > > will change. It may not be possible to marshall these "extended" > > > property names back to a client that only understands XML 1.0. > > > > > > Similar problems appear with control characters in property > > > values -- once they appear in a property value, the property can > > > only be marshalled back to clients with XML-1.1 compliant parsers. > > > > > > At this point, I don't have a recommendation how to treat this, > > > but maybe some more WG members should take a look at the > current drafts. > > > > > > Julian > > > -- > > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > > From w3c-dist-auth-request@w3.org Sat Nov 16 17:35:50 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25548 for ; Sat, 16 Nov 2002 17:35:49 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAGMbEt15610; Sat, 16 Nov 2002 17:37:14 -0500 (EST) Resent-Date: Sat, 16 Nov 2002 17:37:14 -0500 (EST) Resent-Message-Id: <200211162237.gAGMbEt15610@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAGMbCB15584 for ; Sat, 16 Nov 2002 17:37:12 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA20012 for ; Sat, 16 Nov 2002 17:37:07 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18DBeN-0006N2-00; Sat, 16 Nov 2002 22:42:51 +0000 Received: from nat.briank.com ([198.144.201.195] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18DBeM-0006Mr-00; Sat, 16 Nov 2002 22:42:51 +0000 Date: Sat, 16 Nov 2002 14:36:52 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "WebDAV" To: "Julian Reschke" From: Brian Korver In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Old-X-Envelope-To: w3c-dist-auth@w3.org, julian.reschke@gmx.de Subject: Re: Impact of XML 1.1 and namespaces 1.1 on WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7040 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Saturday, November 16, 2002, at 01:57 AM, Julian Reschke wrote: > I'm in violent diasgreement. > > The principle you mention is one of the biggest factors leading to > interoperability. If servers do not reject non-compliant requests, > clients > do not get fixed. If clients do not get fixed, other server > implementors are > forced to implement "workarounds" as well. We already see the results > of > this within WebDAV -- almost everybody has workarounds in the server > code to > please the most-deployed but worst-supported client (Microsoft > webfolders). > > While doing this sometimes is unavoidable in real life, putting this > into > the protocol is a completely different story. Julian, The principal you object to (Postel's robustness principal, spelled out in RFC-793, the TCP/IP draft), informs the design of many IETF protocols, especially when dealing with issues of backward compatibility. Within the IETF, this principal is believed to increase interoperability, in contrast to what you state. As for forcing servers to reject non-compliant requests, I think we'll all agree that non-compliant implementations are a problem, but how can the protocol document force these implementations into compliance? And if vendor Y decides to interoperate with non-compliant vendor X, there is little that this working group can do to prohibit vendor Y from doing so. On the subject of certain non-compliant clients, if we were to prohibit the accepting of XML1.1, what effect would you expect that prohibition to have on the decisions made by the vendors of such clients? Eric, I don't recall if you stated the client requirements. Did you expect that clients would be permitted to generate XML1.1? Note, the above should not be construed as an argument either for or against WebDAV support for XML1.1. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Sat Nov 16 18:17:35 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26161 for ; Sat, 16 Nov 2002 18:17:35 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAGNJO217157; Sat, 16 Nov 2002 18:19:24 -0500 (EST) Resent-Date: Sat, 16 Nov 2002 18:19:24 -0500 (EST) Resent-Message-Id: <200211162319.gAGNJO217157@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAGNJNB17131 for ; Sat, 16 Nov 2002 18:19:23 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA24915 for ; Sat, 16 Nov 2002 18:19:18 -0500 Received: (qmail 18885 invoked by uid 0); 16 Nov 2002 23:18:47 -0000 Received: from p3ee24831.dip.t-dialin.net (HELO lisa) (62.226.72.49) by mail.gmx.net (mp011-rz3) with SMTP; 16 Nov 2002 23:18:47 -0000 From: "Julian Reschke" To: "Brian Korver" Cc: "WebDAV" Date: Sun, 17 Nov 2002 00:18:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Impact of XML 1.1 and namespaces 1.1 on WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7041 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Saturday, November 16, 2002 11:37 PM > To: Julian Reschke > Cc: WebDAV > Subject: Re: Impact of XML 1.1 and namespaces 1.1 on WebDAV > > ... > > Julian, > > The principal you object to (Postel's robustness principal, spelled out > in RFC-793, the TCP/IP draft), informs the design of many IETF > protocols, especially when dealing with issues of backward > compatibility. Within the IETF, this principal is believed to > increase interoperability, in contrast to what you state. However, XML is conservative in both directions (malformed requests are never accepted), and has reached very high interoperability. Are you suggesting that an XML parser should accept documents with minor wellformedness errors if it thinks it can fix them? For example: Microsoft's XML parsers used to accept control characters that aren't allowed in XML. People solely on the Microsoft platform started using this as a feature -- they never tested against other implementations. Guess what they said when Microsoft finally fixed their parser? So yes, I think that this well known principle is *causing* interoperability problems. It's much better to have a as-precise-as-possible protocol definition and to mandate that both clients and servers stick to it. > As for forcing servers to reject non-compliant requests, I think > we'll all agree that non-compliant implementations are a problem, > but how can the protocol document force these implementations > into compliance? And if vendor Y decides to interoperate with > non-compliant vendor X, there is little that this working group > can do to prohibit vendor Y from doing so. It can't. However, Eric was suggesting that the protocol explicitly *allows* accepting XML 1.1 requests. That's very different from not saying anything about it. Accepting XML 1.1 requests as they are defined right now would mean that property values and names (and labels, privileges...) can occur that can't be marshalled to a client using XML 1.0. That's what I call a major interop problem. > On the subject of certain non-compliant clients, if we were to > prohibit the accepting of XML1.1, what effect would you expect > that prohibition to have on the decisions made by the vendors of > such clients? Hopefully they'd send XML 1.0. > Eric, I don't recall if you stated the client requirements. Did you > expect that clients would be permitted to generate XML1.1? > > Note, the above should not be construed as an argument either for or > against WebDAV support for XML1.1. Understood. Actually, it's a good thing that finally we've got a discussion thread about this topic :-) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Nov 18 11:21:31 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25548 for ; Mon, 18 Nov 2002 11:21:31 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAIGN6r17061; Mon, 18 Nov 2002 11:23:06 -0500 (EST) Resent-Date: Mon, 18 Nov 2002 11:23:06 -0500 (EST) Resent-Message-Id: <200211181623.gAIGN6r17061@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAIGN4B17031 for ; Mon, 18 Nov 2002 11:23:04 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA29407 for ; Mon, 18 Nov 2002 11:22:53 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18Dolq-0007aP-00 for w3c-dist-auth@w3c.org; Mon, 18 Nov 2002 16:29:10 +0000 Received: from [204.42.72.212] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18Dolq-0007a0-00 for w3c-dist-auth@w3c.org; Mon, 18 Nov 2002 16:29:10 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Mon, 18 Nov 2002 08:22:45 -0800 Message-ID: <000b01c28f1e$bd354150$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: New draft of significant interest : SASL & HTTP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7042 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The authors of this draft are looking for comments: http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt This could be very useful to WebDAV, considering all the discussions we've had about Basic and Digest authentication, and the problems with each. However I haven't read it closely yet. Lisa From w3c-dist-auth-request@w3.org Mon Nov 18 14:58:21 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01696 for ; Mon, 18 Nov 2002 14:58:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAIJxpo18307; Mon, 18 Nov 2002 14:59:51 -0500 (EST) Resent-Date: Mon, 18 Nov 2002 14:59:51 -0500 (EST) Resent-Message-Id: <200211181959.gAIJxpo18307@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAIJxnB18276 for ; Mon, 18 Nov 2002 14:59:49 -0500 (EST) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA23646 for ; Mon, 18 Nov 2002 14:59:48 -0500 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id gAIJTTr25708 for ; Mon, 18 Nov 2002 11:29:29 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 18 Nov 2002 11:26:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: Re: Status of ACL specification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7043 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] Sent: Saturday, November 16, 2002 1:23 PM To: Jim Whitehead Cc: WebDAV Subject: [Moderator Action] Re: Status of ACL specification A status update is in order here. The WEBDAV ACL document was on the IESG telechat agenda on 14-Nov. There were a few issues raised that I believe will be easy to address: This document uses various domain names such as www.webdav.org, www.foo.org, foo.org, and www.BigCorp.com. RFCs are supposed to use specific domains in examples: example.com, example.net, etc. The introduction states, in part: This specification intentionally omits discussion of authentication, as the HTTP protocol already has a number of authentication mechanisms [RFC2617]. Some authentication mechanism (such as HTTP Digest Authentication, which all WebDAV compliant implementations are required to support) must be available to validate the identity of a principal. This should be changed to refer to the discussion of authentication in RFC 2518 section 17.1. In particular, this document needs to refer to something that makes it clear that BASIC authentication can only be used in conjunction with some sort of security layer. However, another issue arose that received substantial pushback from the IESG: The complexity of the proposed ACL facility is seen as excessive. There was some debate as to how to proceed but no conclusion was reached. This issue will be discussed again at the IESG meeting tomorrow (Sunday). I quite honestly don't know how this will go so I cannot advice the WG as to what steps to take at this point. I do think, howeve,r that some time should be set aside at the meeting to discuss this. > The intent is to publish a new Internet-Draft, draft-ietf-webdav-acl-10, > immediately after the Atlanta IETF meeting (i.e., on or about the 25th of > November). This draft will then be sent to the IESG for review, and > hopefully approval. Assuming it is approved, publication as an RFC will > happen about 1-2 months afterwards. Please go ahead and address the additional minor points raised above in the -10 revision of the document. Ned From w3c-dist-auth-request@w3.org Wed Nov 20 01:22:15 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18685 for ; Wed, 20 Nov 2002 01:22:15 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAK6NEI05636; Wed, 20 Nov 2002 01:23:14 -0500 (EST) Resent-Date: Wed, 20 Nov 2002 01:23:14 -0500 (EST) Resent-Message-Id: <200211200623.gAK6NEI05636@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAK6NCB05606 for ; Wed, 20 Nov 2002 01:23:12 -0500 (EST) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA17350 for ; Wed, 20 Nov 2002 01:23:12 -0500 Received: from Tycho (dsl3-63-249-68-9.cruzio.com [63.249.68.9]) by mail.cruzio.com with SMTP id WAA22201 for ; Tue, 19 Nov 2002 22:23:05 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 19 Nov 2002 22:19:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Interim WEBDAV WG meeting: Jan 20-21, 2003, Cupertino, CA Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7044 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'd like to thank Jim Luther, and the Mac OS X Core OS group for hosting the following Interim WebDAV WG meeting. The meeting is free of charge, and open to all working group members. An agenda will be sent out the mailing list soon, but will focus on finishing RFC 2518bis, as well as making significant progress on DASL, bindings, and property-related specifications and registration. If you are planning on attending, please RSVP to Jim Luther at . - Jim WebDAV Working Group Interim Meeting Dates Monday, January 20 and Tuesday, January 21, 2003 Location Apple Computer, Inc. Singapore conference room R&D Building 1, 1st floor One Infinite Loop Cupertino, CA 95014 The building is open to the conference room from 8:00 AM to 5:00 PM Pacific time. How to get to Apple's R&D campus The Apple Computer R&D campus is located in Cupertino, California immediately south of Interstate 280 on the east side of De Anza Boulevard. Cupertino is 5 minutes west of San Jose and 45 minutes southeast of San Francisco in the heart of Silicon Valley. From Interstate 280, take De Anza Blvd south to Mariani Avenue (the first stoplight). Turn left onto Mariani Ave and then turn left again onto Infinite Loop. Free parking will be on your left (park in either of the large lots). R&D Building 1 is the building directly across from the parking lot. From w3c-dist-auth-request@w3.org Wed Nov 20 12:07:12 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25054 for ; Wed, 20 Nov 2002 12:07:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAKH7JA28408; Wed, 20 Nov 2002 12:07:19 -0500 (EST) Resent-Date: Wed, 20 Nov 2002 12:07:19 -0500 (EST) Resent-Message-Id: <200211201707.gAKH7JA28408@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAKH7GB28382 for ; Wed, 20 Nov 2002 12:07:16 -0500 (EST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA24428 for ; Wed, 20 Nov 2002 12:07:15 -0500 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gAKH7Ew04762 for ; Wed, 20 Nov 2002 09:07:14 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 20 Nov 2002 09:07:14 -0800 Received: from apple.com (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gAKH7Dp20079; Wed, 20 Nov 2002 09:07:13 -0800 (PST) Date: Wed, 20 Nov 2002 09:07:13 -0800 Content-Type: multipart/mixed; boundary=Apple-Mail-7--624708952 Mime-Version: 1.0 (Apple Message framework v548) Cc: Jim Whitehead To: From: Jim Luther In-Reply-To: Message-Id: <834E8DE2-FCAA-11D6-B1C3-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.548) Subject: Re: Interim WEBDAV WG meeting: Jan 20-21, 2003, Cupertino, CA Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7045 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --Apple-Mail-7--624708952 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Actually, DO NOT RSVP me. To RSVP, send email to Nora Mosqueda and let Nora know that you plan to attend the IETF WebDAV Working Group Interim Meeting (include "WebDAV WG Interim Meeting" in the title of your email), what day(s) you will be attending, and if you have any dietary requirements we should be aware of. I've included more extensive information below (including an attached map). - Jim Luther WebDAV Working Group Interim Meeting Dates Monday, January 20 and Tuesday, January 21, 2003 Location Apple Computer, Inc. Singapore conference room R&D Building 1, 1st floor One Infinite Loop Cupertino, CA 95014 The building is open to the conference room from 8:00 AM to 5:00 PM Pacific time. How to get to Apple's R&D campus The Apple Computer R&D campus is located in Cupertino, California immediately south of Interstate 280 on the east side of De Anza Boulevard. Cupertino is 5 minutes west of San Jose and 45 minutes southeast of San Francisco in the heart of Silicon Valley. From Interstate 280, take De Anza Blvd south to Mariani Avenue (the first stoplight). Turn left onto Mariani Ave and then turn left again onto Infinite Loop. Free parking will be on your left (park in either of the large lots). R&D Building 1 is the building directly across from the parking lot. --Apple-Mail-7--624708952 Content-Disposition: inline; filename=applemap.jpg Content-Type: image/jpeg; x-mac-creator=70727677; x-unix-mode=0644; x-mac-type=4A504547; name="applemap.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD//gAMQXBwbGVNYXJrCv/bAIQABwUFBgUFBwYGBggHBwgKEQsK CQkKFA8PDBEYFRkZFxUXFxodJSAaHCMcFxchLCEjJygqKioZHy4xLSkxJSkqKAEHCAgKCQoTCwsT KBsXGygoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgo/8QB ogAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJ CgsQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJ ChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeI iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq 8fLz9PX29/j5+hEAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3 eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4uPk5ebn6Onq8vP09fb3+Pn6/8AAEQgB3AGUAwEiAAIRAQMRAf/aAAwDAQACEQMRAD8A+ba3vDfg zW/Fd59i0fTri9uMbjHCo+QHoXYkKgPqx/DmjwZ4buvFfiGx0ey2/aLyYRRlhkJwS0hHcIoLH8K+ iL6+vvhjqFx4Z8M3QtLC2EZ5giaSV2iQs7sVJZiSTz06DAAFAHBxfsueN7mNZBcaPZEjmK4vHdh+ KREfrT/+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/0FfD/wD4ET//ABmj/hlTxx/0FfD/AP4E T/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf9BXw/wD+BE//AMZr62ooA+Sf+GVPHH/Q V8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/0FfD/wD4ET//ABmj/hlTxx/0 FfD/AP4ET/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf9BXw/wD+BE//AMZr62ooA+Sf +GVPHH/QV8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/0FfD/wD4ET//ABmj /hlTxx/0FfD/AP4ET/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf9BXw/wD+BE//AMZr 62ooA+Sf+GVPHH/QV8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/0FfD/wD4 ET//ABmj/hlTxx/0FfD/AP4ET/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf9BXw/wD+ BE//AMZr62ooA+Sf+GVPHH/QV8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/ 0FfD/wD4ET//ABmj/hlTxx/0FfD/AP4ET/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf 9BXw/wD+BE//AMZr62ooA+Sf+GVPHH/QV8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPk aX9lzxvbRtIbjR70gcRW946MfxeID9a8z8SeDNb8KXn2LWNOuLK4xuEcyj5wOpRgSrgeqn8OK/QW sTxb4S0nxros+kavbiWGQZjkHEkD9nQ9mH/1jwTQB+e9Fb3jPw3deFPEN9o97t+0WcxikKjAfgFZ AOwdSGH41g0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHtX7LkSXPxBnEigm00yeeM+jM8K H9Cfzrtvif8A8jxqf/bL/wBFJXGfsqf8lD1L/sDS/wDo+CvQvi9beR4t83H/AB8WscmfoSv/ALLQ B7Xp1z9s0+0us58+FJPzUH+tWa5/wJc/a/B+kSZzttxH/wB8Er/7LXQUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHyN+1HElt8 QYBGoBu9MgnkPqyvMg/QD8q8Vr239qv/AJKHpv8A2Bov/R89eJUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFAHtv7Kn/ACUPUv8AsDS/+j4K9R+NO3+2tO/vfZTn6bzj+teXfsqf8lD1L/sDS/8A o+CvRPjDP5viuOPP+ptEX82Y/wBaAPR/hkCPA+l5GP8AW/8Ao166usHwNB9n8IaQmMZtlf8A76+b +tb1ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQB8k/tV/wDJQ9N/7A0X/o+evEq9t/ar/wCSh6b/ANgaL/0fPXiVABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQB7b+yp/wAlD1L/ALA0v/o+Cux+JdyLrxpqRU5WMpGP+AooP65r jv2VP+Sh6l/2Bpf/AEfBW9eMdd8UTFTk31+QuP8Abk4/nQB9F6LB9l0ewt8Y8q2jTH0UCrtAAAAA wB0ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKAPkn9qv/koem/9gaL/ANHz14lXtv7Vf/JQ9N/7A0X/AKPnrxKgAooooAKKKKAC iiigAooooAKKKKACiiigAooooA9f/ZvujY+KvEV2vWDw5cyD/gMkJ/pXdfD2z+2+MtKjIyElMp9t ilh+oFee/s//APIb8V/9itef+hxV638HYVl8VzOw5isndfruRf5E0Ae40UUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHyT+1X /wAlD03/ALA0X/o+evEq9t/ar/5KHpv/AGBov/R89eJUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFAHq/wCz/wD8hvxX/wBitef+hxV6/wDBj/kaLv8A68H/APRkdeQ/s/AnXPFYAyT4XvP/AEOK vVfhFP5Xi9Uz/rraRP5N/wCy0Ae7UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHyT+1X/wAlD03/ALA0X/o+evEq9t/ar/5K Hpv/AGBov/R89eJUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHsn7MsH2rxnrlvjPm+H7hM fWWEV1fg/Vl0PxLp9+5AjSXbIT2RgVY/gCT+Fc7+yp/yUPUv+wNL/wCj4K6fxxo39heJ760VdsLP 5sPpsbkAfTkfhQB9H0VzPw/11de8M2khfdcW6iCcHruUYBP1GD+JrpqACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD5J/ar/AOSh 6b/2Bov/AEfPXiVe2/tV/wDJQ9N/7A0X/o+evEqACiiigAooooAKKKKACiiigAooooAKKKKACiii gD239lT/AJKHqX/YGl/9HwV7b8YPDrXunwa3AuZLP93OAOTGTwfwJ/8AHj6V4l+yp/yUPUv+wNL/ AOj4K+sriCK6glt50EkUqFHQ9GUjBFAHgnw28Tf8I9r6RTvtsr3EU2Twp/hb8CcfQmvf6+avFfh2 fwzrM9jKrGLJaCQj/WRnofr2PuK9G+Gfj/7WsWhatL/pCjbazuf9YOyMf73oe/Tr1APT6KKKACiu cvte1G91GfSfDltBLPbELd392T9ntWIBCbVw0smCDtBUAEZYEgHHljtW1Q6brXjTV5rvKq8dqhs7 aNiu4J5kSDaxXkK0pbGD3oA7uivPUj8HvaSXkWu+JVCGMY/tTUzK5kz5ZSJmJcNg4KqQcHGcGtSy 0/V3sodQ8OeK5b+2lXfHDq0KzRsPTeoSRT2+Ytg/w9qAOuorx7XPil4r0jUpdNu9IsrC5iAJRt0o ZTnDo2QGU4ODgdCCAQQMaX4s+KZPu3FvF/uQL/XNAHvVFfPh+J/i8n/kLY/7dof/AIij/hZ3i/8A 6C//AJLQ/wDxFAH0HRXz5/ws/wAX/wDQX/8AJaH/AOIqeP4reK0+9eQyf71un9AKAPfKK8LX4v8A iUdVsm+sJ/8Aiqa/xd8Tt0azT6Qf4mgD3aivA3+K3itul5Cn0t0/qKhb4oeLieNVC/S2i/8AiaAP oKivn+P4o+LkOW1NZPZraL+iirkXxf8AE0f3hZS/78J/owoA90oryjTvjX0XU9J+slrJ/wCyt/8A FV1enfEzwvqOB/aH2Vz/AAXSFMf8C+7+tAHVuwRGdmChQSWY8D3NeYeHNQ1aw1LRD4gv9Xt7u8JS ad3iudM1JjE7DyWQ/uem9chchSDuzmvS4Z7e8hEkEsc8Ljho2DK34jisKy8CaBYyQtFbTyR2+fs9 tPeTSwW+VKny4mYovyswGBwCQMCgDmE+Kl19nvZP7LgndLJb228iaTy5FMqRlPMaMKx+dTuQsvX2 J6vw/rd/fXuq6fqtrbW11pzx5NrM0kbpIm5TllUgjkHjtnviq0Xw78NxBR9luZAsH2ZfNv7iTEQZ WWMbnPygopA7Y9zndg020tr27vYottxebPPfcTv2DC8E4GAe1AHHeJPF0uj+IILm0f7dZy6MZYLe OUCKeWS5giibcMgD9597nAJPNOvPG2taat5aXWjwyX9nNCs0tq0s1vHFKjsJWCxmTAZCpAU43KxI BONS0+H3huyt7q2isZGhubcWrJLdTSCOEHIjj3MfKUHkBMYIGOgw9fAuiLa+QFvfM+0i6+1nUJzc +aE2BvO37/uErjOMEjFAHM3vxSukESafpUF9MmnpfXCwSzSo+9nURwtHE2WPlPy+0dAe+3V+Ivju TwP4Wt/EUVkbmM3MCS27gq5jfqB6MPfuMVfuPh/4cuI4ozaTRpHCYGEN5NH58RYsUl2uPNBZmJ35 yWb+8c7V3pllfpBHdWsUyW8qzRI65VHX7rAdMjt6UAPsbtb+yt7tI5YlniWQRzIUkUMM4ZTyCM8i p6KKACiiigD5J/ar/wCSh6b/ANgaL/0fPXiVe2/tV/8AJQ9N/wCwNF/6PnrxKgAooooAKKKKACii igAooooAKKKKACiiigAooooA9t/ZU/5KHqX/AGBpf/R8FfWFxeW1qM3FzFCPWRwv86+T/wBlT/ko epf9gaX/ANHwV6p478CeI9Z8VX9/Yad51tN5eyTz41ziNQeCwPUGgDsvFbeE/FGmvZXWuaZHMmTD N9rj3RN+fT1Hf8q8JvLWTTrySAyxu8TcSwSB0b0ZWHUV1Ufwp8VuuWtIYz6NcJn9Caif4XeLkbC6 Wrj1W5ix+rCgDsPDHxbs4tJ8rXvOa8gwqvEm4zj1PYN6569ah1H419V0zSfpJdSf+yr/APFV5de2 Vzp13LaXcLQ3ELbXjbqDXbfD3wZofiqKZry+uBdQNl7WPavy9myc5HY9MflQB0Pwx8eae6XGkarN FZ6hcX09zC7nalyZpGkKqT/EpYqFJyVC4zzjodT0LXdR16aZ4tPOmqwazIumVon8raZpIfJIlkBJ ADPtCheAeauWfw+8K2cTRDRbW4Vhtb7Uvnbh7h8ikHgaxtuNK1LV9IXtHaXztEv+7HJvRfoFAoA5 vRvAGq6KILq3hs1ns5LWSK0e/mmSVooponYyum5AUmG1ApVSgxjccdjoVmfD+hLHqE8EbI0txcOH xFG0kjSMAzY+VS5AJxwBwOlU/wDhFdSPD+NvEDJ/d22S/qtuD+tLF4F0QypPfpc6xMjBlbVLl7lV I6FY2JRT7hRQBkLpum/EDxFFrEtmLnRdPtXt7WeQMq3kjujM6DjdGgjwGPDF2xkDJ6eHwzoVuAId GsEx3FsmfzxWn04FFAEMVnawf6q2hj/3EA/lU1FFAEclvDN/rYY5P95QaqSaFpE3+t0qyk/3rdD/ AEq/RQBk/wDCK+Hv+gDpn/gHH/hUieHNDT7mjaev0tUH9K0qyvE+qSaLoN7qEKhpYU+QEZAYkKD+ BOaunB1JqEd27EVJxpwc5bJX+4sppGmp9zT7VfpCo/pUws7UDAtoQPQIK+fP+Ej1n7X9s/tS68/d u3+af5dMe3SvdPDGqSa1oNlqEyhZZk+cAYBYEqT+JGa9PH5XUwUIzlJNPT5nk5fm1PHTlCMWmtfk WZdH0yf/AFunWkn+/Ap/mKydQ8BeGNSBEuj28Z/vW48oj/vnGfxroqK8k9k8z1H4LWEuW07U57c9 knQSD6ZGCP1rkNV+FfiXTsvDBFfxjvbPlv8Avk4P5Zr3uigD5gjn1bw/dEI95ptwOoBaJvxHFdbo 3xc16wZVvxFqMI671CSY9mHH5g17VeWFpqMJhvbWG5iP8EqBh+tcB4g+D+nXm6bRpzYynnyZMvEf oeq/r9KAN/w/8QtA8QbY47r7LdNx9nucIxPseh/A59q6ivmbXvDWq+G7gQalbGPd9yRfmR/o39Ot dN4P+J9/oXl2ep776wHAJOZYh7E9R7H8CKAPc6KpaVq9hrdmt5p9ylxC3dTyp9COoPsau0AFFFFA BRRRQAUUUUAfJP7Vf/JQ9N/7A0X/AKPnrxKvbf2q/wDkoem/9gaL/wBHz14lQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAe2/sqf8lD1L/sDS/+j4K+tq+Sf2VP+Sh6l/2Bpf8A0fBX1tQAUUUU AcR8RvBK+IrE31lEP7Ttl+XA5mQfwH39Py714vo2r3nh/VIb+0YpNC3Know7qw9DX0/XkHxV8Fi2 d/EOnx4ikYfa41/hYnAcexPX357mgD03w/rtp4j0uHUbNvkkGHQnmNh1U+4/wNaVeJfB/WDZ69Np ruRFfRHaM8eYvI/8d3fpXttABRRRQAUUUUAFFFFABRRRQBzni7xla+EEsGuLeW4F3PsfyyB5EI/1 k7Z/gTK5/wB4VNrmueG0aTRdX1OzhkuEVGt5ZgrYc4U47ZPQ+uKzNc8C/wDCUa5e3Wq3k0di1h9g tobOcoxRyTP5nGPmIjGBniMetcpB4a8V3MmvaFKunTTXmiWenXepSSyLtwJ0MqDyz5jbTu2krhiO SOaabTuhNKSs9hkfgfw1Nrf9mR+L4HuPOaP7GFUzZXJKZ3feABPTsTjiuz0Lxf4bt9C0ISXlrpX9 oWscltaXE6hwrYAz9ScZ7n3rA0XQtav7u7t/JtbfTYfE0t+100r/AGh/LfIUJswdxAG/f90kY9c5 fhbrUFktlvtbqO70m20+7zqNxDHEYlZWOxFHnIQ5IBKEHPPzZHViMbiMSkqsr29P0OTDYHDYVt0Y Wb9f1PW6KQDAA9PWlrkOwKKKKACiiigCtf6daapavaX1ulxBIPmRxkfX2PvXj3jD4VXel+Ze6Jvv LQctB1ljHt/eH6/XrXtVFAHzFouval4dvBdadcNDIOHXqrj0YdxXtvg34h2HigLazhbPUgOYSflk 90P9Ov161H4x+HGn+I1ku7MJZ6l18wDCSn/bA/8AQhz9a8S1HTdQ0G/a1vIZLW6iOR2+jKR1HoRQ B9Q0V5V4I+KYfy9N8QyANwsd8eh9pP8A4r8/WvVFYOoZSGUjIIPBFAC0UUUAFFFFAHyT+1X/AMlD 03/sDRf+j568Sr239qv/AJKHpv8A2Bov/R89eJUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF AHtv7Kn/ACUPUv8AsDS/+j4K+tq+Sf2VP+Sh6l/2Bpf/AEfBX1tQAUUUUAFVNW0+PVtMu7CX7lzE 0ZPpkcH8OtW6KAPmCxubjQNahuNpW4sbgFk91blf0Ir6bt547q3iuIW3RSoHRvUEZBrwf4p6R/Zn iuaZFxFfIJ19Nx4b9QT+NemfC7UzqPhC1V23PaO1ux9hyv8A46yj8KAOwooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKyPEfhjTfE9kba/iyy58qZeHiPqD/Toa16KAPnDxV4 N1LwpdbLlfNtXOIrpB8r+x9D7fzrW8FfEa88NFLO833emZxsz88PuhPb/Z/lXuV7ZW2o2slreQJP BKMPG4yDXjXjP4X3WkeZf6MHu7EfM8PWSEf+zL79R39aAPYNL1Wx1qzS80+4S4gfoynofQjqD7Gr lfMvh/xJqXhq8F1p05TP+siblJB6MP69RXufhHx1pviqIRoRbX6jL2rtyfdT/EP1HegDp6KKKAPk n9qv/koem/8AYGi/9Hz14lXtv7Vf/JQ9N/7A0X/o+evEqACiiigAooooAKKKKACiiigAooooAKKK KACiiigD239lT/koepf9gaX/ANHwV9bV8k/sqf8AJQ9S/wCwNL/6Pgr62oAKKKKACiiigDzf4z6d 52jWN+q5a2nMbH0Vx/io/Os34KahiXVNNZvvKk6D6fK381ro/H9xDqAl0S5keDTbazbVNWnjXMiQ IcoiejOyPz2WNsckEYgs/AVvZJ5Xg5herefYNqtAt4knlCXP2kzD+AqciUnLAdeKAPUqK5fw5d32 n6pJ4f1Gae4BtheWE1yytP5WQrxSMpIZ42K/MCch1ySQSeooAKKKKACiiigAqlqWtaXo0Yk1TUrO wjPRrqdIgfxYiuG8WeLNc1rxE/gjwQ8cOoRIsmq6vKm+PTY26KB0aVh0Hb8ys2kfBbwhZObrVbN/ EepyczX2sSG4eQ/7rfKB+H4mgDc/4WP4I/6HLw//AODSD/4qj/hY/gf/AKHLw/8A+DSD/wCKo/4V x4H/AOhN8P8A/grg/wDiaP8AhXHgf/oTfD//AIK4P/iaAD/hY/gf/ocvD/8A4NIP/iqP+Fj+B/8A ocvD/wD4NIP/AIqj/hXHgf8A6E3w/wD+CuD/AOJo/wCFceB/+hN8P/8Agrg/+JoAP+Fj+B/+hy8P /wDg0g/+Ko/4WP4H/wChy8P/APg0g/8AiqP+FceB/wDoTfD/AP4K4P8A4mj/AIVx4H/6E3w//wCC uD/4mgA/4WP4H/6HLw//AODSD/4qj/hY/gf/AKHLw/8A+DSD/wCKo/4Vx4H/AOhN8P8A/grg/wDi aP8AhXHgf/oTfD//AIK4P/iaAD/hY/gf/ocvD/8A4NIP/iqP+Fj+B/8AocvD/wD4NIP/AIqj/hXH gf8A6E3w/wD+CuD/AOJo/wCFceB/+hN8P/8Agrg/+JoAP+Fj+B/+hy8P/wDg0g/+Ko/4WP4H/wCh y8P/APg0g/8AiqP+FceB/wDoTfD/AP4K4P8A4mj/AIVx4H/6E3w//wCCuD/4mgA/4WP4H/6HLw// AODSD/4qj/hY/gf/AKHLw/8A+DSD/wCKrhdQ1P4Vabf3VjN4CsGltpnhcpo9oVJUkHGT04rstP8A AvgPUrC1vofBehLFcwpMgfSoAwDAEZwvXmgCx/wsfwP/ANDl4f8A/BpB/wDFUf8ACx/A/wD0OXh/ /wAGkH/xVH/CuPA//Qm+H/8AwVwf/E0f8K48D/8AQm+H/wDwVwf/ABNAHAeNIPh7rfmX2k+MfDlp fn5mT+1IBHMff5vlPv8An615UNe0+xud0es2Uc0L/LJDeIcEdwyt+oNfSn/CuPA//Qm+H/8AwVwf /E0f8K48D/8AQm+H/wDwVwf/ABNAHFeAvjPpGoh7DX9c0qCSGLel5LeRRrJggbTkgbuc8dQD6V2v /Cx/A/8A0OXh/wD8GkH/AMVR/wAK48D/APQm+H//AAVwf/E0f8K48D/9Cb4f/wDBXB/8TQB8v/tK 63pWveOtPutI1Oz1K3TSY42ls7hJkVhNMSpKkjOCDj3FeQV9/wD/AArjwP8A9Cb4f/8ABXB/8TR/ wrjwP/0Jvh//AMFcH/xNAHwBRX3/AP8ACuPA/wD0Jvh//wAFcH/xNH/CuPA//Qm+H/8AwVwf/E0A fAFFff8A/wAK48D/APQm+H//AAVwf/E0f8K48D/9Cb4f/wDBXB/8TQB8AUV9/wD/AArjwP8A9Cb4 f/8ABXB/8TR/wrjwP/0Jvh//AMFcH/xNAHwBRX3/AP8ACuPA/wD0Jvh//wAFcH/xNH/CuPA//Qm+ H/8AwVwf/E0AfAFFff8A/wAK48D/APQm+H//AAVwf/E0f8K48D/9Cb4f/wDBXB/8TQB8BvBNGiu8 TorfdZlIB+lMr7c8R/AnwLr0Egt9KXRrplIW40391j2KfcYeoI/EV8r/ABH+HGq/D/WWsb5VkR1M lvcxLiO5QdWUfwsONyds5HGKAOLooooA9t/ZU/5KHqX/AGBpf/R8FfW1fJP7Kn/JQ9S/7A0v/o+C vragAooooAKKKKAOG8XWkcGsXL3ly1np/iDTF0qS9HS2mR5Gi3dMK/nSDJIGQq5ywqS18APZ2rxw SaMjSXTTm3/scG0QGIRkRxeZlCdu4kNySwI5rsbi3hu4JLe4hjmhlUrJHIoZXB6gg8EV4B8RtJOg +IJtNtLi8h0qWFJIrAXcv2dVIwQIt2zGQ3GKAPTfCttDca1bPYTNdaZ4e0v+yIbxjn7TKzRmXB/i 2iCMEjjczD+E121c38PbyO98HaU0YVRDD5BVRjbsO3p9AD+NdJQAUUUUAFUta1JNG0fUNUkG5LK2 kuGHqEUsf5Vdrm/iP/yT3xX/ANga8/8ARD0AYfwW0hrLwNa6rdHzNT1921S9nI5keU7l/ALt4+vr XoFc38OP+SeeFP8AsDWf/ohK6SgAooooAKKKKACiiigAooooAKKKKACiiigD5m8Vf8jRrX/X/P8A +jGr6D8K/wDIr6L/ANeEH/ota+fPFX/I0a1/1/z/APoxq+g/Cv8AyK+i/wDXhB/6LWgDWooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArzj47eHIde+HWpXBjVrrSV+327sM42ffB9i m4EfT0r0eub+I/8AyTzxX/2Brz/0Q9AHwHOixzyIjblVyFb1APWmUUUAe2/sqf8AJQ9S/wCwNL/6 Pgr62r5J/ZU/5KHqX/YGl/8AR8FfW1ABRRRQAUUUUAFeU/GrTSU0zVFXgFreQ/X5l/k9erVzvjzS DrXhW/to0LzInnRADncnOB7kAj8aAOO+C2q7oNR0l25RhcRj2Pyt/Jfzr1Ovmnwpr0nhvXbXUVyY 0bbMo/ijPDD+o9wK+k4pY54kmicPHIoZGHRgeQaAH0UUUAFc38R/+SeeK/8AsDXn/oh66Sub+I// ACTzxX/2Brz/ANEPQAfDj/knnhT/ALA1n/6ISukrm/hx/wAk88Kf9gaz/wDRCV0lABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFAHzN4q/5GjWv+v8An/8ARjV9B+Ff+RX0X/rwg/8ARa18+eKv+Ro1r/r/ AJ//AEY1fQfhX/kV9F/68IP/AEWtAGtRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABXN/Ef/knniv8A7A15/wCiHrpK5v4j/wDJPPFf/YGvP/RD0AfAFFFFAHtv7Kn/ACUPUv8AsDS/ +j4K+tq+Sf2VP+Sh6l/2Bpf/AEfBX1tQAUUUUAFFFFABRRRQB8+fEbw5/wAI94il8pNtpd5ngwOB k/Mv4H9CK9F+EmvnUtBbTZnzPp7bVyeTGeV/I5H0Aq58T9B/trw1JNEm65sD56YHJX+Mflz/AMBF eP8AhDxHL4X1uG+XLQn93cRj+OM9fxHBHuKAPpKio7e4iu4I7iCQSQyqHR16MpGQakoAK5v4j/8A JPPFf/YGvP8A0Q9dJXN/Ef8A5J54r/7A15/6IegA+HH/ACTzwp/2BrP/ANEJXSVzfw4/5J54U/7A 1n/6ISukoAKKKKACiiigAooooAKKKKACiiigAooooA+ZvFX/ACNGtf8AX/P/AOjGr6D8K/8AIr6L /wBeEH/ota+fPFX/ACNGtf8AX/P/AOjGr6D8K/8AIr6L/wBeEH/otaANaiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACub+I/8AyTzxX/2Brz/0Q9dJXN/Ef/knniv/ALA15/6IegD4 AooooA9t/ZU/5KHqX/YGl/8AR8FfW1fJP7Kn/JQ9S/7A0v8A6Pgr62oAKKKKACiiigAooooACMjB 6V8//EXwofDWtGS3TFheEyQYHCH+JPw7exFfQFZHifw/b+JtHn06fCsw3RSY5jcdG/x9iaAPP/hJ 4u/5l29k9Ws2Y/iyfzI/H2r1evly4t73Q9TeGTdb3lnL1B5VlPBB/UGvoLwX4oi8VaLHdZVbqL93 cxj+F/Uex6j8u1AHQ1zfxH/5J54r/wCwNef+iHrpK5v4j/8AJPPFf/YGvP8A0Q9AB8OP+SeeFP8A sDWf/ohK6SvOtM8Vf8Ij8KPB9/8AY/tnmabZQ+X5vl4zbBs5wf7v61m/8Lv/AOpf/wDJ3/7XQB6v RXlH/C7/APqX/wDyd/8AtdH/AAu//qX/APyd/wDtdAHq9NlljhjaSV1jjUZZnOAB7mvM9M+KGp+K tQj0TRtIhs724Rn+1T3BlS3jXG6QoFXdjKgDIyzLnjNaWveFLHT7KPULyS11O6WZfP1LxHm5jgXB +ZIAVQMW2qFj28tnnGCAb0/jvwhbOY5/FWiRODgrJqMKn8i1XtO1/R9X/wCQbq1jff8AXtcpJ/6C TXC2njS/tdQ0ywbR7exjlFolzEtlIFRp3ZfmkBCwEAKRG4LMXC9TVjR1tPF1zZ/2/oOj3EGq2Daj YlbT97boroNruScviVDuXbg7hjjNAHoVFcTrEeo+ALCfV9LuJ9S0i1Qvc6be3DO0KDrJFM2WAXqU bcNoO3aRg89/wu//AKl//wAnf/tdAHq9FeUf8Lv/AOpf/wDJ3/7XR/wu/wD6l/8A8nf/ALXQB6vR XlH/AAu//qX/APyd/wDtdH/C7/8AqX//ACd/+10Aee+Kv+Ro1r/r/n/9GNX0H4V/5FfRf+vCD/0W tfOOq339p6pe3/l+V9quJJvL3btu5i2M8ZxmvQtK+MP9maXZWH9h+b9lt44fM+17d21QucbDjOKA PYqK8o/4Xf8A9S//AOTv/wBro/4Xf/1L/wD5O/8A2ugD1eivKP8Ahd//AFL/AP5O/wD2uj/hd/8A 1L//AJO//a6APV6K8o/4Xf8A9S//AOTv/wBro/4Xf/1L/wD5O/8A2ugD1eivKP8Ahd//AFL/AP5O /wD2uj/hd/8A1L//AJO//a6APV6K8o/4Xf8A9S//AOTv/wBro/4Xf/1L/wD5O/8A2ugD1eivKP8A hd//AFL/AP5O/wD2uj/hd/8A1L//AJO//a6APV6K8o/4Xf8A9S//AOTv/wBro/4Xf/1L/wD5O/8A 2ugD1eivKP8Ahd//AFL/AP5O/wD2uj/hd/8A1L//AJO//a6APV6K8o/4Xf8A9S//AOTv/wBro/4X f/1L/wD5O/8A2ugD1eub+I//ACTzxX/2Brz/ANEPXGf8Lv8A+pf/APJ3/wC11pan4q/4S74UeML/ AOx/Y/L029h8vzfMzi2LZzgf3v0oA+IaKKKAPbf2VP8Akoepf9gaX/0fBX1tXyT+yp/yUPUv+wNL /wCj4K+tqACiiigAooooAKKKKACiiigDzf4reDzqNr/btjFuurZcXCKOZIx/F9V/l9K8z8KeJrrw tqqXtvl4m+WeHPEien19DX0p1rxD4l+Bv7DuW1bTov8AiXTt+8RRxA5/9lPb0PHpQB7Jpep2usWE N/ZSiWCZdyt3HqD6EdCKxviP/wAk88V/9ga8/wDRD15P8O/GjeGdQFrdyE6ZdMBID/yyboHH9fb6 V6t8RHWT4deKXRgytot2QwOQR5D80AYGmeFf+Eu+FHg+w+2fY/L02ym8zyvMzi2C4xkf3v0rN/4U h/1MH/kl/wDbK7P4cf8AJPPCn/YGs/8A0QldJQB5R/wpD/qYP/JL/wC2Uf8ACkP+pg/8kv8A7ZXq 9FAHmOmfC/U/CuoR63o2rw3l7boyfZZ7cxJcRtjdGXDNtzhSDg4ZVzxmtnUde8L62LW08StdaFd2 84mihvriSxZZdrLlJkdVk4Zh8jsOfWu1pssUc0bRyoskbDDK4yCPcUAYFv4b8PXMsN7C8lyY/Lbc dQmlWQxtujaQFyJGU8hmyRgegxWSTwb4PuJbh9TtLKaUbAlxfliqli2yJGY7QSSdqAduOBi5P4D8 IXLmSfwrokzk5LSadCx/MrV7TtA0fSP+QbpNjY/9e1skf/oIFAHM6xJqPj+wn0jS7efTdIukKXOp XtuyNMh6xxQthiG6F22jaTt3E5HPf8KQ/wCpg/8AJL/7ZXq9FAHlH/CkP+pg/wDJL/7ZR/wpD/qY P/JL/wC2V6vRQB5R/wAKQ/6mD/yS/wDtlH/CkP8AqYP/ACS/+2V6vRQB8t6rY/2Zql7YeZ5v2W4k h8zbt3bWK5xzjOK9C0r4Pf2npdlf/wBueV9qt45vL+ybtu5Q2M7xnGa4jxV/yNGtf9f8/wD6Mavo Pwr/AMivov8A14Qf+i1oA8+/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KAPKP+FIf9TB/5Jf8A 2yj/AIUh/wBTB/5Jf/bK9XooA8o/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KAPKP+FIf9TB/5 Jf8A2yj/AIUh/wBTB/5Jf/bK9XooA8o/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KAPKP+FIf9 TB/5Jf8A2yj/AIUh/wBTB/5Jf/bK9XooA8o/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KAPKP+ FIf9TB/5Jf8A2yj/AIUh/wBTB/5Jf/bK9XooA8o/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KA PKP+FIf9TB/5Jf8A2ytLU/Cv/CI/CjxhYfbPtnmabezeZ5Xl4zbFcYyf7v616LXN/Ef/AJJ54r/7 A15/6IegD4AooooA9q/ZclS2+IM5kYA3emTwRj1ZXhc/oD+VfXNfn14M8SXXhTxDY6xZbftFnMJY wxwH4IaMnsHUlT+FfdXhLxbpPjXRYNX0i4EsMgxJGeJIH7o47MP/AK44IoA26KKKACiiigAooooA KKKKACobu1gvraW1uYllgmUo6N0YGpqKAPCtZ+FPiC21GaPTLT7ZZ7sxS+dGp2nsQzA5FegeJ7Wa x+D2sWlwmyeDw1NHIuQdrLasCMjg8iu1rm/iP/yTzxX/ANga8/8ARD0AHw4/5J54U/7A1n/6ISuk rm/hx/yTzwp/2BrP/wBEJXSUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVHbyvMhZ4JICHddkhUkgMQ G+UkYYAMOc4IyAcgAHzV4q/5GjWv+v8An/8ARjV9B+Ff+RX0X/rwg/8ARa18+eKv+Ro1r/r/AJ// AEY1fQfhX/kV9F/68IP/AEWtAGtRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX N/Ef/knniv8A7A15/wCiHrpK5v4j/wDJPPFf/YGvP/RD0AfAFFFFABW94b8Z634UvPtmj6jcWVxj aZIWHzgdA6kFXA9GH48Vg0UAe1RftR+N7aNYxb6PeEDmW4s3Rj+CSgfpT/8Ahqvxx/0CvD//AIDz /wDx6vEqKAPbf+Gq/HH/AECvD/8A4Dz/APx6j/hqvxx/0CvD/wD4Dz//AB6vEqKAPbf+Gq/HH/QK 8P8A/gPP/wDHqP8Ahqvxx/0CvD//AIDz/wDx6vEqKAPbf+Gq/HH/AECvD/8A4Dz/APx6j/hqvxx/ 0CvD/wD4Dz//AB6vEqKAPbf+Gq/HH/QK8P8A/gPP/wDHqP8Ahqvxx/0CvD//AIDz/wDx6vEqKAPb f+Gq/HH/AECvD/8A4Dz/APx6qOt/tK+Mde0bUNIutN0NLfULWS1laKCYOqupUlSZSM4PGQa8gooA +/8A4cf8k88Kf9gaz/8ARCV0lc38OP8AknnhT/sDWf8A6ISukoAKKKKACiiigAooooAKKKKACiii gDzv4geEdKn1S010eHbO6uikkV3dzaCmpx7T5YUywo6Tu4KKqMgfYpk3AA7h0ngax0rTvDFpb6Le 2d9Yl5pUnsNgtyzyu8giCkhUV2ZVXJ2gAEkgk8b44ub7VtebTo47fU7WCYWsVjLpjTQzXLQrO0Ei tfQxzMIh5waSPYoGFbzOD3fhfUp9W0SC6upo5brfLFP5dsYAkkcjI6bDJJgoylSQ7KSpKkgigD59 8Vf8jRrX/X/P/wCjGr6D8K/8ivov/XhB/wCi1r588Vf8jRrX/X/P/wCjGr6D8K/8ivov/XhB/wCi 1oA1qKKKACiimu6RI0kjKiKMszHAA9SaAHUVw+pfFPSoLk2mlWtzrE4/59l+Q/Q9T+AIqt/wsXxA engHUyPXMn/xqgD0GivPv+FieIf+hB1P85P/AI1R/wALF8QDr4B1MD1zJ/8AGqAPQaK4fTfinpU9 yLTVbW50ec/8/K/IPqeo/EAV2yOkqLJGyujDKspyCPUGgB1FFFABRRRQAUUUUAFFFFABXN/Ef/kn niv/ALA15/6Ieukrm/iP/wAk88V/9ga8/wDRD0AfAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQB9/8Aw4/5J54U/wCwNZ/+iErpK5v4cf8AJPPCn/YGs/8A0QldJQAUUUUAFFFFABRRRQAU UUUAFFFFAHCeL9J8E6Zfpq2tyapBeXl0ssa6fe3+9ptiW4kWG2fg7WjiLhR/rFUnLgHoPB66Wmgw jR4biGy86cqt1K0kxczOZGcuzOGL7iVc71JKsFYFRkeM7C71LWdJhi0WPUbWG1uridgZIpsq0AWK KdXVY3O4yqH4L28ZBjKCVNLwRIZPDsbfYJLBBdXSxRTQyxSNGLiQRySCX94XkQLIzP8AMzOWPWgD wbxV/wAjRrX/AF/z/wDoxq+g/Cv/ACK+i/8AXhB/6LWvnzxV/wAjRrX/AF/z/wDoxq+g/Cv/ACK+ i/8AXhB/6LWgDWooooAK838S3F5438THwpYTtBptn8+oTJ/ER/D+BwAPXJ7V6RXnnwhUXOnatqj8 z3d8wdu5wob+bmgDtNH0PTtBtVtdOtUgjA5IHzOfVj1Jq/RRQAUUUUAUNY0PTtetWtdRtUnjI4JH zIfVT1BrhvDVxeeCPEw8KX87T6befPp8z/wk/wAP4nII9cHvXpFeefF5RbadpOqJxPaXyhG7jKlv 5oKAPQ6KKKACiiigAooooAKKKKACub+I/wDyTzxX/wBga8/9EPXSVzfxH/5J54r/AOwNef8Aoh6A PgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+//AIcf8k88Kf8AYGs//RCV0lc38OP+ SeeFP+wNZ/8AohK6SgAooooAKKKKACiiigAooooAKKKKAPO/ircWVk+k3mowaHqFnbpcvNpmszOV mUKhMsUCQSs7x4yZNp8uNpcjDlk6nwdHNF4cs0n8N2/hiUb92k20kckdv87dGjAU7vvcDqxzzms3 xf4W8M6jFP8A2he/2Hc61/oEl3a3K28l6ZEMYiYNlJ2KblUOrlQSU2nmt/RpZ7jS7ae4v7PUXmTz Bd2MRjgmVuUZFLvxtI53HPXvgAHzp4q/5GjWv+v+f/0Y1fQfhX/kV9F/68IP/Ra18+eKv+Ro1r/r /n/9GNX0H4V/5FfRf+vCD/0WtAGtRRRQAV598GP+RXu/+v8Af/0XHXoNeffBj/kV7v8A6/3/APRc dAHoNFFFABRRRQAV598Z/wDkV7T/AK/0/wDRcleg1598Z/8AkV7T/r/T/wBFyUAeg0UUUAFFFFAB RRRQAUUUUAFc38R/+SeeK/8AsDXn/oh66Sub+I//ACTzxX/2Brz/ANEPQB8AUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFAH3/wDDj/knnhT/ALA1n/6ISukrm/hx/wAk88Kf9gaz/wDRCV0l ABRRRQAUUUUAFFFFABRRRQAUUUUAcJ44tLbX723gs7PXLzUNLdGkuNFe0U237yKdY3N0wjJLwwSb VBYBEztWQB+k8LxadFokA0ueS4t3eWV5phiR5nkZpjIuF2P5pfcm1drZXauNopTeEZ/7T1G/sPE+ saZ/aMyzzwWyWjx71ijiyPNgdhlYk43YzmtLQNFj8P6YthHdXF3++mnee52eZI8sryuTsVVHzO3A UADFAHzx4q/5GjWv+v8An/8ARjV9B+Ff+RX0X/rwg/8ARa18+eKv+Ro1r/r/AJ//AEY1elaJ4D12 80bT7mHxvqNtFNaxyJAgk2xAqCFGJRwM46DpQB6fRXn3/Cu/EP8A0P2p/lJ/8do/4V34h/6H7U/y k/8AjtAHoNeI+C/HMfhbw5Lax2pubqW8eTDNtRV2IAc9zkHiut/4V34h/wCh+1P8pP8A47XmOleH 9U1HSft9lZy3UKztAwhUuysArcqOcfN19q9PLKVCriFGu9Lel2eVmtbEUcM5Yde9f1su57B4P8ew +Jp3s57f7LeKu9QG3LIB1x6H2rr68p+HHhPU7fWV1S9tZrOG3VgqzIUZ2Ix0POME816tRmdKhSxD jQelvWzDKq2IrYZSxC96/pddwooorzD1Qrz74z/8ivaf9f6f+i5K9Brz74z/APIr2n/X+n/ouSgD 0GiiigAooooAKKKKACiiigArm/iP/wAk88V/9ga8/wDRD10lc38R/wDknniv/sDXn/oh6APgCiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooA+/wD4cf8AJPPCn/YGs/8A0QldJXN/Dj/knnhT /sDWf/ohK6SgAooooAKKKKACiiigAooooAKKKKACiiigD5m8Vf8AI0a1/wBf8/8A6MavoPwr/wAi vov/AF4Qf+i1r588Vf8AI0a1/wBf8/8A6MavoPwr/wAivov/AF4Qf+i1oA1qKKKACvPvgx/yK93/ ANf7/wDouOvQa89+DXHhq8Q8Mt++R6fu4/8ACgDtdY1jT9A06bU9Vu47Oygx5k0pwq5IUfmSB+NX QQwBBBB5BHeuL8b6bqfiLVNK0eztYXsoRJe3j3kbm3kIHlxxEr1OXZ8Z48tT3rjLaW4gudH0bxTF rkn9naVd2jpp6XP+kvFNEkMwEXzMGTBDHgM3JyBQB7PVezvrbUI5JLWZZUjleFyvZ0Yq6/gwI/Cv G4ZNale+gvhrU/imG200WiwNO0EVyYUMm8ofLX5sl9+ARnGeak1Ox1qK48u5j1G30p7zVZFEFtdu TO12xjYi3ZX5Qkox+Xk9ytAHtFeffGf/AJFe0/6/0/8ARcldh4eS9j0HTE1GSSW9W0iFxJKgR2k2 DcWAJAOc5AJGe5rjvjLz4as0HLNfpgev7uT/ABoA9CooooAKKKKACiiigAooooAK5v4j/wDJPPFf /YGvP/RD10lc38R/+SeeK/8AsDXn/oh6APgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oA+//hx/yTzwp/2BrP8A9EJXSVzfw4/5J54U/wCwNZ/+iErpKACiiigAooooAKKKKACiiigAoorh tQ+LWhabf3VjNaai0ttM8LlI4ypKkg4y/TigDuaK8+/4XN4e/wCfPU/+/Uf/AMco/wCFzeHv+fPU /wDv1H/8coA8n8Vf8jRrX/X/AD/+jGr6D8K/8ivov/XhB/6LWvnTW72PUtZ1C+hVliubqSZA4AYB mJGcd+a9S0T4taFpujafYzWmotLbWscLlI4ypKqAcZfpxQB6fRXn3/C5vD3/AD56n/36j/8AjlH/ AAubw9/z56n/AN+o/wD45QB6DXmuhXC+CfG+o6NeHyrDVX8+0lbhQxJwv6lfqB61Z/4XN4e/589T /wC/Uf8A8crF8T+P/B/iqw+yXtjqiunzQzpFHuib1Hz9PUd/yoA9bqA2Vs16t8YVN0kRhWXuEJBK /TKg/hXiehfE7WdHQWxkj1S0ThPtR8uVVHT5sn8vm+tbn/C7iOvh/n2vf/tdAHqENlbW9xcXMUKp NdFTM46uVG0Z+gGKnry21+MlxfTrb2nheW4nfO2KK6Ls2Bk4AjyeATWj/wALE8RHgeAdTz7mT/41 QB6DXmuu3C+NvG+naNZnzbDSn8+7lXlSwIyv6BfqT6U6aXx/4uBthaJ4esX4kkYnzSO4/vfkF+td f4Y8L2HhWw+yWSlnf5pp3+9K3qfb0Hb86ANmiiigAooooAKKKKACiiigArm/iP8A8k88V/8AYGvP /RD10lc38R/+SeeK/wDsDXn/AKIegD4AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPv /wCHH/JPPCn/AGBrP/0QldJXN/Dj/knnhT/sDWf/AKISukoAKKKKACiiigAooooAKKKKACiiigAo oooA+ZvFX/I0a1/1/wA//oxq+g/Cv/Ir6L/14Qf+i1r588Vf8jRrX/X/AD/+jGr2PU3kj+Em6GaW CT+xY9ssLlHT90vKsOQfcUAdtRXjtx4q1WC/sLye7mQaHDcadcghjHPdpE5kkdNyhl+WFwSQAHbk cmr0PjvWtWhvLaG4ssWkGoSTyeXlpUhjt2QAxykKT57AsrEfLkc0AeqUV5RffE3UbOa7itZLR/Ls 7kxRyoAUlhh3jP70uQSG+8q5GCpIBJ6PSNb1OXxs+i6hJBObWG6HnwxvEHAWycZTewyPOYZOTgDG MtkA7SivLzruvSeJ7jVbRLlNP1F7jSrCa4dGsxIi/uJNgfdlpo5wTtG5ZE54FOu/iPqsunwanbRQ WVjevIsE9yifuzHGm9X8yWMbjKZVxnOIWwMnIAPTqKoaLqQ1TT4Z2MS3IjT7VDG+7yJWRXKHuCAw PPOCD3q/QAUUUUAFFFFABRRRQAUUUUAFFFFABXN/Ef8A5J54r/7A15/6Ieukrm/iP/yTzxX/ANga 8/8ARD0AfAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB9//AA4/5J54U/7A1n/6ISuk rm/hx/yTzwp/2BrP/wBEJXSUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfM3ir/kaNa/6/5//RjV 9B+Ff+RX0X/rwg/9FrXz54q/5GjWv+v+f/0Y1fQfhX/kV9F/68IP/Ra0Aa1AAHQAUUUAJgZzgZpa KKACkIDDBAI96WigAooooAKKKKACiiigAooooAKKKKACiiigArm/iP8A8k88V/8AYGvP/RD10lc3 8R/+SeeK/wDsDXn/AKIegD4AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPv/wCHH/JP PCn/AGBrP/0QldJXN/Dj/knnhT/sDWf/AKISukoAKKKKACiiigAooooAKKKKACiiigAooooA+ZvF X/I0a1/1/wA//oxq+g/Cv/Ir6L/14Qf+i1r588Vf8jRrX/X/AD/+jGr6D8K/8ivov/XhB/6LWgDW ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArm/iP/yTzxX/ANga8/8ARD10lc38 R/8Aknniv/sDXn/oh6APgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+/8A4cf8k88K f9gaz/8ARCV0lc38OP8AknnhT/sDWf8A6ISukoAKKKKACiiigAooooAKKKKACiiigAooooA+ZvFX /I0a1/1/z/8Aoxq+g/Cv/Ir6L/14Qf8Aota+fPFX/I0a1/1/z/8Aoxq+g/Cv/Ir6L/14Qf8AotaA NaiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACub+I//ACTzxX/2Brz/ANEPXSVz fxH/AOSeeK/+wNef+iHoA+AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiinwOsc8buu5VcF l9QD0oA+/Phx/wAk88Kf9gaz/wDRCV0lecfAnxHDr3w6023EitdaSv2C4RTnGzhCPYptIP19K9Ho AKKKKACiiigAooooAKKKKACiiigAooooA+ZvFX/I0a1/1/z/APoxq+g/Cv8AyK+i/wDXhB/6LWvn zxV/yNGtf9f8/wD6MavoPwr/AMivov8A14Qf+i1oA1qKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAK5v4j/APJPPFf/AGBrz/0Q9dJXnHx28Rw6D8OtStzIq3WrL9gt0Y4zv++T7BNx J+nrQB8R0U+d1knkdF2qzkqvoCelMoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO0+HHxH1 X4f6yt9YssiOojuLaVsR3KDorH+FhztftnB4zX1R4c+O3gXXoIzcaqujXTKC1vqX7rHuH+4w9CD+ Ar4jp6TzRoyJK6K33lViAfrQB9+f8LH8D/8AQ5eH/wDwaQf/ABVH/Cx/A/8A0OXh/wD8GkH/AMVX wBRQB9//APCx/A//AEOXh/8A8GkH/wAVR/wsfwP/ANDl4f8A/BpB/wDFV8AUUAff/wDwsfwP/wBD l4f/APBpB/8AFUf8LH8D/wDQ5eH/APwaQf8AxVfAFFAH3/8A8LH8D/8AQ5eH/wDwaQf/ABVH/Cx/ A/8A0OXh/wD8GkH/AMVXwBRQB9//APCx/A//AEOXh/8A8GkH/wAVR/wsfwP/ANDl4f8A/BpB/wDF V8AUUAff/wDwsfwP/wBDl4f/APBpB/8AFUf8LH8D/wDQ5eH/APwaQf8AxVfAFFAH2LqGmfCrUr+6 vpvHtgstzM8zhNYtAoLEk4yOnNdlp/jrwHptha2MPjTQmitoUhQvqsBYhQAM4brxXwRRQB9//wDC x/A//Q5eH/8AwaQf/FUf8LH8D/8AQ5eH/wDwaQf/ABVfAFFAH3//AMLH8D/9Dl4f/wDBpB/8VR/w sfwP/wBDl4f/APBpB/8AFV8AUUAff/8AwsfwP/0OXh//AMGkH/xVH/Cx/A//AEOXh/8A8GkH/wAV XwBRQB9//wDCx/A//Q5eH/8AwaQf/FUf8LH8D/8AQ5eH/wDwaQf/ABVfAFFAH3//AMLH8D/9Dl4f /wDBpB/8VR/wsfwP/wBDl4f/APBpB/8AFV8AUUAff/8AwsfwP/0OXh//AMGkH/xVH/Cx/A//AEOX h/8A8GkH/wAVXwBRQB9//wDCx/A//Q5eH/8AwaQf/FUf8LH8D/8AQ5eH/wDwaQf/ABVfAFFAH3// AMLH8D/9Dl4f/wDBpB/8VR/wsfwP/wBDl4f/APBpB/8AFV8AUUAff/8AwsfwP/0OXh//AMGkH/xV H/Cx/A//AEOXh/8A8GkH/wAVXwBRQB9ueI/jt4F0GCQ2+qrrN0qkrb6b+9z7l/uKPUk/ga+V/iP8 R9V+IGstfXzLGiKY7e2ibMdsh6qp/iY8bn74wOMVxzzzSIqPK7qv3VZiQPpTKACiiigD/9k= --Apple-Mail-7--624708952 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable FAQ * Do I need to RSVP? Yes, please RSVP at least 1 week before the meeting so visitor badges=20 can be printed, and refreshments and meals can be planned. To RSVP,=20 send email to Nora Mosqueda and let Nora know that=20= you plan to attend the IETF WebDAV Working Group Interim Meeting=20 (include "WebDAV WG Interim Meeting" in the title of your email), what=20= day(s) you will be attending, and if you have any dietary requirements=20= we should be aware of. * What food is being provided for attendees? Refreshments will be provided during the morning and afternoon in the=20 meeting room. Lunches will be provided at Apple=92s cafeteria, Caff=E9=20= Macs. Caff=E9 Macs provides restaurant-quality full-service menus with=20= daily specials (including vegan and vegetarian menu choices). Apple is=20= providing refreshments and lunches at no charge to attendees. * What kind of network access will be available? AirPort (IEEE 802.11b) wireless networking is available in the=20 conference room. If Ethernet access is required, please note that=20 requirement when you RSVP. * Will my cell phone work at Apple? Yes. There is good coverage from several major cell phone networks. * Are there hotels close to the Apple campus? Cypress Hotel - walking distance from the Apple campus. 10050 South DeAnza Boulevard Cupertino, CA 950124 (408) 253-8900 Cupertino Inn - walking distance from the Apple campus. 10889 North DeAnza Blvd Cupertino, CA 95014 (408) 996-7700 Courtyard by Marriott - requires car to get to the Apple campus 10605 N. Wolfe Road Cupertino, CA 95014 (408) 252-9100 Hilton Garden Inn Cupertino - requires car to get to the Apple campus 10741 North Wolfe Road Cupertino CA 95014 (408) 777-8787 WoodCrest Hotel - requires car to get to the Apple campus 5415 Stevens Creek Blvd. Santa Clara, CA (408) 446-9636 Moorpark Hotel - requires car to get to the Apple campus 4241 Moorpark Avenue San Jose CA 95129 (408) 864-0300 Wild Palms Hotel - requires car to get to the Apple campus 910 East Fremont Avenue Sunnyvale, CA 94087 (408) 738-0500 Other area hotels within a short drive: Wellesley Inn Santa Clara, Santa Clara, CA Oakwood San Jose South, San Jose, CA Best Western Inn & Suites, Sunnyvale, CA =A0 Woodfin Suites Hotel Sunnyvale, Sunnyvale, CA Corporate Inn Sunnyvale, Sunnyvale, CA =A0 St. Francis Arms, Sunnyvale, CA =A0 Maple Tree Inn, Sunnyvale, CA =A0 Comfort Inn, Sunnyvale, CA =A0 Quality Inn Civic Center, Sunnyvale, CA =A0 Grand Hotel, Sunnyvale, CA On Tuesday, November 19, 2002, at 10:19 PM, Jim Whitehead wrote: > > I'd like to thank Jim Luther, and the Mac OS X Core OS group for=20 > hosting the > following Interim WebDAV WG meeting. The meeting is free of charge,=20 > and open > to all working group members. An agenda will be sent out the mailing=20= > list > soon, but will focus on finishing RFC 2518bis, as well as making=20 > significant > progress on DASL, bindings, and property-related specifications and > registration. > > If you are planning on attending, please RSVP to Jim Luther at > . > > - Jim > > > WebDAV Working Group Interim Meeting > > Dates > Monday, January 20 and Tuesday, January 21, 2003 > > Location > Apple Computer, Inc. > Singapore conference room > R&D Building 1, 1st floor > One Infinite Loop > Cupertino, CA 95014 > > The building is open to the conference room from 8:00 AM to 5:00 PM=20 > Pacific > time. > > How to get to Apple's R&D campus > The Apple Computer R&D campus is located in Cupertino, California > immediately south of Interstate 280 on the east side of De Anza=20 > Boulevard. > Cupertino is 5 minutes west of San Jose and 45 minutes southeast of = San > Francisco in the heart of Silicon Valley. > > =46rom Interstate 280, take De Anza Blvd south to Mariani Avenue (the=20= > first > stoplight). Turn left onto Mariani Ave and then turn left again onto > Infinite Loop. Free parking will be on your left (park in either of = the > large lots). R&D Building 1 is the building directly across from the=20= > parking > lot. > --Apple-Mail-7--624708952-- From w3c-dist-auth-request@w3.org Wed Nov 20 22:51:56 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10815 for ; Wed, 20 Nov 2002 22:51:40 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAL3q5522764; Wed, 20 Nov 2002 22:52:05 -0500 (EST) Resent-Date: Wed, 20 Nov 2002 22:52:05 -0500 (EST) Resent-Message-Id: <200211210352.gAL3q5522764@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAL3q3B22737 for ; Wed, 20 Nov 2002 22:52:03 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA30093 for ; Wed, 20 Nov 2002 22:52:03 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 20 Nov 2002 22:39:10 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403ZZTP8>; Wed, 20 Nov 2002 22:51:32 -0500 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Wed, 20 Nov 2002 22:51:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29111.473FCBB0" Subject: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7046 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C29111.473FCBB0 Content-Type: text/plain One of the topics discussed at this weeks WebDAV working group meeting was how to provide a mechanism that would allow a client to submit a set of lock tokens without a validity check (i.e. the request could succeed even if some or all of those lock tokens have expired). Note that a client needs to submit an If header with etags with such a request, to avoid lock protection. There are currently two alternative proposals for this (the semantics of these two proposals are identical, so this is a marshalling question): Proposal One: Extend the If header so that it can take a comma separated list of arguments (and therefore can be split into multiple If statements). To submit a set of lock tokens without a validity check, the following pattern would be used: If: urlA (tokenA [etagA]) (Not tokenA [etagA]) If: urlB (tokenB [etagA]) (Not tokenB [etagB]) ... Proposal Two: Add a new header for a comma separated list of lock tokens that indicate possession of the lock token but do not cause the request to fail if they are invalid (I neglected to write down the proposed name, so I'll just call it New-Header). Since the etag list can be long when the client holds a large number of locks, the extension defined in alternative one is also required, to handle the possibly large number of etags. The pattern of usage for this proposal would be: New-Header: tokenA If: urlA ([etagA]) New-Header: tokenB If: urlB ([etagB]) ... Advantage of proposal 1: - It does not require defining an extra header. Advantage of proposal 2: - It requires 40% fewer strings per resource (3 non-constant strings instead of 5 non-constant strings). Lisa: You calculated that proposal one requires four times as many non-constant strings ... how did you get that number? I believe that it is not appropriate to add a new header to the protocol just to decrease the header length for this particular use case by 40%. I am particularly disinclined to optimize this kind of request, because I believe that it is significantly simpler for a client to use a standard If header, and if locks have expired, the request fails, the client deletes from its state those expired locks, and then resubmits the request, replacing the expired locks with etags. This allows the client to just issue very simple If header requests, i.e. if the lock token for urlA is still valid but the lock token for urlB has expired: If: urlA (tokenA) If: urlB ([etagB]) Cheers, Geoff ------_=_NextPart_001_01C29111.473FCBB0 Content-Type: text/html Submitting lock tokens without a validity check

One of the topics discussed at this weeks WebDAV working group meeting
was how to provide a mechanism that would allow a client to submit a
set of lock tokens without a validity check (i.e. the request could
succeed even if some or all of those lock tokens have expired).
Note that a client needs to submit an If header with etags with such
a request, to avoid lock protection.

There are currently two alternative proposals for this (the semantics
of these two proposals are identical, so this is a marshalling question):

Proposal One: Extend the If header so that it can take a comma
separated list of arguments (and therefore can be split into multiple
If statements).  To submit a set of lock tokens without a validity
check, the following pattern would be used:

  If: urlA (tokenA [etagA]) (Not tokenA [etagA])
  If: urlB (tokenB [etagA]) (Not tokenB [etagB])
  ...

Proposal Two: Add a new header for a comma separated list of lock
tokens that indicate possession of the lock token but do not cause the
request to fail if they are invalid (I neglected to write down the
proposed name, so I'll just call it New-Header).  Since the etag list
can be long when the client holds a large number of locks, the
extension defined in alternative one is also required, to handle the
possibly large number of etags.  The pattern of usage for this
proposal would be:

  New-Header: tokenA
  If: urlA ([etagA])
  New-Header: tokenB
  If: urlB ([etagB])
  ...


Advantage of proposal 1:

- It does not require defining an extra header.

Advantage of proposal 2:

- It requires 40% fewer strings per resource (3 non-constant strings
instead of 5 non-constant strings).  Lisa: You calculated that
proposal one requires four times as many non-constant strings ... how
did you get that number?


I believe that it is not appropriate to add a new header to the protocol
just to decrease the header length for this particular use case by 40%.

I am particularly disinclined to optimize this kind of request,
because I believe that it is significantly simpler for a client to
use a standard If header, and if locks have expired, the request
fails, the client deletes from its state those expired locks, and then
resubmits the request, replacing the expired locks with etags.  This
allows the client to just issue very simple If header requests,
i.e. if the lock token for urlA is still valid but the lock token for
urlB has expired:

If: urlA (tokenA)
If: urlB ([etagB])

Cheers,
Geoff

------_=_NextPart_001_01C29111.473FCBB0-- From w3c-dist-auth-request@w3.org Wed Nov 20 23:13:33 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11113 for ; Wed, 20 Nov 2002 23:13:33 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAL4FAq24617; Wed, 20 Nov 2002 23:15:10 -0500 (EST) Resent-Date: Wed, 20 Nov 2002 23:15:10 -0500 (EST) Resent-Message-Id: <200211210415.gAL4FAq24617@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAL4F9B24591 for ; Wed, 20 Nov 2002 23:15:09 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA01275 for ; Wed, 20 Nov 2002 23:15:09 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 20 Nov 2002 23:02:17 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403ZZ423>; Wed, 20 Nov 2002 23:14:38 -0500 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Wed, 20 Nov 2002 23:14:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29114.80495C20" Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7047 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C29114.80495C20 Content-Type: text/plain Oops: "to avoid lock protection" should read "to avoid lost updates". Cheers, Geoff -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, November 20, 2002 10:52 PM To: 'Webdav WG' Subject: Submitting lock tokens without a validity check One of the topics discussed at this weeks WebDAV working group meeting was how to provide a mechanism that would allow a client to submit a set of lock tokens without a validity check (i.e. the request could succeed even if some or all of those lock tokens have expired). Note that a client needs to submit an If header with etags with such a request, to avoid lock protection. There are currently two alternative proposals for this (the semantics of these two proposals are identical, so this is a marshalling question): Proposal One: Extend the If header so that it can take a comma separated list of arguments (and therefore can be split into multiple If statements). To submit a set of lock tokens without a validity check, the following pattern would be used: If: urlA (tokenA [etagA]) (Not tokenA [etagA]) If: urlB (tokenB [etagA]) (Not tokenB [etagB]) ... Proposal Two: Add a new header for a comma separated list of lock tokens that indicate possession of the lock token but do not cause the request to fail if they are invalid (I neglected to write down the proposed name, so I'll just call it New-Header). Since the etag list can be long when the client holds a large number of locks, the extension defined in alternative one is also required, to handle the possibly large number of etags. The pattern of usage for this proposal would be: New-Header: tokenA If: urlA ([etagA]) New-Header: tokenB If: urlB ([etagB]) ... Advantage of proposal 1: - It does not require defining an extra header. Advantage of proposal 2: - It requires 40% fewer strings per resource (3 non-constant strings instead of 5 non-constant strings). Lisa: You calculated that proposal one requires four times as many non-constant strings ... how did you get that number? I believe that it is not appropriate to add a new header to the protocol just to decrease the header length for this particular use case by 40%. I am particularly disinclined to optimize this kind of request, because I believe that it is significantly simpler for a client to use a standard If header, and if locks have expired, the request fails, the client deletes from its state those expired locks, and then resubmits the request, replacing the expired locks with etags. This allows the client to just issue very simple If header requests, i.e. if the lock token for urlA is still valid but the lock token for urlB has expired: If: urlA (tokenA) If: urlB ([etagB]) Cheers, Geoff ------_=_NextPart_001_01C29114.80495C20 Content-Type: text/html RE: Submitting lock tokens without a validity check

Oops: "to avoid lock protection" should read "to avoid lost updates".

Cheers,
Geoff


-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]
Sent: Wednesday, November 20, 2002 10:52 PM
To: 'Webdav WG'
Subject: Submitting lock tokens without a validity check

One of the topics discussed at this weeks WebDAV working group meeting
was how to provide a mechanism that would allow a client to submit a
set of lock tokens without a validity check (i.e. the request could
succeed even if some or all of those lock tokens have expired).
Note that a client needs to submit an If header with etags with such
a request, to avoid lock protection.

There are currently two alternative proposals for this (the semantics
of these two proposals are identical, so this is a marshalling question):

Proposal One: Extend the If header so that it can take a comma
separated list of arguments (and therefore can be split into multiple
If statements).  To submit a set of lock tokens without a validity
check, the following pattern would be used:

  If: urlA (tokenA [etagA]) (Not tokenA [etagA])
  If: urlB (tokenB [etagA]) (Not tokenB [etagB])
  ...

Proposal Two: Add a new header for a comma separated list of lock
tokens that indicate possession of the lock token but do not cause the
request to fail if they are invalid (I neglected to write down the
proposed name, so I'll just call it New-Header).  Since the etag list
can be long when the client holds a large number of locks, the
extension defined in alternative one is also required, to handle the
possibly large number of etags.  The pattern of usage for this
proposal would be:
  New-Header: tokenA
  If: urlA ([etagA])
  New-Header: tokenB
  If: urlB ([etagB])
  ...


Advantage of proposal 1:
- It does not require defining an extra header.

Advantage of proposal 2:
- It requires 40% fewer strings per resource (3 non-constant strings
instead of 5 non-constant strings).  Lisa: You calculated that
proposal one requires four times as many non-constant strings ... how
did you get that number?


I believe that it is not appropriate to add a new header to the protocol
just to decrease the header length for this particular use case by 40%.

I am particularly disinclined to optimize this kind of request,
because I believe that it is significantly simpler for a client to
use a standard If header, and if locks have expired, the request
fails, the client deletes from its state those expired locks, and then
resubmits the request, replacing the expired locks with etags.  This
allows the client to just issue very simple If header requests,
i.e. if the lock token for urlA is still valid but the lock token for
urlB has expired:

If: urlA (tokenA)
If: urlB ([etagB])

Cheers,
Geoff

------_=_NextPart_001_01C29114.80495C20-- From w3c-dist-auth-request@w3.org Thu Nov 21 03:52:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25799 for ; Thu, 21 Nov 2002 03:52:14 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAL8rFQ19591; Thu, 21 Nov 2002 03:53:15 -0500 (EST) Resent-Date: Thu, 21 Nov 2002 03:53:15 -0500 (EST) Resent-Message-Id: <200211210853.gAL8rFQ19591@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAL8rDB19561 for ; Thu, 21 Nov 2002 03:53:13 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA10136 for ; Thu, 21 Nov 2002 03:53:12 -0500 Received: (qmail 5299 invoked by uid 0); 21 Nov 2002 08:52:37 -0000 Received: from p3ee24768.dip.t-dialin.net (HELO lisa) (62.226.71.104) by mail.gmx.net (mp004-rz3) with SMTP; 21 Nov 2002 08:52:37 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Thu, 21 Nov 2002 09:52:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7048 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for the summary, Geoff. Some thoughts/questions: > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Thursday, November 21, 2002 4:52 AM > To: 'Webdav WG' > Subject: Submitting lock tokens without a validity check > > > One of the topics discussed at this weeks WebDAV working group meeting > was how to provide a mechanism that would allow a client to submit a > set of lock tokens without a validity check (i.e. the request could > succeed even if some or all of those lock tokens have expired). > Note that a client needs to submit an If header with etags with such > a request, to avoid lock protection. > There are currently two alternative proposals for this (the semantics > of these two proposals are identical, so this is a marshalling question): Checking: the desired semantics are that the request succeeds independently of the lock still being present or not? > Proposal One: Extend the If header so that it can take a comma > separated list of arguments (and therefore can be split into multiple > If statements). To submit a set of lock tokens without a validity > check, the following pattern would be used: > If: urlA (tokenA [etagA]) (Not tokenA [etagA]) > If: urlB (tokenB [etagA]) (Not tokenB [etagB]) > ... I think this can be minimized to: If: urlA (tokenA [etagA]) (Not () [etagA]) ( is the URI of a known not-to-be-present lock, so the second List always evaluates to true). > Proposal Two: Add a new header for a comma separated list of lock > tokens that indicate possession of the lock token but do not cause the > request to fail if they are invalid (I neglected to write down the > proposed name, so I'll just call it New-Header). Since the etag list > can be long when the client holds a large number of locks, the > extension defined in alternative one is also required, to handle the > possibly large number of etags. The pattern of usage for this > proposal would be: > New-Header: tokenA > If: urlA ([etagA]) > New-Header: tokenB > If: urlB ([etagB]) > ... Is ordering relevant here? So would New-Header: tokenB If: urlA ([etagA]) New-Header: tokenA If: urlB ([etagB]) mean the same thing? > Advantage of proposal 1: > - It does not require defining an extra header. > Advantage of proposal 2: > - It requires 40% fewer strings per resource (3 non-constant strings > instead of 5 non-constant strings). Lisa: You calculated that > proposal one requires four times as many non-constant strings ... how > did you get that number? With my minimization above, I'm getting only one additional non-constant string. > I believe that it is not appropriate to add a new header to the protocol > just to decrease the header length for this particular use case by 40%. Agreed. > I am particularly disinclined to optimize this kind of request, > because I believe that it is significantly simpler for a client to > use a standard If header, and if locks have expired, the request > fails, the client deletes from its state those expired locks, and then > resubmits the request, replacing the expired locks with etags. This > allows the client to just issue very simple If header requests, > i.e. if the lock token for urlA is still valid but the lock token for > urlB has expired: > If: urlA (tokenA) > If: urlB ([etagB]) Maybe we should discuss enhancements for error reporting for precondition failures on if headers? That would probably make it easier for a client to recover. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Nov 21 09:32:20 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04028 for ; Thu, 21 Nov 2002 09:32:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gALEXkl10842; Thu, 21 Nov 2002 09:33:46 -0500 (EST) Resent-Date: Thu, 21 Nov 2002 09:33:46 -0500 (EST) Resent-Message-Id: <200211211433.gALEXkl10842@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gALEXiB10816 for ; Thu, 21 Nov 2002 09:33:44 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA04888 for ; Thu, 21 Nov 2002 09:33:44 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18EsVZ-000226-00; Thu, 21 Nov 2002 14:40:45 +0000 Received: from [204.42.72.212] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18EsVY-00021v-00; Thu, 21 Nov 2002 14:40:45 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'Webdav WG'" Date: Thu, 21 Nov 2002 06:33:39 -0800 Message-ID: <000001c2916a$fd886310$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id gALEXiB10816 Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7049 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit If a client uses "If: urlA (tokenA) (Not tokenA)" then the client will *not* find out that their lock is invalid. So that's not a real advantage of the existing header depending on how the client chooses to use it. Since the client could still choose to use the If header if a new header were defined, the two proposals you outline are equivalent in that regard. There is, however, another way to solve this that does have the property of consistently letting the client know when it has bad tokens: extend the existing If header to use * to indicate "any resource". This is consistent with If-Match and If-None-Match (HTTP 1.1) which use * to indicate "any token". To provide a token in this manner the client would use the * for the URL with the lock token they wanted to use: If: * () Or several in one header: If: * () * () () The way the server evaluates this: if matches any resource, AND matches any resource, AND matches the resource , then the request succeeds. This gives the advantage (not found with the two proposals discussed previously), of letting the server return an error if the lock token is invalid. The client can use the lock token more easily as long as it's valid, and the client gets its state corrected if its token is invalid. --- Side note on header length: this is an improvement over the If-OR-NOT-If syntax in length terms (it has one fewer lock token and a single-character URL). However, we might still want to add commas to the If header. Side note on backward compatibility: Adding commas and a '*' syntax to the if header (assuming no OPTIONS flag) would cause some interoperability issues. However, it shouldn't last too long (I think servers can pick this up rather quickly in particular) and is fairly easy to deal with. If a client sends the */, syntax to a server that doesn't yet support it, a 400 Bad Request is the most likely response, so I expect for a few years clients that want to use the */, syntax will see this and fail back to the older syntax. Servers should be able to parse the If header with or without tokens, and the addition of the '*' URL is simply an extension of the syntax that doesn't affect how the existing URL stuff works. (And of course, we could also add a "I support rfc2518 bis" flag to the OPTIONS response to prevent the error roundtrip for the case of new client --> old server.) Side note on how I came up with "four times" larger: Assuming the new header requires one copy of the token and zero URLs, and the If-OR-NOT-If solution requires two copies of the token and one URL (per resource), I should have said "three times" larger. Just an off by one error. But in my experience URLs are twice as long as lock tokens so maybe in practice it is four times larger :) Lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, November 20, 2002 7:52 PM To: 'Webdav WG' Subject: Submitting lock tokens without a validity check One of the topics discussed at this weeks WebDAV working group meeting was how to provide a mechanism that would allow a client to submit a set of lock tokens without a validity check (i.e. the request could succeed even if some or all of those lock tokens have expired). Note that a client needs to submit an If header with etags with such a request, to avoid lock protection. There are currently two alternative proposals for this (the semantics of these two proposals are identical, so this is a marshalling question): Proposal One: Extend the If header so that it can take a comma separated list of arguments (and therefore can be split into multiple If statements).  To submit a set of lock tokens without a validity check, the following pattern would be used:   If: urlA (tokenA [etagA]) (Not tokenA [etagA])   If: urlB (tokenB [etagA]) (Not tokenB [etagB])   ... Proposal Two: Add a new header for a comma separated list of lock tokens that indicate possession of the lock token but do not cause the request to fail if they are invalid (I neglected to write down the proposed name, so I'll just call it New-Header).  Since the etag list can be long when the client holds a large number of locks, the extension defined in alternative one is also required, to handle the possibly large number of etags.  The pattern of usage for this proposal would be:   New-Header: tokenA   If: urlA ([etagA])   New-Header: tokenB   If: urlB ([etagB])   ... Advantage of proposal 1: - It does not require defining an extra header. Advantage of proposal 2: - It requires 40% fewer strings per resource (3 non-constant strings instead of 5 non-constant strings).  Lisa: You calculated that proposal one requires four times as many non-constant strings ... how did you get that number? I believe that it is not appropriate to add a new header to the protocol just to decrease the header length for this particular use case by 40%. I am particularly disinclined to optimize this kind of request, because I believe that it is significantly simpler for a client to use a standard If header, and if locks have expired, the request fails, the client deletes from its state those expired locks, and then resubmits the request, replacing the expired locks with etags.  This allows the client to just issue very simple If header requests, i.e. if the lock token for urlA is still valid but the lock token for urlB has expired: If: urlA (tokenA) If: urlB ([etagB]) Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Nov 21 09:49:05 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04450 for ; Thu, 21 Nov 2002 09:49:04 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gALEog212334; Thu, 21 Nov 2002 09:50:42 -0500 (EST) Resent-Date: Thu, 21 Nov 2002 09:50:42 -0500 (EST) Resent-Message-Id: <200211211450.gALEog212334@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gALEofB12308 for ; Thu, 21 Nov 2002 09:50:41 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA07744 for ; Thu, 21 Nov 2002 09:50:41 -0500 Received: (qmail 16656 invoked by uid 0); 21 Nov 2002 14:50:19 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 21 Nov 2002 14:50:19 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Thu, 21 Nov 2002 15:50:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000001c2916a$fd886310$620afea9@xythoslap> Importance: Normal Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7050 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, November 21, 2002 3:34 PM > To: 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: Submitting lock tokens without a validity check > > > > If a client uses "If: urlA (tokenA) (Not tokenA)" then the client will > *not* find out that their lock is invalid. So that's not a real Wow. You managed to completely puzzle me. I thought that was exactly the point of this kind of request. Can you please explain again what the issue to be solved is, or point me to "the" mailing list message (in the archive) that explains it? -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Nov 21 10:51:34 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07262 for ; Thu, 21 Nov 2002 10:51:33 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gALFnbb25791; Thu, 21 Nov 2002 10:49:37 -0500 (EST) Resent-Date: Thu, 21 Nov 2002 10:49:37 -0500 (EST) Resent-Message-Id: <200211211549.gALFnbb25791@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gALFnZB25765 for ; Thu, 21 Nov 2002 10:49:35 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA21196 for ; Thu, 21 Nov 2002 10:49:34 -0500 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 21 Nov 2002 16:49:16 +0100 Date: Thu, 21 Nov 2002 16:49:15 +0100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "'Clemm, Geoff'" , "'Webdav WG'" To: "Lisa Dusseault" From: Stefan Eissing In-Reply-To: <000001c2916a$fd886310$620afea9@xythoslap> Message-Id: X-Mailer: Apple Mail (2.548) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id gALFnZB25765 Subject: Re: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7051 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Lisa, the use case which started the whole thread is "the client wants the request to succeed irregardless of wether the lock is still there or not". The addition of "*" to the If header does not help to solve this case. The introduction of "*" addresses the problem where the client is not sure for exactly which URIs it must provide lock-tokens in the IF header. That is also a problem worth addressing. Jason mentioned some weeks ago that 2518 does not clearly define when a lock-token is "submitted" and how the methods should check for submitted tokens. As I see it, the IF header is used for two purposes: P1) resource state checking P2) submitting "known" lock tokens P1 is, IMHO, pretty good defined. A client puts the URI of the resource to check in the IF header. If the URI is omitted, the request URI is silently substituted. All mentioned resource states are then verified by the server. Should a state not match (e.g. a lock token no longer there), the server will fail the request immediatly. For P2 we should define that server implementations should regard all lock-tokens supplied in the IF header as "submitted tokens". When verifying locks on resources affected by methods (such as COPY or MOVE), servers should for locked resources look into the set of "submitted tokens". If the lock is there, the request can proceed. Otherwise it will fail with a 423. Defining this behaviour will increase interoperability and ease life for clients. Clients just memorize the lock token together with the URI the lock was created on. They can then simply place those tuples in the IF headers of requests and everything should work fine. More optimizing clients might more carefully chose the locks to submit, but that is left up to their implementation. //Stefan Am Donnerstag, 21.11.02, um 15:33 Uhr (Europe/Berlin) schrieb Lisa Dusseault: > > If a client uses "If: urlA (tokenA) (Not tokenA)" then the client will > *not* find out that their lock is invalid. So that's not a real > advantage of the existing header depending on how the client chooses to > use it. Since the client could still choose to use the If header if a > new header were defined, the two proposals you outline are equivalent > in > that regard. > > There is, however, another way to solve this that does have the > property > of consistently letting the client know when it has bad tokens: extend > the existing If header to use * to indicate "any resource". This is > consistent with If-Match and If-None-Match (HTTP 1.1) which use * to > indicate "any token". > > To provide a token in this manner the client would use the * for the > URL > with the lock token they wanted to use: > > If: * () > > Or several in one header: > If: * () * () () > > The way the server evaluates this: if matches any > resource, AND matches any resource, AND > matches the resource , then the request succeeds. > > This gives the advantage (not found with the two proposals discussed > previously), of letting the server return an error if the lock token is > invalid. The client can use the lock token more easily as long as it's > valid, and the client gets its state corrected if its token is invalid. > > --- > > Side note on header length: this is an improvement over the > If-OR-NOT-If > syntax in length terms (it has one fewer lock token and a > single-character URL). However, we might still want to add commas to > the If header. > > Side note on backward compatibility: Adding commas and a '*' syntax to > the if header (assuming no OPTIONS flag) would cause some > interoperability issues. However, it shouldn't last too long (I think > servers can pick this up rather quickly in particular) and is fairly > easy to deal with. If a client sends the */, syntax to a server that > doesn't yet support it, a 400 Bad Request is the most likely response, > so I expect for a few years clients that want to use the */, syntax > will > see this and fail back to the older syntax. Servers should be able to > parse the If header with or without tokens, and the addition of the '*' > URL is simply an extension of the syntax that doesn't affect how the > existing URL stuff works. (And of course, we could also add a "I > support rfc2518 bis" flag to the OPTIONS response to prevent the error > roundtrip for the case of new client --> old server.) > > Side note on how I came up with "four times" larger: Assuming the new > header requires one copy of the token and zero URLs, and the > If-OR-NOT-If solution requires two copies of the token and one URL (per > resource), I should have said "three times" larger. Just an off by one > error. But in my experience URLs are twice as long as lock tokens so > maybe in practice it is four times larger :) > > Lisa > > > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, November 20, 2002 7:52 PM > To: 'Webdav WG' > Subject: Submitting lock tokens without a validity check > > One of the topics discussed at this weeks WebDAV working group meeting > was how to provide a mechanism that would allow a client to submit a > set of lock tokens without a validity check (i.e. the request could > succeed even if some or all of those lock tokens have expired). > Note that a client needs to submit an If header with etags with such > a request, to avoid lock protection. > There are currently two alternative proposals for this (the semantics > of these two proposals are identical, so this is a marshalling > question): > Proposal One: Extend the If header so that it can take a comma > separated list of arguments (and therefore can be split into multiple > If statements).  To submit a set of lock tokens without a validity > check, the following pattern would be used: >   If: urlA (tokenA [etagA]) (Not tokenA [etagA]) >   If: urlB (tokenB [etagA]) (Not tokenB [etagB]) >   ... > Proposal Two: Add a new header for a comma separated list of lock > tokens that indicate possession of the lock token but do not cause the > request to fail if they are invalid (I neglected to write down the > proposed name, so I'll just call it New-Header).  Since the etag list > can be long when the client holds a large number of locks, the > extension defined in alternative one is also required, to handle the > possibly large number of etags.  The pattern of usage for this > proposal would be: >   New-Header: tokenA >   If: urlA ([etagA]) >   New-Header: tokenB >   If: urlB ([etagB]) >   ... > > Advantage of proposal 1: > - It does not require defining an extra header. > Advantage of proposal 2: > - It requires 40% fewer strings per resource (3 non-constant strings > instead of 5 non-constant strings).  Lisa: You calculated that > proposal one requires four times as many non-constant strings ... how > did you get that number? > > I believe that it is not appropriate to add a new header to the > protocol > just to decrease the header length for this particular use case by 40%. > I am particularly disinclined to optimize this kind of request, > because I believe that it is significantly simpler for a client to > use a standard If header, and if locks have expired, the request > fails, the client deletes from its state those expired locks, and then > resubmits the request, replacing the expired locks with etags.  This > allows the client to just issue very simple If header requests, > i.e. if the lock token for urlA is still valid but the lock token for > urlB has expired: > If: urlA (tokenA) > If: urlB ([etagB]) > Cheers, > Geoff > > > From w3c-dist-auth-request@w3.org Thu Nov 21 13:22:33 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14072 for ; Thu, 21 Nov 2002 13:22:33 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gALIO4318367; Thu, 21 Nov 2002 13:24:04 -0500 (EST) Resent-Date: Thu, 21 Nov 2002 13:24:04 -0500 (EST) Resent-Message-Id: <200211211824.gALIO4318367@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gALIO2B18336 for ; Thu, 21 Nov 2002 13:24:02 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA19611 for ; Thu, 21 Nov 2002 13:24:02 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 21 Nov 2002 13:11:09 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Z5X6D>; Thu, 21 Nov 2002 13:23:31 -0500 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Thu, 21 Nov 2002 13:23:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2918B.1722E640" Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7052 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2918B.1722E640 Content-Type: text/plain; charset="iso-8859-1" From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > One of the topics discussed at this weeks WebDAV working group > meeting was how to provide a mechanism that would allow a client > to submit a set of lock tokens without a validity check (i.e. the > request could succeed even if some or all of those lock tokens > have expired). Note that a client needs to submit an If header > with etags with such a request, to avoid lock protection. There > are currently two alternative proposals for this (the semantics > of these two proposals are identical, so this is a marshalling > question): Checking: the desired semantics are that the request succeeds independently of the lock still being present or not? Yes. > Proposal One: Extend the If header so that it can take a comma > separated list of arguments (and therefore can be split into > multiple If statements). To submit a set of lock tokens without > a validity check, the following pattern would be used: > > If: urlA (tokenA [etagA]) (Not tokenA [etagA]) > If: urlB (tokenB [etagA]) (Not tokenB [etagB]) > ... I think this can be minimized to: If: urlA (tokenA [etagA]) (Not () [etagA]) ( is the URI of a known not-to-be-present lock, so the second List always evaluates to true). Good point! That makes the benefit of the second approach only a 25% decrease in non-constant strings per resource, rather than a 40% decrease. > Proposal Two: Add a new header for a comma separated list of lock > tokens that indicate possession of the lock token but do not > cause the request to fail if they are invalid (I neglected to > write down the proposed name, so I'll just call it New-Header). > Since the etag list can be long when the client holds a large > number of locks, the extension defined in alternative one is also > required, to handle the possibly large number of etags. The > pattern of usage for this proposal would be: > > New-Header: tokenA > If: urlA ([etagA]) > New-Header: tokenB > If: urlB ([etagB]) > ... Is ordering relevant here? So would New-Header: tokenB If: urlA ([etagA]) New-Header: tokenA If: urlB ([etagB]) mean the same thing? Yes, that would mean the same thing, and ordering is not relevant. > I am particularly disinclined to optimize this kind of request, > because I believe that it is significantly simpler for a client > to use a standard If header, and if locks have expired, the > request fails, the client deletes from its state those expired > locks, and then resubmits the request, replacing the expired > locks with etags. This allows the client to just issue very > simple If header requests, i.e. if the lock token for urlA is > still valid but the lock token for urlB has expired: > > If: urlA (tokenA) > If: urlB ([etagB]) Maybe we should discuss enhancements for error reporting for precondition failures on if headers? That would probably make it easier for a client to recover. Excellent point! Currently, I believe the spec is rather vague on how a client reports a violation of a clause in an If header, and it would be of great value to clarify this. Cheers, Geoff ------_=_NextPart_001_01C2918B.1722E640 Content-Type: text/html; charset="iso-8859-1" RE: Submitting lock tokens without a validity check

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   >
   > One of the topics discussed at this weeks WebDAV working group
   > meeting was how to provide a mechanism that would allow a client
   > to submit a set of lock tokens without a validity check (i.e. the
   > request could succeed even if some or all of those lock tokens
   > have expired).  Note that a client needs to submit an If header
   > with etags with such a request, to avoid lock protection.  There
   > are currently two alternative proposals for this (the semantics
   > of these two proposals are identical, so this is a marshalling
   > question):

   Checking: the desired semantics are that the request succeeds
   independently of the lock still being present or not?

Yes.

   > Proposal One: Extend the If header so that it can take a comma
   > separated list of arguments (and therefore can be split into
   > multiple If statements).  To submit a set of lock tokens without
   > a validity check, the following pattern would be used:
   >
   >   If: urlA (tokenA [etagA]) (Not tokenA [etagA])
   >   If: urlB (tokenB [etagA]) (Not tokenB [etagB])
   > ...

   I think this can be minimized to:

     If: urlA (tokenA [etagA]) (Not (<DAV:no-lock>) [etagA])

   (<DAV:no-lock> is the URI of a known not-to-be-present lock, so the
   second List always evaluates to true).

Good point!  That makes the benefit of the second approach only
a 25% decrease in non-constant strings per resource, rather than
a 40% decrease.

   > Proposal Two: Add a new header for a comma separated list of lock
   > tokens that indicate possession of the lock token but do not
   > cause the request to fail if they are invalid (I neglected to
   > write down the proposed name, so I'll just call it New-Header).
   > Since the etag list can be long when the client holds a large
   > number of locks, the extension defined in alternative one is also
   > required, to handle the possibly large number of etags.  The
   > pattern of usage for this proposal would be:
   >
   >   New-Header: tokenA
   >   If: urlA ([etagA])
   >   New-Header: tokenB
   >   If: urlB ([etagB])
   >   ...

   Is ordering relevant here? So would

     New-Header: tokenB
     If: urlA ([etagA])
     New-Header: tokenA
     If: urlB ([etagB])

   mean the same thing?

Yes, that would mean the same thing, and ordering is not relevant.

   > I am particularly disinclined to optimize this kind of request,
   > because I believe that it is significantly simpler for a client
   > to use a standard If header, and if locks have expired, the
   > request fails, the client deletes from its state those expired
   > locks, and then resubmits the request, replacing the expired
   > locks with etags.  This allows the client to just issue very
   > simple If header requests, i.e. if the lock token for urlA is
   > still valid but the lock token for urlB has expired:
   >
   > If: urlA (tokenA)
   > If: urlB ([etagB])

   Maybe we should discuss enhancements for error reporting for
   precondition failures on if headers? That would probably make it
   easier for a client to recover.

Excellent point!  Currently, I believe the spec is rather vague
on how a client reports a violation of a clause in an If header,
and it would be of great value to clarify this.

Cheers,
Geoff

------_=_NextPart_001_01C2918B.1722E640-- From w3c-dist-auth-request@w3.org Thu Nov 21 13:36:33 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14948 for ; Thu, 21 Nov 2002 13:36:32 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gALIcHc19782; Thu, 21 Nov 2002 13:38:17 -0500 (EST) Resent-Date: Thu, 21 Nov 2002 13:38:17 -0500 (EST) Resent-Message-Id: <200211211838.gALIcHc19782@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gALIcDB19756 for ; Thu, 21 Nov 2002 13:38:13 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA22937 for ; Thu, 21 Nov 2002 13:38:12 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 21 Nov 2002 13:24:59 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Z5Z1F>; Thu, 21 Nov 2002 13:37:17 -0500 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Thu, 21 Nov 2002 13:37:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2918D.03ACFCC0" Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7053 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2918D.03ACFCC0 Content-Type: text/plain; charset="iso-8859-1" The semantics of locks guarantee that a lock never "moves", so the client can simply store and submit the URL and the lock-token as a pair, so there is no compelling reason to have a "*" operator for lock token URLs. In addition, the uniqueness of an etag is only guaranteed for a particular URL, so the "*" operator cannot be used for etag clauses of an If header. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Thursday, November 21, 2002 9:34 AM To: 'Clemm, Geoff'; 'Webdav WG' Subject: RE: Submitting lock tokens without a validity check If a client uses "If: urlA (tokenA) (Not tokenA)" then the client will *not* find out that their lock is invalid. So that's not a real advantage of the existing header depending on how the client chooses to use it. Since the client could still choose to use the If header if a new header were defined, the two proposals you outline are equivalent in that regard. There is, however, another way to solve this that does have the property of consistently letting the client know when it has bad tokens: extend the existing If header to use * to indicate "any resource". This is consistent with If-Match and If-None-Match (HTTP 1.1) which use * to indicate "any token". To provide a token in this manner the client would use the * for the URL with the lock token they wanted to use: If: * () Or several in one header: If: * () * () () The way the server evaluates this: if matches any resource, AND matches any resource, AND matches the resource , then the request succeeds. This gives the advantage (not found with the two proposals discussed previously), of letting the server return an error if the lock token is invalid. The client can use the lock token more easily as long as it's valid, and the client gets its state corrected if its token is invalid. --- Side note on header length: this is an improvement over the If-OR-NOT-If syntax in length terms (it has one fewer lock token and a single-character URL). However, we might still want to add commas to the If header. Side note on backward compatibility: Adding commas and a '*' syntax to the if header (assuming no OPTIONS flag) would cause some interoperability issues. However, it shouldn't last too long (I think servers can pick this up rather quickly in particular) and is fairly easy to deal with. If a client sends the */, syntax to a server that doesn't yet support it, a 400 Bad Request is the most likely response, so I expect for a few years clients that want to use the */, syntax will see this and fail back to the older syntax. Servers should be able to parse the If header with or without tokens, and the addition of the '*' URL is simply an extension of the syntax that doesn't affect how the existing URL stuff works. (And of course, we could also add a "I support rfc2518 bis" flag to the OPTIONS response to prevent the error roundtrip for the case of new client --> old server.) Side note on how I came up with "four times" larger: Assuming the new header requires one copy of the token and zero URLs, and the If-OR-NOT-If solution requires two copies of the token and one URL (per resource), I should have said "three times" larger. Just an off by one error. But in my experience URLs are twice as long as lock tokens so maybe in practice it is four times larger :) Lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, November 20, 2002 7:52 PM To: 'Webdav WG' Subject: Submitting lock tokens without a validity check One of the topics discussed at this weeks WebDAV working group meeting was how to provide a mechanism that would allow a client to submit a set of lock tokens without a validity check (i.e. the request could succeed even if some or all of those lock tokens have expired). Note that a client needs to submit an If header with etags with such a request, to avoid lock protection. There are currently two alternative proposals for this (the semantics of these two proposals are identical, so this is a marshalling question): Proposal One: Extend the If header so that it can take a comma separated list of arguments (and therefore can be split into multiple If statements).  To submit a set of lock tokens without a validity check, the following pattern would be used:   If: urlA (tokenA [etagA]) (Not tokenA [etagA])   If: urlB (tokenB [etagA]) (Not tokenB [etagB])   ... Proposal Two: Add a new header for a comma separated list of lock tokens that indicate possession of the lock token but do not cause the request to fail if they are invalid (I neglected to write down the proposed name, so I'll just call it New-Header).  Since the etag list can be long when the client holds a large number of locks, the extension defined in alternative one is also required, to handle the possibly large number of etags.  The pattern of usage for this proposal would be:   New-Header: tokenA   If: urlA ([etagA])   New-Header: tokenB   If: urlB ([etagB])   ... Advantage of proposal 1: - It does not require defining an extra header. Advantage of proposal 2: - It requires 40% fewer strings per resource (3 non-constant strings instead of 5 non-constant strings).  Lisa: You calculated that proposal one requires four times as many non-constant strings ... how did you get that number? I believe that it is not appropriate to add a new header to the protocol just to decrease the header length for this particular use case by 40%. I am particularly disinclined to optimize this kind of request, because I believe that it is significantly simpler for a client to use a standard If header, and if locks have expired, the request fails, the client deletes from its state those expired locks, and then resubmits the request, replacing the expired locks with etags.  This allows the client to just issue very simple If header requests, i.e. if the lock token for urlA is still valid but the lock token for urlB has expired: If: urlA (tokenA) If: urlB ([etagB]) Cheers, Geoff ------_=_NextPart_001_01C2918D.03ACFCC0 Content-Type: text/html; charset="iso-8859-1" RE: Submitting lock tokens without a validity check

The semantics of locks guarantee that a lock never "moves",
so the client can simply store and submit the URL and the lock-token
as a pair, so there is no compelling
reason to have a "*" operator for lock token URLs.  In addition,
the uniqueness of an etag is only guaranteed for a particular
URL, so the "*" operator cannot be used for etag clauses of an
If header.

Cheers,
Geoff 

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Thursday, November 21, 2002 9:34 AM
To: 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: Submitting lock tokens without a validity check


If a client uses "If: urlA (tokenA) (Not tokenA)" then the client will
*not* find out that their lock is invalid.   So that's not a real
advantage of the existing header depending on how the client chooses to
use it.  Since the client could still choose to use the If header if a
new header were defined, the two proposals you outline are equivalent in
that regard.

There is, however, another way to solve this that does have the property
of consistently letting the client know when it has bad tokens: extend
the existing If header to use * to indicate "any resource".  This is
consistent with If-Match and If-None-Match (HTTP 1.1) which use * to
indicate "any token".

To provide a token in this manner the client would use the * for the URL
with the lock token they wanted to use:

    If: * (<lock-token-A>)

Or several in one header:
    If: * (<lock-token-A>) * (<lock-token-B>) <urlC> (<lock-token-C>)

The way the server evaluates this: if <lock-token-A> matches any
resource, AND <lock-token-B> matches any resource, AND <lock-token-C>
matches the resource <urlC>, then the request succeeds.

This gives the advantage (not found with the two proposals discussed
previously), of letting the server return an error if the lock token is
invalid.  The client can use the lock token more easily as long as it's
valid, and the client gets its state corrected if its token is invalid.

---

Side note on header length: this is an improvement over the If-OR-NOT-If
syntax in length terms (it has one fewer lock token and a
single-character URL).  However, we might still want to add commas to
the If header.

Side note on backward compatibility: Adding commas and a '*' syntax to
the if header (assuming no OPTIONS flag) would cause some
interoperability issues.  However, it shouldn't last too long (I think
servers can pick this up rather quickly in particular) and is fairly
easy to deal with.  If a client sends the */, syntax to a server that
doesn't yet support it, a 400 Bad Request is the most likely response,
so I expect for a few years clients that want to use the */, syntax will
see this and fail back to the older syntax.  Servers should be able to
parse the If header with or without tokens, and the addition of the '*'
URL is simply an extension of the syntax that doesn't affect how the
existing URL stuff works.  (And of course, we could also add a "I
support rfc2518 bis" flag to the OPTIONS response to prevent the error
roundtrip for the case of new client --> old server.)

Side note on how I came up with "four times" larger: Assuming the new
header requires one copy of the token and zero URLs, and the
If-OR-NOT-If solution requires two copies of the token and one URL (per
resource), I should have said "three times" larger.  Just an off by one
error.  But in my experience URLs are twice as long as lock tokens so
maybe in practice it is four times larger :)

Lisa


-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: Wednesday, November 20, 2002 7:52 PM
To: 'Webdav WG'
Subject: Submitting lock tokens without a validity check

One of the topics discussed at this weeks WebDAV working group meeting
was how to provide a mechanism that would allow a client to submit a
set of lock tokens without a validity check (i.e. the request could
succeed even if some or all of those lock tokens have expired).
Note that a client needs to submit an If header with etags with such
a request, to avoid lock protection.
There are currently two alternative proposals for this (the semantics
of these two proposals are identical, so this is a marshalling
question):
Proposal One: Extend the If header so that it can take a comma
separated list of arguments (and therefore can be split into multiple
If statements).  To submit a set of lock tokens without a validity
check, the following pattern would be used:
  If: urlA (tokenA [etagA]) (Not tokenA [etagA])
  If: urlB (tokenB [etagA]) (Not tokenB [etagB])
  ...
Proposal Two: Add a new header for a comma separated list of lock
tokens that indicate possession of the lock token but do not cause the
request to fail if they are invalid (I neglected to write down the
proposed name, so I'll just call it New-Header).  Since the etag list
can be long when the client holds a large number of locks, the
extension defined in alternative one is also required, to handle the
possibly large number of etags.  The pattern of usage for this
proposal would be:
  New-Header: tokenA
  If: urlA ([etagA])
  New-Header: tokenB
  If: urlB ([etagB])
  ...

Advantage of proposal 1:
- It does not require defining an extra header.
Advantage of proposal 2:
- It requires 40% fewer strings per resource (3 non-constant strings
instead of 5 non-constant strings).  Lisa: You calculated that
proposal one requires four times as many non-constant strings ... how
did you get that number?

I believe that it is not appropriate to add a new header to the protocol
just to decrease the header length for this particular use case by 40%.
I am particularly disinclined to optimize this kind of request,
because I believe that it is significantly simpler for a client to
use a standard If header, and if locks have expired, the request
fails, the client deletes from its state those expired locks, and then
resubmits the request, replacing the expired locks with etags.  This
allows the client to just issue very simple If header requests,
i.e. if the lock token for urlA is still valid but the lock token for
urlB has expired:
If: urlA (tokenA)
If: urlB ([etagB])
Cheers,
Geoff

------_=_NextPart_001_01C2918D.03ACFCC0-- From w3c-dist-auth-request@w3.org Thu Nov 21 23:03:13 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04846 for ; Thu, 21 Nov 2002 23:03:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAM44UC04809; Thu, 21 Nov 2002 23:04:30 -0500 (EST) Resent-Date: Thu, 21 Nov 2002 23:04:30 -0500 (EST) Resent-Message-Id: <200211220404.gAM44UC04809@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAM44SB04779 for ; Thu, 21 Nov 2002 23:04:28 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA08292 for ; Thu, 21 Nov 2002 23:04:27 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18F5AH-0007nw-00 for w3c-dist-auth@w3c.org; Fri, 22 Nov 2002 04:11:37 +0000 Received: from [204.42.72.212] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18F5AH-0007nl-00 for w3c-dist-auth@w3c.org; Fri, 22 Nov 2002 04:11:37 +0000 From: "Lisa Dusseault" To: "'Webdav WG'" Date: Thu, 21 Nov 2002 20:04:25 -0800 Message-ID: <000001c291dc$3f91fd40$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: Notes from the IETF/IESG/IAB Plenaries Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7054 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit There has been a lot of discussion at this IETF and the last one about how to "fix" the IETF. I'd like to pass on some of the things (complaints, suggestions) I've heard at the plenaries since most of you are missing this. - Documents that go to last call must be higher quality. There will be a bigger checklist with more stringent enforcement. Dot all i's. - Documents should be in a different format (one that it is easier to track changes, do algorithmic verification of checklist nits) - Don't do research; solve engineering problems. - Stay on a tightly defined charter. Use it to say "no" to new work. - Keep charter milestones up to date. [any volunteers for this wg?] - Rough consensus doesn't mean "compromise". Don't compromise on good design. - Chairs should be less nice. Make sure the right thing gets done rather than that people are happy and there is no conflict. Enforce quality. - Communicate with other WGs/ADs to avoid surprises in last call. - IAB needs to talk more about overall complicated architectures. - IESG needs to delegate more and identify problems earlier. - Transparency is good (and is increasing -- see ID tracker) Some links for more info: The ID tracker: Some IETF 55 presentations: Instructions to RFC editors: A proposal to improve IETF productivity: Security mechanisms for the Internet: Guidelines for writing security considerations: Toward a quantitative analysis of IETF productivity: General architectural and policy considerations: Some internet architectural guidelines and philosophy Lisa From w3c-dist-auth-request@w3.org Sat Nov 23 17:12:26 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06253 for ; Sat, 23 Nov 2002 17:12:26 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gANMDHM21377; Sat, 23 Nov 2002 17:13:17 -0500 (EST) Resent-Date: Sat, 23 Nov 2002 17:13:17 -0500 (EST) Resent-Message-Id: <200211232213.gANMDHM21377@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gANMDFU21350 for ; Sat, 23 Nov 2002 17:13:15 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA13529 for ; Sat, 23 Nov 2002 17:13:14 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18Fidp-0005ku-00; Sat, 23 Nov 2002 22:20:45 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18Fidp-0005kj-00; Sat, 23 Nov 2002 22:20:45 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Sat, 23 Nov 2002 14:13:07 -0800 Message-ID: <001801c2933d$80b292f0$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, julian.reschke@gmx.de, w3c-dist-auth@w3c.org Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7055 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > If a client uses "If: urlA (tokenA) (Not tokenA)" then the client will > > *not* find out that their lock is invalid. So that's not a real > > Wow. You managed to completely puzzle me. > > I thought that was exactly the point of this kind of request. Weird, eh? By using the If-Not-If hack, the client asks the request to succeed if the locktoken is invalid, or the locktoken is valid. So the client never finds out if the locktoken is invalid, because the if-not-if combination never fails. > > Can you please explain again what the issue to be solved is, or point me > to > "the" mailing list message (in the archive) that explains it? The issue to be solved is that all the client developers who have spoken up about the if header say that it's too hard to make interoperable. Every time the client is tested against a new server, some operations on locked resources fail. Usually they fail because 1. the server expects to see a lock token that the client hasn't provided, 2. the server expects a lock token to apply to a specific URL and the client didn't use the correct URL, 3. the client provides a locktoken for a URL that isn't even affected in the request, and that lock token or URL is incorrect, or 4. the lock expired. The reason why I suggested the approach of defining '*' as a wildcard for the IF header is because - it removes the need to figure out which URL to put the locktoken on (fixing #2) - when multiple resources are under the same lock, and when the lock token appears with '*', it's clear that it applies to any resource locked with that token (fixing #2 even more); - it makes it easier to include lock tokens that aren't actually required (fixing #3 and making #1 less likely) - It's shorter than putting the full URL (although we may still need comma support) (making #1 easier to achieve by including more lock tokens before running up against length limitations) Lisa From w3c-dist-auth-request@w3.org Sat Nov 23 17:13:54 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06285 for ; Sat, 23 Nov 2002 17:13:54 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gANMFq721610; Sat, 23 Nov 2002 17:15:52 -0500 (EST) Resent-Date: Sat, 23 Nov 2002 17:15:52 -0500 (EST) Resent-Message-Id: <200211232215.gANMFq721610@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gANMFpU21584 for ; Sat, 23 Nov 2002 17:15:51 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA13914 for ; Sat, 23 Nov 2002 17:15:50 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18FigO-0005mg-00; Sat, 23 Nov 2002 22:23:24 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18FigO-0005mV-00; Sat, 23 Nov 2002 22:23:24 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'Webdav WG'" Date: Sat, 23 Nov 2002 14:15:46 -0800 Message-ID: <001901c2933d$df6a29c0$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id gANMFpU21584 Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7056 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Julian said: "Checking: the desired semantics are that the request succeeds    independently of the lock still being present or not?" Geoff said: "Yes." My response: I don't agree with that narrow definition of what's desired. I think the problem statement is that the if header is constantly causing interoperability problems. The desired semantics are "some semantics that make locks easier to use". Lisa From w3c-dist-auth-request@w3.org Sun Nov 24 07:51:43 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26191 for ; Sun, 24 Nov 2002 07:51:28 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAOClsw18879; Sun, 24 Nov 2002 07:47:54 -0500 (EST) Resent-Date: Sun, 24 Nov 2002 07:47:54 -0500 (EST) Resent-Message-Id: <200211241247.gAOClsw18879@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAOClqU18853 for ; Sun, 24 Nov 2002 07:47:52 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA31539 for ; Sun, 24 Nov 2002 07:47:51 -0500 Received: (qmail 16841 invoked by uid 0); 24 Nov 2002 12:47:20 -0000 Received: from p3ee24770.dip.t-dialin.net (HELO lisa) (62.226.71.112) by mail.gmx.net (mp009-rz3) with SMTP; 24 Nov 2002 12:47:20 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Sun, 24 Nov 2002 13:47:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001901c2933d$df6a29c0$620afea9@xythoslap> Importance: Normal Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7057 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, November 23, 2002 11:16 PM > To: 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: Submitting lock tokens without a validity check > > > > Julian said: "Checking: the desired semantics are that the request > succeeds >    independently of the lock still being present or not?" > > Geoff said: "Yes." > > My response: I don't agree with that narrow definition of what's > desired. I think the problem statement is that the if header is > constantly causing interoperability problems. The desired semantics are > "some semantics that make locks easier to use". Sorry, but that isn't a definition. I doubt it makes sense to try to solve a set of problems that constantly is being redefined while we are trying to solve it. Unless the mostly silent client implementors are willing to write down *why* locks are hard to use, there's no point in debating it. So far I've seen the following things mentioned, each of which should have it's separate entry in the RFC2518 issues list (Jason?): 1) Syntax of If header relies on "long" HTTP headers, for which support cannot be relied upon (because of proxies). Solution: allow comma separated format and distribution across several header lines. Note: need to find out how a client can discover support for this (support for "long" headers *can* be discovered using TRACE). 2) Clients have both lock tokens and entity tags and want a request to succeed no matter whether the lock is there or not. Solution: possible with current If header syntax. Note: very questionable feature. 3) Clients are in doubt which URL to pass for a given lock token. Solution: clarify that it's the lock root (the URI against which the lock was created). 4) Clients are in doubt which locks need to be provided for a certain operation to succeed. Solution 1: try to clarify. Solution 2: submit all locks using existing If header syntax. 5) Clients want to be notified about expiring/disappearing locks. I wasn't aware of this before and would like to see the use case. If a client is in doubt about the state of the lock tokens it holds, it can discover them using PROPFIND. Anything else? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Nov 24 08:19:26 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26408 for ; Sun, 24 Nov 2002 08:19:26 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAODL4Y21097; Sun, 24 Nov 2002 08:21:04 -0500 (EST) Resent-Date: Sun, 24 Nov 2002 08:21:04 -0500 (EST) Resent-Message-Id: <200211241321.gAODL4Y21097@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAODKxU21067 for ; Sun, 24 Nov 2002 08:20:59 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA02883 for ; Sun, 24 Nov 2002 08:20:59 -0500 Received: (qmail 18242 invoked by uid 0); 24 Nov 2002 13:20:28 -0000 Received: from p3ee24770.dip.t-dialin.net (HELO lisa) (62.226.71.112) by mail.gmx.net (mp005-rz3) with SMTP; 24 Nov 2002 13:20:28 -0000 From: "Julian Reschke" To: "'Webdav WG'" Date: Sun, 24 Nov 2002 14:20:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001801c2933d$80b292f0$620afea9@xythoslap> Importance: Normal Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7058 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, November 23, 2002 11:13 PM > To: julian.reschke@gmx.de > Subject: RE: Submitting lock tokens without a validity check > > > > > > > > > If a client uses "If: urlA (tokenA) (Not tokenA)" then the client > will > > > *not* find out that their lock is invalid. So that's not a real > > > > Wow. You managed to completely puzzle me. > > > > I thought that was exactly the point of this kind of request. > > Weird, eh? By using the If-Not-If hack, the client asks the request to > succeed if the locktoken is invalid, or the locktoken is valid. So the > client never finds out if the locktoken is invalid, because the > if-not-if combination never fails. Yes. Really weird. Why would it want to know then? It will certainly find out when it finally does the UNLOCK. Where's the problem with that? > > > > Can you please explain again what the issue to be solved is, or point > me > > to > > "the" mailing list message (in the archive) that explains it? > > The issue to be solved is that all the client developers who have spoken > up about the if header say that it's too hard to make interoperable. > Every time the client is tested against a new server, some operations on > locked resources fail. Usually they fail because > 1. the server expects to see a lock token that the client hasn't > provided, So we need to clarify which are required. > 2. the server expects a lock token to apply to a specific URL and the > client didn't use the correct URL, Fix the client or the server. > 3. the client provides a locktoken for a URL that isn't even affected If the URL isn't affected, use If header syntax that makes the matching of the lock optional (we have that), > in the request, and that lock token or URL is incorrect, or Fix the client. > 4. the lock expired. Yes. That's the point of locking. If it expired before it should, the server may be broken. Fix it. On the other hand, somebody may have removed the lock *on purpose*. We *want* the request to fail in this case. > The reason why I suggested the approach of defining '*' as a wildcard > for the IF header is because > - it removes the need to figure out which URL to put the locktoken on > (fixing #2) But that's trivial to figure it. It's the URI that was used to create the LOCK. > - when multiple resources are under the same lock, and when the lock > token appears with '*', it's clear that it applies to any resource > locked with that token (fixing #2 even more); See answer above. > - it makes it easier to include lock tokens that aren't actually > required (fixing #3 and making #1 less likely) We already have a syntax for that. > - It's shorter than putting the full URL (although we may still need > comma support) (making #1 easier to achieve by including more lock > tokens before running up against length limitations) I'm stricty against changing the *existing* protocol just to minimize header sizes. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Nov 24 08:22:19 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26518 for ; Sun, 24 Nov 2002 08:22:19 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAODNpq21216; Sun, 24 Nov 2002 08:23:51 -0500 (EST) Resent-Date: Sun, 24 Nov 2002 08:23:51 -0500 (EST) Resent-Message-Id: <200211241323.gAODNpq21216@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAODNmU21190 for ; Sun, 24 Nov 2002 08:23:48 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA03153 for ; Sun, 24 Nov 2002 08:23:48 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 24 Nov 2002 08:10:48 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403511XZ>; Sun, 24 Nov 2002 08:23:17 -0500 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Sun, 24 Nov 2002 08:23:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C293BC.A52CDA30" Subject: RE: Submitting lock tokens without a validity check Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7059 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C293BC.A52CDA30 Content-Type: text/plain; charset="iso-8859-1" From: Lisa Dusseault [mailto:lisa@xythos.com] > > If a client uses "If: urlA (tokenA) (Not tokenA)" then the > > client will *not* find out that their lock is invalid. > Wow. You managed to completely puzzle me. > I thought that was exactly the point of this kind of request. Weird, eh? By using the If-Not-If hack, the client asks the request to succeed if the locktoken is invalid, or the locktoken is valid. So the client never finds out if the locktoken is invalid, because the if-not-if combination never fails. And if the client uses the proposed new header, the exact same thing occurs, i.e. the client never finds out if the locktoken is invalid, because the new header never fails. What puzzled Julian was not the semantics that you were describing, but rather the fact that you dislike the semantics when it is marshalled in an If header, but like it when it is marshalled in the new header. The issue to be solved is that all the client developers who have spoken up about the if header say that it's too hard to make interoperable. And we have two proposals for how to fix this. We are now debating the relative merits of those two proposals. Every time the client is tested against a new server, some operations on locked resources fail. Usually they fail because 1. the server expects to see a lock token that the client hasn't provided, 2. the server expects a lock token to apply to a specific URL and the client didn't use the correct URL, 3. the client provides a locktoken for a URL that isn't even affected in the request, and that lock token or URL is incorrect, or 4. the lock expired. The reason why I suggested the approach of defining '*' as a wildcard for the IF header is because - it removes the need to figure out which URL to put the locktoken on (fixing #2) Since the only safe way (i.e. that prevents lost updates) to avoid checking the validity of the lock token is to also specify an If header with an etag for the resource, the client must specify the appropriate URL for the etag. And if it can remember what etag goes with a URL, it can remember what lock token goes with a URL. This is one of my objections to this separate header. It makes it too easy for a client writer who finds the If header "too complicated" to just use this new header, omit to specify an If header with appropriate etags, and then overwrite changes made by other clients to resources whose locks have expired. Conversely, a client that can properly keep track of an etag (which requires keeping track of what URL it goes with), can use the same data structures to keep track of what lock token goes with that URL (and therefore #2 would not be an issue). - when multiple resources are under the same lock, and when the lock token appears with '*', it's clear that it applies to any resource locked with that token (fixing #2 even more); As above, * doesn't work with etags (which must be used if locks are not going to be checked), and if a client is going to accurately track the etag for a URL, it can use the same data structure to accurately track the lock token for a URL. - it makes it easier to include lock tokens that aren't actually required (fixing #3 and making #1 less likely) A debate of which method is "easier" is unlikely to be productive. Those of us that prefer the If/Not method believe it is "easier" because it is more regular and more accurately reflects the semantics being used. - It's shorter than putting the full URL (although we may still need comma support) (making #1 easier to achieve by including more lock tokens before running up against length limitations) We have agreed that the "new header" method has 25% fewer non-constant strings per locked resource (3 instead of 4). But several of us feel that the 25% savings in header length for this use case does not merit the introduction of a new header. From: Lisa Dusseault [mailto:lisa@xythos.com] Julian said: "Checking: the desired semantics are that the request succeeds independently of the lock still being present or not?" Geoff said: "Yes." My response: I don't agree with that narrow definition of what's desired. I think the problem statement is that the if header is constantly causing interoperability problems. The desired semantics are "some semantics that make locks easier to use". Julian was not asking for a problem statement. He was asking for the desired semantics for the proposed new header. Cheers, Geoff ------_=_NextPart_001_01C293BC.A52CDA30 Content-Type: text/html; charset="iso-8859-1" RE: Submitting lock tokens without a validity check

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   > > If a client uses "If: urlA (tokenA) (Not tokenA)" then the
   > > client will *not* find out that their lock is invalid.

   > Wow. You managed to completely puzzle me.
   > I thought that was exactly the point of this kind of request.

   Weird, eh?  By using the If-Not-If hack, the client asks the
   request to succeed if the locktoken is invalid, or the locktoken is
   valid.  So the client never finds out if the locktoken is invalid,
   because the if-not-if combination never fails.

And if the client uses the proposed new header, the exact same thing
occurs, i.e. the client never finds out if the locktoken is invalid,
because the new header never fails.  What puzzled Julian was not
the semantics that you were describing, but rather the fact that
you dislike the semantics when it is marshalled in an If header,
but like it when it is marshalled in the new header.

   The issue to be solved is that all the client developers who have
   spoken up about the if header say that it's too hard to make
   interoperable.

And we have two proposals for how to fix this.  We are now debating
the relative merits of those two proposals.

   Every time the client is tested against a new server, some operations on
   locked resources fail.  Usually they fail because
    1. the server expects to see a lock token that the client hasn't
   provided,
    2. the server expects a lock token to apply to a specific URL and the
   client didn't use the correct URL,
    3. the client provides a locktoken for a URL that isn't even affected
   in the request, and that lock token or URL is incorrect, or
    4. the lock expired.

   The reason why I suggested the approach of defining '*' as a wildcard
   for the IF header is because
    - it removes the need to figure out which URL to put the locktoken on
   (fixing #2)

Since the only safe way (i.e. that prevents lost updates) to avoid
checking the validity of the lock token is to also specify an If
header with an etag for the resource, the client must specify
the appropriate URL for the etag.  And if it can remember what etag
goes with a URL, it can remember what lock token goes with a URL.

This is one of my objections to this separate header.  It makes it too
easy for a client writer who finds the If header "too complicated" to
just use this new header, omit to specify an If header with
appropriate etags, and then overwrite changes made by other clients to
resources whose locks have expired.  Conversely, a client that can
properly keep track of an etag (which requires keeping track of what
URL it goes with), can use the same data structures to keep track of
what lock token goes with that URL (and therefore #2 would not be an
issue).

    - when multiple resources are under the same lock, and when the lock
   token appears with '*', it's clear that  it applies to any resource
   locked with that token (fixing #2 even more);

As above, * doesn't work with etags (which must be used if locks are
not going to be checked), and if a client is going to accurately track
the etag for a URL, it can use the same data structure to accurately
track the lock token for a URL.

    - it makes it easier to include lock tokens that aren't actually
   required (fixing #3 and making #1 less likely)

A debate of which method is "easier" is unlikely to be productive.
Those of us that prefer the If/Not method believe it is "easier"
because it is more regular and more accurately reflects the semantics
being used.

    - It's shorter than putting the full URL (although we may still need
   comma support) (making #1 easier to achieve by including more lock
   tokens before running up against length limitations)

We have agreed that the "new header" method has 25% fewer non-constant
strings per locked resource (3 instead of 4).  But several of us feel
that the 25% savings in header length for this use case does not merit
the introduction of a new header.

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   Julian said: "Checking: the desired semantics are that the request
   succeeds independently of the lock still being present or not?"

   Geoff said: "Yes."

   My response: I don't agree with that narrow definition of what's
   desired.  I think the problem statement is that the if header is
   constantly causing interoperability problems. The desired semantics
   are "some semantics that make locks easier to use".

Julian was not asking for a problem statement.  He was asking for the
desired semantics for the proposed new header.

Cheers,
Geoff

------_=_NextPart_001_01C293BC.A52CDA30-- From w3c-dist-auth-request@w3.org Wed Nov 27 21:37:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06347 for ; Wed, 27 Nov 2002 21:37:02 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAS2cOO29171; Wed, 27 Nov 2002 21:38:24 -0500 (EST) Resent-Date: Wed, 27 Nov 2002 21:38:24 -0500 (EST) Resent-Message-Id: <200211280238.gAS2cOO29171@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAS2cNA29141 for ; Wed, 27 Nov 2002 21:38:23 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA21431 for ; Wed, 27 Nov 2002 21:38:22 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18HEhi-0003QQ-00 for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 02:47:02 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18HEhh-0003QF-00 for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 02:47:01 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Wed, 27 Nov 2002 18:38:19 -0800 Message-ID: <000001c29687$36eda310$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: RFC2518 bis, attributes on property names -- in or out? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7060 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I heard from at least one implementor (Joel Soderberg) that random attributes on property names should not be stored "as part of" the property. This makes it more complicated to marshall the property again when responding to a PROPFIND request. Attribute namespaces may be difficult here. What namespace are the attributes in? What if the attribute on the property name is a namespace declaration -- does that have to be preserved *in that location*? Another consideration is that we may want to reserve attributes on the property name for meta-information *about* the property (like data types). That kind of information isn't part of the *value* of the property, but it may be used to figure out how to treat the property now or later. An implementation could safely ignore attributes it didn't understand. RFC2518 says "Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND." I believe the spec is silent about other attributes. In RFC2518bis, we got more specific about what makes up the value of a property: "The value of a property consists of attributes on the property name element, language attributes which are scoped to the property, namespaces which are used in the property name element or its children, and child elements including text. The server MUST persistently store this information and reconstruct it in PROPFIND responses. " Now that objections have been raised, who feels strongly for one side or another? Lisa From w3c-dist-auth-request@w3.org Wed Nov 27 21:52:58 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06702 for ; Wed, 27 Nov 2002 21:52:57 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAS2t1Z08555; Wed, 27 Nov 2002 21:55:01 -0500 (EST) Resent-Date: Wed, 27 Nov 2002 21:55:01 -0500 (EST) Resent-Message-Id: <200211280255.gAS2t1Z08555@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAS2sxA08510 for ; Wed, 27 Nov 2002 21:54:59 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA25510 for ; Wed, 27 Nov 2002 21:54:59 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18HExn-0003W9-00 for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 03:03:39 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18HExm-0003Vy-00 for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 03:03:38 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Wed, 27 Nov 2002 18:54:56 -0800 Message-ID: <000601c29689$890b99c0$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: RFC2518 issue: requiring ETags (Atlanta wg mtg) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7061 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The issue of requiring ETags was brought up at the WG mtg, as one of the remaining 2518 bis issues. The discussion covered dynamic resources, and a couple possible methods to generate ETags without too much pain (using combinations of sequence numbers, timestamps, hashes of resource names or content.). Most interestingly, there was also a suggestion that ETags could be required only for resources that can be PUT to. I think I'm satisfied with this compromise, because it's precisely in the situation when a client is trying to PUT a resource body, that ETag support is needed. We've already discovered since 2518 was published that locks aren't the only tool necessary to prevent lost updates - you also need ETags. For read-only resources Etags are nice-to-have in some situations (like synchronization and caching) but there isn't the data loss possibility. Note that this would require that for any resource that supports PUT, the server MUST return the ETag header on each GET request - because the server can't tell when the GET request is received, whether the user intends to try to do a PUT later or not. Comments? Lisa From w3c-dist-auth-request@w3.org Wed Nov 27 21:57:13 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06804 for ; Wed, 27 Nov 2002 21:57:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAS2xDO10091; Wed, 27 Nov 2002 21:59:13 -0500 (EST) Resent-Date: Wed, 27 Nov 2002 21:59:13 -0500 (EST) Resent-Message-Id: <200211280259.gAS2xDO10091@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAS2x9A09945 for ; Wed, 27 Nov 2002 21:59:09 -0500 (EST) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA23622 for ; Wed, 27 Nov 2002 21:46:08 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18HEpE-0003Ti-00 for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 02:54:48 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18HEpD-0003TP-00 for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 02:54:47 +0000 From: "Lisa Dusseault" To: "'Webdav WG'" Date: Wed, 27 Nov 2002 18:46:06 -0800 Message-ID: <000101c29688$4cab0430$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C29645.3E87C430" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: Quota draft issues from Atlanta WG mtg. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7062 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C29645.3E87C430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The quota draft was very briefly discussed in the WG meeting in Atlanta. The first open issue were how to define "quota" so that it could be flexible enough for many different implementations yet still simple enough for clients to easily use. The attendees favoured some kind of language like "quota is the maximum storage available to the current user in the current collection". This gives the quota enough context that both user-based quota systems and collection-based quota systems can represent quota with a single number. The second open issue was whether to rename the property names from "*-bytes" to "*-octets". The consensus of the attendees was not to bother. (I still don't have complete notes from the meeting but did scribble down this and some other notes myself). Lisa ------=_NextPart_000_0002_01C29645.3E87C430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The quota draft was very briefly discussed in the WG = meeting in Atlanta. 

 

The first open issue were how to define = “quota” so that it could be flexible enough for many different implementations = yet still simple enough for clients to easily use.  The attendees = favoured some kind of language like “quota is the maximum storage available to = the current user in the current collection”.  This gives the = quota enough context that both user-based quota systems and collection-based quota systems = can represent quota with a single number.

 

The second open issue was whether to rename the = property names from “*-bytes” to “*-octets”.  The = consensus of the attendees was not to bother.

 

(I still don’t have complete notes from the = meeting but did scribble down this and some other notes myself).

 

Lisa

 

 

------=_NextPart_000_0002_01C29645.3E87C430-- From w3c-dist-auth-request@w3.org Wed Nov 27 22:40:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07720 for ; Wed, 27 Nov 2002 22:40:18 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAS3gE523245; Wed, 27 Nov 2002 22:42:14 -0500 (EST) Resent-Date: Wed, 27 Nov 2002 22:42:14 -0500 (EST) Resent-Message-Id: <200211280342.gAS3gE523245@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAS3gCA23215 for ; Wed, 27 Nov 2002 22:42:12 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA05408 for ; Wed, 27 Nov 2002 22:42:12 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 27 Nov 2002 22:29:00 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 27 Nov 2002 22:41:36 -0500 Message-ID: From: "Clemm, Geoff" To: Webdav WG Date: Wed, 27 Nov 2002 22:41:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29690.0CC884C0" Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7063 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C29690.0CC884C0 Content-Type: text/plain Just one comment on the statement "we've already discovered since 2518 was published that locks aren't the only tool required to prevent lost updates". I disagree ... locks are sufficient to prevent lost updates. If a client decides not to use the locking protocol correctly (i.e. by updating a resource for which it does not have a valid lock), then of course something additional is required, but for a client that uses the locking protocol properly, locks are the only tool required to prevent lost updates. With that said, I personally have no objection to requiring etag support for PUT'able resources, but I am interested in hearing from any server writers for whom requiring etag support would be problematic. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Wednesday, November 27, 2002 9:55 PM To: Webdav WG Subject: RFC2518 issue: requiring ETags (Atlanta wg mtg) The issue of requiring ETags was brought up at the WG mtg, as one of the remaining 2518 bis issues. The discussion covered dynamic resources, and a couple possible methods to generate ETags without too much pain (using combinations of sequence numbers, timestamps, hashes of resource names or content.). Most interestingly, there was also a suggestion that ETags could be required only for resources that can be PUT to. I think I'm satisfied with this compromise, because it's precisely in the situation when a client is trying to PUT a resource body, that ETag support is needed. We've already discovered since 2518 was published that locks aren't the only tool necessary to prevent lost updates - you also need ETags. For read-only resources Etags are nice-to-have in some situations (like synchronization and caching) but there isn't the data loss possibility. Note that this would require that for any resource that supports PUT, the server MUST return the ETag header on each GET request - because the server can't tell when the GET request is received, whether the user intends to try to do a PUT later or not. Comments? Lisa ------_=_NextPart_001_01C29690.0CC884C0 Content-Type: text/html RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

Just one comment on the statement "we've already discovered since
2518 was published that locks aren't the only tool required to
prevent lost updates".  I disagree ... locks are sufficient to
prevent lost updates.  If a client decides not to use the locking
protocol correctly (i.e. by updating a resource for which it does
not have a valid lock), then of course something additional is
required, but for a client that uses the locking protocol properly,
locks are the only tool required to prevent lost updates.

With that said, I personally have no objection to requiring etag
support for PUT'able resources, but I am interested in hearing from
any server writers for whom requiring etag support would be problematic.

Cheers,
Geoff


-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Wednesday, November 27, 2002 9:55 PM
To: Webdav WG
Subject: RFC2518 issue: requiring ETags (Atlanta wg mtg)



The issue of requiring ETags was brought up at the WG mtg, as one of the
remaining 2518 bis issues.  The discussion covered dynamic resources,
and a couple possible methods to generate ETags without too much pain
(using combinations of sequence numbers, timestamps, hashes of resource
names or content.).  Most interestingly, there was also a suggestion
that ETags could be required only for resources that can be PUT to. 

 

I think I'm satisfied with this compromise, because it's precisely in
the situation when a client is trying to PUT a resource body, that ETag
support is needed.  We've already discovered since 2518 was published
that locks aren't the only tool necessary to prevent lost updates - you
also need ETags.  For read-only resources Etags are nice-to-have in some
situations (like synchronization and caching) but there isn't the data
loss possibility.

 

Note that this would require that for any resource that supports PUT,
the server MUST return the ETag header on each GET request - because the
server can't tell when the GET request is received, whether the user
intends to try to do a PUT later or not. 

 

Comments?

 

Lisa


------_=_NextPart_001_01C29690.0CC884C0-- From w3c-dist-auth-request@w3.org Thu Nov 28 03:48:02 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23083 for ; Thu, 28 Nov 2002 03:48:01 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAS8njB21020; Thu, 28 Nov 2002 03:49:45 -0500 (EST) Resent-Date: Thu, 28 Nov 2002 03:49:45 -0500 (EST) Resent-Message-Id: <200211280849.gAS8njB21020@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAS8ngA20990 for ; Thu, 28 Nov 2002 03:49:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA06017 for ; Thu, 28 Nov 2002 03:49:42 -0500 Received: (qmail 24566 invoked by uid 0); 28 Nov 2002 08:49:11 -0000 Received: from p3ee24712.dip.t-dialin.net (HELO lisa) (62.226.71.18) by mail.gmx.net (mp007-rz3) with SMTP; 28 Nov 2002 08:49:11 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Webdav WG'" Date: Thu, 28 Nov 2002 09:49:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000101c29688$4cab0430$620afea9@xythoslap> Subject: RE: Quota draft issues from Atlanta WG mtg. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7064 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Lisa Dusseault > Sent: Thursday, November 28, 2002 3:46 AM > To: 'Webdav WG' > Subject: Quota draft issues from Atlanta WG mtg. > > ... > > The second open issue was whether to rename the property names from > "*-bytes" to "*-octets". The consensus of the attendees was not > to bother. > > ... If attendees did not bother, but IETF does, it seems it would best to change term term to "octets". -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Nov 28 04:00:14 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23321 for ; Thu, 28 Nov 2002 04:00:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAS8xNt22823; Thu, 28 Nov 2002 03:59:23 -0500 (EST) Resent-Date: Thu, 28 Nov 2002 03:59:23 -0500 (EST) Resent-Message-Id: <200211280859.gAS8xNt22823@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAS8xJA22797 for ; Thu, 28 Nov 2002 03:59:19 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA07886 for ; Thu, 28 Nov 2002 03:59:18 -0500 Received: (qmail 10484 invoked by uid 0); 28 Nov 2002 08:58:47 -0000 Received: from p3ee24712.dip.t-dialin.net (HELO lisa) (62.226.71.18) by mail.gmx.net (mp002-rz3) with SMTP; 28 Nov 2002 08:58:47 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Thu, 28 Nov 2002 09:58:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000601c29689$890b99c0$620afea9@xythoslap> Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7065 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, November 28, 2002 3:55 AM > To: Webdav WG > Subject: RFC2518 issue: requiring ETags (Atlanta wg mtg) > > > > The issue of requiring ETags was brought up at the WG mtg, as one of the > remaining 2518 bis issues. The discussion covered dynamic resources, > and a couple possible methods to generate ETags without too much pain > (using combinations of sequence numbers, timestamps, hashes of resource > names or content.). Most interestingly, there was also a suggestion > that ETags could be required only for resources that can be PUT to. This makes sort of sense. However, I still don't see why this should be a requirement. A client that requires entity tags can trivially find out whether a resource supports them. If the resource doesn't support entity tags, but the client needs them, don't attempt the operation. I do agree with the earlier consensus that servers must be consistent in what they say about etag support (per ressource), notably that DAV:getetag must be present as property if and only iff HEAD/GET return the etag as well (but this is just a clarification, not a new requirement). > I think I'm satisfied with this compromise, because it's precisely in > the situation when a client is trying to PUT a resource body, that ETag > support is needed. We've already discovered since 2518 was published Actually, that requires *strong* entitity tags as opposed to weak entitity tags, right? If you make strong etags a requirement, Apache moddav (when talking to a fs backend) becomes non-compliant. Have you considered that? > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Nov 28 04:09:39 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23515 for ; Thu, 28 Nov 2002 04:09:39 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gAS9BZT24578; Thu, 28 Nov 2002 04:11:35 -0500 (EST) Resent-Date: Thu, 28 Nov 2002 04:11:35 -0500 (EST) Resent-Message-Id: <200211280911.gAS9BZT24578@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gAS9BWA24536 for ; Thu, 28 Nov 2002 04:11:32 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA10307 for ; Thu, 28 Nov 2002 04:11:30 -0500 Received: (qmail 26532 invoked by uid 0); 28 Nov 2002 09:11:00 -0000 Received: from p3ee24712.dip.t-dialin.net (HELO lisa) (62.226.71.18) by mail.gmx.net (mp001-rz3) with SMTP; 28 Nov 2002 09:11:00 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Thu, 28 Nov 2002 10:10:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000001c29687$36eda310$620afea9@xythoslap> Subject: RE: RFC2518 bis, attributes on property names -- in or out? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7066 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, November 28, 2002 3:38 AM > To: Webdav WG > Subject: RFC2518 bis, attributes on property names -- in or out? > > > > > I heard from at least one implementor (Joel Soderberg) that random > attributes on property names should not be stored "as part of" the > property. This makes it more complicated to marshall the property again > when responding to a PROPFIND request. Attribute namespaces may be > difficult here. What namespace are the attributes in? What if the I don't understand that part of the question. The namespace of an attribute is defined by the "Namespaces in XML" recommendation. There's no ambiguity here. > attribute on the property name is a namespace declaration -- does that > have to be preserved *in that location*? Back last year, I wrote down a precise definition of what I think needs to be persisted. This is not part of it. > Another consideration is that we may want to reserve attributes on the > property name for meta-information *about* the property (like data > types). That kind of information isn't part of the *value* of the > property, but it may be used to figure out how to treat the property now > or later. An implementation could safely ignore attributes it didn't > understand. This is a no-brainer. Attributes can be put into namespaces to disambiguate them. The specific case of putting type information into attributes is discussed in [1], which is compatible with the requirement to persist attributes. > RFC2518 says "Language tagging information in the property's value (in > the "xml:lang" attribute, if present) MUST be persistently stored along > with the property, and MUST be subsequently retrievable using PROPFIND." > I believe the spec is silent about other attributes. The spec is silent about what the value of a property actually is. So this needs to be resolved (issues list [2], issue "PROP_ROUNDTRIP"). > In RFC2518bis, we got more specific about what makes up the value of a > property: > "The value of a property consists of attributes on the property name > element, language attributes which are scoped to the property, > namespaces which are used in the property name element or its > children, and child elements including text. The server MUST > persistently store this information and reconstruct it in PROPFIND > responses. " > > Now that objections have been raised, who feels strongly for one side or > another? I feel strongly for keeping it this way, although I'd prefer wording that uses the more precise terminology from the XML Infoset recommendation.PROP_ROUNDTRIP. In particular I'd prefer to delay any change until the issues above have been dicussed. Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Nov 28 14:21:55 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02837 for ; Thu, 28 Nov 2002 14:21:55 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gASJKn028056; Thu, 28 Nov 2002 14:20:49 -0500 (EST) Resent-Date: Thu, 28 Nov 2002 14:20:49 -0500 (EST) Resent-Message-Id: <200211281920.gASJKn028056@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gASJKlA28026 for ; Thu, 28 Nov 2002 14:20:47 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA28583 for ; Thu, 28 Nov 2002 14:20:46 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA10193 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 11:20:40 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA10170 sender ccjason@us.ibm.com; Thu, 28 Nov 2002 11:20:39 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gASJKbWj092762; Thu, 28 Nov 2002 14:20:37 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gASJNOBg133226; Thu, 28 Nov 2002 12:23:25 -0700 To: "Julian Reschke" Cc: "Lisa Dusseault" , "Webdav WG" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Thu, 28 Nov 2002 14:20:31 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0 [IBM]|November 8, 2002) at 11/28/2002 14:20:34, Serialize complete at 11/28/2002 14:20:34 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC2518 bis, attributes on property names -- in or out? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7067 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: My preference is to keep things the way it is in 2518bis. I don't feel so strongly about keeping all the attributes on the propertyname tag, but I definitely don't wan't to agonize over it if there is no strong case to be made either way. I do want to hear more about what Joel Soderberg encountered that would make it lean away from persisting random attributes. I do agree with Julian that the namespace persistance issue is pretty clear, but I'll resurrect the discussion on property value roundtripping and see if we can nail that issue and all sub issues shut. J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Thu Nov 28 14:52:57 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03192 for ; Thu, 28 Nov 2002 14:52:57 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gASJt0c01338; Thu, 28 Nov 2002 14:55:00 -0500 (EST) Resent-Date: Thu, 28 Nov 2002 14:55:00 -0500 (EST) Resent-Message-Id: <200211281955.gASJt0c01338@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gASJswA01305 for ; Thu, 28 Nov 2002 14:54:58 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA01296 for ; Thu, 28 Nov 2002 14:54:57 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA12429 sender joels@exchange.microsoft.com for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 11:54:56 -0800 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA12408 sender joels@exchange.microsoft.com; Thu, 28 Nov 2002 11:54:55 -0800 Received: from DF-YURI.platinum.corp.microsoft.com ([10.197.0.60]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.5255); Thu, 28 Nov 2002 11:55:27 -0800 Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 28 Nov 2002 11:54:53 -0800 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Nov 2002 11:54:51 -0800 Received: from DF-BOWWOW.platinum.corp.microsoft.com ([10.197.1.20]) by DF-BEG.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 11:54:51 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Thu, 28 Nov 2002 11:54:50 -0800 Message-ID: <4B52672946805F4D8B93BA8FEDD30F2501DDC56A@DF-BOWWOW.platinum.corp.microsoft.com> From: "Joel Soderberg" To: "Jason Crawford" , "Julian Reschke" Cc: "Lisa Dusseault" , "Webdav WG" Subject: RE: RFC2518 bis, attributes on property names -- in or out? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7068 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29718.032E26EA" ------_=_NextPart_001_01C29718.032E26EA Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Preserving namespaces is almost a given (I would be surprised if that = was not already being done by most implementations). However, I don't = believe that the namespace aliasing must be preserved. When returning = the value, different aliases may be used. =20 This has no bearing, though, on random attributes (metadata) on the = property name. If you force persistance of these items, that means that = you dictate a storage format that is XML. WebDAV should not be in the = business of dictating formats. =20 If the only reason for asking for persistance is for namespacing, there = are other ways that information can be retained that does not tie the = hands of the non-XML based property storage. Joel -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thu 11/28/2002 11:20 AM To: Julian Reschke Cc: Lisa Dusseault; Webdav WG Subject: RE: RFC2518 bis, attributes on property names -- in or out? My preference is to keep things the way it is in 2518bis. I don't feel = so=20 strongly about keeping all the attributes on the propertyname tag, but I = definitely don't wan't to agonize over it if there is no strong case to = be=20 made either way. I do want to hear more about what Joel Soderberg encountered that would = make it lean away from persisting random=20 attributes. I do agree with Julian that the namespace persistance issue is pretty=20 clear, but I'll resurrect the discussion on property value roundtripping = and see if we can nail that issue and all sub issues shut. J. ------------------------------------------ Phone: 914-784-7569 ------_=_NextPart_001_01C29718.032E26EA Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: RFC2518 bis, attributes on property names -- in or = out?

Preserving namespaces is almost a given (I would be = surprised if that was not already being done by most = implementations).  However, I don't believe that the namespace = aliasing must be preserved.  When returning the value, different = aliases may be used. 

This has no bearing, though, on random attributes (metadata) on the = property name.  If you force persistance of these items, that means = that you dictate a storage format that is XML.  WebDAV should not = be in the business of dictating formats. 

If the only reason for asking for persistance is for namespacing, there = are other ways that information can be retained that does not tie the = hands of the non-XML based property storage.

Joel

-----Original Message-----
From:   Jason Crawford [mailto:ccjason@us.ibm.com]
Sent:   Thu 11/28/2002 11:20 AM
To:     Julian Reschke
Cc:     Lisa Dusseault; Webdav WG
Subject:        RE: RFC2518 bis, = attributes on property names -- in or out?


My preference is to keep things the way it is in 2518bis.  I don't = feel so
strongly about keeping all the attributes on the propertyname tag, but = I
definitely don't wan't to agonize over it if there is no strong case to = be
made either way.

I do want to hear more about what Joel Soderberg encountered that would = make it lean away from persisting random
attributes.

I do agree with Julian that the namespace persistance issue is = pretty
clear, but I'll resurrect the discussion on property value = roundtripping
and see if we can nail that issue and all sub issues shut.

J.

------------------------------------------
Phone: 914-784-7569

------_=_NextPart_001_01C29718.032E26EA-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Thu Nov 28 15:37:28 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04098 for ; Thu, 28 Nov 2002 15:37:27 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gASKdGO06939; Thu, 28 Nov 2002 15:39:16 -0500 (EST) Resent-Date: Thu, 28 Nov 2002 15:39:16 -0500 (EST) Resent-Message-Id: <200211282039.gASKdGO06939@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gASKdEA06870 for ; Thu, 28 Nov 2002 15:39:14 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA08949 for ; Thu, 28 Nov 2002 15:39:12 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA14108 sender julian.reschke@gmx.de for w3c-dist-auth@w3c.org; Thu, 28 Nov 2002 12:39:10 -0800 Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by sunbelt.seagull.net (8.9.3) with SMTP id MAA14101 sender julian.reschke@gmx.de for ; Thu, 28 Nov 2002 12:39:08 -0800 Received: (qmail 29629 invoked by uid 0); 28 Nov 2002 20:38:37 -0000 Received: from p3ee2470b.dip.t-dialin.net (HELO lisa) (62.226.71.11) by mail.gmx.net (mp006-rz3) with SMTP; 28 Nov 2002 20:38:37 -0000 From: "Julian Reschke" To: "Joel Soderberg" Cc: "Webdav WG" Date: Thu, 28 Nov 2002 21:38:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Subject: RE: RFC2518 bis, attributes on property names -- in or out? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7069 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Joel Soderberg > Sent: Thursday, November 28, 2002 8:55 PM > To: Jason Crawford; Julian Reschke > Cc: Lisa Dusseault; Webdav WG > Subject: RE: RFC2518 bis, attributes on property names -- in or out? > > > Preserving namespaces is almost a given (I would be surprised if that was > not already being done by most implementations). However, I don't believe If you're referring to namespaces of property names -- sure. A property is identified by an XML name, and if an implementation looses half of it (the namespace), it's simply broken. > that the namespace aliasing must be preserved. When returning the value, > different aliases may be used. Yes, for the property name itself. But not for any child elements contained inside the property. And probably undecided for attributes on the property element itself. > This has no bearing, though, on random attributes (metadata) on the property > name. If you force persistance of these items, that means that you dictate > a storage format that is XML. WebDAV should not be in the business of > dictating formats. I don't understand these statements. The format for WebDAV property values *is* XML. So if you can't persist a dead property with nested child elements (and attributes on those for that matter), you're not compliant to RFC2518. The *only* controversial thing here is whether attributes that appear *on* the property name element itself are part of the value to be persisted. So you need to be able to persist XML anyway -- how does persisting attributes on the property itself make things harder? > If the only reason for asking for persistance is for namespacing, there are > other ways that information can be retained that does not tie the hands of > the non-XML based property storage. In general, to be compliant with RFC2518 you can't use an XML-unfriendly property storage. Whether attributes are in and out seems to be of little importance here. I'm happy to discuss this as a new issue (for instance, are servers allowed to only persist the immediate child text nodes of a property element as a string?), but this is definitively a new requirement. Note that both IIS and moddav (the most widely deployed WebDAV servers) *do* persist XML in property values, so we have proven interoperability in this point. Finally (as mentioned many times before), the best way to *precisely* define these things is to use the terminology from the XML Infoset spec, and the guidelines from section 2.4 (document subsets) of RFC3076. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Nov 29 11:50:05 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03038 for ; Fri, 29 Nov 2002 11:50:05 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gATGpiK04957; Fri, 29 Nov 2002 11:51:44 -0500 (EST) Resent-Date: Fri, 29 Nov 2002 11:51:44 -0500 (EST) Resent-Message-Id: <200211291651.gATGpiK04957@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gATGpgA04931 for ; Fri, 29 Nov 2002 11:51:42 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA27815 for ; Fri, 29 Nov 2002 11:51:41 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id IAA14314 sender joels@exchange.microsoft.com for w3c-dist-auth@w3c.org; Fri, 29 Nov 2002 08:51:39 -0800 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by sunbelt.seagull.net (8.9.3) with ESMTP id IAA14307 sender joels@exchange.microsoft.com for ; Fri, 29 Nov 2002 08:51:39 -0800 Received: from DF-YURI.platinum.corp.microsoft.com ([10.197.0.60]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.5255); Fri, 29 Nov 2002 08:52:14 -0800 Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 29 Nov 2002 08:51:38 -0800 Received: from 10.197.0.48 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 29 Nov 2002 08:51:38 -0800 Received: from DF-BOWWOW.platinum.corp.microsoft.com ([10.197.1.20]) by DF-STIMPY.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 29 Nov 2002 08:51:38 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Fri, 29 Nov 2002 08:51:37 -0800 Message-ID: <4B52672946805F4D8B93BA8FEDD30F2501DDC56C@DF-BOWWOW.platinum.corp.microsoft.com> From: "Joel Soderberg" To: "Julian Reschke" Cc: "Webdav WG" Subject: RE: RFC2518 bis, attributes on property names -- in or out? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7070 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C297C7.9530CD0D" ------_=_NextPart_001_01C297C7.9530CD0D Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Couple more comments inline.... -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thu 11/28/2002 12:38 PM To: Joel Soderberg Cc: Webdav WG Subject: RE: RFC2518 bis, attributes on property names -- in or out? > From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Joel Soderberg > Sent: Thursday, November 28, 2002 8:55 PM > To: Jason Crawford; Julian Reschke > Cc: Lisa Dusseault; Webdav WG > Subject: RE: RFC2518 bis, attributes on property names -- in or out? > > > Preserving namespaces is almost a given (I would be surprised if that = was > not already being done by most implementations). However, I don't = believe If you're referring to namespaces of property names -- sure. A property = is identified by an XML name, and if an implementation looses half of it = (the namespace), it's simply broken. [js] Yes, but even more so, I am talking about any namespaces used in = the=20 context of the proptery value. An implementation must be smart about = this such that any namespace defined above the property value scope is = persisted if it is used in the property value. There is nothing in the DAV drafts = that requires all namespaces used in a property value to be defined or = redefined at the property/value level. > that the namespace aliasing must be preserved. When returning the = value, > different aliases may be used. Yes, for the property name itself. But not for any child elements = contained inside the property. And probably undecided for attributes on the = property element itself. [js] Why? This is an arbitrary requirement, no? Namespaces are not = tied to an alias outside of any document. I believe (although I may be = wrong), that the namespace documents even indicate tha the revelence of the alias = outside of the current document cannot be relied on. It should be perfectly = allowable for an implementation to persist the namespace/tag pairs instead of = having to persist the alias. I can think of at least three different DAV server=20 implementations that model behavior that way. > This has no bearing, though, on random attributes (metadata) on the property > name. If you force persistance of these items, that means that you dictate > a storage format that is XML. WebDAV should not be in the business of > dictating formats. I don't understand these statements. The format for WebDAV property = values *is* XML. So if you can't persist a dead property with nested child = elements (and attributes on those for that matter), you're not compliant to = RFC2518. The *only* controversial thing here is whether attributes that appear = *on* the property name element itself are part of the value to be persisted. [js] Actually, I'll take this bit offline with you -- I get back to the = office on Monday. So you need to be able to persist XML anyway -- how does persisting attributes on the property itself make things harder? [js] Needing to persist XML does not mean that everything is XML, true? I can point you to a couple of DAV implementations that use the XML = datatype draft (that I think is long since forgotten) that honors a DT attribute = and will persist the value in that format. There is nothing in the drafts that = prevent this behavior, and nothing should be added that would suddenly make such = implementations non-compliant. > If the only reason for asking for persistance is for namespacing, = there are > other ways that information can be retained that does not tie the = hands of > the non-XML based property storage. In general, to be compliant with RFC2518 you can't use an XML-unfriendly property storage. Whether attributes are in and out seems to be of = little importance here. [js] Again, XML friendly is not the same as XML exclusive. I don't = think forcing the hands of server developers to XML is a goal of the DAV = drafts and should not added to the BIS. I'm happy to discuss this as a new issue (for instance, are servers = allowed to only persist the immediate child text nodes of a property element as = a string?), but this is definitively a new requirement. [js] I don't believe it is a new requirement. I believe it is a = reasonable option that allowed DAV server developers to add-value to their=20 implementations. It certainly was not required, but it also was not = forbidden. Note that both IIS and moddav (the most widely deployed WebDAV servers) = *do* persist XML in property values, so we have proven interoperability in = this point. [js] Again, I will take this offline, but no. You have interop with = implementations that persist the XML values, they don't always persist random attributes = in the value node. Finally (as mentioned many times before), the best way to *precisely* = define these things is to use the terminology from the XML Infoset spec, and = the guidelines from section 2.4 (document subsets) of RFC3076. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C297C7.9530CD0D Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: RFC2518 bis, attributes on property names -- in or = out?

Couple more comments inline....

-----Original Message-----
From:   Julian Reschke [mailto:julian.reschke@gmx.de] Sent:   Thu 11/28/2002 12:38 PM
To:     Joel Soderberg
Cc:     Webdav WG
Subject:        RE: RFC2518 bis, = attributes on property names -- in or out?

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request= @w3.org]On
> Behalf Of Joel Soderberg
> Sent: Thursday, November 28, 2002 8:55 PM
> To: Jason Crawford; Julian Reschke
> Cc: Lisa Dusseault; Webdav WG
> Subject: RE: RFC2518 bis, attributes on property names -- in or = out?
>
>
> Preserving namespaces is almost a given (I would be surprised if = that was
> not already being done by most implementations).  However, I = don't believe

If you're referring to namespaces of property names -- sure. A property = is
identified by an XML name, and if an implementation looses half of it = (the
namespace), it's simply broken.

[js] Yes, but even more so, I am talking about any namespaces used in = the
context of the proptery value.  An implementation must be smart = about this
such that any namespace defined above the property value scope is = persisted
if it is used in the property value.  There is nothing in the DAV = drafts that
requires all namespaces used in a property value to be defined or = redefined
at the property/value level.

> that the namespace aliasing must be preserved.  When returning = the value,
> different aliases may be used.

Yes, for the property name itself. But not for any child elements = contained
inside the property. And probably undecided for attributes on the = property
element itself.

[js] Why?  This is an arbitrary requirement, no?  Namespaces = are not tied
to an alias outside of any document.  I believe (although I may be = wrong), that
the namespace documents even indicate tha the revelence of the alias = outside
of the current document cannot be relied on.  It should be = perfectly allowable
for an implementation to persist the namespace/tag pairs instead of = having to
persist the alias.  I can think of at least three different DAV = server
implementations that model behavior that way.

> This has no bearing, though, on random attributes (metadata) on = the
property
> name.  If you force persistance of these items, that means = that  you
dictate
> a storage format that is XML.  WebDAV should not be in the = business of
> dictating formats.

I don't understand these statements. The format for WebDAV property = values
*is* XML. So if you can't persist a dead property with nested child = elements
(and attributes on those for that matter), you're not compliant to = RFC2518.
The *only* controversial thing here is whether attributes that appear = *on*
the property name element itself are part of the value to be = persisted.

[js] Actually, I'll take this bit offline with you -- I get back to the = office on
Monday.

So you need to be able to persist XML anyway -- how does persisting
attributes on the property itself make things harder?

[js] Needing to persist XML does not mean that everything is XML, = true?
I can point you to a couple of DAV implementations that use the XML = datatype
draft (that I think is long since forgotten) that honors a DT attribute = and will
persist the value in that format.  There is nothing in the drafts = that prevent
this behavior, and nothing should be added that would suddenly make = such
implementations non-compliant.

> If the only reason for asking for persistance is for = namespacing,  there
are
> other ways that information can be retained that does not tie the = hands of
> the non-XML based property storage.

In general, to be compliant with RFC2518 you can't use an = XML-unfriendly
property storage. Whether attributes are in and out seems to be of = little
importance here.

[js] Again, XML friendly is not the same as XML exclusive.  I don't = think
forcing the hands of server developers to XML is a goal of the DAV = drafts
and should not added to the BIS.

I'm happy to discuss this as a new issue (for instance, are servers = allowed
to only persist the immediate child text nodes of a property element as = a
string?), but this is definitively a new requirement.

[js] I don't believe it is a new requirement.  I believe it is a = reasonable
option that allowed DAV server developers to add-value to their
implementations.  It certainly was not required, but it also was = not forbidden.

Note that both IIS and moddav (the most widely deployed WebDAV servers) = *do*
persist XML in property values, so we have proven interoperability in = this
point.

[js] Again, I will take this offline, but no.  You have interop = with implementations
that persist the XML values, they don't always persist random attributes = in the value
node.

Finally (as mentioned many times before), the best way to *precisely* = define
these things is to use the terminology from the XML Infoset spec, and = the
guidelines from section 2.4 (document subsets) of RFC3076.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- = tel:+492512807760

------_=_NextPart_001_01C297C7.9530CD0D-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Fri Nov 29 12:19:32 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03630 for ; Fri, 29 Nov 2002 12:19:32 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gATHLXx10753; Fri, 29 Nov 2002 12:21:33 -0500 (EST) Resent-Date: Fri, 29 Nov 2002 12:21:33 -0500 (EST) Resent-Message-Id: <200211291721.gATHLXx10753@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gATHLVA10727 for ; Fri, 29 Nov 2002 12:21:31 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA00437 for ; Fri, 29 Nov 2002 12:21:31 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id JAA15625 sender julian.reschke@gmx.de for w3c-dist-auth@w3c.org; Fri, 29 Nov 2002 09:21:30 -0800 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by sunbelt.seagull.net (8.9.3) with SMTP id JAA15618 sender julian.reschke@gmx.de for ; Fri, 29 Nov 2002 09:21:29 -0800 Received: (qmail 4541 invoked by uid 0); 29 Nov 2002 17:20:57 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp017-rz3) with SMTP; 29 Nov 2002 17:20:57 -0000 From: "Julian Reschke" To: "Joel Soderberg" , "Julian Reschke" Cc: "Webdav WG" Date: Fri, 29 Nov 2002 18:20:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Subject: RE: RFC2518 bis, attributes on property names -- in or out? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7071 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Joel Soderberg > Sent: Friday, November 29, 2002 5:52 PM > To: Julian Reschke > Cc: Webdav WG > Subject: RE: RFC2518 bis, attributes on property names -- in or out? > > > Couple more comments inline.... > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thu 11/28/2002 12:38 PM > To: Joel Soderberg > Cc: Webdav WG > Subject: RE: RFC2518 bis, attributes on property names -- > in or out? > > > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On > > Behalf Of Joel Soderberg > > Sent: Thursday, November 28, 2002 8:55 PM > > To: Jason Crawford; Julian Reschke > > Cc: Lisa Dusseault; Webdav WG > > Subject: RE: RFC2518 bis, attributes on property names -- in or out? > > > > > > Preserving namespaces is almost a given (I would be surprised > if that was > > not already being done by most implementations). However, I > don't believe > > If you're referring to namespaces of property names -- sure. A property is > identified by an XML name, and if an implementation looses half of it (the > namespace), it's simply broken. > > [js] Yes, but even more so, I am talking about any namespaces used in the > context of the proptery value. An implementation must be smart about this > such that any namespace defined above the property value scope is persisted > if it is used in the property value. There is nothing in the DAV drafts that > requires all namespaces used in a property value to be defined or redefined > at the property/value level. Correct. > > that the namespace aliasing must be preserved. When returning the value, > > different aliases may be used. > > Yes, for the property name itself. But not for any child elements contained > inside the property. And probably undecided for attributes on the property > element itself. > > [js] Why? This is an arbitrary requirement, no? Namespaces are not tied > to an alias outside of any document. I believe (although I may be wrong), that > the namespace documents even indicate tha the revelence of the alias outside > of the current document cannot be relied on. It should be perfectly allowable > for an implementation to persist the namespace/tag pairs instead of having to > persist the alias. I can think of at least three different DAV server > implementations that model behavior that way. Well, I would have agreed with this a few years ago. Since then, W3C recommendations have been published in which the alias itself has become significant as well (for instance, when using QNames in attribute values). So yes, to round-trip XML contents you need the aliases as well. > ... > > So you need to be able to persist XML anyway -- how does persisting > attributes on the property itself make things harder? > > [js] Needing to persist XML does not mean that everything is XML, true? True. > I can point you to a couple of DAV implementations that use the XML datatype > draft (that I think is long since forgotten) that honors a DT attribute and will > persist the value in that format. There is nothing in the drafts that prevent > this behavior, and nothing should be added that would suddenly make such > implementations non-compliant. I didn't intend to do that. Actually, our server does honor the XML Schema xsi:type attribute to do the same thing (see [1]). > > If the only reason for asking for persistance is for namespacing, there are It's not. > > other ways that information can be retained that does not tie the hands of > > the non-XML based property storage. Does it? The server needs to decide on a case-by-case basis anyway. If the property value contains for instance nested elements, in general you can't persist it non-XML. Having an "unexpected" attribute is just another case. > In general, to be compliant with RFC2518 you can't use an XML-unfriendly > property storage. Whether attributes are in and out seems to be of little > importance here. > > [js] Again, XML friendly is not the same as XML exclusive. I don't think > forcing the hands of server developers to XML is a goal of the DAV drafts > and should not added to the BIS. Again, nobody said that. If a server thinks that it can round-trip a property value internally using a non-XML format, it's free to do so. > I'm happy to discuss this as a new issue (for instance, are servers allowed > to only persist the immediate child text nodes of a property element as a > string?), but this is definitively a new requirement. > > [js] I don't believe it is a new requirement. I believe it is a reasonable > option that allowed DAV server developers to add-value to their > implementations. It certainly was not required, but it also was not > forbidden. It's *allowed* to choose an optimized internal representation. It's however *required* to be able to persist arbitrary XML. > Note that both IIS and moddav (the most widely deployed WebDAV servers) *do* > persist XML in property values, so we have proven interoperability in this > point. > > [js] Again, I will take this offline, but no. You have interop with implementations > that persist the XML values, they don't always persist random attributes in > the value node. I'll check, but anyway...: if they're able to do the one thing (nested element content), where's the problem doing the other thing as well? > ... [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760