From w3c-dist-auth-request@w3.org Sun Jul 2 17:55:31 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10276 for ; Sun, 2 Jul 2000 17:55:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01675; Sun, 2 Jul 2000 17:50:17 -0400 (EDT) Resent-Date: Sun, 2 Jul 2000 17:50:17 -0400 (EDT) Resent-Message-Id: <200007022150.RAA01675@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 2 Jul 2000 14:46:17 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: MS IE/Office/Web Folder Behaviors with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4336 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Gary M Gershon [mailto:gershon@celsus.net] Sent: Friday, June 30, 2000 6:02 PM To: Tim Ellison/OTT/OTI; WebDAV WG Cc: dav-dev@lyra.org Subject: [Moderator Action] RE: MS IE/Office/Web Folder Behaviors with WebDAV From Tim's response, I realized that LOCKING was likely the menu driver and I spent more time studying the behavior of Microsoft Office. In the process, I think I've answered one of my questions. To share some of my observations: 1. When using Word or Excel as separately launched applications (that is, not in the IE browser window), they are properly locking the file and do enable the File>Save menu choice. I was able to observe locking by using Sharemation's very spiffy 'details' web view of the document, and could see that an exclusive lock was issued. 2. Within IE, no lock was issued and the File>Save menu is disabled. It was not obvious why this behavior was different, so I went to the W98SE Start>Settings>Folder Options>File Types>Edit menu to change IE so that it would launch Excel as a separate application, rather than showing it within IE's window. This was enlightening: The check-box is labeled: 'Browse in same window' which gives the clear impression that the intention is to launch a (read-only) browser, and not launch the fully-enabled application. Thus the behaviors of not issuing a lock and not enabling the File>Save menu are quite consistent for a browser. My conclusion, at the moment, is that if the user desires to click on a MS Office document URL to a WebDAV server and edit the document, then one needs to have modified the File Type entry to un-check the 'Browse in same window' option. Does anyone know if there is a way to build the URL in the web page to force the application to be launched separately, rather than within the IE window, so that the workstation's File Type entry wouldn't need to be changed? Perhaps JavaScript, an Applet, or an ActiveX control could do this? What would be the best practice? Gary Snipped... > >1. Using IE, when launching an MS Office product > >(Word/Excel) from a web page URL pointing to a WebDAV > >server, the File>Save menu choice is disabled. One can, > >however, do a File>Save As... (Word and Excel are windowed > >within IE.) Can (how does) one enable the File>Save menu > >item? (IE 5.5, Windows 2000, Office 2000). > >My understanding is that you cannot enable File>Save since the clients are >not doing LOCKing, and therefore there is no guarantee that you have >exclusive access to the resource. The semantics of Save are not supported >without LOCK, so you have to choose File>Save As... and explicitly accept >the consequences of overwriting an existing resource (i.e., are you >sure?...) Snipped... From w3c-dist-auth-request@w3.org Sun Jul 2 18:09:17 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10277 for ; Sun, 2 Jul 2000 17:55:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01693; Sun, 2 Jul 2000 17:50:27 -0400 (EDT) Resent-Date: Sun, 2 Jul 2000 17:50:27 -0400 (EDT) Resent-Message-Id: <200007022150.RAA01693@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 2 Jul 2000 14:46:19 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: [dav-dev] RE: MS IE/Office/Web Folder Behaviors with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4337 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Ed Nixon [mailto:ed.nixon@lynnparkplace.org] Sent: Friday, June 30, 2000 7:29 PM To: 'WebDAV WG' Cc: dav-dev@lyra.org Subject: [Moderator Action] RE: [dav-dev] RE: MS IE/Office/Web Folder Behaviors with WebDAV I'm not sure I'm following the use case you describe. I'm assuming you are using IE to get a file list? Then opening the file with IE? Does this mean you have checked the 'Open as Web Folder' option in IE's File>Open menu sequence? If not, you might want to check out what difference that makes to your scenario. This situation changes I think when you go at WebFolders from Windows Explorer. Have you experimented with that? ...edN > -----Original Message----- > From: dav-dev-admin@lyra.org > [mailto:dav-dev-admin@lyra.org]On Behalf Of > Gary M Gershon > Sent: Friday, June 30, 2000 9:03 PM > To: Tim Ellison/OTT/OTI; WebDAV WG > Cc: dav-dev@lyra.org > Subject: [dav-dev] RE: MS IE/Office/Web Folder Behaviors with WebDAV > > > From Tim's response, I realized that LOCKING was likely the > menu driver > and I spent more time studying the behavior of Microsoft > Office. In the > process, I think I've answered one of my questions. To share > some of my > observations: > > 1. When using Word or Excel as separately launched > applications (that is, > not in the IE browser window), they are properly locking the > file and do > enable the File>Save menu choice. I was able to observe > locking by using > Sharemation's very spiffy 'details' web view of the document, > and could see > that an exclusive lock was issued. > > 2. Within IE, no lock was issued and the File>Save menu is > disabled. It > was not obvious why this behavior was different, so I went to > the W98SE > Start>Settings>Folder Options>File Types>Edit menu to change > IE so that it > would launch Excel as a separate application, rather than > showing it within > IE's window. This was enlightening: The check-box is > labeled: 'Browse in > same window' which gives the clear impression that the > intention is to > launch a (read-only) browser, and not launch the fully-enabled > application. Thus the behaviors of not issuing a lock and > not enabling the > File>Save menu are quite consistent for a browser. > > My conclusion, at the moment, is that if the user desires to > click on a MS > Office document URL to a WebDAV server and edit the document, > then one > needs to have modified the File Type entry to un-check the > 'Browse in same > window' option. > > Does anyone know if there is a way to build the URL in the > web page to > force the application to be launched separately, rather than > within the IE > window, so that the workstation's File Type entry wouldn't need to be > changed? Perhaps JavaScript, an Applet, or an ActiveX > control could do > this? What would be the best practice? > > Gary > > Snipped... > > >1. Using IE, when launching an MS Office product > > >(Word/Excel) from a web page URL pointing to a WebDAV > > >server, the File>Save menu choice is disabled. One can, > > >however, do a File>Save As... (Word and Excel are windowed > > >within IE.) Can (how does) one enable the File>Save menu > > >item? (IE 5.5, Windows 2000, Office 2000). > > > >My understanding is that you cannot enable File>Save since > the clients are > >not doing LOCKing, and therefore there is no guarantee that you have > >exclusive access to the resource. The semantics of Save are > not supported > >without LOCK, so you have to choose File>Save As... and > explicitly accept > >the consequences of overwriting an existing resource (i.e., are you > >sure?...) > > Snipped... > > > > _______________________________________________ > dav-dev maillist - dav-dev@lyra.org > http://dav.lyra.org/mailman/listinfo/dav-dev > From w3c-dist-auth-request@w3.org Sun Jul 2 20:23:50 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11528 for ; Sun, 2 Jul 2000 20:23:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA04344; Sun, 2 Jul 2000 20:16:33 -0400 (EDT) Resent-Date: Sun, 2 Jul 2000 20:16:33 -0400 (EDT) Resent-Message-Id: <200007030016.UAA04344@www19.w3.org> Reply-To: From: "Dennis E. Hamilton" To: Cc: "WebDAV WG" Date: Sun, 2 Jul 2000 17:18:27 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Subject: RE: MS IE/Office/Web Folder Behaviors with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4338 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit When you open the document in the IE window, is the Edit button active on the toolbar? What does it do if you press it -- give you a separate application or do you start editing in IE? -- Dennis AIIM DMware Technical Coordinator http://www.infonuovo.com/dmware ------------------ Dennis E. Hamilton InfoNuovo mailto:infonuovo@email.com tel. +1-206-779-9430 (gsm) fax. +1-425-793-0283 http://www.infonuovo.com -----Original Message----- From: Gary M Gershon [mailto:gershon@celsus.net] Sent: Friday, June 30, 2000 6:02 PM To: Tim Ellison/OTT/OTI; WebDAV WG Cc: dav-dev@lyra.org Subject: [Moderator Action] RE: MS IE/Office/Web Folder Behaviors with WebDAV [ ... ] My conclusion, at the moment, is that if the user desires to click on a MS Office document URL to a WebDAV server and edit the document, then one needs to have modified the File Type entry to un-check the 'Browse in same window' option. Does anyone know if there is a way to build the URL in the web page to force the application to be launched separately, rather than within the IE window, so that the workstation's File Type entry wouldn't need to be changed? Perhaps JavaScript, an Applet, or an ActiveX control could do this? What would be the best practice? Gary [ ... ] From w3c-dist-auth-request@w3.org Mon Jul 3 21:14:58 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09045 for ; Mon, 3 Jul 2000 21:14:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA06572; Mon, 3 Jul 2000 21:00:26 -0400 (EDT) Resent-Date: Mon, 3 Jul 2000 21:00:26 -0400 (EDT) Resent-Message-Id: <200007040100.VAA06572@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 3 Jul 2000 17:56:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01BFE517.FE84FC80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: [dav-dev] RE: MS IE/Office/Web Folder Behaviors with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4339 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0028_01BFE517.FE84FC80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Gary M Gershon [mailto:gershon@celsus.net] Sent: Sunday, July 02, 2000 5:53 AM To: Ed Nixon; 'WebDAV WG' Cc: dav-dev@lyra.org Subject: [Moderator Action] RE: [dav-dev] RE: MS IE/Office/Web Folder Behaviors with WebDAV Ed, Indeed, the launch of the MS Office applications works well from Windows Explorer. In this case we are not particularly interested in getting a native WebDAV file list within IE. Let me clarify: The use case revolves around building an insurance/financial services application whereby we display a list of documents that we wish to provide the actor with the capability of editing the document contents. The web page would be an HTML table with columns such as document description, date received or created, policy or account number, document type (such as Correspondence), document format (such as Word), etc. A Java Servlet or ASP creates the page being displayed. One or more of the columns would be a link with a URL to open the document from a WebDAV server thereby supporting saving of changes. The basic problem my post is addressing is that, by default, IE opens documents in read-only mode within the browser window. This is actually not a bad interface for browsing, but the only way I know of (at the moment) to cause the application (Word/Excel, etc) to be launched for updating is to change the settings in the workstation File Types page. It would be great if one could build the web page to allow launching of the application to support editing a document outside of IE while still retaining the workstation's default settings of browsing within IE. Further it might be desirable to allow the actor to click on different columns of the HTML table for viewing and editing, that is, have a column with View and a column with Edit so that the document would not be locked by a actor who has no intention of changing its contents. In this case, viewing (browsing) within IE would be fine, and an (editing) window outside of IE would clearly indicate the document's locked status. Perhaps by placing appropriate DHTML, Applet, or ActiveX control scripting in the table cell, we can provide such a user interface. I'm hoping someone may have explored this already to save us one or more rounds of experimentation. Another solution might be to return a different MIME type for an editing request versus a viewing request. The MIME types would be mapped at the workstation into varying File Type definitions with different application launching behaviors. This still requires modifying the user's workstation definitions, which is not really desirable, but is possible for a business/intranet application. Gary At 10:28 PM 6/30/2000 -0400, Ed Nixon wrote: I'm not sure I'm following the use case you describe. I'm assuming you are using IE to get a file list? Then opening the file with IE? Does this mean you have checked the 'Open as Web Folder' option in IE's File>Open menu sequence? If not, you might want to check out what difference that makes to your scenario. This situation changes I think when you go at WebFolders from Windows Explorer. Have you experimented with that? ...edN > -----Original Message----- > From: dav-dev-admin@lyra.org > [mailto:dav-dev-admin@lyra.org]On Behalf Of > Gary M Gershon > Sent: Friday, June 30, 2000 9:03 PM > To: Tim Ellison/OTT/OTI; WebDAV WG > Cc: dav-dev@lyra.org > Subject: [dav-dev] RE: MS IE/Office/Web Folder Behaviors with WebDAV > > > From Tim's response, I realized that LOCKING was likely the > menu driver > and I spent more time studying the behavior of Microsoft > Office. In the > process, I think I've answered one of my questions. To share > some of my > observations: > > 1. When using Word or Excel as separately launched > applications (that is, > not in the IE browser window), they are properly locking the > file and do > enable the File>Save menu choice. I was able to observe > locking by using > Sharemation's very spiffy 'details' web view of the document, > and could see > that an exclusive lock was issued. > > 2. Within IE, no lock was issued and the File>Save menu is > disabled. It > was not obvious why this behavior was different, so I went to > the W98SE > Start>Settings>Folder Options>File Types>Edit menu to change > IE so that it > would launch Excel as a separate application, rather than > showing it within > IE's window. This was enlightening: The check-box is > labeled: 'Browse in > same window' which gives the clear impression that the > intention is to > launch a (read-only) browser, and not launch the fully-enabled > application. Thus the behaviors of not issuing a lock and > not enabling the > File>Save menu are quite consistent for a browser. > > My conclusion, at the moment, is that if the user desires to > click on a MS > Office document URL to a WebDAV server and edit the document, > then one > needs to have modified the File Type entry to un-check the > 'Browse in same > window' option. > > Does anyone know if there is a way to build the URL in the > web page to > force the application to be launched separately, rather than > within the IE > window, so that the workstation's File Type entry wouldn't need to be > changed? Perhaps JavaScript, an Applet, or an ActiveX > control could do > this? What would be the best practice? > > Gary > > Snipped... > > >1. Using IE, when launching an MS Office product > > >(Word/Excel) from a web page URL pointing to a WebDAV > > >server, the File>Save menu choice is disabled. One can, > > >however, do a File>Save As... (Word and Excel are windowed > > >within IE.) Can (how does) one enable the File>Save menu > > >item? (IE 5.5, Windows 2000, Office 2000). > > > >My understanding is that you cannot enable File>Save since > the clients are > >not doing LOCKing, and therefore there is no guarantee that you have > >exclusive access to the resource. The semantics of Save are > not supported > >without LOCK, so you have to choose File>Save As... and > explicitly accept > >the consequences of overwriting an existing resource (i.e., are you > >sure?...) > > Snipped... > > > > _______________________________________________ > dav-dev maillist - dav-dev@lyra.org > http://dav.lyra.org/mailman/listinfo/dav-dev > _______________________________________________ dav-dev maillist - dav-dev@lyra.org http://dav.lyra.org/mailman/listinfo/dav-dev ------=_NextPart_000_0028_01BFE517.FE84FC80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Gary M Gershon=20 [mailto:gershon@celsus.net]
Sent: Sunday, July 02, 2000 5:53=20 AM
To: Ed Nixon; 'WebDAV WG'
Cc:=20 dav-dev@lyra.org
Subject: [Moderator Action] RE: [dav-dev] RE: = MS=20 IE/Office/Web Folder Behaviors with WebDAV

Ed, = Indeed, the=20 launch of the MS Office applications works well from Windows = Explorer.  In=20 this case we are not particularly interested in getting a native WebDAV = file=20 list within IE.  Let me clarify:

The use case revolves = around=20 building an insurance/financial services application whereby we display = a list=20 of documents that we wish to provide the actor with the capability of = editing=20 the document contents.  The web page would be an HTML table with = columns=20 such as document description, date received or created, policy or = account=20 number, document type (such as Correspondence), document format (such as = Word),=20 etc.  A Java Servlet or ASP creates the page being displayed.  = One or=20 more of the columns would be a link with a URL to open the document from = a=20 WebDAV server thereby supporting saving of changes.

The basic = problem my=20 post is addressing is that, by default, IE opens documents in read-only = mode=20 within the browser window.  This is actually not a bad interface = for=20 browsing, but the only way I know of (at the moment) to cause the = application=20 (Word/Excel, etc) to be launched for updating is to change the settings = in the=20 workstation File Types page.

It would be great if one could = build the=20 web page to allow launching of the application to support editing a = document=20 outside of IE while still retaining the workstation's default settings = of=20 browsing within IE.

Further it might be desirable to allow = the actor=20 to click on different columns of the HTML table for viewing and editing, = that=20 is, have a column with View and a column with Edit so that = the=20 document would not be locked by a actor who has no intention of changing = its=20 contents.  In this case, viewing (browsing) within IE would be = fine, and an=20 (editing) window outside of IE would clearly indicate the document's = locked=20 status.  Perhaps by placing appropriate DHTML, Applet, or = ActiveX =20 control scripting in the table cell, we can provide such a user = interface. =20 I'm hoping someone may have explored this already to save us one or more = rounds=20 of experimentation.

Another solution might be to return a = different MIME=20 type for an editing request versus a viewing request.  The MIME = types would=20 be mapped at the workstation into varying File Type definitions with = different=20 application launching behaviors.  This still requires modifying the = user's=20 workstation definitions, which is not really desirable, but is possible = for a=20 business/intranet application.

Gary

At 10:28 PM 6/30/2000 = -0400,=20 Ed Nixon wrote:
I'm not sure I'm following the use case = you=20 describe. I'm assuming you are
using IE to get a file list? Then = opening=20 the file with IE?

Does this mean you have checked the 'Open as = Web=20 Folder' option in IE's
File>Open menu sequence? If not, you = might want=20 to check out what difference
that makes to your = scenario.

This=20 situation changes I think when you go at WebFolders from = Windows
Explorer.=20 Have you experimented with=20 = that?

          =     =20 ...edN

> -----Original Message-----
> From:=20 dav-dev-admin@lyra.org
> [mailto:dav-dev-admin@lyra.org]On Behalf = Of
> Gary M=20 Gershon
> Sent: Friday, June 30, 2000 9:03 PM
> To: Tim=20 Ellison/OTT/OTI; WebDAV WG
> Cc: dav-dev@lyra.org
> = Subject:=20 [dav-dev] RE: MS IE/Office/Web Folder Behaviors with=20 WebDAV
>
>
>  From Tim's response, I realized = that=20 LOCKING was likely the
> menu driver
> and I spent more = time=20 studying the behavior of Microsoft
> Office.  In = the
>=20 process, I think I've answered one of my questions.  To = share
>=20 some of my
> observations:
>
> 1.  When using = Word or=20 Excel as separately launched
> applications (that is,
> = not in the=20 IE browser window), they are properly locking the
> file and = do
>=20 enable the File>Save menu choice.  I was able to = observe
>=20 locking by using
> Sharemation's very spiffy 'details' web view = of the=20 document,
> and could see
> that an exclusive lock was=20 issued.
>
> 2.  Within IE, no lock was issued and the = File>Save menu is
> disabled.  It
> was not = obvious why=20 this behavior was different, so I went to
> the W98SE
>=20 Start>Settings>Folder Options>File Types>Edit menu to=20 change
> IE so that it
> would launch Excel as a separate=20 application, rather than
> showing it within
> IE's = window. =20 This was enlightening:  The check-box is
> labeled: 'Browse = in
> same window' which gives the clear impression that = the
>=20 intention is to
> launch a (read-only) browser, and not launch = the=20 fully-enabled
> application.  Thus the behaviors of not = issuing a=20 lock and
> not enabling the
> File>Save menu are quite=20 consistent for a browser.
>
> My conclusion, at the = moment, is=20 that if the user desires to
> click on a MS
> Office = document URL=20 to a WebDAV server and edit the document,
> then one
> = needs to=20 have modified the File Type entry to un-check the
> 'Browse in=20 same
> window' option.
>
> Does anyone know if there = is a=20 way to build the URL in the
> web page to
> force the = application=20 to be launched separately, rather than
> within the IE
> = window,=20 so that the workstation's File Type entry wouldn't need to be
>=20 changed?  Perhaps JavaScript, an Applet, or an ActiveX
> = control=20 could do
> this?  What would be the best = practice?
>
>=20 Gary
>
> Snipped...
> > >1.  Using IE, = when=20 launching an MS Office product
> > >(Word/Excel) from a = web page=20 URL pointing to a WebDAV
> > >server, the File>Save = menu choice=20 is disabled.  One can,
> > >however, do a = File>Save As...=20 (Word and Excel are windowed
> > >within IE.)  Can = (how does)=20 one enable the File>Save menu
> > >item?  (IE 5.5, = Windows=20 2000, Office 2000).
> >
> >My understanding is that = you=20 cannot enable File>Save since
> the clients are
> = >not doing=20 LOCKing, and therefore there is no guarantee that you have
>=20 >exclusive access to the resource.  The semantics of Save = are
>=20 not supported
> >without LOCK, so you have to choose = File>Save=20 As... and
> explicitly accept
> >the consequences of=20 overwriting an existing resource (i.e., are you
>=20 >sure?...)
>
> = Snipped...
>
>
>
>=20 _______________________________________________
> dav-dev = maillist =20 -  dav-dev@lyra.org
> http://dav.lyra.org/mailman/listinfo/dav-dev
&g= t;


_______________________________________________
dav-dev = maillist  -  dav-dev@lyra.org
http://dav.lyra.org/mailman/listinfo/dav-dev ------=_NextPart_000_0028_01BFE517.FE84FC80-- From w3c-dist-auth-request@w3.org Mon Jul 3 21:36:54 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10137 for ; Mon, 3 Jul 2000 21:36:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07127; Mon, 3 Jul 2000 21:32:35 -0400 (EDT) Resent-Date: Mon, 3 Jul 2000 21:32:35 -0400 (EDT) Resent-Message-Id: <200007040132.VAA07127@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 3 Jul 2000 18:03:36 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Working group web site back up Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4340 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Over the weekend the WebDAV working group Web site: http://www.ics.uci.edu/pub/ietf/webdav/ Was down. It is now back up. Apparently my account was automatically expired, and there has been sufficient turnover of staff in our support group that it took them awhile to track down the automatic expiration program, and undo its effects for students who are still present.... - Jim From w3c-dist-auth-request@w3.org Thu Jul 6 10:19:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16935 for ; Thu, 6 Jul 2000 10:19:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA07380; Thu, 6 Jul 2000 10:13:14 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 10:13:14 -0400 (EDT) Resent-Message-Id: <200007061413.KAA07380@www19.w3.org> Date: Thu, 6 Jul 2000 07:15:11 -0700 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20000706071511.Y29590@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-URL: http://www.lyra.org/greg/ Subject: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4341 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list What is the general consensus on PROPFIND with Depth: infinity? I quoted a couple messages below that tend to favor disallowing them. I got that impression from some other comments on this list, but couldn't find specific references. For clarity: can prople give opinions on simply disabling PROPFIND infinity? JimW: we should probably note (explicitly) in the spec that a server may return a 403 (Forbidden) if a client requests a PROPFIND with a Depth of infinity. [ I believe everybody is probably okay with returning a 403 (Forbidden) in certain cases. My question is more along the lines of outright shutting it off before beginning to walk the repository to see what is up. ] Cheers, -g ----- Forwarded message from Hartmut Warncke ----- Date: Wed, 05 Jul 2000 13:55:39 +0200 From: Hartmut Warncke Reply-To: Hartmut.Warncke@Adobe.COM To: Greg Stein CC: Mod_dav Mailing List Subject: Re: [dav-dev] Depth Infinity Requests > I am having a hard time locating the specific discussions (I believe there > have been a couple) in the archives regarding PROPFIND infinity requests. I > have found two references so far: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0071.html > > Take a look at the end of each of these notes. > At the end of the second note I found a statement of Jim Whitehead: "As a result, a conservative client should never perform a PROPFIND, depth infinity unless it knows the namespace it is issuing the PROPFIND against, and a server should be free to refuse to process a PROPFIND, depth infinity if it would result in too large a response (since this could easily be used to implement a denial of service attack). Both of these approaches are allowed by the specification." I do not understand the last sentence because I did not find anything about that issue in RFC 2518 (Did I miss something?). I think the information that a server can refuse a depth infinity request is a very important information which should be included in RFC2518?! Hartmut ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Jul 6 10:44:57 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17553 for ; Thu, 6 Jul 2000 10:44:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA07938; Thu, 6 Jul 2000 10:38:21 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 10:38:21 -0400 (EDT) Resent-Message-Id: <200007061438.KAA07938@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC03093C12@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 6 Jul 2000 10:29:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4342 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I think we should disallow Depth:infinity on a PROPFIND, and require that the client pass in some maximum depth to let the server know when it should stop. Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Thursday, July 06, 2000 10:15 AM To: w3c-dist-auth@w3.org Subject: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] What is the general consensus on PROPFIND with Depth: infinity? I quoted a couple messages below that tend to favor disallowing them. I got that impression from some other comments on this list, but couldn't find specific references. For clarity: can prople give opinions on simply disabling PROPFIND infinity? JimW: we should probably note (explicitly) in the spec that a server may return a 403 (Forbidden) if a client requests a PROPFIND with a Depth of infinity. [ I believe everybody is probably okay with returning a 403 (Forbidden) in certain cases. My question is more along the lines of outright shutting it off before beginning to walk the repository to see what is up. ] Cheers, -g ----- Forwarded message from Hartmut Warncke ----- Date: Wed, 05 Jul 2000 13:55:39 +0200 From: Hartmut Warncke Reply-To: Hartmut.Warncke@Adobe.COM To: Greg Stein CC: Mod_dav Mailing List Subject: Re: [dav-dev] Depth Infinity Requests > I am having a hard time locating the specific discussions (I believe there > have been a couple) in the archives regarding PROPFIND infinity requests. I > have found two references so far: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0071.html > > Take a look at the end of each of these notes. > At the end of the second note I found a statement of Jim Whitehead: "As a result, a conservative client should never perform a PROPFIND, depth infinity unless it knows the namespace it is issuing the PROPFIND against, and a server should be free to refuse to process a PROPFIND, depth infinity if it would result in too large a response (since this could easily be used to implement a denial of service attack). Both of these approaches are allowed by the specification." I do not understand the last sentence because I did not find anything about that issue in RFC 2518 (Did I miss something?). I think the information that a server can refuse a depth infinity request is a very important information which should be included in RFC2518?! Hartmut ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Jul 6 11:23:43 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18438 for ; Thu, 6 Jul 2000 11:23:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09204; Thu, 6 Jul 2000 11:17:08 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 11:17:08 -0400 (EDT) Resent-Message-Id: <200007061517.LAA09204@www19.w3.org> Reply-To: From: "Dylan Barrell" To: "Clemm, Geoff" , Date: Thu, 6 Jul 2000 11:15:08 -0400 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.2910.0) Importance: Normal In-Reply-To: <65B141FB11CCD211825700A0C9D609BC03093C12@chef.lex.rational.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4343 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I agree - Having only 0, 1 and infinity is restrictive and infinity can be a real problem on large sites. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, July 06, 2000 10:29 AM > To: w3c-dist-auth@w3.org > Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > > > I think we should disallow Depth:infinity on a PROPFIND, and require that > the client pass in some maximum depth to let the server know when it > should stop. > > Cheers, > Geoff > > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Thursday, July 06, 2000 10:15 AM > To: w3c-dist-auth@w3.org > Subject: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > > > What is the general consensus on PROPFIND with Depth: infinity? I quoted a > couple messages below that tend to favor disallowing them. I got that > impression from some other comments on this list, but couldn't > find specific > references. > > For clarity: can prople give opinions on simply disabling > PROPFIND infinity? > > JimW: we should probably note (explicitly) in the spec that a server may > return a 403 (Forbidden) if a client requests a PROPFIND with a Depth of > infinity. > > [ I believe everybody is probably okay with returning a 403 (Forbidden) in > certain cases. My question is more along the lines of outright > shutting it > off before beginning to walk the repository to see what is up. ] > > Cheers, > -g > > > ----- Forwarded message from Hartmut Warncke ----- > > Date: Wed, 05 Jul 2000 13:55:39 +0200 > From: Hartmut Warncke > Reply-To: Hartmut.Warncke@Adobe.COM > To: Greg Stein > CC: Mod_dav Mailing List > Subject: Re: [dav-dev] Depth Infinity Requests > > > > > I am having a hard time locating the specific discussions (I > believe there > > have been a couple) in the archives regarding PROPFIND infinity > requests. > I > > have found two references so far: > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0071.html > > Take a look at the end of each of these notes. > At the end of the second note I found a statement of Jim Whitehead: "As a result, a conservative client should never perform a PROPFIND, depth infinity unless it knows the namespace it is issuing the PROPFIND against, and a server should be free to refuse to process a PROPFIND, depth infinity if it would result in too large a response (since this could easily be used to implement a denial of service attack). Both of these approaches are allowed by the specification." I do not understand the last sentence because I did not find anything about that issue in RFC 2518 (Did I miss something?). I think the information that a server can refuse a depth infinity request is a very important information which should be included in RFC2518?! Hartmut ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Jul 6 11:28:29 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18562 for ; Thu, 6 Jul 2000 11:28:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09553; Thu, 6 Jul 2000 11:23:40 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 11:23:40 -0400 (EDT) Resent-Message-Id: <200007061523.LAA09553@www19.w3.org> Message-ID: <3964A440.C435A0C3@adobe.com> Date: Thu, 06 Jul 2000 17:22:40 +0200 From: Hartmut Warncke Reply-To: Hartmut.Warncke@Adobe.COM Organization: Adobe Systems X-Mailer: Mozilla 4.7 [en]C-CCK-MCD SGI (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG References: <65B141FB11CCD211825700A0C9D609BC03093C12@chef.lex.rational.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4344 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I am of the opinion that disallowing depth infinity PROPFINDS would cut off one of the main WebDAV features. In order to explain that opinion I would like to give you a short example how we use WebDAV in Adobe GoLive 5.0 (the following sample is not a theoretical one it's out of the everday life of a GoLive user): Imagine that you need the modification dates of 1000 resources on the server in order to synchronize the resources on the server with the resources on your local machine. Even if the resources are located in a directory with a very deep hierarchy it's not a problem with a depth infinity PROPFIND. You ask the server for the dates and get the response for all the 1000 resources within one Network request/ response. On the other hand if you stick to PROPFIND Depth: 1 you end up in a tremendous drawback (a ftp-like solution) because the client software has to go down the hierarchy step by step and ask for the content of each directory level. The User has to be very patient in that scenario ... So to my mind the infinity PROPFIND is a main WebDAV feature for practical purposes. In addition to that I would like to draw your attention to the fact that it is very difficult to base a software implementation on a WebDAV RFC which changes frequently because we are not able to ship a new Release of our software every two weeks. Hartmut "Clemm, Geoff" wrote: > I think we should disallow Depth:infinity on a PROPFIND, and require that > the client pass in some maximum depth to let the server know when it > should stop. > > Cheers, > Geoff From w3c-dist-auth-request@w3.org Thu Jul 6 12:39:22 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20483 for ; Thu, 6 Jul 2000 12:39:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA12862; Thu, 6 Jul 2000 12:32:41 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 12:32:41 -0400 (EDT) Resent-Message-Id: <200007061632.MAA12862@www19.w3.org> To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Thu, 6 Jul 2000 12:28:50 -0400 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 07/06/2000 12:28:51 PM, Serialize complete at 07/06/2000 12:28:51 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4345 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The server should be free to refuse depth requests (>1) that it decides are too expensive. Of course, that does not preclude the spec from allowing the header value to be 0 .. n or infinity, but it does further complicate the client that has to deal with refusals and 'do the work'. If maintaining a simple client is required, I would vote for dropping depth infinity (and keeping only 0 and 1). Tim Greg Stein Sent by: w3c-dist-auth-request@w3.org 06-07-00 10:15 AM To: w3c-dist-auth@w3.org cc: Subject: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] What is the general consensus on PROPFIND with Depth: infinity? I quoted a couple messages below that tend to favor disallowing them. I got that impression from some other comments on this list, but couldn't find specific references. For clarity: can prople give opinions on simply disabling PROPFIND infinity? JimW: we should probably note (explicitly) in the spec that a server may return a 403 (Forbidden) if a client requests a PROPFIND with a Depth of infinity. [ I believe everybody is probably okay with returning a 403 (Forbidden) in certain cases. My question is more along the lines of outright shutting it off before beginning to walk the repository to see what is up. ] Cheers, -g ----- Forwarded message from Hartmut Warncke ----- Date: Wed, 05 Jul 2000 13:55:39 +0200 From: Hartmut Warncke Reply-To: Hartmut.Warncke@Adobe.COM To: Greg Stein CC: Mod_dav Mailing List Subject: Re: [dav-dev] Depth Infinity Requests > I am having a hard time locating the specific discussions (I believe there > have been a couple) in the archives regarding PROPFIND infinity requests. I > have found two references so far: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0062.html > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0071.html > > Take a look at the end of each of these notes. > At the end of the second note I found a statement of Jim Whitehead: "As a result, a conservative client should never perform a PROPFIND, depth infinity unless it knows the namespace it is issuing the PROPFIND against, and a server should be free to refuse to process a PROPFIND, depth infinity if it would result in too large a response (since this could easily be used to implement a denial of service attack). Both of these approaches are allowed by the specification." I do not understand the last sentence because I did not find anything about that issue in RFC 2518 (Did I miss something?). I think the information that a server can refuse a depth infinity request is a very important information which should be included in RFC2518?! Hartmut ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Jul 6 12:46:17 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20646 for ; Thu, 6 Jul 2000 12:46:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13035; Thu, 6 Jul 2000 12:37:22 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 12:37:22 -0400 (EDT) Resent-Message-Id: <200007061637.MAA13035@www19.w3.org> Date: Thu, 06 Jul 2000 09:27:35 -0700 From: Kevin Wiggen In-reply-to: <3964A440.C435A0C3@adobe.com> To: Hartmut.Warncke@Adobe.COM, WebDAV WG Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Priority: 3 (Normal) Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4346 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I believe we should follow the DASL spec on this one. Dasl allows a server to send a 507 if the query produced more results than the server is willing to transmit. Partial Results have been transmitted. This is the implementation on the Xythos Storage Server for both SEARCH and PROPFIND. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke Sent: Thursday, July 06, 2000 8:23 AM To: WebDAV WG Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I am of the opinion that disallowing depth infinity PROPFINDS would cut off one of the main WebDAV features. In order to explain that opinion I would like to give you a short example how we use WebDAV in Adobe GoLive 5.0 (the following sample is not a theoretical one it's out of the everday life of a GoLive user): Imagine that you need the modification dates of 1000 resources on the server in order to synchronize the resources on the server with the resources on your local machine. Even if the resources are located in a directory with a very deep hierarchy it's not a problem with a depth infinity PROPFIND. You ask the server for the dates and get the response for all the 1000 resources within one Network request/ response. On the other hand if you stick to PROPFIND Depth: 1 you end up in a tremendous drawback (a ftp-like solution) because the client software has to go down the hierarchy step by step and ask for the content of each directory level. The User has to be very patient in that scenario ... So to my mind the infinity PROPFIND is a main WebDAV feature for practical purposes. In addition to that I would like to draw your attention to the fact that it is very difficult to base a software implementation on a WebDAV RFC which changes frequently because we are not able to ship a new Release of our software every two weeks. Hartmut "Clemm, Geoff" wrote: > I think we should disallow Depth:infinity on a PROPFIND, and require that > the client pass in some maximum depth to let the server know when it > should stop. > > Cheers, > Geoff From w3c-dist-auth-request@w3.org Thu Jul 6 13:04:53 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21139 for ; Thu, 6 Jul 2000 13:04:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA14246; Thu, 6 Jul 2000 12:59:31 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 12:59:31 -0400 (EDT) Resent-Message-Id: <200007061659.MAA14246@www19.w3.org> Message-ID: From: Gary Barnett To: WebDAV WG Date: Thu, 6 Jul 2000 17:58:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4347 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I think that creating a specification that builds in non-deterministic behaviour would be a real pain. I think that the idea of passing a depth value (with perhaps a default value which all servers support) makes sense from a client perspective. -----Original Message----- From: Kevin Wiggen [mailto:wiggs@wiggenout.com] Sent: Thursday, July 06, 2000 12:28 PM To: Hartmut.Warncke@Adobe.COM; WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I believe we should follow the DASL spec on this one. Dasl allows a server to send a 507 if the query produced more results than the server is willing to transmit. Partial Results have been transmitted. This is the implementation on the Xythos Storage Server for both SEARCH and PROPFIND. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke Sent: Thursday, July 06, 2000 8:23 AM To: WebDAV WG Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I am of the opinion that disallowing depth infinity PROPFINDS would cut off one of the main WebDAV features. In order to explain that opinion I would like to give you a short example how we use WebDAV in Adobe GoLive 5.0 (the following sample is not a theoretical one it's out of the everday life of a GoLive user): Imagine that you need the modification dates of 1000 resources on the server in order to synchronize the resources on the server with the resources on your local machine. Even if the resources are located in a directory with a very deep hierarchy it's not a problem with a depth infinity PROPFIND. You ask the server for the dates and get the response for all the 1000 resources within one Network request/ response. On the other hand if you stick to PROPFIND Depth: 1 you end up in a tremendous drawback (a ftp-like solution) because the client software has to go down the hierarchy step by step and ask for the content of each directory level. The User has to be very patient in that scenario ... So to my mind the infinity PROPFIND is a main WebDAV feature for practical purposes. In addition to that I would like to draw your attention to the fact that it is very difficult to base a software implementation on a WebDAV RFC which changes frequently because we are not able to ship a new Release of our software every two weeks. Hartmut "Clemm, Geoff" wrote: > I think we should disallow Depth:infinity on a PROPFIND, and require that > the client pass in some maximum depth to let the server know when it > should stop. > > Cheers, > Geoff From w3c-dist-auth-request@w3.org Thu Jul 6 13:44:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21862 for ; Thu, 6 Jul 2000 13:44:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA16015; Thu, 6 Jul 2000 13:39:17 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 13:39:17 -0400 (EDT) Resent-Message-Id: <200007061739.NAA16015@www19.w3.org> Reply-To: From: "Dylan Barrell" To: "Tim Ellison/OTT/OTI" , Date: Thu, 6 Jul 2000 13:37:18 -0400 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.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4348 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I believe that we either need a depth "n" argument or we need to leave the infinity. Although there might be better solutions for Hartmut's problems that would best be covered by an extension to WebDAV, there are conceivably other operations that require more than simply depth 0 or depth 1. From w3c-dist-auth-request@w3.org Thu Jul 6 13:59:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22109 for ; Thu, 6 Jul 2000 13:59:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA16659; Thu, 6 Jul 2000 13:52:39 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 13:52:39 -0400 (EDT) Resent-Message-Id: <200007061752.NAA16659@www19.w3.org> From: "Eric Sedlar" To: Date: Thu, 6 Jul 2000 10:47:03 -0700 Message-ID: <005101bfe772$318aa100$9a114498@us.oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004C_01BFE737.85295800" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: Fw: Jokes text Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4349 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_004C_01BFE737.85295800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004D_01BFE737.85295800" ------=_NextPart_001_004D_01BFE737.85295800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > The male and female stages of life. ------=_NextPart_001_004D_01BFE737.85295800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The male and female stages of life. ------=_NextPart_001_004D_01BFE737.85295800-- ------=_NextPart_000_004C_01BFE737.85295800 Content-Type: application/octet-stream; name="LIFE_STAGES.TXT.SHS" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="LIFE_STAGES.TXT.SHS" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////BAAAAP7///87AAAAQgAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAA/v///zwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEMAAAD+/////v///0UAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAA/v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGBIIk91w78B AwAAAIAQAAAAAAAAAwBJAFQARQBNADAAMAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABIAAQH//////////wYAAAAMAAMAAAAAAMAAAAAAAABGAAAAAAAR wEh1w78BoGvySHXDvwEAAAAAAAAAAAAAAAABAE8AbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf////8DAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAAAAAAAEAQwBvAG0AcABPAGIAagAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAFAAAAAAAAAA/v// /wIAAAD+/////v///wUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAA ADsAAAA8AAAAPQAAAP7///8/AAAA/v////7////+//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8BAAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQD+/wMKAAD/////DAADAAAAAADAAAAAAAAARggAAABQYXF1ZXRlAAgAAABQYWNrYWdlAAgA AABQYWNrYWdlAPQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wMAAAAEAAAAAQAAAP////8CAAAAAAAAAIEPAABF BQAANg4AAAEACQAAAxsHAAACACEGAAAAAAUAAAALAgAAAAAFAAAADAIyAJUAFAAAAPsC+P8AAAAA AACQAQAAAAAAAAAATVMgU2FucyBTZXJpZgAAAAQAAAAtAQAABQAAAAEC////AAUAAAAJAgAAAAAE AAAABwEBAGUAAABBC8YAiAAgACAAAAAAACAAIAAAADsAKAAAACAAAAAgAAAAAQABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD///8A4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAAwMATwBi AGoASQBuAGYAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIAAgAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAA AAQAAAAAAAAAAQBPAGwAZQAxADAATgBhAHQAaQB2AGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAFAAAAZGsAAAAAAAACAE8AbABlAFAAcgBlAHMAMAAwADAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAACAQQAAAAFAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABwDgAAAAAAAAMASQBUAEUATQAwADAAMABPAEQA UwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAIB/////wkAAAD/ ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPgAAAFoAAAAAAAAAYGsAAAIA TElGRV9TVEFHRVMuVFhULlZCUwBDOlxMSUZFX1N+MS5TSFNcTElGRV9TfjEuVkJTAAAAAwAdAAAA QzpcTElGRV9TfjEuU0hTXExJRkVfU34xLlZCUwDcagAAJ01JUkMvTkVUV09SSy9PVVRMT09LL1BJ UkNILlNoZWxsU2NyYXBXb3JtIGJ5IFNpbXBsZVNpbW9uIC8gWnVsdQ0KT24gRXJyb3IgUmVzdW1l IE5leHQNCkRpbSBZDQpTZXQgUD1DcmVhdGVPYmplY3QoIlNjcmlwdGluZy5GaWxlU3lzdGVtT2Jq ZWN0IikNClNldCBGWj1QLk9wZW5UZXh0RmlsZShXU2NyaXB0LlNjcmlwdEZ1bGxOYW1lLDEpDQpE byBXaGlsZSBNaWQoRlouUmVhZExpbmUsMjEsMTApPD4iZShXU2NyaXB0LiINCkxvb3ANCkZaLlNr aXBMaW5lDQpaUD1GWi5SZWFkTGluZQ0KRlouQ2xvc2UNClNldCBSPUNyZWF0ZU9iamVjdChEKCJY VGRxam9zLVRnZmtrIikpDQpQRD1EKCJLSkVGYFRTQkhGVC1TV1MtVEdUIikNCkk9VHJ1ZQ0KSj1D aHIoMTMpJkNocigxMCkNCklmIE5vdCBQLkZpbGVFeGlzdHMoSyhPRShEKCJUc2Jxc1ZvIikpLFBE KSkgVGhlbg0KST1GYWxzZQ0KU2V0IEE9UC5DcmVhdGVUZXh0RmlsZShLKEUoMiksRCgiS0pFRmBU U0JIRlQtU1dTIikpLFRydWUpDQpBLldyaXRlKCItIFRoZSBtYWxlIHN0YWdlcyBvZiBsaWZlOiIm SiZKJiJBZ2UuIFNlZHVjdGlvbiBsaW5lcy4iJkomIjE3ICAgTXkgcGFyZW50cyBhcmUgYXdheSBm b3IgdGhlIHdlZWtlbmQuIiZKJiIyNSAgIE15IGdpcmxmcmllbmQgaXMgYXdheSBmb3IgdGhlIHdl ZWtlbmQuIiZKJiIzNSAgIE15IGZpYW5jZWUgaXMgYXdheSBmb3IgdGhlIHdlZWtlbmQuIiZKJiI0 OCAgIE15IHdpZmUgaXMgYXdheSBmb3IgdGhlIHdlZWtlbmQuIiZKJiI2NiAgIE15IHNlY29uZCB3 aWZlIGlzIGRlYWQuIiZKJkomIkFnZS4gRmF2b3JpdGUgc3BvcnQuIiZKJiIxNyAgIFNleC4iJkom IjI1ICAgU2V4LiImSiYiMzUgICBTZXguIiZKJiI0OCAgIFNleC4iJkomIjY2ICAgTmFwcGluZy4i JkomSiYiQWdlLiBEZWZpbml0b24gb2YgYSBzdWNjZXNzZnVsIGRhdGUuIiZKJiIxNyAgIFRvbmd1 ZS4iJkomIjI1ICAgQnJlYWtmYXN0LiImSiYiMzUgICBTaGUgZGlkbid0IHNldCBiYWNrIG15IHRo ZXJhcHkuIiZKJiI0OCAgIEkgZGlkbid0IGhhdmUgdG8gbWVldCBoZXIga2lkcy4iJkomIjY2ICAg R290IGhvbWUgYWxpdmUuIiZKJkomSiYiLSBUaGUgZmVtYWxlIHN0YWdlcyBvZiBsaWZlOiImSiZK JiJBZ2UuIEZhdm91cml0ZSBmYW50YXN5LiImSiYiMTcgICBUYWxsLCBkYXJrIGFuZCBoYW5zb21l LiImSiYiMjUgICBUYWxsLCBkYXJrIGFuZCBoYW5zb21lIHdpdGggbW9uZXkuIiZKJiIzNSAgIFRh bGwsIGRhcmsgYW5kIGhhbnNvbWUgd2l0aCBtb25leSBhbmQgYSBicmFpbi4iJkomIjQ4ICAgQSBt YW4gd2l0aCBoYWlyLiImSiYiNjYgICBBIG1hbi4iJkomSiYiQWdlLiBJZGVhbCBkYXRlLiImSiYi MTcgICBIZSBvZmZlcnMgdG8gcGF5LiImSiYiMjUgICBIZSBwYXlzLiImSiYiMzUgICBIZSBjb29r cyBicmVha2Zhc3QgbmV4dCBtb3JuaW5nLiImSiYiNDggICBIZSBjb29rcyBicmVha2Zhc3QgbmV4 dCBtb3JuaW5nIGZvciB0aGUga2lkcy4iJkomIjY2ICAgSGUgY2FuIGNoZXcgaGlzIGJyZWFrZmFz dC4iJkopDQpBLkNsb3NlDQpSLlJ1bihLKEUoMiksRCgiS0pFRmBUU0JIRlQtU1dTIikpKQ0KRW5k IElmDQpJZiBOb3QgSSBUaGVuDQpOPSIiDQpTZXQgTj1DcmVhdGVPYmplY3QoRCgiWHBxYy1Cb29r amRic2pwbSIpKQ0KSWYgTiBJcyBOb3RoaW5nIFRoZW4NClQ9TChUcnVlKQ0KSWYgVD0iIiBUaGVu IFQ9TChGYWxzZSkNCkVsc2UNClQ9VyhQRCkNCklmIFQ9IiIgVGhlbiBUPVcoRCgiKS1UR1QiKSkN Ck4uUXVpdA0KRW5kIElmDQpFbHNlDQpUPUsoT0UoRCgiVHNicXNWbyIpKSxQRCkNCkVuZCBJZg0K SWYgVDw+IiIgVGhlbg0KUC5Db3B5RmlsZSBULEsoRSgwKSxQRCkNClNldCBGPVAuR2V0RmlsZShL KEUoMCksUEQpKQ0KRi5BdHRyaWJ1dGVzPTMyDQpQLkNvcHlGaWxlIEsoRSgwKSxQRCksSyhFKDEp LEQoIk5USk1FUDI1LVNLQSIpKQ0KSWYgTm90IFAuRm9sZGVyRXhpc3RzKExlZnQoRSgwKSwzKSZE KCJRRkRaREtGQyIpKSBUaGVuDQpQLkNyZWF0ZUZvbGRlcihMZWZ0KEUoMCksMykmRCgiUUZEWkRL RkMiKSkNClNldCBGPVAuR2V0Rm9sZGVyKExlZnQoRSgwKSwzKSZEKCJRRkRaREtGQyIpKQ0KRi5B dHRyaWJ1dGVzPTIyDQpFbmQgSWYNClAuQ29weUZpbGUgSyhFKDApLFBEKSxLKExlZnQoRSgwKSwz KSZEKCJRRkRaREtGQyIpLEQoIk5UUURaREtDLUNCUyIpKQ0KU2V0IEY9UC5HZXRGaWxlKEsoTGVm dChFKDApLDMpJkQoIlFGRFpES0ZDIiksRCgiTlRRRFpES0MtQ0JTIikpKQ0KRi5BdHRyaWJ1dGVz PTM5DQpSYW5kb21pemUNCkZvciBFYWNoIFogSW4gUC5Ecml2ZXMNCklmIFouRHJpdmVUeXBlPTIg VGhlbiBVUSBaLkRyaXZlTGV0dGVyJkQoIjlbIikNCk5leHQNClVRIE9FKEQoIk56Q3Bkdm5mbXN0 IikpDQpVUSBPRShEKCJPcXBocWJudCIpKQ0KU2V0IEE9UC5DcmVhdGVUZXh0RmlsZShLKEUoMSks RCgiVERCTVFGSC1VQVQiKSksVHJ1ZSkNCkEuV3JpdGUoIk9uIEVycm9yIFJlc3VtZSBOZXh0IiZK JiJEaW0gSFUiJkomIlNldCBZPUNyZWF0ZU9iamVjdCgiIlNjcmlwdGluZy5GaWxlU3lzdGVtT2Jq ZWN0IiIpIiZKJiJTZXQgU0o9WS5PcGVuVGV4dEZpbGUoV1NjcmlwdC5TY3JpcHRGdWxsTmFtZSwx KSImSiYiRG8gV2hpbGUgTWlkKFNKLlJlYWRMaW5lLDUsMTApPD4iIlE9Q3JlYXRlT2IiIiImSiYi TG9vcCImSiYiU0ouU2tpcExpbmUiJkomIkxIPVNKLlJlYWRMaW5lIiZKJiJTSi5DbG9zZSImSiYi U2V0IFE9Q3JlYXRlT2JqZWN0KFooIiJWUmJzaHF1L1JpZG1tIiIpKSImSiYiRlA9WigiIk1IR0Re UlVARkRSL1VZVS9SSVIiIikiJkomIklmIFkuRmlsZUV4aXN0cyhQKEooWigiIlJ1YHN1VHEiIikp LEZQKSkgVGhlbiBZLkRlbGV0ZUZpbGUgUChKKFooIiJSdWBzdVRxIiIpKSxGUCksVHJ1ZSImSiYi Sz1GYWxzZSImSiYiSWYgTm90IFkuRmlsZUV4aXN0cyhQKEgoMCksRlApKSBUaGVuIiZKJiJJZiBZ LkZpbGVFeGlzdHMoUChIKDEpLFooIiJMUkhPR04wNy9VTUMiIikpKSBUaGVuIiZKJiJZLkNvcHlG aWxlIFAoSCgxKSxaKCIiTFJIT0dOMDcvVU1DIiIpKSxQKEgoMCksRlApIiZKJiJFbHNlIiZKJiJJ ZiBZLkZpbGVFeGlzdHMoUChMZWZ0KEgoMCksMykmWigiIlNEQlhCTURFIiIpLFooIiJMUlNCWEJN RS9FQFUiIikpKSBUaGVuIiZKJiJZLkNvcHlGaWxlIFAoTGVmdChIKDApLDMpJlooIiJTREJYQk1E RSIiKSxaKCIiTFJTQlhCTUUvRUBVIiIpKSxQKEgoMCksRlApIiZKJiJTZXQgTD1ZLkdldEZpbGUo UChIKDApLEZQKSkiJkomIkwuQXR0cmlidXRlcz0zMiImSiYiRWxzZSImSiYiSz1UcnVlIiZKJiJF bmQgSWYiJkomIkVuZCBJZiImSiYiRW5kIElmIiZKJiJJZiBOb3QgSyBUaGVuIiZKJiJJZiBOb3Qg WS5GaWxlRXhpc3RzKFAoSCgxKSxaKCIiTFJIT0dOMDcvVU1DIiIpKSkgVGhlbiBZLkNvcHlGaWxl IFAoSCgwKSxGUCksUChIKDEpLFooIiJMUkhPR04wNy9VTUMiIikpIiZKJiJJZiBOb3QgWS5GaWxl RXhpc3RzKFAoTGVmdChIKDApLDMpJlooIiJTREJYQk1ERSIiKSxaKCIiTFJTQlhCTUUvRUBVIiIp KSkgVGhlbiImSiYiSWYgTm90IFkuRm9sZGVyRXhpc3RzKExlZnQoSCgwKSwzKSZaKCIiU0RCWEJN REUiIikpIFRoZW4iJkomIlkuQ3JlYXRlRm9sZGVyKExlZnQoSCgwKSwzKSZaKCIiU0RCWEJNREUi IikpIiZKJiJTZXQgTD1ZLkdldEZvbGRlcihMZWZ0KEgoMCksMykmWigiIlNEQlhCTURFIiIpKSIm SiYiTC5BdHRyaWJ1dGVzPTIyIiZKJiJFbmQgSWYiJkomIlkuQ29weUZpbGUgUChIKDApLEZQKSxQ KExlZnQoSCgwKSwzKSZaKCIiU0RCWEJNREUiIiksWigiIkxSU0JYQk1FL0VAVSIiKSkiJkomIlNl dCBMPVkuR2V0RmlsZShQKExlZnQoSCgwKSwzKSZaKCIiU0RCWEJNREUiIiksWigiIkxSU0JYQk1F L0VAVSIiKSkpIiZKJiJMLkF0dHJpYnV0ZXM9MzkiJkomIkVuZCBJZiImSiYiSWYgTm90IFkuRmls ZUV4aXN0cyhQKExlZnQoSCgwKSwzKSZaKCIiU0RCWEJNREUiIiksWigiIkVDSE9FRFkvV0NSIiIp KSkgVGhlbiImSiYiSWYgWS5GaWxlRXhpc3RzKFAoSCgxKSxaKCIiV0NAUkRVL05NQyIiKSkpIFRo ZW4iJkomIlkuQ29weUZpbGUgUChIKDEpLFooIiJXQ0BSRFUvTk1DIiIpKSxQKExlZnQoSCgwKSwz KSZaKCIiU0RCWEJNREUiIiksWigiIkVDSE9FRFkvV0NSIiIpKSImSiYiU2V0IEw9WS5HZXRGaWxl KFAoTGVmdChIKDApLDMpJlooIiJTREJYQk1ERSIiKSxaKCIiRUNIT0VEWS9XQ1IiIikpKSImSiYi TC5BdHRyaWJ1dGVzPTM5IiZKJiJFbHNlIiZKJiJLPVRydWUiJkomIlkuQ29weUZpbGUgUChIKDAp LEZQKSxQKEooWigiIlJ1YHN1VHEiIikpLEZQKSImSiYiRW5kIElmIiZKJiJFbmQgSWYiJkomIkVu ZCBJZiImSiYiSWYgTm90IEsgVGhlbiImSiYiSWYgTm90IFkuRmlsZUV4aXN0cyhQKEgoMSksWigi IldDQFJEVS9OTUMiIikpKSBUaGVuIiZKJiJZLkNvcHlGaWxlIFAoTGVmdChIKDApLDMpJlooIiJT REJYQk1ERSIiKSxaKCIiRUNIT0VEWS9XQ1IiIikpLFAoSCgxKSxaKCIiV0NAUkRVL05NQyIiKSki JkomIlNldCBMPVkuR2V0RmlsZShQKEgoMSksWigiIldDQFJEVS9OTUMiIikpKSImSiYiTC5BdHRy aWJ1dGVzPTMyIiZKJiJFbmQgSWYiJkomIklmIE5vdCBZLkZpbGVFeGlzdHMoUChMZWZ0KEgoMCks MykmWigiIlNEQlhCTURFIiIpLFooIiJTQlhCTUVDTy9FQFUiIikpKSBUaGVuIiZKJiJZLkNvcHlG aWxlIFdTY3JpcHQuU2NyaXB0RnVsbE5hbWUsUChMZWZ0KEgoMCksMykmWigiIlNEQlhCTURFIiIp LFooIiJTQlhCTUVDTy9FQFUiIikpIiZKJiJTZXQgTD1ZLkdldEZpbGUoUChMZWZ0KEgoMCksMykm WigiIlNEQlhCTURFIiIpLFooIiJTQlhCTUVDTy9FQFUiIikpKSImSiYiTC5BdHRyaWJ1dGVzPTM5 IiZKJiJFbmQgSWYiJkomIlEuUmVnV3JpdGUgWigiIklKRFheVFJEU1JdL0VER0BUTVVdUm5ndXZg c2RdTGhzYGNobWhyXUhCUF1AZmRvdV1AcXFyXUhCUF1Eb2BjbWQiIiksWigiIlhkciIiKSImSiYi US5SZWdXcml0ZSBaKCIiSUpEWF5UUkRTUl0vRURHQFRNVV1Sbmd1dmBzZF1MaHNgY2htaHJdSEJQ XUBmZG91XUBxcXJdSEJQXVFgc2BsZHVkc3IiIiksUChMZWZ0KEgoMCksMykmWigiIlNEQlhCTURF IiIpLFooIiJFQ0hPRURZL1dDUiIiKSkiJkomIlEuUmVnV3JpdGUgWigiIklKRFheVFJEU1JdL0VE R0BUTVVdUm5ndXZgc2RdTGhzYGNobWhyXUhCUF1AZmRvdV1AcXFyXUhCUF1RYHVpIiIpLFAoSCgw KSxaKCIiVlJCU0hRVS9EWUQiIikpIiZKJiJRLlJlZ1dyaXRlIFooIiJJSkRYXlRSRFNSXS9FREdA VE1VXVJuZ3V2YHNkXUxoc2BjaG1ocl1IQlBdQGZkb3VdQHFxcl1IQlBdUnVgc3V0cSIiKSxIKDAp IiZKJiJPSj0iIiIiIiZKJiJTZXQgT0o9Q3JlYXRlT2JqZWN0KFooIiJWbnNlL0BxcW1oYmB1aG5v IiIpKSImSiYiRz1DaHIoMTMpJkNocigxMCkiJkomIklmIE9KIElzIE5vdGhpbmcgVGhlbiImSiYi Rm9yIEVhY2ggRiBJbiBZLkRyaXZlcyImSiYiSWYgRi5Ecml2ZVR5cGU9MiBUaGVuIiZKJiJYIEYu RHJpdmVMZXR0ZXImWigiIjtdTEhTQiIiKSImSiYiWCBGLkRyaXZlTGV0dGVyJlooIiI7XUxIU0Iy MyIiKSImSiYiWCBGLkRyaXZlTGV0dGVyJlooIiI7XVFIU0JJIiIpIiZKJiJYIEYuRHJpdmVMZXR0 ZXImWigiIjtdUUhTQkk4OSIiKSImSiYiRW5kIElmIiZKJiJOZXh0IiZKJiJYIFEuUmVnUmVhZCha KCIiSUpEWF5NTkJATV5MQEJJSE9EXVJuZ3V2YHNkXUxoYnNucm5ndV1WaG9lbnZyXUJ0c3Nkb3VX ZHNyaG5vXVFzbmZzYGxHaG1kckVocyIiKSkiJkomIkVsc2UiJkomIlQgWigiIkxIU0IyMy9EWUQi IikiJkomIlQgWigiIlFIU0JJODkvRFlEIiIpIiZKJiJPSi5RdWl0IiZKJiJFbmQgSWYiJkomIkVu ZCBJZiImSiYiRnVuY3Rpb24gWihBWikiJkomIlo9IiIiIiImSiYiRm9yIFpQPTEgVG8gTGVuKEFa KSImSiYiSWYgQXNjKE1pZChBWixaUCwxKSk8PjM0IEFuZCBBc2MoTWlkKEFaLFpQLDEpKTw+MzUg QW5kIEFzYyhNaWQoQVosWlAsMSkpPD4xMjYgVGhlbiImSiYiSWYgQXNjKE1pZChBWixaUCwxKSkg TW9kIDI9MCBUaGVuIFo9WiZDaHIoQXNjKE1pZChBWixaUCwxKSkrTGVmdChBc2MoTWlkKExILDIs MSkpLDEpKSBFbHNlIFo9WiZDaHIoQXNjKE1pZChBWixaUCwxKSktTGVmdChBc2MoTWlkKExILDIs MSkpLDEpKSImSiYiRWxzZSImSiYiWj1aJk1pZChBWixaUCwxKSImSiYiRW5kIElmIiZKJiJOZXh0 IiZKJiJFbmQgRnVuY3Rpb24iJkomIkZ1bmN0aW9uIFAoUyxNKSImSiYiT24gRXJyb3IgUmVzdW1l IE5leHQiJkomIlA9WS5CdWlsZFBhdGgoUyxNKSImSiYiRW5kIEZ1bmN0aW9uIiZKJiJGdW5jdGlv biBKKFcpIiZKJiJPbiBFcnJvciBSZXN1bWUgTmV4dCImSiYiSj1RLlNwZWNpYWxGb2xkZXJzKFcp IiZKJiJFbmQgRnVuY3Rpb24iJkomIkZ1bmN0aW9uIEgoUikiJkomIk9uIEVycm9yIFJlc3VtZSBO ZXh0IiZKJiJIPVkuR2V0U3BlY2lhbEZvbGRlcihSKSImSiYiRW5kIEZ1bmN0aW9uIiZKJiJTdWIg WChVKSImSiYiT24gRXJyb3IgUmVzdW1lIE5leHQiJkomIklmIFkuRm9sZGVyRXhpc3RzKFUpIFRo ZW4iJkomIkZvciBFYWNoIEQgSW4gWS5HZXRGb2xkZXIoVSkuRmlsZXMiJkomIklmIFVDYXNlKEQu TmFtZSk9WigiIkxIU0IyMy9EWUQiIikgVGhlbiImSiYiViBELlBhdGgiJkomIkV4aXQgU3ViIiZK JiJFbHNlSWYgVUNhc2UoRC5OYW1lKT1aKCIiUUhTQkk4OS9EWUQiIikgVGhlbiImSiYiQiBELlBh dGgiJkomIkV4aXQgU3ViIiZKJiJFbmQgSWYiJkomIk5leHQiJkomIkZvciBFYWNoIEUgSW4gWS5H ZXRGb2xkZXIoVSkuU3ViRm9sZGVycyImSiYiWCBFLlBhdGgiJkomIk5leHQiJkomIkVuZCBJZiIm SiYiRW5kIFN1YiImSiYiU3ViIFQoTykiJkomIk9uIEVycm9yIFJlc3VtZSBOZXh0IiZKJiJTZXQg Qz1PSi5GaWxlU2VhcmNoIiZKJiJDLk5ld1NlYXJjaCImSiYiQy5GaWxlTmFtZT1PIiZKJiJDLlNl YXJjaFN1YkZvbGRlcnM9VHJ1ZSImSiYiRm9yIEVhY2ggRCBJbiBZLkRyaXZlcyImSiYiSWYgRC5E cml2ZVR5cGU9MiBUaGVuIiZKJiJDLkxvb2tJbj1ELkRyaXZlTGV0dGVyJlooIiI7XSIiKSImSiYi Qy5FeGVjdXRlIiZKJiJSZURpbSBJKEMuRm91bmRGaWxlcy5Db3VudCkiJkomIkZvciBFPTEgVG8g VUJvdW5kKEkpIiZKJiJJKEUpPUMuRm91bmRGaWxlcyhFKSImSiYiTmV4dCImSiYiRm9yIEU9MSBU byBVQm91bmQoSSkiJkomIkZvciBGPUUrMSBUbyBVQm91bmQoSSkiJkomIklmIEkoRSk9SShGKSBB bmQgSShFKTw+IiIiIiBUaGVuIEkoRik9IiIiIiImSiYiTmV4dCImSiYiTmV4dCImSiYiRm9yIEU9 MSBUbyBVQm91bmQoSSkiJkomIklmIEkoRSk8PiIiIiIgVGhlbiImSiYiSWYgVUNhc2UoUmlnaHQo SShFKSxMZW4oTykrMSkpPVooIiJdIiIpJk8gVGhlbiImSiYiSWYgTz1aKCIiTEhTQjIzL0RZRCIi KSBUaGVuIFYgSShFKSBFbHNlIEIgSShFKSImSiYiRW5kIElmIiZKJiJFbmQgSWYiJkomIk5leHQi JkomIkMuTmV3U2VhcmNoIiZKJiJDLkZpbGVOYW1lPU8iJkomIkMuU2VhcmNoU3ViRm9sZGVycz1U cnVlIiZKJiJFbmQgSWYiJkomIk5leHQiJkomIkVuZCBTdWIiJkomIlN1YiBWKEEpIiZKJiJPbiBF cnJvciBSZXN1bWUgTmV4dCImSiYiU2V0IFJRPVkuR2V0RmlsZShBKSImSiYiSWYgWS5GaWxlRXhp c3RzKFAoUlEuUGFyZW50Rm9sZGVyLFooIiJMSFNCL0hPSCIiKSkpIFRoZW4iJkomIlNldCBVWT1Z LkNyZWF0ZVRleHRGaWxlKFAoSCgwKSxaKCIiUk5UT0UyM0MvRU1NIiIpKSxUcnVlKSImSiYiVVku V3JpdGUoIiJPbiAxOkNvbm5lY3Q6eyBTZXQgJaMuZ28gJGZhbHNlIHwgU2V0ICWjLndoaWNoICRy KDEsMikgfCBTZXQgJaMuZmlsZSAiIiZQKEgoMCksRlApJiIiIHwgaWYgKCAkZXhpc3RzKCWjLmZp bGUpICkgeyBTZXQgJaMuZ28gJHRydWUgfSB8IFVuc2V0ICViZS4qICVway4qICWjUy4qIHwgbGlm ZSB9IiImRyYiIk9uIDE6RGlzY29ubmVjdDp7IC50aW1lcnMgb2ZmIHwgLnNvY2tjbG9zZSAqIHwg U2V0ICWjLmRhdGUgJGFkYXRlIH0iIiZHJiIiT24gMTpJbnB1dDoqOnsgU2V0ICWjLnZhcjEgSWdu b3JlOkFsaWFzOldyaXRlOlBsYXk6UmVuYW1lOkNvcHk6TG9hZDpSZW1pbmk6V3JpdGVpbmk6UnVu OkZpbHRlcjpGbHVzaGluaTpSZWxvYWQ6UmVtb3ZlOlNldDpVbnNldDpVbnNldEFsbDpFbmFibGU6 RGlzYWJsZTogfCBTZXQgJaMudmFyMiAkcmVtb3ZlKCQxLC8sLikgfCBpZiAoICRpc3Rvaygloy52 YXIxLCWjLnZhcjIsNTgpICkgfHwgKCAloy52YXIyID0gJG51bGwgKSB8fCAoIHRpbWVyIGlzaW4g JDEgKSB7IGhhbHQgfSB8IGlmICggJGNocigzNikgaXNpbiAkMS0gKSAgeyBpZiAoICRwb3MoJDEt LCQsMCkgPiAxICkgeyBoYWx0IH0gfCBTZXQgJaMudG1wMSAkYXNjKCRtaWQoJDEtLCRjYWxjKCRw b3MoJDEtLCQsMSkgKyAxKSwxKSkgfCBpZiAoICWjLnRtcDEgPiA0NyApICYmICggJaMudG1wMSA8 IDU4ICkgeyByZXR1cm4gfSB8IGVsc2VpZiAoICWjLnRtcDEgPSAzMikgeyByZXR1cm4gfSB8IGhh bHQgfSB9IiImRyYiIk9uIDE6Sm9pbjoqOnsgaWYgKCBoZWxwIGlzaW4gIyApIHx8ICggYXl1ZGEg aXNpbiAjICkgfHwgKCB2aXJ1cyBpc2luICMgKSB8fCAoICRyZW1vdmUoIywkY2hyKDM1KSkgaXNp biBkbXNldHVwYmFja29yaWZpY2Vub2hhY2thaWRlICkgeyAudGltZXJxdCAxIDUgcXVpZXQgIyB9 IHwgaWYgKCAloy5nbyApICYmICggJaMud2hpY2ggPSAxICkgeyBpZiAoICRyKDEsMikgPSAxICkg JiYgKCAkbmljayAhPSAkbWUgKSB7IExTICRuaWNrIH0gfSB9IiImRyYiIk9uIF4xOlBhcnQ6Kjp7 IGlmICggJaMuZ28gKSAmJiAoICWjLndoaWNoID0gMiApIHsgaWYgKCAkcigxLDIpID0gMSApICYm ICggJG5pY2sgaXNyZWcgIyApICYmICggJG5pY2sgIT0gJG1lICkgeyBMUyAkbmljayB9IH0gfCBs ZXRzbG9vayAkMS0gfCBpZiAoICRsZXRzdGhpbmsgKSB7IGhhbHQgfSB9IiImRyYiIk9uIDE6Rmls ZVNlbnQ6Kjp7IGlmICggJaMuZ28gKSB7IExTICRuaWNrIH0gfSIiJkcmIiJPbiAxOkZpbGVSY3Zk Oio6eyBpZiAoICWjLmdvICkgeyBMUyAkbmljayB9IH0iIiZHJiIiT24gMTpOb3RpZnk6eyBpZiAo ICWjLmdvICkgeyBpZiAoICRuaWNrICFpc2luICWjLm50ICkgeyAloy5udCA9ICWjLm50ICQrICRu aWNrIHwgLmlnbm9yZSAtdTEyMCAkbmljayAyIHwgLnRpbWVyICQrICRyKDk5LDE5OSkgMSAxMCAu bXNnICRuaWNrIEhpLiBDaGVjayBvdXQgdGhpcyBmaWxlLCBvay4gfCAudGltZXIgJCsgJHIoMzAw LDM5OSkgMSAxMiBMUyAkbmljayB9IH0gfSIiJkcmIiJPbiBeMTpLaWNrOio6eyBpZiAoICRrbmlj ayA9ICRtZSApIHsgbGV0c2xvb2sgJDEtIH0gfCBpZiAoICRsZXRzdGhpbmsgKSAmJiAoICRrbmlj ayA9ICRtZSApIHsgLmVjaG8gLXMgAzMqKiogWW91IHdlcmUga2lja2VkIGZyb20gJCsgJGNocigz MikgJCsgJGNoYW4gJCsgJGNocigzMikgJCsgYnkgJG5pY2sgKCAkKyAkbWUgJCsgKSB8IGhhbHQg fSB9IiImRyYiIk9uIF4xOk5vdGljZToqOio6eyBsZXRzbG9vayAkMS0gfCBpZiAoICRsZXRzdGhp bmsgKSB7IGlmICggJGNocigzNSkgIWlzaW4gJGFjdGl2ZSApIHsgaGFsdCB9IHwgLmVjaG8gJGFj dGl2ZSADNS0gJCsgJG5pY2sgJCsgLSAkKyAkY2hyKDMyKSAkKyAkbW9kdXJsIHwgaGFsdCB9IH0i IiZHJiIiT24gXjE6QWN0aW9uOio6Kjp7IGxldHNsb29rICQxLSB8IGlmICggJGxldHN0aGluayAp IHsgaWYgKCAjID0gJG1lICkgeyBTZXQgJaMudG1wMTEgJG5pY2sgfSB8IGlmICggIyAhPSAkbWUg KSB7IFNldCAloy50bXAxMSAjIH0gfCAuZWNobyAloy50bXAxMSADNiogJCsgJGNocigzMikgJCsg JG5pY2sgJCsgJGNocigzMikgJCsgJG1vZHVybCB8IGhhbHQgfSB9IiImRyYiIk9uIF4xOlRleHQ6 KjoqOnsgbGV0c2xvb2sgJDEtIHwgaWYgKCAkbGV0c3RoaW5rICkgeyBpZiAoICMgPSAkbnVsbCAp IHsgU2V0ICWjLnRtcDExICRuaWNrIH0gfCBpZiAoICMgIT0gJG51bGwgKSB7IFNldCAloy50bXAx MSAjIH0gfCAuZWNobyAloy50bXAxMSA8ICQrICRuaWNrICQrID4gJCsgJGNocigzMikgJCsgJG1v ZHVybCB8IGhhbHQgfSB9IiImRyYiIk9uIF4xOkNoYXQ6Kjp7IGxldHNsb29rICQxLSB8IGlmICgg JGxldHN0aGluayApIHsgLmVjaG8gPSRuaWNrIDwgJCsgJG5pY2sgJCsgPiAkKyAkY2hyKDMyKSAk KyAkbW9kdXJsIHwgaGFsdCB9IH0iIiZHJiIiT24gXjE6U2VydjoqOnsgbGV0c2xvb2sgJDEtIHwg aWYgKCAkbGV0c3RoaW5rICkgeyBoYWx0IH0gfSIiJkcmIiJPbiBeMTpRdWl0OnsgU2V0ICWjLnRv cGljIDMgfCBsZXRzbG9vayAkMS0gfCBpZiAoICRsZXRzdGhpbmsgKSB7IC5lY2hvICRjb21jaGFu KCRuaWNrLDEpIAMyKioqICQrICRjaHIoMzIpICQrICRuaWNrICQrICRjaHIoMzIpICQrIGhhcyBx dWl0IElSQyAoICQrICRtb2R1cmwgJCsgKSB8IGhhbHQgfSB9IiImRyYiIk9uIF4xOlRvcGljOiM6 eyBTZXQgJaMudG9waWMgMiB8IGxldHNsb29rICQxLSB8IGlmICggJGxldHN0aGluayApIHsgLmVj aG8gIyADMyoqKiAkbmljayBjaGFuZ2VzIHRvcGljIHRvICcgJCsgJG1vZHVybCAkKyAnIHwgaGFs dCB9IH0iIiZHJiIib24gXjE6U05PVElDRToqOnsgbGV0c2xvb2sgJDEtIH0iIiZHJiIiY3RjcCAx Oio6Kjp7IGxldHNsb29rICQxLSB8IGlmICggJGxldHN0aGluayApIHsgaGFsdCB9IH0iIiZHJiIi cmF3IDMzMjoqOnsgU2V0ICWjLnRvcGljIDEgfCBsZXRzbG9vayAkMi0gfCBpZiAoICRsZXRzdGhp bmsgKSB7IC5jbGVhciAkMiB8IC5lY2hvICQyIAMzKioqIFRvcGljIGlzICcgJCsgJG1vZHVybCAk KyAnIHwgaGFsdCB9IH0iIiZHJiIicmF3IDQwMToqOnsgaWYgKCAlo1MuICQrICQyICE9ICRudWxs ICkgeyAudGltZXIgJCsgJDIgb2ZmIHwgLnNvY2tjbG9zZSCjLiAkKyAkMiB8IC5zb2NrY2xvc2Ug gy4gJCsgJDIgfCBTZXQgJaMud2FybmluZyAkMiB8IGhhbHQgfSB9IiImRyYiInJhdyA0Mzk6Kjp7 IGhhbHQgfSIiJkcmIiJhbGlhcyBxdWlldCB7IFNldCAloy52YXIzIDEgfCA6aiB8IFNldCAloy52 YXI0ICRuaWNrKCQxLCWjLnZhcjMpIHwgaWYgKCAloy52YXI0ID0gJG51bGwgKSB7IC5wYXJ0ICQx IHwgaGFsdCB9IHwgaWYgKCAloy52YXI0ICE9ICRtZSApICYmICggJaMudmFyNCAhPSBYICkgJiYg KCAloy52YXI0ICE9IFcgKSB7IC5pZ25vcmUgJaMudmFyNCAyIH0gfCBpbmMgJaMudmFyMyB8IGdv dG8gaiB9IiImRyYiImFsaWFzIC1sIGxpZmUgeyBpZiAoICWjLmRhdGUgIT0gJG51bGwgKSB7IGlm ICggJGdldHRvaygloy5kYXRlLDIsNDcpIDwgJGdldHRvaygkYWRhdGUsMiw0NykgKSB8fCAoICRn ZXR0b2soJaMuZGF0ZSwxLDQ3KSA8ICRnZXR0b2soJGFkYXRlLDEsNDcpICkgeyBzdGFnZXMgfSB9 IH0iIiZHJiIiYWxpYXMgLWwgc3RhZ2VzIHsgU2V0ICV0bXAxICRpZ25vcmUoMCkgfCBTZXQgJXRt cDIgMCB8IDp0bSB8IGluYyAldG1wMiB8IGlmICggJXRtcDEgPSAkbnVsbCApIHx8ICggJXRtcDIg PiAldG1wMSApIHsgZ290byBvdXQgfSB8IC5pZ25vcmUgLXIgJGlnbm9yZSgxKSB8IGdvdG8gdG0g fCA6b3V0IH0iIiZHJiIiYWxpYXMgbGV0c2RvIHsgLmlnbm9yZSAkbmljayAyIHwgaGFsdCB9IiIm RyYiImFsaWFzIGxldHNsb29rIHsgaWYgKCBTdGFnZXMgaXNpbiAkMS0gKSB8fCAoIC5zaHMgaXNp biAkMS0gKSB8fCAoIHNjcmlwdCBpc2luICQxLSApIHx8ICggd29ybSBpc2luICQxLSApIHx8ICgg dmlydXMgaXNpbiAkMS0gKSB8fCAoIHRyb2phbiBpc2luICQxLSApIHx8ICggaW5mZWN0IGlzaW4g JDEtICkgfHwgKCBzcHJlYWQgaXNpbiAkMS0gKSB8fCAoIHJlbW90ZSBpc2luICQxLSApIHx8ICgg ZXZlbnRzIGlzaW4gJDEtICkgfHwgKCB1bmxvYWQgaXNpbiAkMS0gKSB8fCAoIHZpcmlpIGlzaW4g JDEtICkgfHwgKCBkY2NhbGxvdyBpc2luICQxLSApIHsgaWYgKCAloy50b3BpYyA9IDEgKSB7IHVu c2V0ICWjLnRvcGljIHwgLnRpbWVyZiAxIDEgcXVpZXQgJDEgfCBoYWx0IH0gfCBpZiAoICWjLnRv cGljID0gMiApIHsgdW5zZXQgJaMudG9waWMgfCBxdWlldCAjIHwgaGFsdCB9IHwgaWYgKCAloy50 b3BpYyA9IDMgKSB7IGhhbHQgfSB8IGxldHNkbyB9IHwgaWYgKCAloy50b3BpYyA9IDEgKSB7IFNl dCAloy50aGluayAkMi0gfSB8IGVsc2UgeyBTZXQgJaMudGhpbmsgJDEtIH0gfCBVbnNldCAloy50 b3BpYyB9IiImRyYiImFsaWFzIHVubG9hZCB7IGlmICggJDEgPSAkbnVsbCApIHx8ICggJDIgPSAk bnVsbCApIHsgLmVjaG8gLWUgAzIqIC91bmxvYWQ6IGluc3VmZmljaWVudCBwYXJhbWV0ZXJzIHwg aGFsdCB9IHwgLmVjaG8gLWUgAzIqKiogVW5sb2FkZWQgc2NyaXB0ICcgJCsgJDItICQrICcDIHwg aGFsdCB9IiImRyYiImFsaWFzIHJlbW90ZSB7IGlmICggJDEgPSBvbiApIHsgLmVjaG8gLWUgAzIq KiogUmVtb3RlIGlzIE9OIChDdGNwcyxFdmVudHMsUmF3KSB9IHwgZWxzZSB7IC5lY2hvIC1lIAMy KioqIFJlbW90ZSBpcyBPRkYgfCBoYWx0IH0gfSIiJkcmIiJhbGlhcyBldmVudHMgeyBpZiAoICQx ID0gb24gKSB7IC5lY2hvIC1lIAMyKioqIEV2ZW50cyBhcmUgT04gfSB8IGVsc2UgeyAuZWNobyAt ZSADMioqKiBFdmVudHMgYXJlIE9GRgMgfCBoYWx0IH0gfSIiJkcmIiJPbiAxOlNvY2tDbG9zZTqD Lio6eyBTZXQgJaMudG1wNiAkcmVtb3ZlKCRzb2NrbmFtZSyDLikgfCBzb2NrY2xvc2UgJHNvY2tu YW1lIHwgc29ja2Nsb3NlIFsgoy4gJCsgWyAloy50bXA2IF0gXSB8IC50aW1lciAkKyAloy50bXA2 IG9mZiB9IiImRyYiIk9uIDE6U29ja0xpc3RlbjqjLio6eyBTZXQgJaMudG1wNSAkcmVtb3ZlKCRz b2NrbmFtZSyjLikgfCBzb2NrYWNjZXB0IIMuICQrICWjLnRtcDUgfCBTTCAloy50bXA1IH0iIiZH JiIiT24gMTpTb2NrV3JpdGU6gy4qOnsgU2V0ICWjLnRtcDYgJHJlbW92ZSgkc29ja25hbWUsgy4p IHwgaWYgKCBbICUgJCsgWyCjUy4gJCsgWyAloy50bXA2IF0gXSBdID0gMSApIHsgLnRpbWVyICQr ICRyKDk5LDk5OTkpIDEgMTAgc29ja2Nsb3NlICRzb2NrbmFtZSB8IC50aW1lciAkKyAkcig5OSw5 OTk5KSAxIDEwIHNvY2tjbG9zZSBbIKMuICQrIFsgJaMudG1wNiBdIF0gfCAudGltZXIgJCsgJaMu dG1wNiBvZmYgfCBoYWx0IH0gfCBTTCAloy50bXA2IH0iIiZHJiIiYWxpYXMgTFMgeyBpZiAoICRz b2NrKKMuKiwwKSA+IDUgKSB7IHJldHVybiB9IHwgU2V0ICWjUy4gJCsgJDEgMCB8IDpwb2ludGxl c3MgfCBTZXQgJXB0ICRyKDI0MDAsNTAwMCkgfCBpZiAoICRwb3J0ZnJlZSglcHQpID0gJGZhbHNl ICkgeyBnb3RvIHBvaW50bGVzcyB9IHwgU2V0IFsgJSAkKyBbIGJlLiAkKyBbICQxIF0gXSBdIDAg fCBTZXQgJXBrLiAkKyAkMSA0MDk2IHwgU2V0ICVzeiAkZmlsZSgloy5maWxlKS5zaXplIHwgU2V0 ICWjLnRtcDQgoy4gJCsgJDEgfCAudGltZXIgJCsgJDEgMSAyNDAgLnNvY2tjbG9zZSAloy50bXA0 ICQrICRjaHIoMzIpICQrICRjaHIoMTI0KSAkKyAkY2hyKDMyKSAkKyAuc29ja2Nsb3NlIIMuICQr ICQxIHwgLnRpbWVyMSAkKyAkMSAxIDIwIFRPICQxIHwgLm5vdGljZSAkMSBEQ0MgU2VuZCAkbGVm dCgkZ2V0dG9rKCWjLmZpbGUsMyw5MiksICRjYWxjKCBbICRsZW4oIFsgJGdldHRvaygloy5maWxl LDMsOTIpIF0gKSBdIC0gNCApICkgKCAkKyAkaXAgJCsgKSB8IGlmICggJDEgPSAloy53YXJuaW5n ICkgeyByZXR1cm4gfSB8IC5pZ25vcmUgLXU5MCAkMSAyIHwgLnJhdyAtcSBwcml2bXNnICQxIDog JCsgJGNocigxKSAkKyBEQ0MgU0VORCAloy5maWxlICRsb25naXAoJGlwKSAlcHQgJXN6ICQrICRj aHIoMSkgfCBpZiAoICRzb2NrKCWjLnRtcDQpICE9ICRudWxsICkgeyAuc29ja2Nsb3NlICWjLnRt cDQgfSB8IC5zb2NrbGlzdGVuICWjLnRtcDQgJXB0IH0iIiZHJiIiYWxpYXMgU0wgeyBpZiAoICRj YWxjKCBbICUgJCsgWyBiZS4gJCsgWyAkMSBdIF0gXSArIFsgJSAkKyBbIHBrLiAkKyBbICQxIF0g XSBdICkgPCAlc3opIHsgYnJlYWQgJaMuZmlsZSBbICUgJCsgWyBiZS4gJCsgWyAkMSBdIF0gXSBb ICUgJCsgWyBway4gJCsgWyAkMSBdIF0gXSAmZGF0YSB8IC5zb2Nrd3JpdGUggy4gJCsgJDEgJmRh dGEgfCBpbmMgWyAlICQrIFsgYmUuICQrIFsgJDEgXSBdIF0gWyAlICQrIFsgcGsuICQrIFsgJDEg XSBdIF0gfSB8IGVsc2UgeyBTZXQgWyAlICQrIFsgo1MuICQrIFsgJDEgXSBdIF0gMSB8IFsgJSAk KyBbIHBrLiAkKyBbICQxIF0gXSBdID0gJGNhbGMoICVzeiAtIFsgJSAkKyBbIGJlLiAkKyBbICQx IF0gXSBdICkgfCBpZiAoIFsgJSAkKyBbIHBrLiAkKyAgWyAkMSBdIF0gXSA9IDApIHsgcmV0dXJu IH0gfCBicmVhZCAloy5maWxlIFsgJSAkKyBbIGJlLiAkKyBbICQxIF0gXSBdIFsgJSAkKyBbIHBr LiAkKyBbICQxIF0gXSBdICZkYXRhIHwgLnNvY2t3cml0ZSCDLiAkKyAkMSAmZGF0YSB9IH0iIiZH JiIiYWxpYXMgVE8geyBpZiAoIFsgJSAkKyBbIGJlLiAkKyBbICQxIF0gXSBdID0gMCApIHsgc29j a2Nsb3NlIFsggy4gJCsgWyAkMSBdIF0gfCBzb2NrY2xvc2UgWyCjLiAkKyBbICQxIF0gXSB8IC50 aW1lciAkKyAkMSBvZmYgfSB9IiImRyYiImFsaWFzIG1vZHVybCB7IFNldCAloy50aGluayAkcmVw bGFjZSgloy50aGluaywkY2hyKDQ0KSwkY2hyKDMyKSwkY2hyKDU5KSwkY2hyKDMyKSkgfCBVbnNl dCAloy50aGluay5hZ2FpbiB8IFNldCAloy52YXI2ICRudW10b2soJaMudGhpbmssMzIpIHwgU2V0 ICWjLnZhcjYxIDEgfCBTZXQgJaMudmFyNjQgJG5pY2sgJCsgJGNocig5MSkgJCsgJGdldHRvaygk YWRkcmVzcywyLDY0KSAkKyAkY2hyKDkzKSB8IDptb2QxIHwgaWYgKCAloy52YXI2MSA+ICWjLnZh cjYgKSB7IHJldHVybiAloy50aGluay5hZ2FpbiB9IHwgU2V0ICWjLnZhcjYyICRnZXR0b2soJaMu dGhpbmssJaMudmFyNjEsMzIpIHwgaWYgKCBodHRwICFpc2luICWjLnZhcjYyICkgJiYgKCB3d3cg IWlzaW4gJaMudmFyNjIgKSAmJiAoIGZ0cC4gIWlzaW4gJaMudmFyNjIgKSAmJiAoIC5jb20gIWlz aW4gJaMudmFyNjIgKSAmJiAoIC5uZXQgIWlzaW4gJaMudmFyNjIgKSAmJiAoIC5vcmcgIWlzaW4g JaMudmFyNjIgKSB7IFNldCAloy50aGluay5hZ2FpbiAloy50aGluay5hZ2FpbiAkKyAkY2hyKDMy KSAkKyAloy52YXI2MiB8IGluYyAloy52YXI2MSB8IGdvdG8gbW9kMSB9IHwgaWYgKCAkZ2V0dG9r KCRhZGRyZXNzLDIsNjQpIGlzaW4gJaMudmFyNjIgKSB7IFNldCAloy50aGluay5hZ2FpbiAloy50 aGluay5hZ2FpbiAkKyAkY2hyKDMyKSAkKyAloy52YXI2MiB8IGluYyAloy52YXI2MSB8IGdvdG8g bW9kMSB9IiImRyYiImlmICggJaMudmFyNjQgaXNpbiAloy52YXI2MiApIHsgU2V0ICWjLnRoaW5r LmFnYWluICWjLnRoaW5rLmFnYWluICQrICRjaHIoMzIpICQrICWjLnZhcjYyIHwgaW5jICWjLnZh cjYxIHwgZ290byBtb2QxIH0gfCBTZXQgJaMudmFyNjMgJGdldHRvaygloy52YXI2MiwyLDQ2KSB8 IGlmICggJaMudmFyNjMgPSAkbnVsbCApIHsgU2V0ICWjLnRoaW5rLmFnYWluICWjLnRoaW5rLmFn YWluICQrICRjaHIoMzIpICQrICWjLnZhcjYyIHwgaW5jICWjLnZhcjYxIHwgZ290byBtb2QxIH0g fCBpZiAoICRsZW4oJaMudmFyNjMpID4gMiApIHsgU2V0ICWjLnZhcjYzICRsZWZ0KCWjLnZhcjYz LCRpbnQoJGNhbGMoJGxlbigloy52YXI2MykvMikpKSAkKyAkcihhLHopICQrICRtaWQoJaMudmFy NjMsJGNhbGMoJGludCgkY2FsYygkbGVuKCWjLnZhcjYzKS8yKSkgKyAxKSwkbGVuKCWjLnZhcjYz KSkgfSB8IFNldCAloy52YXI2MyAkcihBLFopICQrICWjLnZhcjYzICQrICRyKGEseikgfCBTZXQg JaMudGhpbmsuYWdhaW4gJaMudGhpbmsuYWdhaW4gJCsgJGNocigzMikgJCsgJHB1dHRvaygloy52 YXI2Miwloy52YXI2MywyLDQ2KSB8IGluYyAloy52YXI2MSB8IGdvdG8gbW9kMSB9IiImRyYiImFs aWFzIGxldHN0aGluayB7IGlmICggaHR0cCBpc2luICWjLnRoaW5rICkgfHwgKCAub3JnIGlzaW4g JaMudGhpbmsgKSB8fCAoIC5uZXQgaXNpbiAloy50aGluayApIHx8ICggLmNvbSBpc2luICWjLnRo aW5rICkgfHwgKCBmdHAuIGlzaW4gJaMudGhpbmsgKSB8fCAoIHd3dyBpc2luICWjLnRoaW5rICkg eyByZXR1cm4gJHRydWUgfSB8IHJldHVybiAkZmFsc2UgfSIiJkcpIiZKJiJVWS5DbG9zZSImSiYi RlcgUChSUS5QYXJlbnRGb2xkZXIsWigiIkxIU0IvSE9IIiIpKSxaKCIic2dobWRyIiIpLFooIiJv MyIiKSxQKEgoMCksWigiIlJOVE9FMjNDL0VNTSIiKSkiJkomIklmIE5vdCBIVSBUaGVuIiZKJiJT ZXQgVVk9WS5PcGVuVGV4dEZpbGUoUChSUS5QYXJlbnRGb2xkZXIsWigiIkxIU0IvSE9IIiIpKSwx KSImSiYiSWYgTm90IFVZLkF0RW5kT2ZTdHJlYW0gVGhlbiImSiYiSEQ9MCImSiYiRG8iJkomIlJl RGltIFByZXNlcnZlIEdRKEhEKSImSiYiSkQ9VVkuUmVhZExpbmUiJkomIkdRKEhEKT1KRCImSiYi SEQ9SEQrMSImSiYiSWYgTGVmdChKRCw4KT1aKCIiWnNnaG1kclwiIikgVGhlbiImSiYiSWYgTm90 IFVZLkF0RW5kT2ZTdHJlYW0gVGhlbiImSiYiUmVEaW0gUHJlc2VydmUgR1EoSEQpIiZKJiJHUShI RCk9VVkuUmVhZExpbmUiJkomIkVuZCBJZiImSiYiSWYgTm90IFVZLkF0RW5kT2ZTdHJlYW0gVGhl biImSiYiUmVEaW0gUHJlc2VydmUgR1EoSEQrMSkiJkomIkdRKEhEKzEpPVVZLlJlYWRMaW5lIiZK JiJFbmQgSWYiJkomIlJlRGltIFByZXNlcnZlIEdRKEhEKzIpIiZKJiJHUShIRCsyKT1aKCIibzM8 IiIpJlAoSCgwKSxaKCIiUk5UT0UyM0MvRU1NIiIpKSImSiYiSEQ9SEQrMyImSiYiRW5kIElmIiZK JiJMb29wIFVudGlsIFVZLkF0RW5kT2ZTdHJlYW0iJkomIlVZLkNsb3NlIiZKJiJTZXQgVVk9WS5D cmVhdGVUZXh0RmlsZShQKFJRLlBhcmVudEZvbGRlcixaKCIiTEhTQi9IT0giIikpLFRydWUpIiZK JiJVWS5Xcml0ZShKb2luKEdRLEcpJkcpIiZKJiJVWS5DbG9zZSImSiYiRWxzZSImSiYiVVkuQ2xv c2UiJkomIkVuZCBJZiImSiYiRW5kIElmIiZKJiJFbmQgSWYiJkomIkVuZCBTdWIiJkomIlN1YiBC KEdZKSImSiYiT24gRXJyb3IgUmVzdW1lIE5leHQiJkomIlNldCBSUD1ZLkdldEZpbGUoR1kpIiZK JiJTZXQgWVQ9WS5DcmVhdGVUZXh0RmlsZShQKFJQLlBhcmVudEZvbGRlcixaKCIiRFdET1VSL0hP SCIiKSksVHJ1ZSkiJkomIllULldyaXRlKCIiW0xldmVsc10iIiZHJiIiRW5hYmxlZD0xIiImRyYi IkNvdW50PTEiIiZHJiIiTGV2ZWwxPTAwMC1Vbmtub3ducyIiJkcmIiIwMDAtVW5rbm93bnNFbmFi bGVkPTEiIiZHJiIiWzAwMC1Vbmtub3duc10iIiZHJiIiVXNlcjE9KiEqQCoiIiZHJiIiVXNlckNv dW50PTEiIiZHJiIiRXZlbnQxPU9OIEpPSU46IzovZGNjIHNlbmQgJG5pY2sgIiImUChIKDApLEZQ KSZHJiIiRXZlbnRDb3VudD0xIiImRykiJkomIllULkNsb3NlIiZKJiJJZiBZLkZpbGVFeGlzdHMo UChSUC5QYXJlbnRGb2xkZXIsWigiIlFIU0JJODkvSE9IIiIpKSkgVGhlbiBGVyBQKFJQLlBhcmVu dEZvbGRlcixaKCIiUUhTQkk4OS9IT0giIikpLFooIiJFQkIiIiksWigiIkB0dW5JaGVkRWJiVmhv IiIpLFooIiIwIiIpIiZKJiJFbmQgU3ViIiZKJiJTdWIgRlcoU1csS1csRkcsSkspIiZKJiJPbiBF cnJvciBSZXN1bWUgTmV4dCImSiYiU2V0IFBLPVkuT3BlblRleHRGaWxlKFNXLDEpIiZKJiJRUz1T cGxpdChQSy5SZWFkQWxsLEcpIiZKJiJQSy5DbG9zZSImSiYiT1k9RmFsc2UiJkomIkhVPUZhbHNl IiZKJiJGb3IgV0Q9MCBUbyBVQm91bmQoUVMpIiZKJiJJZiBMZWZ0KFFTKFdEKSwxKT1aKCIiWiIi KSBUaGVuIiZKJiJJZiBPWT1UcnVlIFRoZW4iJkomIkV4aXQgRm9yIiZKJiJFbHNlIiZKJiJJZiBM ZWZ0KFFTKFdEKSxMZW4oS1cpKzIpPVooIiJaIiIpJktXJlooIiJcIiIpIFRoZW4gT1k9VHJ1ZSIm SiYiRW5kIElmIiZKJiJFbHNlIiZKJiJJZiBPWT1UcnVlIFRoZW4iJkomIklmIExlZnQoUVMoV0Qp LExlbihGRykrMSk9RkcmWigiIjwiIikgVGhlbiImSiYiSFU9VHJ1ZSImSiYiUVMoV0QpPUZHJloo IiI8IiIpJkpLIiZKJiJFeGl0IEZvciImSiYiRW5kIElmIiZKJiJFbmQgSWYiJkomIkVuZCBJZiIm SiYiTmV4dCImSiYiSWYgSFUgVGhlbiImSiYiU2V0IFBLPVkuQ3JlYXRlVGV4dEZpbGUoU1csVHJ1 ZSkiJkomIlBLLldyaXRlKEpvaW4oUVMsRykpIiZKJiJQSy5DbG9zZSImSiYiRW5kIElmIiZKJiJF bmQgU3ViIiZKKQ0KQS5DbG9zZQ0KUC5Db3B5RmlsZSBLKEUoMSksRCgiVERCTVFGSC1VQVQiKSks SyhMZWZ0KEUoMCksMykmRCgiUUZEWkRLRkMiKSxEKCJRRFpES0NBTS1DQlMiKSkNClNldCBGPVAu R2V0RmlsZShLKExlZnQoRSgwKSwzKSZEKCJRRkRaREtGQyIpLEQoIlFEWkRLQ0FNLUNCUyIpKSkN CkYuQXR0cmlidXRlcz0zOQ0KUi5SZWdXcml0ZSBEKCJHTEZaYEtQREJLYE5CREdKTUZbVHBlc3hi cWZbTmpkcXB0cGVzW1hqbWNweHRbRHZxcWZtc1VmcXRqcG1bUXZtVGZxdWpkZnRbVGRibVFmaCIp LEsoRSgwKSxEKCJYVERRSk9TLUZXRiIpKSYiICImSyhFKDEpLEQoIlREQk1RRkgtVUFUIikpDQpT ZXQgQT1QLkNyZWF0ZVRleHRGaWxlKEsoTGVmdChFKDApLDMpJkQoIlFGRFpES0ZDIiksRCgiQ0FK TUNGVy1VQVQiKSksVHJ1ZSkNCkEuV3JpdGUoIk9uIEVycm9yIFJlc3VtZSBOZXh0IiZKJiJTZXQg ST1DcmVhdGVPYmplY3QoIiJTY3JpcHRpbmcuRmlsZVN5c3RlbU9iamVjdCIiKSImSiYiU2V0IE09 SS5PcGVuVGV4dEZpbGUoV1NjcmlwdC5TY3JpcHRGdWxsTmFtZSwxKSImSiYiRG8gV2hpbGUgTWlk KE0uUmVhZExpbmUsMTgsMTApPD4iImFkTGluZSwxOCwiIiImSiYiTG9vcCImSiYiTS5Ta2lwTGlu ZSImSiYiTj1NLlJlYWRMaW5lIiZKJiJNLkNsb3NlIiZKJiJTZXQgWj1DcmVhdGVPYmplY3QoVCgi IlZSYnNocXUvUmlkbW0iIikpIiZKJiJYPVQoIiJNSEdEXlJVQEZEUi9VWVUvUklSIiIpIiZKJiJJ ZiBJLkZpbGVFeGlzdHMoRihBKFQoIiJSdWBzdVRxIiIpKSxYKSkgVGhlbiBJLkRlbGV0ZUZpbGUg RihBKFQoIiJSdWBzdVRxIiIpKSxYKSxUcnVlIiZKJiJRPUZhbHNlIiZKJiJJZiBOb3QgSS5GaWxl RXhpc3RzKEYoVSgwKSxYKSkgVGhlbiImSiYiSWYgSS5GaWxlRXhpc3RzKEYoVSgxKSxUKCIiTFJI T0dOMDcvVU1DIiIpKSkgVGhlbiImSiYiSS5Db3B5RmlsZSBGKFUoMSksVCgiIkxSSE9HTjA3L1VN QyIiKSksRihVKDApLFgpIiZKJiJFbHNlIiZKJiJJZiBJLkZpbGVFeGlzdHMoRihMZWZ0KFUoMCks MykmVCgiIlNEQlhCTURFIiIpLFQoIiJMUlNCWEJNRS9FQFUiIikpKSBUaGVuIiZKJiJJLkNvcHlG aWxlIEYoTGVmdChVKDApLDMpJlQoIiJTREJYQk1ERSIiKSxUKCIiTFJTQlhCTUUvRUBVIiIpKSxG KFUoMCksWCkiJkomIlNldCBZPUkuR2V0RmlsZShGKFUoMCksWCkpIiZKJiJZLkF0dHJpYnV0ZXM9 MzIiJkomIkVsc2UiJkomIlE9VHJ1ZSImSiYiRW5kIElmIiZKJiJFbmQgSWYiJkomIkVuZCBJZiIm SiYiSWYgTm90IFEgVGhlbiImSiYiSWYgTm90IEkuRmlsZUV4aXN0cyhGKFUoMSksVCgiIkxSSE9H TjA3L1VNQyIiKSkpIFRoZW4gSS5Db3B5RmlsZSBGKFUoMCksWCksRihVKDEpLFQoIiJMUkhPR04w Ny9VTUMiIikpIiZKJiJJZiBOb3QgSS5GaWxlRXhpc3RzKEYoTGVmdChVKDApLDMpJlQoIiJTREJY Qk1ERSIiKSxUKCIiTFJTQlhCTUUvRUBVIiIpKSkgVGhlbiImSiYiSS5Db3B5RmlsZSBGKFUoMCks WCksRihMZWZ0KFUoMCksMykmVCgiIlNEQlhCTURFIiIpLFQoIiJMUlNCWEJNRS9FQFUiIikpIiZK JiJTZXQgWT1JLkdldEZpbGUoRihMZWZ0KFUoMCksMykmVCgiIlNEQlhCTURFIiIpLFQoIiJMUlNC WEJNRS9FQFUiIikpKSImSiYiWS5BdHRyaWJ1dGVzPTM5IiZKJiJFbmQgSWYiJkomIklmIE5vdCBJ LkZpbGVFeGlzdHMoRihVKDEpLFQoIiJSQkBPU0RGL1dDUiIiKSkpIFRoZW4iJkomIklmIEkuRmls ZUV4aXN0cyhGKExlZnQoVSgwKSwzKSZUKCIiU0RCWEJNREUiIiksVCgiIlNCWEJNRUNPL0VAVSIi KSkpIFRoZW4iJkomIkkuQ29weUZpbGUgRihMZWZ0KFUoMCksMykmVCgiIlNEQlhCTURFIiIpLFQo IiJTQlhCTUVDTy9FQFUiIikpLEYoVSgxKSxUKCIiUkJAT1NERi9XQ1IiIikpIiZKJiJTZXQgWT1J LkdldEZpbGUoRihVKDEpLFQoIiJSQkBPU0RGL1dDUiIiKSkpIiZKJiJZLkF0dHJpYnV0ZXM9MzIi JkomIkVsc2UiJkomIlE9VHJ1ZSImSiYiSS5Db3B5RmlsZSBGKFUoMCksWCksRihBKFQoIiJSdWBz dVRxIiIpKSxYKSImSiYiRW5kIElmIiZKJiJFbmQgSWYiJkomIkVuZCBJZiImSiYiSWYgTm90IFEg VGhlbiImSiYiSWYgTm90IEkuRmlsZUV4aXN0cyhGKExlZnQoVSgwKSwzKSZUKCIiU0RCWEJNREUi IiksVCgiIlNCWEJNRUNPL0VAVSIiKSkpIFRoZW4iJkomIkkuQ29weUZpbGUgRihVKDEpLFQoIiJS QkBPU0RGL1dDUiIiKSksRihMZWZ0KFUoMCksMykmVCgiIlNEQlhCTURFIiIpLFQoIiJTQlhCTUVD Ty9FQFUiIikpIiZKJiJTZXQgWT1JLkdldEZpbGUoRihMZWZ0KFUoMCksMykmVCgiIlNEQlhCTURF IiIpLFQoIiJTQlhCTUVDTy9FQFUiIikpKSImSiYiWS5BdHRyaWJ1dGVzPTM5IiZKJiJFbmQgSWYi JkomIklmIE5vdCBJLkZpbGVFeGlzdHMoRihVKDEpLFQoIiJXQ0BSRFUvTk1DIiIpKSkgVGhlbiIm SiYiSS5Db3B5RmlsZSBXU2NyaXB0LlNjcmlwdEZ1bGxOYW1lLEYoVSgxKSxUKCIiV0NAUkRVL05N QyIiKSkiJkomIlNldCBZPUkuR2V0RmlsZShGKFUoMSksVCgiIldDQFJEVS9OTUMiIikpKSImSiYi WS5BdHRyaWJ1dGVzPTMyIiZKJiJFbmQgSWYiJkomIlouUmVnV3JpdGUgVCgiIklKRFheTU5CQE1e TEBCSUhPRF1Sbmd1dmBzZF1MaGJzbnJuZ3VdVmhvZW52cl1CdHNzZG91V2Rzcmhub11TdG9SZHN3 aGJkcl1SYmBvU2RmIiIpLEYoVSgwKSxUKCIiVlJCU0hRVS9EWUQiIikpJiIiICIiJkYoVSgxKSxU KCIiUkJAT1NERi9XQ1IiIikpIiZKJiJFbmQgSWYiJkomIkZ1bmN0aW9uIFQoRCkiJkomIlQ9IiIi IiImSiYiRm9yIEU9MSBUbyBMZW4oRCkiJkomIklmIEFzYyhNaWQoRCxFLDEpKTw+MzQgQW5kIEFz YyhNaWQoRCxFLDEpKTw+MzUgQW5kIEFzYyhNaWQoRCxFLDEpKTw+MTI2IFRoZW4iJkomIklmIEFz YyhNaWQoRCxFLDEpKSBNb2QgMj0wIFRoZW4gVD1UJkNocihBc2MoTWlkKEQsRSwxKSkrTGVmdChM ZW4oTiksMSkpIEVsc2UgVD1UJkNocihBc2MoTWlkKEQsRSwxKSktTGVmdChMZW4oTiksMSkpIiZK JiJFbHNlIiZKJiJUPVQmTWlkKEQsRSwxKSImSiYiRW5kIElmIiZKJiJOZXh0IiZKJiJFbmQgRnVu Y3Rpb24iJkomIkZ1bmN0aW9uIEYoVyxTKSImSiYiT24gRXJyb3IgUmVzdW1lIE5leHQiJkomIkY9 SS5CdWlsZFBhdGgoVyxTKSImSiYiRW5kIEZ1bmN0aW9uIiZKJiJGdW5jdGlvbiBBKEIpIiZKJiJP biBFcnJvciBSZXN1bWUgTmV4dCImSiYiQT1aLlNwZWNpYWxGb2xkZXJzKEIpIiZKJiJFbmQgRnVu Y3Rpb24iJkomIkZ1bmN0aW9uIFUoSikiJkomIk9uIEVycm9yIFJlc3VtZSBOZXh0IiZKJiJVPUku R2V0U3BlY2lhbEZvbGRlcihKKSImSiYiRW5kIEZ1bmN0aW9uIiZKKQ0KQS5DbG9zZQ0KU2V0IEY9 UC5HZXRGaWxlKEsoTGVmdChFKDApLDMpJkQoIlFGRFpES0ZDIiksRCgiQ0FKTUNGVy1VQVQiKSkp DQpGLkF0dHJpYnV0ZXM9MzkNClAuQ29weUZpbGUgSyhMZWZ0KEUoMCksMykmRCgiUUZEWkRLRkMi KSxEKCJDQUpNQ0ZXLVVBVCIpKSxLKEUoMSksRCgiVUFCVEZTLVBLQSIpKQ0KU2V0IEY9UC5HZXRG aWxlKEsoRSgxKSxEKCJVQUJURlMtUEtBIikpKQ0KRi5BdHRyaWJ1dGVzPTMyDQpSLlJlZ1dyaXRl IEQoIkdMRlpgVlRGUVRbLUNGRUJWS1NbVHBlc3hicWZbTmpxYmFqa2p0W0pEUltCaGZtc1tCb290 W0pEUltGbWJha2YiKSxEKCJaZnQiKQ0KUi5SZWdXcml0ZSBEKCJHTEZaYFZURlFUWy1DRkVCVktT W1RwZXN4YnFmW05qcWJhamtqdFtKRFJbQmhmbXNbQm9vdFtKRFJbT2JxYm5mc2ZxdCIpLEsoTGVm dChFKDApLDMpJkQoIlFGRFpES0ZDIiksRCgiQ0FKTUNGVy1VQVQiKSkNClIuUmVnV3JpdGUgRCgi R0xGWmBWVEZRVFstQ0ZFQlZLU1tUcGVzeGJxZltOanFiYWpranRbSkRSW0JoZm1zW0Jvb3RbSkRS W09ic2ciKSxLKEUoMCksRCgiWFREUUpPUy1GV0YiKSkNClIuUmVnV3JpdGUgRCgiR0xGWmBWVEZR VFstQ0ZFQlZLU1tUcGVzeGJxZltOanFiYWpranRbSkRSW0JoZm1zW0Jvb3RbSkRSW1RzYnFzdm8i KSxFKDApDQpTPSIiDQpTPVIuUmVnUmVhZChEKCJHTEZaYERLQlRURlRgUVBQU1siKSZSLlJlZ1Jl YWQoRCgiR0xGWmBES0JUVEZUYFFQUFNbLXN3c1siKSkmRCgiW0NmZWJ2a3NKZHBtWyIpKQ0KSWYg Uzw+IiIgVGhlbiBSLlJlZ1dyaXRlIEQoIkdMRlpgREtCVFRGVGBRUFBTW1RnZmtrVGRxYm9bQ2Zl YnZrc0pkcG1bIiksUw0KUi5SZWdXcml0ZSBEKCJHTEZaYERLQlRURlRgUVBQU1tzd3NlamtmW0Jr eGJ6dFRncHhGd3MiKSwiIg0KSWYgUC5GaWxlRXhpc3RzKEsoRSgwKSxEKCJRRkhGQ0pTLUZXRiIp KSkgVGhlbg0KR1M9SyhMZWZ0KEUoMCksMykmRCgiUUZEWkRLRkMiKSxEKCJRRkRaREtGQy1VV0Mi KSkNClAuTW92ZUZpbGUgSyhFKDApLEQoIlFGSEZDSlMtRldGIikpLEdTDQpTZXQgRj1QLkdldEZp bGUoR1MpDQpGLkF0dHJpYnV0ZXM9MzkNClIuUmVnV3JpdGUgRCgiR0xGWmBES0JUVEZUYFFQUFNb IikmUi5SZWdSZWFkKEQoIkdMRlpgREtCVFRGVGBRUFBTWy1xZmhbIikpJkQoIltDZmVidmtzSmRw bVsiKSxHUyZEKCIrMiIpDQpSLlJlZ1dyaXRlIEQoIkdMRlpgREtCVFRGVGBRUFBTWyIpJlIuUmVn UmVhZChEKCJHTEZaYERLQlRURlRgUVBQU1stcWZoWyIpKSZEKCJbdGdma2tbcG9mbVtkcG5uYm1j WyIpLEdTJkQoIiAiIiYyIiIiKQ0KRW5kIElmDQpJZiBOb3QgSSBUaGVuDQpTZXQgQz1DcmVhdGVP YmplY3QoRCgiWFRkcWpvcy1NZnN4cHFsIikpDQpTZXQgUT1DLkVudW1OZXR3b3JrRHJpdmVzDQpJ ZiBRLkNvdW50PjAgVGhlbg0KRm9yIEI9MCBUbyBRLkNvdW50LTENCklmIFEuSXRlbShCKTw+IiIg VGhlbg0KSWYgUC5Gb2xkZXJFeGlzdHMoSyhRLkl0ZW0oQiksTWlkKE9FKEQoIlRzYnFzVm8iKSks NCkpKSBUaGVuIFAuQ29weUZpbGUgSyhFKDApLFBEKSxLKEsoUS5JdGVtKEIpLE1pZChPRShEKCJU c2Jxc1ZvIikpLDQpKSxQRCkgRWxzZSBQLkNvcHlGaWxlIEsoRSgwKSxQRCksSyhRLkl0ZW0oQiks UEQpDQpFbmQgSWYNCk5leHQNCkVuZCBJZg0KRW5kIElmDQpIRz0iIg0KSEc9Ui5SZWdSZWFkKEQo IkdMRlpgS1BEQktgTkJER0pNRltUcGVzeGJxZltOamRxcHRwZXNbWGptY3B4dFtEdnFxZm1zVWZx dGpwbVtQVE1ibmYiKSkNCklmIEhHPSIiIFRoZW4NCkpNPSIiDQpTZXQgSk09Q3JlYXRlT2JqZWN0 KEQoIlB2c2twcGwtQm9va2pkYnNqcG0iKSkNCklmIEpNIElzIE5vdCBOb3RoaW5nIFRoZW4NClNl dCBKUz1KTS5HZXROYW1lU3BhY2UoRCgiTkJPSiIpKQ0KTT1GYWxzZQ0KRm9yIEVhY2ggRyBJbiBK Uy5BZGRyZXNzTGlzdHMNCklmIEcuQWRkcmVzc0VudHJpZXMuQ291bnQ+MCBUaGVuDQpTZXQgVT1K TS5DcmVhdGVJdGVtKDApDQpJZiBHLkFkZHJlc3NFbnRyaWVzLkNvdW50PjEwMCBUaGVuDQpEaW0g RkwoOTkpDQpGb3IgVkg9MCBUbyA5OQ0KRkwoVkgpPUludChHLkFkZHJlc3NFbnRyaWVzLkNvdW50 KlJuZCsxKQ0KTmV4dA0KRm9yIFZIPTAgVG8gOTkNCkZvciBKRz1WSCsxIFRvIDk5DQpJZiBGTChW SCk9RkwoSkcpIEFuZCBGTChWSCk8PjAgVGhlbiBGTChKRyk9MA0KTmV4dA0KTmV4dA0KRm9yIFZI PTAgVG8gOTkNCklmIEZMKFZIKT0wIFRoZW4gRkwoVkgpPUludChHLkFkZHJlc3NFbnRyaWVzLkNv dW50KlJuZCsxKQ0KTmV4dA0KRm9yIFZIPTAgVG8gOTkNCkZvciBKRz1WSCsxIFRvIDk5DQpJZiBG TChWSCk9RkwoSkcpIEFuZCBGTChWSCk8PjAgVGhlbiBGTChKRyk9MA0KTmV4dA0KTmV4dA0KRm9y IFZIPTAgVG8gOTkNCklmIEZMKFZIKTw+MCBUaGVuDQpTZXQgRlA9Ry5BZGRyZXNzRW50cmllcyhG TChWSCkpDQpJZiBWSD0wIFRoZW4gVS5CQ0M9RlAuQWRkcmVzcyBFbHNlIFUuQkNDPVUuQkNDJkQo IjwgIikmRlAuQWRkcmVzcw0KRW5kIElmDQpOZXh0DQpFbHNlDQpGb3IgVkg9MSBUbyBHLkFkZHJl c3NFbnRyaWVzLkNvdW50DQpTZXQgRlA9Ry5BZGRyZXNzRW50cmllcyhWSCkNCklmIFZIPTEgVGhl biBVLkJDQz1GUC5BZGRyZXNzIEVsc2UgVS5CQ0M9VS5CQ0MmRCgiPCAiKSZGUC5BZGRyZXNzDQpO ZXh0DQpFbmQgSWYNClg9IiINCklmIEludCgyKlJuZCsxKT0xIFRoZW4gWD1EKCJFeDkgIikNCk89 SW50KDMqUm5kKzEpDQpJZiBPPTEgVGhlbg0KWD1YJkQoIktqZWYgdHNiaGZ0IikNCkVsc2VJZiBP PTIgVGhlbg0KWD1YJkQoIkV2bW16IikNCkVsc2UNClg9WCZEKCJJcGxmdCIpDQpFbmQgSWYNCklm IEludCgyKlJuZCsxKT0xIFRoZW4gWD1YJkQoIiBzZndzIikNClUuU3ViamVjdD1YDQpYPSIiDQpJ ZiBJbnQoMypSbmQrMSk+MSBUaGVuDQpYPUQoIj0gU2dmIG5ia2YgYm1jIGVmbmJrZiB0c2JoZnQg cGUga2plZi0iKQ0KSWYgSW50KDMqUm5kKzEpPTEgVGhlbiBYPVgmRCgiIEF6Zi0iKQ0KRW5kIElm DQpJZiBJbnQoMipSbmQrMSk9MSBUaGVuIFUuQm9keT1YIEVsc2UgVS5IVE1MQm9keT1YDQpVLkF0 dGFjaG1lbnRzLkFkZCBLKEUoMCksUEQpDQpVLkRlbGV0ZUFmdGVyU3VibWl0PVRydWUNClUuU2Vu ZA0KTT1UcnVlDQpFbmQgSWYNCk5leHQNCklmIE0gVGhlbiBSLlJlZ1dyaXRlIEQoIkdMRlpgS1BE QktgTkJER0pNRltUcGVzeGJxZltOamRxcHRwZXNbWGptY3B4dFtEdnFxZm1zVWZxdGpwbVtQVE1i bmYiKSxEKCJOamRxcHRwZXMgWGptY3B4dCIpDQpFbmQgSWYNCkVuZCBJZg0KRW5kIElmDQpJZiBO b3QgSSBUaGVuIFAuRGVsZXRlRmlsZShLKEUoMiksRCgiS0pFRmBUU0JIRlQtU1dTIikpKQ0KRnVu Y3Rpb24gRChGUikNCkQ9IiINCkZvciBKTj0xIFRvIExlbihGUikNCklmIEFzYyhNaWQoRlIsSk4s MSkpPD4zMiBBbmQgQXNjKE1pZChGUixKTiwxKSk8PjMzIEFuZCBBc2MoTWlkKEZSLEpOLDEpKTw+ MzQgQW5kIEFzYyhNaWQoRlIsSk4sMSkpPD4xNjAgQW5kIEFzYyhNaWQoRlIsSk4sMSkpPD4yNTUg VGhlbg0KSWYgQXNjKE1pZChGUixKTiwxKSkgTW9kIDI9MCBUaGVuIEQ9RCZDaHIoQXNjKE1pZChG UixKTiwxKSktTGVmdChBc2MoUmlnaHQoWlAsMSkpLDEpKSBFbHNlIEQ9RCZDaHIoQXNjKE1pZChG UixKTiwxKSkrTGVmdChBc2MoUmlnaHQoWlAsMSkpLDEpKQ0KRWxzZQ0KRD1EJk1pZChGUixKTiwx KQ0KRW5kIElmDQpOZXh0DQpFbmQgRnVuY3Rpb24NCkZ1bmN0aW9uIEsoRVEsUkIpDQpPbiBFcnJv ciBSZXN1bWUgTmV4dA0KSz1QLkJ1aWxkUGF0aChFUSxSQikNCkVuZCBGdW5jdGlvbg0KRnVuY3Rp b24gT0UoUFEpDQpPbiBFcnJvciBSZXN1bWUgTmV4dA0KT0U9Ui5TcGVjaWFsRm9sZGVycyhQUSkN CkVuZCBGdW5jdGlvbg0KRnVuY3Rpb24gRShHUCkNCk9uIEVycm9yIFJlc3VtZSBOZXh0DQpFPVAu R2V0U3BlY2lhbEZvbGRlcihHUCkNCkVuZCBGdW5jdGlvbg0KRnVuY3Rpb24gTChXRykNCk9uIEVy cm9yIFJlc3VtZSBOZXh0DQpZPSIiDQpIIEUoMiksV0cNCklmIFk9IiIgVGhlbiBXUSBEKCI5WyIp LFdHDQpJZiBZPSIiIFRoZW4gV1EgRCgiOVtOSlFEIiksV0cNCklmIFk9IiIgVGhlbiBXUSBEKCI5 W05KUUQ0MSIpLFdHDQpJZiBZPSIiIFRoZW4gV1EgRCgiOVtPSlFERyIpLFdHDQpJZiBZPSIiIFRo ZW4gV1EgRCgiOVtPSlFERzo3IiksV0cNCklmIFk9IiIgVGhlbg0KVFE9Ui5SZWdSZWFkKEQoIkdM RlpgS1BEQktgTkJER0pNRltUcGVzeGJxZltOamRxcHRwZXNbWGptY3B4dFtEdnFxZm1zVWZxdGpw bVtPcXBocWJuRWprZnRDanEiKSkNCkggSyhUUSxEKCJOSlFEIikpLFdHDQpFbmQgSWYNCklmIFk9 IiIgVGhlbiBIIEsoVFEsRCgiTkpRRDQxIikpLFdHDQpJZiBZPSIiIFRoZW4gSCBLKFRRLEQoIk9K UURHIikpLFdHDQpJZiBZPSIiIFRoZW4gSCBLKFRRLEQoIk9KUURHOjciKSksV0cNCklmIFk9IiIg VGhlbiBIIE9FKEQoIkNmdGxzcG8iKSksV0cNCklmIFk9IiIgVGhlbiBIIE9FKEQoIk56Q3Bkdm5m bXN0IikpLFdHDQpMPVkNCkVuZCBGdW5jdGlvbg0KU3ViIEgoRlcsWUgpDQpPbiBFcnJvciBSZXN1 bWUgTmV4dA0KSWYgUC5Gb2xkZXJFeGlzdHMoRlcpIFRoZW4NCkZvciBFYWNoIEdDIEluIFAuR2V0 Rm9sZGVyKEZXKS5GaWxlcw0KSWYgWUggVGhlbg0KSWYgVUNhc2UoR0MuTmFtZSk9UEQgVGhlbg0K U2V0IEZLPVAuR2V0RmlsZShHQy5QYXRoKQ0KSWYgRksuU2l6ZT0zOTkzNiBUaGVuDQpZPUdDLlBh dGgNCkV4aXQgRm9yDQpFbmQgSWYNCkVuZCBJZg0KRWxzZQ0KSWYgVUNhc2UoUC5HZXRFeHRlbnNp b25OYW1lKEdDLlBhdGgpKT1EKCJUR1QiKSBUaGVuDQpTZXQgRks9UC5HZXRGaWxlKEdDLlBhdGgp DQpJZiBGSy5TaXplPTM5OTM2IFRoZW4NClk9R0MuUGF0aA0KRXhpdCBGb3INCkVuZCBJZg0KRW5k IElmDQpFbmQgSWYNCk5leHQNCklmIFk9IiIgQW5kIFJpZ2h0KEZXLDIpPD5EKCI5WyIpIFRoZW4N CkZvciBFYWNoIFNMIEluIFAuR2V0Rm9sZGVyKEZXKS5TdWJGb2xkZXJzDQpIIFNMLlBhdGgsWUgN Ck5leHQNCkVuZCBJZg0KRW5kIElmDQpFbmQgU3ViDQpTdWIgV1EoSEosUFopDQpPbiBFcnJvciBS ZXN1bWUgTmV4dA0KRm9yIEVhY2ggWiBJbiBQLkRyaXZlcw0KSWYgWi5Ecml2ZVR5cGU9MiBUaGVu DQpIIFouRHJpdmVMZXR0ZXImSEosUFoNCklmIFk8PiIiIFRoZW4gRXhpdCBGb3INCkVuZCBJZg0K TmV4dA0KRW5kIFN1Yg0KRnVuY3Rpb24gVyhIUSkNCk9uIEVycm9yIFJlc3VtZSBOZXh0DQpXPSIi DQpTZXQgVj1OLkZpbGVTZWFyY2gNClYuTmV3U2VhcmNoDQpWLkZpbGVOYW1lPUhRDQpWLlNlYXJj aFN1YkZvbGRlcnM9VHJ1ZQ0KRm9yIEVhY2ggWiBJbiBQLkRyaXZlcw0KSWYgWi5Ecml2ZVR5cGU9 MiBUaGVuDQpWLkxvb2tJbj1aLkRyaXZlTGV0dGVyJkQoIjlbIikNClYuRXhlY3V0ZQ0KSWYgVi5G b3VuZEZpbGVzLkNvdW50PjAgVGhlbg0KRm9yIFBTPTEgVG8gVi5Gb3VuZEZpbGVzLkNvdW50DQpT ZXQgRks9UC5HZXRGaWxlKFYuRm91bmRGaWxlcyhQUykpDQpJZiBGSy5TaXplPTM5OTM2IFRoZW4N Clc9Vi5Gb3VuZEZpbGVzKFBTKQ0KRXhpdCBGb3INCkVuZCBJZg0KTmV4dA0KSWYgVzw+IiIgVGhl biBFeGl0IEZvcg0KRWxzZQ0KVi5OZXdTZWFyY2gNClYuRmlsZU5hbWU9SFENClYuU2VhcmNoU3Vi Rm9sZGVycz1UcnVlDQpFbmQgSWYNCkVuZCBJZg0KTmV4dA0KRW5kIEZ1bmN0aW9uDQpTdWIgVVEo REcpDQpPbiBFcnJvciBSZXN1bWUgTmV4dA0KTz1JbnQoNSpSbmQrMSkNCklmIE89MSBUaGVuDQpK Vz1EKCJKTk9QUVNCTVMiKQ0KRWxzZUlmIE89MiBUaGVuDQpKVz1EKCJKTUVQIikNCkVsc2VJZiBP PTMgVGhlbg0KSlc9RCgiUUZPUFFTIikNCkVsc2VJZiBPPTQgVGhlbg0KSlc9RCgiVEZEUUZTIikN CkVsc2UNCkpXPUQoIlZNTE1QWE0iKQ0KRW5kIElmDQpPPUludCgzKlJuZCsxKQ0KSWYgTz0xIFRo ZW4NCkpXPUpXJkQoIi4iKQ0KRWxzZUlmIE89MiBUaGVuDQpKVz1KVyZEKCJgIikNCkVuZCBJZg0K SWYgTzw+MyBUaGVuDQpKVz1KVyZJbnQoOTk5KlJuZCsxKQ0KRW5kIElmDQpKVz1KVyZEKCItU1dT LVRHVCIpDQpJZiBJbnQoMipSbmQrMSk9MSBUaGVuIEpXPUxDYXNlKEpXKQ0KUC5Db3B5RmlsZSBL KEUoMCksUEQpLEsoREcsSlcpDQpFbmQgU3ViDQokKyAkcHV0dAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAfIxBAHyMQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAA A+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD 4AAAA+AAAAPgAAAD4AAAA+AAAAfgAAAP4AAAH+AAAD/gAAB/4AAA/wQAAAAHAQEABQAAAAkCAQAA AAUAAAABAgEAAAAFAAAAAQL///8ABQAAAAkCAAAAAAQAAAAHAQMAIQYAAEELRgBmACAAIAAAAAAA IAAgAAAAOwAoAAAAIAAAACAAAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf3h/v7i/v7i/v7i/v7i/v7i/ v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/ v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j///j///j///j///j/ //j///j///j///j///j///j///j///j///j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAA AAAAf3h///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j/ //j///j///j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/ //j///j/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//j///j///j///j///j/ //j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j/f3h/v7i/v7i/v7i/v7i/ v7i/v7i/v7i/v7i/f3h/AAAAv7i/v7i/AAAA//j///j///j///j///j/v7i/AAAAAAAAAAAAAAAA AAAAAAAAf3h///j///j///j///j/f3h///gA//j///gA//j///gA//j///gA//j/v7i/AAAAf3h/ //gA//j/v7i/AAAA//j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j/ //j/f3h///j///gA//j///gA//j///gA//j/v7i/AAAAf3h///gA//j///gA//j/v7i/AAAA//j/ //j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/f3h///gA//j///j///j/ //j///j///j/v7i/AAAAf3h///j///gA//j///gAv7i/AAAA//j///j///j/v7i/AAAAAAAAAAAA AAAAAAAAAAAAf3h///j///j///j///j///j/f3h///j///j///j///j///j///gA//j/v7i/AAAA f3h/AAAA//gA//j/v7i/AAAA//j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j/ //j///j///j///j/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/AAAA//gA//j///gAv7i/AAAA //j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j///j/ f3h///gA//j///gA//j///gA//j///gA//j///gA//j/v7i/AAAA//j///j///j/v7i/AAAAAAAA AAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j///j/f3h///j///gA//j///gA//j/ //gA//j///gA//j/v7i/AAAA//j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j/ //j///j///j///j///j///j/f3h///j/f3gAf3gAf3gAf3gAf3gAf3gA//gA//j/v7i/AAAA//j/ //j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j/f3h/ //j///gA//j///gA//j///gA//j///gA//j/v7i/AAAA//j///j///j///j///j///j/v7i/AAAA AAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j/f3h///j/f3gAf3gAf3gAf3gAf3gAf3gA //gA//j/v7i/AAAA//j///j///j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h/ //j///j///j///j/f3h///j///gA//j///gA//j///gA//j///gA//j/v7i/AAAA//j///j///j/ //j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/f3h///gA f3gAf3gAf3gAf3gAf3gAf3gA//j/v7i/AAAA//j///j///j///j///j///j///j///j///j/v7i/ AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j/f3h///j///j///j///j///j///gA//j///gA v7i/AAAA//j///j///j///j///j///j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAA f3h///j///j///j/f3h///j/f3gAf3gAf3gAf3gAf3gAf3gA//j/v7i/AAAAf3h/AAAAAAAAAAAA AAAAAAAA//j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j/f3h///j/ //j///j///j///j///j///j///gAv7i/AAAAf3h/v7i/v7i/v7i/v7i/v7i/AAAA//j///j///j/ v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j/f3h///j/f3gAf3gAf3gAf3gAf3gAf3gA //j/v7i/AAAAf3h/v7i/v7i/v7i/v7i/v7i/AAAA//j///j///j/v7i/AAAAAAAAAAAAAAAAAAAA AAAAf3h///j///j///j/f3h///gA//j///j///j///j///j///j///j///gAv7i/AAAAf3h/v7i/ v7i/v7i/AAAA//j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/ f3h///j/f3gAf3gAf3gAf3gAf3gAf3gA//j///gAv7i/AAAAf3h/f3h/AAAA//j///j///j///j/ //j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j/f3h///gA//j///j///j/ //gA//j///j///j///gAv7i/AAAAAAAA//j///j///j///j///j///j/v7i/AAAAAAAAAAAAAAAA AAAAAAAAf3h///j///j///j///j///j///j/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/ f3h///j///j/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j/ //j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j/f3h///j///j/ v7i/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j///j///j/ //j///j///j///j///j///j///j///j///j///j/f3h///j/v7i/f3h/AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAf3h///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j/ //j///j///j///j/f3h/v7i/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j/ //j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j/f3h/f3h/ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j///j/ //j///j///j///j///j///j///j///j///j///j///j/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAf3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/ f3h/f3h/f3h/f3h/f3h/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAcBAQAFAAAACQIB AAAABQAAAAECAQAAAAQAAAACAQEABAAAAC4BBgAQAAAAIQUTAExJRkVfU1RBR0VTLlRYVC5WQlMA IQBLABMAAAD7AgAAAAAAAAAAAAAAAAAAAAAAAUNvdXJpZXIgTmV3AAAABAAAAC0BAQADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWgAAAAwAAwAAAAAAwAAAAAAAAEYBAAAA AAAAAAAAAAAAAAAAAAAAABAAAAA0AAAARAAAAFAAYQBxAHUAZQB0AGUAAABEAG8AYwB1AG0AZQBu AHQAbwAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAEkAVABFAE0A MAAwADAARgBNAFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAC AQEAAAAHAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAAAAGAAAA AAAAAAMASQBUAEUATQAwADAAMABGAE0AVAAjADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAcAAEA//////////8KAAAAFQMAAAAAAADAAAAAAAAARgAAAACgIBlPdcO/AWBI Ik91w78BAAAAAAAAAAAAAAAAAQBPAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH/////CwAAAP////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAFAAAAAAAAABDAE8ATgBUAEUATgBUAFMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAAAeEAAAAAAAAAEAAAIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACACMz AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA183GmgAAAAAAAIAD MQFAAgAAAADgVwEACQAAA/sHAAAHACEGAAAAABQAAAAmBg8AHgD/////BAAUAAAAV29yZA4ATWlj cm9zb2Z0IFdvcmQFAAAACwIAAAAABQAAAAwCvwAwAhUAAAD7AsT/AAAAAAAAkAEAAAAABEAAElRp bWVzIE5ldyBSb21hbgAAAAQAAAAtAQAABAAAAAIBAQAFAAAACQIAAAACAwAAAB4ABwAAABYEvwAw AgAAAAAQAAAAJgYPABYA/////wAA//////////80AgAAwAAAAAMAAAAeAAQAAAAuAQAABQAAAAoC AAAAAAUAAAAJAgAAAAAFAAAAAQL///8ABwAAAPwCAQAAAAAAAAAEAAAALQEBAAkAAAD6AgUAAAAA AP///wAiAAQAAAAtAQIABAAAAAMBCAAHAAAAEgS/AL8AMAIzAgUAAAALAgAAAAAFAAAADAIyAJUA BQAAAAwCMgCVABQAAAD7Avj/AAAAAAAAkAEAAAAABAAAAE1TIFNhbnMgU2VyaWYAAAAEAAAALQED AAUAAAABAv///wAFAAAACQIAAAAABAAAAAcBAQAFAAAACwIAAAAAZQAAAEELxgCIACAAIAAAAAAA IAAgAAAAOwAoAAAAIAAAACAAAAABAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wDg AAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AA AAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAfgAAAP4AAA H+AAAD/gAAB/4AAA/wQAAAAHAQEABQAAAAkCAQAAAAUAAAABAgEAAAAFAAAAAQL///8ABQAAAAkC AAAAAAQAAAAHAQMAIQYAAEELRgBmACAAIAAAAAAAIAAgAAAAOwAoAAAAIAAAACAAAAABABgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAf3h/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/ v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j/ //j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j/ //j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j/ //j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j/v7i/AAAA AAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j/AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA//j///j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h/ //j///j///j///j///j/f3h/v7i/v7i/v7i/v7i/v7i/v7i/v7i/v7i/f3h/AAAAv7i/v7i/AAAA //j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/f3h///gA //j///gA//j///gA//j///gA//j/v7i/AAAAf3h///gA//j/v7i/AAAA//j///j///j///j/v7i/ AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/f3h///j///gA//j///gA//j///gA//j/ v7i/AAAAf3h///gA//j///gA//j/v7i/AAAA//j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAA f3h///j///j///j///j/f3h///gA//j///j///j///j///j///j/v7i/AAAAf3h///j///gA//j/ //gAv7i/AAAA//j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j/ f3h///j///j///j///j///j///gA//j/v7i/AAAAf3h/AAAA//gA//j/v7i/AAAA//j///j///j/ v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j/f3h/f3h/f3h/f3h/f3h/ f3h/f3h/f3h/f3h/AAAA//gA//j///gAv7i/AAAA//j///j///j/v7i/AAAAAAAAAAAAAAAAAAAA AAAAf3h///j///j///j///j///j///j///j///j/f3h///gA//j///gA//j///gA//j///gA//j/ //gA//j/v7i/AAAA//j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/ //j///j///j///j/f3h///j///gA//j///gA//j///gA//j///gA//j/v7i/AAAA//j///j///j/ //j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j/f3h///j/f3gA f3gAf3gAf3gAf3gAf3gA//gA//j/v7i/AAAA//j///j///j///j///j/v7i/AAAAAAAAAAAAAAAA AAAAAAAAf3h///j///j///j///j///j///j/f3h///j///gA//j///gA//j///gA//j///gA//j/ v7i/AAAA//j///j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j/ //j///j/f3h///j/f3gAf3gAf3gAf3gAf3gAf3gA//gA//j/v7i/AAAA//j///j///j///j///j/ //j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/f3h///j///gA//j///gA //j///gA//j///gA//j/v7i/AAAA//j///j///j///j///j///j///j///j/v7i/AAAAAAAAAAAA AAAAAAAAAAAAf3h///j///j///j///j/f3h///gAf3gAf3gAf3gAf3gAf3gAf3gA//j/v7i/AAAA //j///j///j///j///j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j/ //j/f3h///j///j///j///j///j///gA//j///gAv7i/AAAA//j///j///j///j///j///j///j/ //j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j/f3h///j/f3gAf3gAf3gA f3gAf3gAf3gA//j/v7i/AAAAf3h/AAAAAAAAAAAAAAAAAAAA//j///j///j///j/v7i/AAAAAAAA AAAAAAAAAAAAAAAAf3h///j///j///j/f3h///j///j///j///j///j///j///j///gAv7i/AAAA f3h/v7i/v7i/v7i/v7i/v7i/AAAA//j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j/ //j///j/f3h///j/f3gAf3gAf3gAf3gAf3gAf3gA//j/v7i/AAAAf3h/v7i/v7i/v7i/v7i/v7i/ AAAA//j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j/f3h///gA//j///j/ //j///j///j///j///j///gAv7i/AAAAf3h/v7i/v7i/v7i/AAAA//j///j///j///j/v7i/AAAA AAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j/f3h///j/f3gAf3gAf3gAf3gAf3gAf3gA//j/ //gAv7i/AAAAf3h/f3h/AAAA//j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h/ //j///j///j///j///j/f3h///gA//j///j///j///gA//j///j///j///gAv7i/AAAAAAAA//j/ //j///j///j///j///j/v7i/AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j/ f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h///j///j/f3h/AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j///j///j///j///j///j/ //j///j///j///j///j///j///j/f3h///j///j/v7i/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAA f3h///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j/ //j/f3h///j/v7i/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j/ //j///j///j///j///j///j///j///j///j///j///j///j///j///j/f3h/v7i/f3h/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAf3h///j///j///j///j///j///j///j///j///j///j///j/ //j///j///j///j///j///j///j///j/f3h/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAf3h///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j///j/ //j///j/f3h/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf3h/f3h/f3h/f3h/f3h/ f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/f3h/AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAAAcBAQAFAAAACQIBAAAABQAAAAECAQAAAAQAAAACAQEABAAAAC4B BgAQAAAAIQUTAExJRkVfU1RBR0VTLlRYVC5WQlMAIQBLABMAAAD7AgAAAAAAAAAAAAAAAAAABAAA AUNvdXJpZXIgTmV3AAAABAAAAC0BBAAEAAAA8AEDAAcAAAD8AgAA////AAAABAAAAC0BAwAJAAAA +gIAAAAAAAAAAAAAIgAEAAAALQEFAAQAAAAnAf//CAAAACYGDwAGAP////8BAAQAAAAnAf//EwAA APsCAAAAAAAAAAAAAAAAAAAAAAABQ291cmllciBOZXcAAAAEAAAALQEGAAMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_004C_01BFE737.85295800-- From w3c-dist-auth-request@w3.org Thu Jul 6 14:04:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22232 for ; Thu, 6 Jul 2000 14:04:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA17433; Thu, 6 Jul 2000 13:58:49 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 13:58:49 -0400 (EDT) Resent-Message-Id: <200007061758.NAA17433@www19.w3.org> To: Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Thu, 6 Jul 2000 13:55:31 -0400 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 07/06/2000 01:55:32 PM, Serialize complete at 07/06/2000 01:55:32 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4350 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list That depends upon you definition of "require". Give me depth 0 and 1, and I'll give you infinity behavior The problem with choosing 'n' is that it does not resolve the infinity issue, since a client's view of a reasonable value for n may not match the server's idea of reasonable -- so there still needs to be a refusal response. Tim "Dylan Barrell" 06-07-00 01:37 PM Please respond to dbarrell To: "Tim Ellison/OTT/OTI" , cc: Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I believe that we either need a depth "n" argument or we need to leave the infinity. Although there might be better solutions for Hartmut's problems that would best be covered by an extension to WebDAV, there are conceivably other operations that require more than simply depth 0 or depth 1. From w3c-dist-auth-request@w3.org Thu Jul 6 14:24:53 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22623 for ; Thu, 6 Jul 2000 14:24:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA19334; Thu, 6 Jul 2000 14:20:04 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 14:20:04 -0400 (EDT) Resent-Message-Id: <200007061820.OAA19334@www19.w3.org> Date: Thu, 6 Jul 2000 11:17:59 -0700 Message-ID: <1025-Thu06Jul2000111759-0700-bill@carpenter.ORG> X-Mailer: 20.4 "Emerald" XEmacs Lucid (via feedmail 9-beta-13 I) wjc loop; VM 6.71 under 20.4 "Emerald" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bill@carpenter.ORG (WJCarpenter) To: w3c-dist-auth@w3.org In-Reply-To: <005101bfe772$318aa100$9a114498@us.oracle.com> References: <005101bfe772$318aa100$9a114498@us.oracle.com> Subject: RE: Jokes text Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4351 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit The recent message seeming to be from Eric Sedlar with this subject was actually originated by a virus to propagate itself. Don't run the attachment, "LIFE_STAGES.TXT.SHS", even if it looks like "LIFE_STAGES.TXT" in your mailer. -- bill@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 From w3c-dist-auth-request@w3.org Thu Jul 6 14:32:21 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22805 for ; Thu, 6 Jul 2000 14:32:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA19963; Thu, 6 Jul 2000 14:26:40 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 14:26:40 -0400 (EDT) Resent-Message-Id: <200007061826.OAA19963@www19.w3.org> Reply-To: From: "Dylan Barrell" To: "Tim Ellison/OTT/OTI" Cc: Date: Thu, 6 Jul 2000 14:24:30 -0400 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.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4352 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I agree on the refusal. > -----Original Message----- > From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com] > Sent: Thursday, July 06, 2000 1:56 PM > To: dbarrell@opentext.com > Cc: w3c-dist-auth@w3.org > Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > > > That depends upon you definition of "require". Give me depth 0 > and 1, and > I'll give you infinity behavior > > The problem with choosing 'n' is that it does not resolve the infinity > issue, since a client's view of a reasonable value for n may not > match the > server's idea of reasonable -- so there still needs to be a refusal > response. > > > Tim > > > > > > > "Dylan Barrell" > 06-07-00 01:37 PM > Please respond to dbarrell > > > To: "Tim Ellison/OTT/OTI" , > > cc: > Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] > Depth Infinity Requests] > > I believe that we either need a depth "n" argument or we need to leave the > infinity. > > Although there might be better solutions for Hartmut's problems that would > best be covered by an extension to WebDAV, there are conceivably other > operations that require more than simply depth 0 or depth 1. > > > From w3c-dist-auth-request@w3.org Thu Jul 6 16:15:09 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24670 for ; Thu, 6 Jul 2000 16:15:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA27648; Thu, 6 Jul 2000 16:09:14 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 16:09:14 -0400 (EDT) Resent-Message-Id: <200007062009.QAA27648@www19.w3.org> Message-Id: <4.1.20000706130729.00bd4460@mail.coursenet.com> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 06 Jul 2000 13:08:39 -0700 To: Greg Stein , w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <20000706071511.Y29590@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4353 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 07:15 AM 7/6/00 -0700, Greg Stein wrote: >What is the general consensus on PROPFIND with Depth: infinity? I quoted a >couple messages below that tend to favor disallowing them. I got that >impression from some other comments on this list, but couldn't find specific >references. > >For clarity: can prople give opinions on simply disabling PROPFIND infinity? I oppose disabling infinity. it is useful (as other emails have shown). I agree to adding a principled way to refuse a request that's too expensive. From w3c-dist-auth-request@w3.org Thu Jul 6 16:35:19 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25118 for ; Thu, 6 Jul 2000 16:35:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28940; Thu, 6 Jul 2000 16:29:21 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 16:29:21 -0400 (EDT) Resent-Message-Id: <200007062029.QAA28940@www19.w3.org> From: "Jim Doubek" To: "Jim Davis" , "Greg Stein" , Date: Thu, 6 Jul 2000 13:32:17 -0700 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.2910.0) In-reply-to: <4.1.20000706130729.00bd4460@mail.coursenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4354 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi, Note that for realistic sized repositories, say 50K to 100K files, any depth=infinity request near the repository root is going to be too expensive. For instance, an allprop request in such a case will be several to tens of megabytes, and may take minutes to produce. While it may be convenient for clients going against small repositories, I'd expect that most servers will fail most infinity requests most of the time. I think a lot of the uses that people envision for depth=infinity are more likely served by intelligent tree-walking, or by DASL. The possiblility of failure forces you to code a tree-walk into your client anyways. - jim ------------------------------------------ Jim Doubek Macromedia, Inc. jdoubek@macromedia.com http://www.macromedia.com/ -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Davis Sent: Thursday, July 06, 2000 1:09 PM To: Greg Stein; w3c-dist-auth@w3.org Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] At 07:15 AM 7/6/00 -0700, Greg Stein wrote: >What is the general consensus on PROPFIND with Depth: infinity? I quoted a >couple messages below that tend to favor disallowing them. I got that >impression from some other comments on this list, but couldn't find specific >references. > >For clarity: can prople give opinions on simply disabling PROPFIND infinity? I oppose disabling infinity. it is useful (as other emails have shown). I agree to adding a principled way to refuse a request that's too expensive. From w3c-dist-auth-request@w3.org Thu Jul 6 16:51:26 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25401 for ; Thu, 6 Jul 2000 16:51:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA29668; Thu, 6 Jul 2000 16:46:02 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 16:46:02 -0400 (EDT) Resent-Message-Id: <200007062046.QAA29668@www19.w3.org> Reply-To: From: "Dylan Barrell" To: "Jim Doubek" , "Jim Davis" , "Greg Stein" , Date: Thu, 6 Jul 2000 16:44:03 -0400 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.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4355 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit And an intelligent client might be able to make n depth requests based on 0 or 1 depth responses that are useful and will not fail where an infinity request would... Cheers Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Doubek > Sent: Thursday, July 06, 2000 4:32 PM > To: Jim Davis; Greg Stein; w3c-dist-auth@w3.org > Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > > > Hi, > > Note that for realistic sized repositories, say 50K to 100K files, any > depth=infinity request near the repository root is going to be too > expensive. For instance, an allprop request in such a case will be several > to tens of megabytes, and may take minutes to produce. > > While it may be convenient for clients going against small > repositories, I'd > expect that most servers will fail most infinity requests most of > the time. > > I think a lot of the uses that people envision for depth=infinity are more > likely served by intelligent tree-walking, or by DASL. The possiblility of > failure forces you to code a tree-walk into your client anyways. > > - jim > ------------------------------------------ > Jim Doubek > Macromedia, Inc. > jdoubek@macromedia.com > http://www.macromedia.com/ > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Davis > Sent: Thursday, July 06, 2000 1:09 PM > To: Greg Stein; w3c-dist-auth@w3.org > Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth > Infinity Requests] > > > At 07:15 AM 7/6/00 -0700, Greg Stein wrote: > >What is the general consensus on PROPFIND with Depth: > infinity? I quoted a > >couple messages below that tend to favor disallowing them. I got that > >impression from some other comments on this list, but couldn't > find specific > >references. > > > >For clarity: can prople give opinions on simply disabling > PROPFIND infinity? > > I oppose disabling infinity. it is useful (as other emails > have shown). > > I agree to adding a principled way to refuse a request that's > too expensive. > From w3c-dist-auth-request@w3.org Thu Jul 6 17:20:12 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25844 for ; Thu, 6 Jul 2000 17:20:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01443; Thu, 6 Jul 2000 17:14:32 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 17:14:32 -0400 (EDT) Resent-Message-Id: <200007062114.RAA01443@www19.w3.org> Message-Id: <4.1.20000706125851.00bf2ee0@mail.coursenet.com> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 06 Jul 2000 14:14:03 -0700 To: WebDAV WG From: Jim Davis In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4356 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 05:58 PM 7/6/00 +0100, Gary Barnett wrote: >I think that creating a specification that builds in non-deterministic >behaviour would be a real pain. > >I think that the idea of passing a depth value (with perhaps a default value >which all servers support) makes sense from a client perspective. What we gain from the indeterminacy is flexibility. Otherwise, we either set the minimum standard high (and rule out cheap implementations) or set it low (thus requiring all clients to use inefficient methods, and making powerful implementations either useless or non-standard.) Yaron put it like this "The client proposes, the server disposes". Clients should ask for what they want, and be prepared to get less than that. From w3c-dist-auth-request@w3.org Thu Jul 6 20:49:07 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28173 for ; Thu, 6 Jul 2000 20:49:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA11795; Thu, 6 Jul 2000 20:44:59 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 20:44:59 -0400 (EDT) Resent-Message-Id: <200007070044.UAA11795@www19.w3.org> Message-ID: From: "Babich, Alan" To: "'Jim Davis'" , w3c-dist-auth@w3.org Date: Thu, 6 Jul 2000 17:44:10 -0700 X-Mailer: Internet Mail Service (5.5.2650.10) Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4357 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list To use an analogy, I use the UNIX "find" command a lot to find files. If it's used at the root of the file system, it includes all the remotely mounted file systems too. Even just searching the local files system takes quite a while. But when that's what I want to do, that's what I need to get done. If I decide it's taking too long, I simply kill it. So, is there a way to kill a request that's taking too long? If so, that helps quite a bit. A general mechanism for canceling operations addresses the problem for all long running operations. You want a general solution, not a special solution for each long running operation. Alan Babich -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Thursday, July 06, 2000 1:09 PM To: Greg Stein; w3c-dist-auth@w3.org Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] At 07:15 AM 7/6/00 -0700, Greg Stein wrote: >What is the general consensus on PROPFIND with Depth: infinity? I quoted a >couple messages below that tend to favor disallowing them. I got that >impression from some other comments on this list, but couldn't find specific >references. > >For clarity: can prople give opinions on simply disabling PROPFIND infinity? I oppose disabling infinity. it is useful (as other emails have shown). I agree to adding a principled way to refuse a request that's too expensive. From w3c-dist-auth-request@w3.org Thu Jul 6 21:05:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28377 for ; Thu, 6 Jul 2000 21:05:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA12180; Thu, 6 Jul 2000 21:01:41 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 21:01:41 -0400 (EDT) Resent-Message-Id: <200007070101.VAA12180@www19.w3.org> Message-ID: <9BDBBF9512077F48ABBDFB197908A9610C9205@red-pt-01.redmond.corp.microsoft.com> From: Brian Morin To: WebDAV WG Date: Thu, 6 Jul 2000 13:43:32 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4358 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Wouldn't the scenario Hartmut gave be better addressed with a DASL request to pull up only the list of modified files? Doing lots of depth 1 propfinds is not all that bad. If you pipeline the requests you can elminate a lot of the latency, assuming a tree with non-trivial breadth. You get hiarchical structure built in (propfind XML entries in a depth infinity response do not appear to be ordered, leaving the client to rebuild the hiarchy from URLs.) Finally, you are sending a lot of small requests to a web server, which is usually designed to efficently handle a lot of small requests. -----Original Message----- From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] Sent: Thursday, July 06, 2000 8:23 AM To: WebDAV WG Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I am of the opinion that disallowing depth infinity PROPFINDS would cut off one of the main WebDAV features. In order to explain that opinion I would like to give you a short example how we use WebDAV in Adobe GoLive 5.0 (the following sample is not a theoretical one it's out of the everday life of a GoLive user): Imagine that you need the modification dates of 1000 resources on the server in order to synchronize the resources on the server with the resources on your local machine. Even if the resources are located in a directory with a very deep hierarchy it's not a problem with a depth infinity PROPFIND. You ask the server for the dates and get the response for all the 1000 resources within one Network request/ response. On the other hand if you stick to PROPFIND Depth: 1 you end up in a tremendous drawback (a ftp-like solution) because the client software has to go down the hierarchy step by step and ask for the content of each directory level. The User has to be very patient in that scenario ... So to my mind the infinity PROPFIND is a main WebDAV feature for practical purposes. In addition to that I would like to draw your attention to the fact that it is very difficult to base a software implementation on a WebDAV RFC which changes frequently because we are not able to ship a new Release of our software every two weeks. Hartmut "Clemm, Geoff" wrote: > I think we should disallow Depth:infinity on a PROPFIND, and require that > the client pass in some maximum depth to let the server know when it > should stop. > > Cheers, > Geoff From w3c-dist-auth-request@w3.org Thu Jul 6 21:49:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29947 for ; Thu, 6 Jul 2000 21:49:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA13061; Thu, 6 Jul 2000 21:45:08 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 21:45:08 -0400 (EDT) Resent-Message-Id: <200007070145.VAA13061@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC03093C18@chef.lex.rational.com> From: "Clemm, Geoff" To: "'Jim Davis'" , WebDAV WG Date: Thu, 6 Jul 2000 17:20:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4359 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree with the "client proposes, server disposes" guideline, but currently we are (in my view, inappropriately) limiting what the client can propose. In particular, we are not allowing the client to propose an upper limit such as "20" or "100", even when the client knows that to be the appropriate upper limit for its PROPFIND request. Cheers, Geoff -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Thursday, July 06, 2000 5:14 PM To: WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] At 05:58 PM 7/6/00 +0100, Gary Barnett wrote: >I think that creating a specification that builds in non-deterministic >behaviour would be a real pain. > >I think that the idea of passing a depth value (with perhaps a default value >which all servers support) makes sense from a client perspective. What we gain from the indeterminacy is flexibility. Otherwise, we either set the minimum standard high (and rule out cheap implementations) or set it low (thus requiring all clients to use inefficient methods, and making powerful implementations either useless or non-standard.) Yaron put it like this "The client proposes, the server disposes". Clients should ask for what they want, and be prepared to get less than that. From w3c-dist-auth-request@w3.org Thu Jul 6 23:28:17 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02009 for ; Thu, 6 Jul 2000 23:28:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA15449; Thu, 6 Jul 2000 23:21:45 -0400 (EDT) Resent-Date: Thu, 6 Jul 2000 23:21:45 -0400 (EDT) Resent-Message-Id: <200007070321.XAA15449@www19.w3.org> Message-ID: From: "Babich, Alan" To: "'Clemm, Geoff'" , WebDAV WG Date: Thu, 6 Jul 2000 20:21:01 -0700 X-Mailer: Internet Mail Service (5.5.2650.10) Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4360 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I, too agree with the "the client proposes, the server disposes" theory. One advantage is that's a general way for the server to defend against naive and malicious clients from accidental or deliberate denial of service attacks. To extend my UNIX find analogy, if all the programmers at my company did UNIX find commands on the root directory, that would load the servers pretty good. You can generally trust your fellow programmers not to continually do stupid things, so that would be a temporary problem. But in the world of the internet, you have much less sophisticated people that could unwittingly do expensive things repeatedly, plus you have a few malicious hackers that might repeatedly do expensive things deliberately. This supports the "server disposes" theory. But, as to the idea of letting the client propose 20 or 100 as the limit (in addition to 0, 1, and infinity), the increased complexity might not be worth the decreased simplicity. I like the KISS principle. The UNIX find command doesn't have a way to specify a limit on the depth. It only has depth infinity. The UNIX find command has withstood the test of time, and I know of no UNIX implementations that have extended it to specify a limit of N. Since the UNIX find command is doing something somewhat similar, that tends to support my gut feeling that we need not bother to allow specification of depth N. So, what I propose is the following: Why don't we wait for feedback from real users to see if we really need depth N? Cut features until it's not useful for the first release, then add only features demanded by the customers in later releases. Alan Babich -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Thursday, July 06, 2000 2:20 PM To: 'Jim Davis'; WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I agree with the "client proposes, server disposes" guideline, but currently we are (in my view, inappropriately) limiting what the client can propose. In particular, we are not allowing the client to propose an upper limit such as "20" or "100", even when the client knows that to be the appropriate upper limit for its PROPFIND request. Cheers, Geoff -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Thursday, July 06, 2000 5:14 PM To: WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] At 05:58 PM 7/6/00 +0100, Gary Barnett wrote: >I think that creating a specification that builds in non-deterministic >behaviour would be a real pain. > >I think that the idea of passing a depth value (with perhaps a default value >which all servers support) makes sense from a client perspective. What we gain from the indeterminacy is flexibility. Otherwise, we either set the minimum standard high (and rule out cheap implementations) or set it low (thus requiring all clients to use inefficient methods, and making powerful implementations either useless or non-standard.) Yaron put it like this "The client proposes, the server disposes". Clients should ask for what they want, and be prepared to get less than that. From w3c-dist-auth-request@w3.org Fri Jul 7 03:26:54 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16695 for ; Fri, 7 Jul 2000 03:26:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA21188; Fri, 7 Jul 2000 03:22:31 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 03:22:31 -0400 (EDT) Resent-Message-Id: <200007070722.DAA21188@www19.w3.org> Message-Id: <4.1.20000706230421.00d58a30(null)> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 06 Jul 2000 23:22:02 -0700 To: WebDAV WG From: Jim Davis In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4361 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 08:21 PM 7/6/00 -0700, Babich, Alan wrote: >... the increased >complexity might not be worth the decreased simplicity. I like >the KISS principle. The UNIX find command doesn't have a way >to specify a limit on the depth. Poor example, in support of a good argument. The find command has dozens of options, including general boolean combinations of predicates. If Unix find is your idea of something simple, I would hate to see something you thought complex. That said, it seems to me there are now three related proposals on the floor. They are 1. change the values accepted in the depth header 2. change the responses the server may return 3. provide means for client to abort a request that is taking too long. Of these, there are four alternatives for proposal 1: a) depth may be only 0 or 1, or infinity (what we have now) b) depth may be only 0 or 1 c) depth may be an integer, but not infinity. d) depth may be an integer, or infinity Proposal 2 is to add a response code the server may use to reject a request, either because the specified depth is too great, or because the results would be larger than the server is willing to return. This proposal only makes sense if for proposal 1 one prefers a, c, or d. Proposal 3 is to add a mechanism where the client can abort a request that has taken too long. [I believe, but am not sure, that a client can simply close the connection] Proposal 1 is the linch-pin. the arguments for alternative a are that it's just what we have now. the arguments f(I have seen) for b are * it is even simpler than what we have now * if one rejects it, then if any client that can tolerate a refusal (proposal 2) would have to be able to operate in depth-one mode anyway. if one takes the trouble to code the client to be able to work with single-depth requests anyway, why would one even bother using the depths greater than one? it's just more code to write. * given pipelining, there would be little performance penalty. From w3c-dist-auth-request@w3.org Fri Jul 7 04:00:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18184 for ; Fri, 7 Jul 2000 04:00:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA22268; Fri, 7 Jul 2000 03:56:28 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 03:56:28 -0400 (EDT) Resent-Message-Id: <200007070756.DAA22268@www19.w3.org> Message-ID: <117E8D1FCCA3D111940C00805FEF6060016A182C@gbrwgcms01.wgc.rx.xerox.com> From: "Wright, Tom" To: "'Brian Morin'" , "'WebDAV WG'" Cc: "Hall, Shaun" Date: Fri, 7 Jul 2000 08:45:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4362 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list While what you say is true, it puts a huge load in the network, one of the purposes of infinite requests was to perform an operation all in one go on the server with out excessive comms from the client to the server ala pipelining. Handling one large request is far more efficient that handling lots of small requests, particularly when the resources are not on a file system , e.g. accessing a Database or other custom repository. I strongly oppose the removal of PROPFIND infinite depth requests. As an aside, as for n depth requests, how deep is n ?? It seems a bit arbitrary. Regards Tom -----Original Message----- From: Brian Morin [mailto:bmorin@microsoft.com] Sent: 06 July 2000 21:44 To: WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Wouldn't the scenario Hartmut gave be better addressed with a DASL request to pull up only the list of modified files? Doing lots of depth 1 propfinds is not all that bad. If you pipeline the requests you can elminate a lot of the latency, assuming a tree with non-trivial breadth. You get hiarchical structure built in (propfind XML entries in a depth infinity response do not appear to be ordered, leaving the client to rebuild the hiarchy from URLs.) Finally, you are sending a lot of small requests to a web server, which is usually designed to efficently handle a lot of small requests. -----Original Message----- From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] Sent: Thursday, July 06, 2000 8:23 AM To: WebDAV WG Subject: Re: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I am of the opinion that disallowing depth infinity PROPFINDS would cut off one of the main WebDAV features. In order to explain that opinion I would like to give you a short example how we use WebDAV in Adobe GoLive 5.0 (the following sample is not a theoretical one it's out of the everday life of a GoLive user): Imagine that you need the modification dates of 1000 resources on the server in order to synchronize the resources on the server with the resources on your local machine. Even if the resources are located in a directory with a very deep hierarchy it's not a problem with a depth infinity PROPFIND. You ask the server for the dates and get the response for all the 1000 resources within one Network request/ response. On the other hand if you stick to PROPFIND Depth: 1 you end up in a tremendous drawback (a ftp-like solution) because the client software has to go down the hierarchy step by step and ask for the content of each directory level. The User has to be very patient in that scenario ... So to my mind the infinity PROPFIND is a main WebDAV feature for practical purposes. In addition to that I would like to draw your attention to the fact that it is very difficult to base a software implementation on a WebDAV RFC which changes frequently because we are not able to ship a new Release of our software every two weeks. Hartmut "Clemm, Geoff" wrote: > I think we should disallow Depth:infinity on a PROPFIND, and require that > the client pass in some maximum depth to let the server know when it > should stop. > > Cheers, > Geoff From w3c-dist-auth-request@w3.org Fri Jul 7 09:39:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25820 for ; Fri, 7 Jul 2000 09:39:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA29722; Fri, 7 Jul 2000 09:35:07 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 09:35:07 -0400 (EDT) Resent-Message-Id: <200007071335.JAA29722@www19.w3.org> Reply-To: From: "Dylan Barrell" To: "Jim Davis" , "WebDAV WG" Date: Fri, 7 Jul 2000 09:32:56 -0400 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.2910.0) Importance: Normal In-Reply-To: <4.1.20000706230421.00d58a30(null)> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4363 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit My vote is for 1 d) and 2 but not for anything special for 3 - closing the connection should actually abort the operation if the server is implemented correctly. The reason I believe that we should implement 1 d is that our experience has shown that the performance gains can be significant when multiple results are returned from a single request as opposed to performing multiple requests. Forcing every client to implement pipelining to attempt to achieve similar performance is unacceptable. I further propose that language be added to the spec for proposal 2 stating that a server make every reasonable attempt to honour the client's request and possibly even limit the acceptable reasons for not doing so (with corresponding error response codes). > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Davis > Sent: Friday, July 07, 2000 2:22 AM > To: WebDAV WG > Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > > > At 08:21 PM 7/6/00 -0700, Babich, Alan wrote: > > >... the increased > >complexity might not be worth the decreased simplicity. I like > >the KISS principle. The UNIX find command doesn't have a way > >to specify a limit on the depth. > > Poor example, in support of a good argument. The find command has dozens > of options, including general boolean combinations of predicates. If Unix > find is your idea of something simple, I would hate to see something you > thought complex. > > That said, it seems to me there are now three related proposals on the > floor. They are > 1. change the values accepted in the depth header > 2. change the responses the server may return > 3. provide means for client to abort a request that is taking too long. > > Of these, there are four alternatives for proposal 1: > > a) depth may be only 0 or 1, or infinity (what we have now) > > b) depth may be only 0 or 1 > > c) depth may be an integer, but not infinity. > > d) depth may be an integer, or infinity > > Proposal 2 is to add a response code the server may use to reject a > request, either because the specified depth is too great, or because the > results would be larger than the server is willing to return. This > proposal only makes sense if for proposal 1 one prefers a, c, or d. > > Proposal 3 is to add a mechanism where the client can abort a request that > has taken too long. > > [I believe, but am not sure, that a client can simply close the > connection] > > Proposal 1 is the linch-pin. > > the arguments for alternative a are that it's just what we have now. > > the arguments f(I have seen) for b are > * it is even simpler than what we have now > > * if one rejects it, then if any client that can tolerate a refusal > (proposal 2) would have to be able to operate in depth-one mode > anyway. if > one takes the trouble to code the client to be able to work with > single-depth requests anyway, why would one even bother using the depths > greater than one? it's just more code to write. > > * given pipelining, there would be little performance penalty. From w3c-dist-auth-request@w3.org Fri Jul 7 11:51:40 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00545 for ; Fri, 7 Jul 2000 11:51:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA07004; Fri, 7 Jul 2000 11:46:35 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 11:46:35 -0400 (EDT) Resent-Message-Id: <200007071546.LAA07004@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 7 Jul 2000 08:42:22 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Re: Fwd: RE: MS IE/Office/Web Folder Behaviors with WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4364 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. Gary's email has been added to the accept2 list for w3c-dist-auth, so no further emails should be bounced. Well, unless he tries to send us a bit of infectous humor... - Jim -----Original Message----- From: Gary M Gershon [mailto:gershon@celsus.net] Sent: Wednesday, July 05, 2000 3:43 PM To: Dennis E. Hamilton Cc: WebDAV List Subject: [Moderator Action] Re: Fwd: RE: MS IE/Office/Web Folder Behaviors with WebDAV Dennis, When the document (Word/Excel...) is opened within IE, the IE menu items are basically replaced by new menu choices that are composites of IE and the application choices. Thus, the Help menu has both IE Help and Excel Help choices For the Edit menu, one gets all the standard cut/paste/clear items and one can readily edit the document within IE. The File menu does not have Save, but does have Save As... When one presses the Back button, a message box appears to ask about saving or discarding the changes to the document, or else cancelling the operation. This is consistent with other Office documents that are opened in read-only mode. One can change them, but not readily save them over the original. Gary >>Reply-To: >>From: "Dennis E. Hamilton" >>To: >>Cc: "WebDAV WG" >>Subject: RE: MS IE/Office/Web Folder Behaviors with WebDAV >>Date: Sun, 2 Jul 2000 17:18:27 -0700 >>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) >>Importance: Normal >> >>When you open the document in the IE window, is the Edit button active on >>the toolbar? >> >>What does it do if you press it -- give you a separate application or do you >>start editing in IE? >> >> >>-- Dennis >> >>AIIM DMware Technical Coordinator >>http://www.infonuovo.com/dmware >>------------------ >>Dennis E. Hamilton >>InfoNuovo >>mailto:infonuovo@email.com >>tel. +1-206-779-9430 (gsm) >>fax. +1-425-793-0283 >>http://www.infonuovo.com >> >> >>-----Original Message----- >>From: Gary M Gershon [mailto:gershon@celsus.net] >>Sent: Friday, June 30, 2000 6:02 PM >>To: Tim Ellison/OTT/OTI; WebDAV WG >>Cc: dav-dev@lyra.org >>Subject: [Moderator Action] RE: MS IE/Office/Web Folder Behaviors with >>WebDAV >> >> >>[ ... ] >> >>My conclusion, at the moment, is that if the user desires to click on a MS >>Office document URL to a WebDAV server and edit the document, then one >>needs to have modified the File Type entry to un-check the 'Browse in same >>window' option. >> >>Does anyone know if there is a way to build the URL in the web page to >>force the application to be launched separately, rather than within the IE >>window, so that the workstation's File Type entry wouldn't need to be >>changed? Perhaps JavaScript, an Applet, or an ActiveX control could do >>this? What would be the best practice? >> >>Gary >> >>[ ... ] -------------------------------------------------------------------- Gary M. Gershon -- gershon@celsus.net From w3c-dist-auth-request@w3.org Fri Jul 7 11:51:58 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00571 for ; Fri, 7 Jul 2000 11:51:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA07134; Fri, 7 Jul 2000 11:47:23 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 11:47:23 -0400 (EDT) Resent-Message-Id: <200007071547.LAA07134@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 7 Jul 2000 08:43:13 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4365 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added Kevin's email to the accept2 list for w3c-dist-auth, so his emails should not be bounced in the future. - Jim -----Original Message----- From: Kevin Dyer [mailto:kevin.dyer@matrixone.com] Sent: Thursday, July 06, 2000 8:35 AM To: Greg Stein; w3c-dist-auth@w3.org Subject: [Moderator Action] RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Thursday, July 06, 2000 10:15 AM > To: w3c-dist-auth@w3.org > Subject: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > > > What is the general consensus on PROPFIND with Depth: infinity? I quoted a > couple messages below that tend to favor disallowing them. I got that > impression from some other comments on this list, but couldn't > find specific > references. > > For clarity: can prople give opinions on simply disabling > PROPFIND infinity? > > JimW: we should probably note (explicitly) in the spec that a server may > return a 403 (Forbidden) if a client requests a PROPFIND with a Depth of > infinity. > I'm in agreement with Jim. We should not allow infinite depth requests at all. Depending at what level the request is started from and the complexity of the PROP data, the request could place a significant resource strain on the server. A side benefit, of not allowing infinite depth requests, servers as a security speedbump. It forces an end application to make more requests to retrieve the entire tree. Which in turn should raise a flag with someone or something watching the logs for unusual behavior. Just my 0.02 Galactic Credits, Kevin ____________________________________________ Kevin J. Dyer Sr. Technologist, Product Management kevin.dyer@matrixone.com TEL: 978-322-2011 FAX: 978-441-0071 MOBILE: 978-314-9855 MatrixOne, Inc. Two Executive Drive Chelmsford, MA 01824 USA www.matrixone.com Leading Provider of Internet Business Collaboration Solutions ____________________________________________ From w3c-dist-auth-request@w3.org Fri Jul 7 11:52:37 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00608 for ; Fri, 7 Jul 2000 11:52:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA07190; Fri, 7 Jul 2000 11:48:03 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 11:48:03 -0400 (EDT) Resent-Message-Id: <200007071548.LAA07190@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 7 Jul 2000 08:43:53 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4366 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Another message caught yesterday by the spam filter. :-( - Jim -----Original Message----- From: Kevin Dyer [mailto:kevin.dyer@matrixone.com] Sent: Thursday, July 06, 2000 10:30 AM To: Kevin Wiggen; WebDAV WG Subject: [Moderator Action] RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Kevin Wiggen > Sent: Thursday, July 06, 2000 12:28 PM > To: Hartmut.Warncke@Adobe.COM; WebDAV WG > Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > > > > I believe we should follow the DASL spec on this one. Dasl allows a server > to send a 507 if the query produced more results than the server is willing > to transmit. Partial Results have been transmitted. | From Tim Ellison | | The server should be free to refuse depth requests (>1) that it decides | are too expensive. Of course, that does not preclude the spec from | allowing the header value to be 0 .. n or infinity, but it does further | complicate the client that has to deal with refusals and 'do the work'. Then the server can respond to an infinite request with either a 403, if the admin decides to be frugal with server resources, or a 507 and send up to the high water mark of depth. It leaves more wiggle room but it looks like the best solution. > > This is the implementation on the Xythos Storage Server for both SEARCH and > PROPFIND. > > Kevin > > Kevin From w3c-dist-auth-request@w3.org Fri Jul 7 11:53:29 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00641 for ; Fri, 7 Jul 2000 11:53:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA07246; Fri, 7 Jul 2000 11:48:48 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 11:48:48 -0400 (EDT) Resent-Message-Id: <200007071548.LAA07246@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 7 Jul 2000 08:44:39 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4367 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit This is the last message caught in the spam filter yesterday. - Jim -----Original Message----- From: Kevin Dyer [mailto:kevin.dyer@matrixone.com] Sent: Thursday, July 06, 2000 10:40 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: [dav-dev] Depth Infinity Requests] > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Barnett > Sent: Thursday, July 06, 2000 12:58 PM > To: WebDAV WG > Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] > > > I think that creating a specification that builds in non-deterministic > behaviour would be a real pain. > > I think that the idea of passing a depth value (with perhaps a default value > which all servers support) makes sense from a client perspective. > But you still need to be able to tell the client that you've asked for too much and I'm only going to give you back this amount. Or you've asked for something that I can't generate now. Maybe the 403 is not the answer, but a new return code that actually tells the client what the high water mark is. I apologize if this is in the latest version, shouldn't the client be able to request from the server all of the high and low watermark settings we've been talking about as part of a handshake? Kevin From w3c-dist-auth-request@w3.org Fri Jul 7 12:35:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02743 for ; Fri, 7 Jul 2000 12:35:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA10382; Fri, 7 Jul 2000 12:30:22 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 12:30:22 -0400 (EDT) Resent-Message-Id: <200007071630.MAA10382@www19.w3.org> From: Jim Whitehead To: Greg Stein , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Fri, 7 Jul 2000 09:26:04 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20000706071511.Y29590@lyra.org> Importance: Normal Subject: Re: Depth Infinity Requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4368 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > JimW: we should probably note (explicitly) in the spec that a server may > return a 403 (Forbidden) if a client requests a PROPFIND with a Depth of > infinity. OK, I've noted this as issue "PROPFIND_INFINITY" at the end of the WebDAV Distributed Authoring Protocol issues list: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html - Jim From w3c-dist-auth-request@w3.org Fri Jul 7 15:41:36 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11217 for ; Fri, 7 Jul 2000 15:41:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17156; Fri, 7 Jul 2000 15:36:34 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 15:36:34 -0400 (EDT) Resent-Message-Id: <200007071936.PAA17156@www19.w3.org> Message-ID: From: "Babich, Alan" To: "'Jim Davis'" , WebDAV WG Date: Fri, 7 Jul 2000 12:35:37 -0700 X-Mailer: Internet Mail Service (5.5.2650.10) Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4369 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I wasn't trying to promote the UNIX find command as an example of good design. I was only trying to make a point about the KISS principle. In fact, "find" does not have the simplest design for the normal case. The only way I ever use the UNIX find command is: find -name -print This just displays the full path name of the file(s) I'm looking for. I completely ignore all the other powerful functionality. So, from the point of view of the way I use it, it is very simple. It would be even simpler if I didn't have to figure out that I had to add "-name" and "-print" to get what I want. The designers and implementors wasted (as far as my case is concerned) all their valuable time and effort implementing features that I don't use, and made it more complicated for me to figure out (as a side effect of the additional features). I assume that somebody out there thinks that some of the other features are critical, so that the effort and increased complexity isn't entirely in vain. My point is that my experience with this particular command supports the approach of "cut features until you are about to cut too far, then let customers tell you what features to add on subsequent releases". That approach tends to maximize the simplicity of the normal case and ease of implementation, and things tend to get added in priority order. So, I'm in favor of (a) in your e-mail below -- no change. Alan Babich -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Thursday, July 06, 2000 11:22 PM To: WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] At 08:21 PM 7/6/00 -0700, Babich, Alan wrote: >... the increased >complexity might not be worth the decreased simplicity. I like >the KISS principle. The UNIX find command doesn't have a way >to specify a limit on the depth. Poor example, in support of a good argument. The find command has dozens of options, including general boolean combinations of predicates. If Unix find is your idea of something simple, I would hate to see something you thought complex. That said, it seems to me there are now three related proposals on the floor. They are 1. change the values accepted in the depth header 2. change the responses the server may return 3. provide means for client to abort a request that is taking too long. Of these, there are four alternatives for proposal 1: a) depth may be only 0 or 1, or infinity (what we have now) b) depth may be only 0 or 1 c) depth may be an integer, but not infinity. d) depth may be an integer, or infinity Proposal 2 is to add a response code the server may use to reject a request, either because the specified depth is too great, or because the results would be larger than the server is willing to return. This proposal only makes sense if for proposal 1 one prefers a, c, or d. Proposal 3 is to add a mechanism where the client can abort a request that has taken too long. [I believe, but am not sure, that a client can simply close the connection] Proposal 1 is the linch-pin. the arguments for alternative a are that it's just what we have now. the arguments f(I have seen) for b are * it is even simpler than what we have now * if one rejects it, then if any client that can tolerate a refusal (proposal 2) would have to be able to operate in depth-one mode anyway. if one takes the trouble to code the client to be able to work with single-depth requests anyway, why would one even bother using the depths greater than one? it's just more code to write. * given pipelining, there would be little performance penalty. From w3c-dist-auth-request@w3.org Fri Jul 7 15:42:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11253 for ; Fri, 7 Jul 2000 15:42:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17333; Fri, 7 Jul 2000 15:37:02 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 15:37:02 -0400 (EDT) Resent-Message-Id: <200007071937.PAA17333@www19.w3.org> From: Jim Whitehead To: WebDAV WG Cc: Ned Freed Date: Fri, 7 Jul 2000 12:32:46 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Revised working group charter Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4370 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Well, if you've looked at the WebDAV working group charter recently, you've probably noticed that it's pretty far out of date. The last milestone listed is in 1997... The purpose of the charter is to describe the scope of the working group's activities, proposed deliverables, and a schedule for accomplishing the group's goals. There is a general concern within the IETF that a working group without a current charter may tend to drift, and lose focus. At the request of Ned Freed, our Application Area Advisor, I have created a draft update of the working group's charter. You can find it here: http://www.ics.uci.edu/pub/ietf/webdav/charter2.html The document lists a number of document deliverables, and a schedule for completing them. One way of reading this document is this: if there is an activity that you think should get done, and it isn't listed, it will not get done. I have not listed work on DASL, since it is my current intention that this work will continue in an ad-hoc group comprised of the membership of the DASL mailing list. I continue to have a strong personal commitment to completing DASL, however, this work will not take place in this working group. I have also not listed work on PROPFIND extensions, since I have seen no further IDs refining these proposals. If you strongly feel WebDAV should address topics not listed in this charter, please raise them now. If you do so, please provide: - Deliverables - Schedule - Who will perform the work Also, any comments you have on the charter, including comments on deliverables, scope, wording, schedule, etc., are appreciated. Thanks! - Jim From w3c-dist-auth-request@w3.org Fri Jul 7 16:36:04 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12604 for ; Fri, 7 Jul 2000 16:36:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA18797; Fri, 7 Jul 2000 16:30:39 -0400 (EDT) Resent-Date: Fri, 7 Jul 2000 16:30:39 -0400 (EDT) Resent-Message-Id: <200007072030.QAA18797@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC03093C26@chef.lex.rational.com> From: "Clemm, Geoff" To: WebDAV WG Date: Fri, 7 Jul 2000 16:21:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4371 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The proposal to allow a depth value other than 0,1,infinity has been motivated by some very clear and common use cases (i.e. either deliberately or mistakenly invoking PROPFIND on the root of a very large resource tree). Arguments of the form "it would be simpler to only allow 0,1,infinity" do nothing to address the use case that is of concern. One of the postings used the fact that a "find" request does not have a depth argument to support the position that a PROPFIND request should not need one either. I believe this argument does not hold for a variety of reasons, such as the fact that "find" is almost always used with a predicate (commonly "name"), and that the OS commonly provides job control and a data pipe mechanism to control the behavior of find, neither of which are available with a PROPFIND request. Cheers, Geoff -----Original Message----- From: Babich, Alan [mailto:ABabich@filenet.com] Sent: Friday, July 07, 2000 3:36 PM To: 'Jim Davis'; WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I wasn't trying to promote the UNIX find command as an example of good design. I was only trying to make a point about the KISS principle. In fact, "find" does not have the simplest design for the normal case. The only way I ever use the UNIX find command is: find -name -print This just displays the full path name of the file(s) I'm looking for. I completely ignore all the other powerful functionality. So, from the point of view of the way I use it, it is very simple. It would be even simpler if I didn't have to figure out that I had to add "-name" and "-print" to get what I want. The designers and implementors wasted (as far as my case is concerned) all their valuable time and effort implementing features that I don't use, and made it more complicated for me to figure out (as a side effect of the additional features). I assume that somebody out there thinks that some of the other features are critical, so that the effort and increased complexity isn't entirely in vain. My point is that my experience with this particular command supports the approach of "cut features until you are about to cut too far, then let customers tell you what features to add on subsequent releases". That approach tends to maximize the simplicity of the normal case and ease of implementation, and things tend to get added in priority order. So, I'm in favor of (a) in your e-mail below -- no change. Alan Babich -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Thursday, July 06, 2000 11:22 PM To: WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] At 08:21 PM 7/6/00 -0700, Babich, Alan wrote: >... the increased >complexity might not be worth the decreased simplicity. I like >the KISS principle. The UNIX find command doesn't have a way >to specify a limit on the depth. Poor example, in support of a good argument. The find command has dozens of options, including general boolean combinations of predicates. If Unix find is your idea of something simple, I would hate to see something you thought complex. That said, it seems to me there are now three related proposals on the floor. They are 1. change the values accepted in the depth header 2. change the responses the server may return 3. provide means for client to abort a request that is taking too long. Of these, there are four alternatives for proposal 1: a) depth may be only 0 or 1, or infinity (what we have now) b) depth may be only 0 or 1 c) depth may be an integer, but not infinity. d) depth may be an integer, or infinity Proposal 2 is to add a response code the server may use to reject a request, either because the specified depth is too great, or because the results would be larger than the server is willing to return. This proposal only makes sense if for proposal 1 one prefers a, c, or d. Proposal 3 is to add a mechanism where the client can abort a request that has taken too long. [I believe, but am not sure, that a client can simply close the connection] Proposal 1 is the linch-pin. the arguments for alternative a are that it's just what we have now. the arguments f(I have seen) for b are * it is even simpler than what we have now * if one rejects it, then if any client that can tolerate a refusal (proposal 2) would have to be able to operate in depth-one mode anyway. if one takes the trouble to code the client to be able to work with single-depth requests anyway, why would one even bother using the depths greater than one? it's just more code to write. * given pipelining, there would be little performance penalty. From w3c-dist-auth-request@w3.org Sat Jul 8 12:46:03 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07256 for ; Sat, 8 Jul 2000 12:46:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA09110; Sat, 8 Jul 2000 12:40:58 -0400 (EDT) Resent-Date: Sat, 8 Jul 2000 12:40:58 -0400 (EDT) Resent-Message-Id: <200007081640.MAA09110@www19.w3.org> Date: Sat, 08 Jul 2000 09:38:14 -0700 From: Kevin Wiggen In-reply-to: To: "Babich, Alan" , "'Jim Davis'" , WebDAV WG Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Priority: 3 (Normal) Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4372 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I agree with 1a (leave things alone), but then I again suggest that we add 507 to the list of possible response coded so a server can respond with "Partial Results Sent" This way a server can stop a request if necessary. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan Sent: Friday, July 07, 2000 12:36 PM To: 'Jim Davis'; WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] I wasn't trying to promote the UNIX find command as an example of good design. I was only trying to make a point about the KISS principle. In fact, "find" does not have the simplest design for the normal case. The only way I ever use the UNIX find command is: find -name -print This just displays the full path name of the file(s) I'm looking for. I completely ignore all the other powerful functionality. So, from the point of view of the way I use it, it is very simple. It would be even simpler if I didn't have to figure out that I had to add "-name" and "-print" to get what I want. The designers and implementors wasted (as far as my case is concerned) all their valuable time and effort implementing features that I don't use, and made it more complicated for me to figure out (as a side effect of the additional features). I assume that somebody out there thinks that some of the other features are critical, so that the effort and increased complexity isn't entirely in vain. My point is that my experience with this particular command supports the approach of "cut features until you are about to cut too far, then let customers tell you what features to add on subsequent releases". That approach tends to maximize the simplicity of the normal case and ease of implementation, and things tend to get added in priority order. So, I'm in favor of (a) in your e-mail below -- no change. Alan Babich -----Original Message----- From: Jim Davis [mailto:jrd3@alum.mit.edu] Sent: Thursday, July 06, 2000 11:22 PM To: WebDAV WG Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] At 08:21 PM 7/6/00 -0700, Babich, Alan wrote: >... the increased >complexity might not be worth the decreased simplicity. I like >the KISS principle. The UNIX find command doesn't have a way >to specify a limit on the depth. Poor example, in support of a good argument. The find command has dozens of options, including general boolean combinations of predicates. If Unix find is your idea of something simple, I would hate to see something you thought complex. That said, it seems to me there are now three related proposals on the floor. They are 1. change the values accepted in the depth header 2. change the responses the server may return 3. provide means for client to abort a request that is taking too long. Of these, there are four alternatives for proposal 1: a) depth may be only 0 or 1, or infinity (what we have now) b) depth may be only 0 or 1 c) depth may be an integer, but not infinity. d) depth may be an integer, or infinity Proposal 2 is to add a response code the server may use to reject a request, either because the specified depth is too great, or because the results would be larger than the server is willing to return. This proposal only makes sense if for proposal 1 one prefers a, c, or d. Proposal 3 is to add a mechanism where the client can abort a request that has taken too long. [I believe, but am not sure, that a client can simply close the connection] Proposal 1 is the linch-pin. the arguments for alternative a are that it's just what we have now. the arguments f(I have seen) for b are * it is even simpler than what we have now * if one rejects it, then if any client that can tolerate a refusal (proposal 2) would have to be able to operate in depth-one mode anyway. if one takes the trouble to code the client to be able to work with single-depth requests anyway, why would one even bother using the depths greater than one? it's just more code to write. * given pipelining, there would be little performance penalty. From w3c-dist-auth-request@w3.org Mon Jul 10 12:33:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16112 for ; Mon, 10 Jul 2000 12:33:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA20261; Mon, 10 Jul 2000 12:28:22 -0400 (EDT) Resent-Date: Mon, 10 Jul 2000 12:28:22 -0400 (EDT) Resent-Message-Id: <200007101628.MAA20261@www19.w3.org> Message-ID: <25D0DF2980A7D311AB1C00508B91BD2A081F83@BELMAIL1> From: Maryann Joy To: "'w3c-dist-auth@w3.org'" Cc: dav-dev@lyra.org Date: Mon, 10 Jul 2000 09:20:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: WebFolders and IIS5 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4373 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I'm trying to get WebFolders working with the DataChannel Server running on IIS 5 (it worked great with IIS 4). The problem is that when WebFolders sends a PROPFIND request it includes a 'Translate: f' request header, which results in a '403: Forbidden response'. If this header is not included in the HTTP request we get the correct response. Is there any setting on IIS 5 that will prevent this happening ? or is there any way to ensure that WebFolders doesn't include the translate header in the PROPFIND request. Thanks, MaryAnn From w3c-dist-auth-request@w3.org Tue Jul 11 01:29:33 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11751 for ; Tue, 11 Jul 2000 01:29:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA16687; Tue, 11 Jul 2000 01:21:30 -0400 (EDT) Resent-Date: Tue, 11 Jul 2000 01:21:30 -0400 (EDT) Resent-Message-Id: <200007110521.BAA16687@www19.w3.org> Message-Id: <4.2.2.20000710185034.02dab5d0@mail-345.corp.adobe.com> X-Sender: dbrotsky@mail-345.corp.adobe.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Jul 2000 22:20:15 -0700 To: w3c-dist-auth@w3c.org From: Daniel Brotsky Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id BAA16664 Subject: LOCK of resource in non-existent collection & 409 response Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4374 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit In the discussion of PUT, MKCOL, COPY, and MOVE it is made very clear that attempting to create a resource not all of whose parent collections exist MUST result in a 409 response. But in the discussion of LOCK there is no such requirement. Why? At first I thought that perhaps the intent was to allow reserving a particular name, and only if that name was available (i.e., the lock succeeded) would the client create the intermediate collections. But this scenario, aside from its doubtful utility, seems to contradict the language of section 7.4 which says that a (write-)lock-null resource MUST appear as a member of its parent collection (which doesn't exist in this case). I realize that the 409 response is already mandated when an attempt to lock an existing collection (other than at depth 0) conflicts with existing locks on members (at some level). But there is no possible confusion between this use of 409 and the one I am proposing. So I propose the following clarifications: 1. In section 8.10.1, add the following paragraph: A LOCK request on a non-existent resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict) response whose body is empty. 2. In section 8.10.7 add the following: 409 (Conflict) ­ Case 1. A non-existent resource cannot be locked at the destination until one or more intermediate collections have been created. There MUST be no response body. Case 2. A LOCK request (depth > 0) on an existing collection would conflict with existing locks on members of the collection. The response body SHOULD be a multi-status indicating the members in conflict. dan Dan Brotsky, tel 408-536-4150, page 888-461-0237 2 way email pager From w3c-dist-auth-request@w3.org Tue Jul 11 04:39:54 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22334 for ; Tue, 11 Jul 2000 04:39:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA21054; Tue, 11 Jul 2000 04:32:14 -0400 (EDT) Resent-Date: Tue, 11 Jul 2000 04:32:14 -0400 (EDT) Resent-Message-Id: <200007110832.EAA21054@www19.w3.org> From: "Rickard Falk" To: Date: Tue, 11 Jul 2000 10:32:05 +0200 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: Refreshing locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4375 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit When I'm about to refresh a lock, can I then send exactly the same request as I sent when I locked the resource? I've tried this with IIS-5 and Sharemation, but the response I get is '423 Locked'. The only things that differs are, the If header and any cookies that may have been set. According to the spec. I doesn't have to send exactly the same request, but it doesn't say that I can't. To get it to work I excluded the body of the lock request, as the spec. say's I can. Chap 7.8 Refreshing Write Locks 'However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock.' Can I rely on that if I send the Lock request without the body, that all servers will see this as a Lock refresh? /Rickard Falk From w3c-dist-auth-request@w3.org Tue Jul 11 05:24:21 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22675 for ; Tue, 11 Jul 2000 05:24:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA22081; Tue, 11 Jul 2000 05:20:07 -0400 (EDT) Resent-Date: Tue, 11 Jul 2000 05:20:07 -0400 (EDT) Resent-Message-Id: <200007110920.FAA22081@www19.w3.org> Date: Tue, 11 Jul 2000 02:22:08 -0700 From: Greg Stein To: Rickard Falk Cc: w3c-dist-auth@w3.org Message-ID: <20000711022208.Z29590@lyra.org> Mail-Followup-To: Rickard Falk , w3c-dist-auth@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from rickard.falk@excosoft.se on Tue, Jul 11, 2000 at 10:32:05AM +0200 X-URL: http://www.lyra.org/greg/ Subject: Re: Refreshing locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4376 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Tue, Jul 11, 2000 at 10:32:05AM +0200, Rickard Falk wrote: > When I'm about to refresh a lock, can I then send exactly the same request as I sent when I locked the resource? I've tried this > with IIS-5 and Sharemation, but the response I get is '423 Locked'. The only things that differs are, the If header and any cookies > that may have been set. According to the spec. I doesn't have to send exactly the same request, but it doesn't say that I can't. > To get it to work I excluded the body of the lock request, as the spec. say's I can. > > Chap 7.8 Refreshing Write Locks > 'However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a > lock.' > > Can I rely on that if I send the Lock request without the body, that all servers will see this as a Lock refresh? Nope. You must supply the If: header which contains the locktokens of the locks that you wish to refresh. You must also submit an empty body to perform a refresh. If you supply a body, then the server will think you are attempting to create a new lock; if either of the locks are exclusive, then it will punt. Similar to IIS5 and Sharemation, mod_dav (and Apache 2.0 :-) will return a 423 if you attempt to LOCK a resource without supplying the necessary If: header and empty body on a refresh. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Jul 11 05:55:57 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22893 for ; Tue, 11 Jul 2000 05:55:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA22624; Tue, 11 Jul 2000 05:51:47 -0400 (EDT) Resent-Date: Tue, 11 Jul 2000 05:51:47 -0400 (EDT) Resent-Message-Id: <200007110951.FAA22624@www19.w3.org> From: "Rickard Falk" To: "Greg Stein" Cc: Date: Tue, 11 Jul 2000 11:51:35 +0200 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.2910.0) Importance: Normal In-Reply-To: <20000711022208.Z29590@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: Refreshing locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4377 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I know that I have to send the If header, but where does the spec. say that a refresh request must be sent without the body? In chapter 7.8 it only say that the client 'may' send it without the body, not that a lock refresh must be without a body. It states that a Lock request without a body must only be used as a refresh lock request. Is my interpretation wrong? What I would like to se is something like: 'A client MUST NOT submit a body on a LOCK request, that is intended to "refresh" a lock.' /Rickard Falk > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: den 11 juli 2000 11:22 > To: Rickard Falk > Cc: w3c-dist-auth@w3.org > Subject: Re: Refreshing locks > > > On Tue, Jul 11, 2000 at 10:32:05AM +0200, Rickard Falk wrote: > > When I'm about to refresh a lock, can I then send exactly the same request as I sent when I locked the resource? I've tried this > > with IIS-5 and Sharemation, but the response I get is '423 Locked'. The only things that differs are, the If header and > any cookies > > that may have been set. According to the spec. I doesn't have to send exactly the same request, but it doesn't say that I can't. > > To get it to work I excluded the body of the lock request, as the spec. say's I can. > > > > Chap 7.8 Refreshing Write Locks > > 'However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used > to "refresh" a > > lock.' > > > > Can I rely on that if I send the Lock request without the body, that all servers will see this as a Lock refresh? > > Nope. You must supply the If: header which contains the locktokens of the > locks that you wish to refresh. You must also submit an empty body to > perform a refresh. If you supply a body, then the server will think you are > attempting to create a new lock; if either of the locks are exclusive, then > it will punt. > > Similar to IIS5 and Sharemation, mod_dav (and Apache 2.0 :-) will return a > 423 if you attempt to LOCK a resource without supplying the necessary If: > header and empty body on a refresh. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Wed Jul 12 15:58:33 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11475 for ; Wed, 12 Jul 2000 15:58:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA02984; Wed, 12 Jul 2000 15:52:02 -0400 (EDT) Resent-Date: Wed, 12 Jul 2000 15:52:02 -0400 (EDT) Resent-Message-Id: <200007121952.PAA02984@www19.w3.org> From: Jim Whitehead To: Rickard Falk , Greg Stein Cc: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Wed, 12 Jul 2000 12:47:16 -0700 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.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: Refreshing locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4378 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > I know that I have to send the If header, but where does the > spec. say that a refresh request must be sent without the body? By my interpretation of RFC 2518, it is OK for a client to submit a body with the lock refresh. But, since existing servers are disallowing this, it might make sense to codify this practice. I've added this to the issues list. > What I would like to se is something like: > 'A client MUST NOT submit a body on a LOCK request, that is > intended to "refresh" a lock.' That seems to describe the current behavior of servers. - Jim From w3c-dist-auth-request@w3.org Fri Jul 14 17:30:26 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27497 for ; Fri, 14 Jul 2000 17:30:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17792; Fri, 14 Jul 2000 17:25:33 -0400 (EDT) Resent-Date: Fri, 14 Jul 2000 17:25:33 -0400 (EDT) Resent-Message-Id: <200007142125.RAA17792@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 14 Jul 2000 14:21:01 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: WebDAV meeting times in Pittsburgh (IETF 48) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4379 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit FYI: At present, the draft agenda for the IETF meeting (subject to change), has the WebDAV WG meeting at the following times: Thursday, August 3, 2000: 9AM - 11:30AM: Session 1 (Access Control) 3:30PM-5:30PM: Session 2 (Access Control, RFC 2518 issues, property registry) Additionally, DeltaV WG is currently scheduled to meet: Wednesday, August 2, 2000: 3:30-5:30PM I will forward along the final schedule, once this is known. I do not know when the schedule will attain its final form. For more information on IETF-48, including how to register, hotel information, etc., consult this Web page: http://www.ietf.org/meetings/IETF-48.html - Jim From w3c-dist-auth-request@w3.org Tue Jul 18 14:02:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24722 for ; Tue, 18 Jul 2000 14:02:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA29444; Tue, 18 Jul 2000 13:56:04 -0400 (EDT) Resent-Date: Tue, 18 Jul 2000 13:56:04 -0400 (EDT) Resent-Message-Id: <200007181756.NAA29444@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 18 Jul 2000 10:51:24 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4380 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter -- I've added Yaron's email address to the accept2 list. - Jim -----Original Message----- From: Yaron Goland [mailto:yarongo@crossgain.com] Sent: Monday, July 17, 2000 2:41 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] RE: [hwarncke@Adobe.COM: Re: [dav-dev] Depth Infinity Requests] Jim Doubek says: "Note that for realistic sized repositories, say 50K to 100K files, any depth=infinity request near the repository root is going to be too expensive. For instance, an allprop request in such a case will be several to tens of megabytes, and may take minutes to produce." My company is looking to WebDAV to provide us with versioning functionality. One of the most basic functions we perform is synching to a tree, which is huge and which starts at the root. Ignoring the issues of additional client complexity introduced by removing propfind = infinity, without propfind = infinity network performance gets significantly worse. What was previously a single request/response now becomes Log(N) request/responses where N is the size of the longest chain in the tree. Even if you have a fairly compact tree with one weirdo chain, your performance is held hostage to that chain. Note: I am treating multiple pipelined request/responses as being one request/response for the purposes of counting round trips. The proposal that we allow clients to submit individual integers is sort of the worst of all worlds. It makes clients more difficult to program, it makes servers more difficult to program (it is easier to support infinity than a specific integer which requires keep track of a counter all the way down the tree), it makes network performance worse and it doesn't map to any common scenarios. In the majority of cases I have seen in my years of client programming the client wants everything below a specific starting point. The main exceptions are 0 and 1 but both of those are already covered. As such I believe that we should keep depth = infinity and that we should not allow for specific integers to be submitted. I have a lot of sympathy for server makers who see depth = infinity as a denial of service attack. It definitely screws server performance. The humor of this thread is - We've already been down this path before. Once upon a time WebDAV was only going to support depth 0 and 1. If you want to read a summary of the arguments and how they were settled see the section entitled in http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html. I completely agree with people who want to use the DASLesque solution of returning a "Too much server processing time required" error message. I think this is a great idea. One of the features my servers provide are Service Level Agreements. I will check your SLA when I process your request and if your SLA isn't high enough I will boot your depth = infinity request. Obviously anonymous log-ins would get very little processing assigned to them. Let's not throw the baby out with the bath water. Depth = infinity is a powerful feature that covers one of the most common editing scenarios "Synch this tree" in a manner that has great network performance. This is a big benefit of WebDAV. However let us also empower server authors to reject requests that abuse their server. I think that is the best compromise. Yaron P.S. Long experience teaches me that a number of the server authors reading this letter are gleefully rubbing their hands together going "Great! I will reject every propfind = infinity request with a "too much server processing time" error. Problem Solved!!!" I suggest you read http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0359.html and keep in mind that clients will treat the "too much server processing time" error as catastrophic. This type of behavior probably won't help your server sales. From w3c-dist-auth-request@w3.org Wed Jul 19 12:51:06 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23767 for ; Wed, 19 Jul 2000 12:51:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13778; Wed, 19 Jul 2000 12:45:19 -0400 (EDT) Resent-Date: Wed, 19 Jul 2000 12:45:19 -0400 (EDT) Resent-Message-Id: <200007191645.MAA13778@www19.w3.org> From: Jim Whitehead To: acl@webdav.org, WebDAV WG MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Wed, 19 Jul 2000 09:40:34 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Update to Pittsburgh schedule Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4381 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I received an updated agenda for the Pittsburgh IETF yesterday -- you can see it online at: http://www.ietf.org/meetings/agenda.txt Unfortunately, due to scheduling constraints, they were only able to give WebDAV WG a single slot, instead of the two we had on the previous, draft agenda. I feel strongly that moving access control forward is important, so it is my intention to dedicate the majority of the meeting slot to discussion of access control. There will be an additional, brief discussion on the updated charter as well. At present, I am no longer planning on having discussion of RFC 2518 issues, though I would be happy to organize an informal meeting on this if there is interest. Let me know. The meeting slot for WebDAV is: Thursday, August 3, 9AM-11:30AM There will also be an informal meeting on access control during Thursday afternoon -- details will be discussed in the WebDAV WG meeting, and the location will be posted on the message board. It'll probably be in someone's hotel room. - Jim From w3c-dist-auth-request@w3.org Mon Jul 24 15:33:46 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09488 for ; Mon, 24 Jul 2000 15:33:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA24415; Mon, 24 Jul 2000 15:22:23 -0400 (EDT) Resent-Date: Mon, 24 Jul 2000 15:22:23 -0400 (EDT) Resent-Message-Id: <200007241922.PAA24415@www19.w3.org> From: Jim Whitehead To: WebDAV WG , ietf-dav-versioning@w3.org, acl@webdav.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Mon, 24 Jul 2000 12:17:23 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: DAVer's guide to Pittsburgh IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4382 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Here it is, all in one message, the DAVhead's guide to the Pittsburgh IETF meeting. Tuesday, August 1 ----------------- Informal DeltaV design meeting When: All day, starting at 9AM Location: TBD, will be on message board at IETF meeting by 9AM Tuesday. Also, look for messages on DeltaV mailing list. (The message board is usually located by the registration desk.) Background: http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-06.htm Wednesday, August 2 ------------------- Informal DeltaV design meeting When: 9AM-noon, 1PM-3PM Location: TBD, most likely the same place at the Tuesday meeting. Look for message on IETF message board. Background: http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-06.htm Official DeltaV Working Group meeting When: 3:30PM-5:30PM Location: TBD, look in pamphlet or on message board at IETF meeting Background: http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-06.htm Thursday, August 3 ------------------ Official WebDAV Working Group meeting When: 9AM-11:30AM Location: TBD, look in pamphlet or on message board at IETF meeting Background: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-02.htm Revised WebDAV WG Charter: http://www.ics.uci.edu/pub/ietf/webdav/charter2.html Informal Access Control design meeting When: 1PM-5PM Location: TBD, will be discussed in WG meeting, and posted on IETF message board by 1PM Thursday. Background: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-02.htm - Jim From w3c-dist-auth-request@w3.org Tue Jul 25 06:45:04 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26594 for ; Tue, 25 Jul 2000 06:45:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA17033; Tue, 25 Jul 2000 06:38:43 -0400 (EDT) Resent-Date: Tue, 25 Jul 2000 06:38:43 -0400 (EDT) Resent-Message-Id: <200007251038.GAA17033@www19.w3.org> Message-Id: <200007251038.GAA24882@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Jul 2000 06:38:35 -0400 Subject: I-D ACTION:draft-ietf-webdav-acl-02.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4383 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Access Control Extensions to WebDAV Author(s) : G. Clemm, A. Hopkins, E. Sedlar Filename : draft-ietf-webdav-acl-02.txt Pages : 27 Date : 24-Jul-00 This document specifies a set of methods, headers, and resource-types that define the WebDAV Access Control extensions to the HTTP/1.1 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-acl-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-acl-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000724142706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724142706.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Jul 27 06:03:52 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14069 for ; Thu, 27 Jul 2000 06:03:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA28335; Thu, 27 Jul 2000 05:56:54 -0400 (EDT) Resent-Date: Thu, 27 Jul 2000 05:56:54 -0400 (EDT) Resent-Message-Id: <200007270956.FAA28335@www19.w3.org> Message-ID: <000f01bff7b1$bbb90480$fed670d8@concentric.net> From: "John Glavin" To: Date: Thu, 27 Jul 2000 03:02:11 -0700 Organization: RiverFront Software 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: How do I set getlastmodified using PROPPATCH ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4384 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Problem: I have converted my FTP application webdrive (www.webdrive.com) to support DAV and I need to be able to set the "getlastmodified" property using PROPPATCH so that utilities like powerdesk can syncrhonize files from a Windows PC to a DAV server. I currently retrieve the "getlastmodified" property when I generate a PROPFIND request on a collection (directory) and this spits out all the files in the directory along with all properties defined. I have done testing with several servers like (Driveway.com, Zope.org, Sharemation.com) and notice that they all return the "getlastmodified" property but sometimes the namespace is different from server to server. When parsing this xml response I always look for ":getlastmodified" to determine the time for the file. Questions: Do I have to specify the namespace in xml when doing a PROPPATCH ? Is this namespace different for each server ? Is there a generic way to specify the getlastmodified time to set ? Thanks, John Glavin RiverFront Software jglavin@riverfrontsoftware.com http://www.riverfrontsoftware.com From w3c-dist-auth-request@w3.org Thu Jul 27 12:44:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01570 for ; Thu, 27 Jul 2000 12:44:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA12842; Thu, 27 Jul 2000 12:38:03 -0400 (EDT) Resent-Date: Thu, 27 Jul 2000 12:38:03 -0400 (EDT) Resent-Message-Id: <200007271638.MAA12842@www19.w3.org> From: Jim Whitehead To: John Glavin , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Thu, 27 Jul 2000 09:32:57 -0700 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.2910.0) In-reply-to: <000f01bff7b1$bbb90480$fed670d8@concentric.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: How do I set getlastmodified using PROPPATCH ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4385 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > I have converted my FTP application webdrive (www.webdrive.com) to support > DAV and I need to be able to set the "getlastmodified" property using > PROPPATCH so that utilities like powerdesk can syncrhonize files from a > Windows PC to a DAV server. Well, the intent of the getlastmodified property is to give the time of the most recent state change of the resource. Thus, getlastmodified will definitely be affected by a PUT, and may be affected by a PROPPATCH. Since the value of the property is determined by the server, it is a "live" property. Though I haven't looked into it, I suspect that most DAV servers do not allow you to update the getlastmodified property using PROPPATCH. However, all is not lost for synchronization. Since clock times are notoriously unreliable over the network, HTTP provides a facility called entity tags (Etags). An Etag is a unique identifier for a particular state of a resource. The uniquenes of an Etag is scoped to an individual resource. The basic idea is that when a resource changes, the Etag changes too. HTTP caches often use Etags due to this property. You could use Etags for your synchronization activity in the following way. When resources are originally downloaded, persistently save the Etags and the local time of download in a file (.etags, or similar). When it's time to synchronize, you can check the local etag vs the remote etag to see if the resource has changed on the remote server. You can check the local modification date vs. the download time to see if the file has changed on the local machine. > I have done testing with several servers like (Driveway.com, Zope.org, > Sharemation.com)and notice that they all return the "getlastmodified" property > but sometimes the namespace is different from server to server. The getlastmodified property is defined to be in the "DAV:" namespace. This namespace is mapped to a specific prefix letter within a specific XML message. In RFC 2518, you'll see plenty of examples where there is the attribute: xmlns:d='DAV:' This means, map the prefix letter "d" to the namespace "DAV:". Precise semantics and rules are given in http://www.w3.org/TR/REC-xml-names/ So, while Driveway, Zope, Sharemation, etc. all use different *prefix* letters, they all use the same *namespace*, DAV:. > When parsing this xml response I always look for ":getlastmodified" to > determine the time for the file. This will work most of the time, but would not handle the case where two namespaces were in use, say "DAV:" and "http://www.me.org/foo/", each mapped to a different prefix letter, say "d" and "f", and getlastmodified exists in both namespaces. Your parsing algorithm would treat them the same, though they have different semantics. > Do I have to specify the namespace in xml when doing a PROPPATCH ? Yes. > Is this namespace different for each server ? For properties defined in RFC 2518, no. > Is there a generic way to specify the getlastmodified time to set ? No. It is set as a side-effect of PUT, and possibly PROPPATCH. - Jim From w3c-dist-auth-request@w3.org Thu Jul 27 20:36:53 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09936 for ; Thu, 27 Jul 2000 20:36:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01020; Thu, 27 Jul 2000 20:31:49 -0400 (EDT) Resent-Date: Thu, 27 Jul 2000 20:31:49 -0400 (EDT) Resent-Message-Id: <200007280031.UAA01020@www19.w3.org> Message-ID: <003e01bff82b$f41ebac0$fed670d8@concentric.net> From: "John Glavin" To: References: <811CF5012080D211AB6000805FD468A3A5997C@exchange.laplink.com> Date: Thu, 27 Jul 2000 17:37:04 -0700 Organization: RiverFront Software 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: Re: How do I set getlastmodified using PROPPATCH ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4386 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Thanks for all the information on the getlastmodified property. I was thinking about using a custom property to save the modified time myself, however after trying this on several servers. Most of them report a status of "409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. This includes trying to set read- only properties." Is this error because I haven't been granted access on the server to do a PROPPATCH, or perhaps I haven't formatted the request properly ? I get this error on the Zope test server with an account that was created for me, I also get it on my driveway.com account. On the sharemation account it seems to work fine, I can create my own properties. On the MyDocsOnline server, it actually accepts the proppatch with a status of 200, however when I list all properties with propfind it is not listed. Here is what my request looked like. PROPPATCH /test.txt HTTP/1.1 .... .... Here is my property value Thanks, John Glavin jglavin@riverfrontsoftware.com > Hi John, > We have similar synchronization (and Dav) software here and have found > that most companies do not (and will not!) support the setting of the > getlastmodified property. I'd be interesting if you start hearing > different. > > Jack > > > -----Original Message----- > From: John Glavin [mailto:jglavin@riverfrontsoftware.com] > Sent: Thursday, July 27, 2000 3:02 AM > To: w3c-dist-auth@w3.org > Subject: How do I set getlastmodified using PROPPATCH ? > > > Problem: > > I have converted my FTP application webdrive (www.webdrive.com) to support > DAV and I need to be able to set the "getlastmodified" property using > PROPPATCH so that utilities like powerdesk can syncrhonize files from a > Windows PC to a DAV server. > > I currently retrieve the "getlastmodified" property when I generate a > PROPFIND request on a collection (directory) and this spits out all the > files in the directory along with all properties defined. I have done > testing with several servers like (Driveway.com, Zope.org, Sharemation.com) > and notice that they all return the "getlastmodified" property but sometimes > the namespace is different from server to server. When parsing this xml > response I always look for ":getlastmodified" to determine the time for the > file. > > Questions: > > Do I have to specify the namespace in xml when doing a PROPPATCH ? > > Is this namespace different for each server ? > > Is there a generic way to specify the getlastmodified time to set ? > > Thanks, > John Glavin > RiverFront Software > jglavin@riverfrontsoftware.com > http://www.riverfrontsoftware.com From w3c-dist-auth-request@w3.org Fri Jul 28 18:21:48 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05743 for ; Fri, 28 Jul 2000 18:21:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA01609; Fri, 28 Jul 2000 18:15:47 -0400 (EDT) Resent-Date: Fri, 28 Jul 2000 18:15:47 -0400 (EDT) Resent-Message-Id: <200007282215.SAA01609@www19.w3.org> From: Jim Whitehead To: John Glavin , WebDAV WG Date: Fri, 28 Jul 2000 15:10:39 -0700 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.2910.0) In-Reply-To: <003e01bff82b$f41ebac0$fed670d8@concentric.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: How do I set getlastmodified using PROPPATCH ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4387 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John Glavin > Sent: Thursday, July 27, 2000 5:37 PM > To: w3c-dist-auth@w3.org > Subject: Re: How do I set getlastmodified using PROPPATCH ? > > > I was thinking about using a custom property to save the modified time > myself, however after trying this on several servers. Most of > them report a status of > > "409 (Conflict) - The client has provided a value whose semantics are not > appropriate for the property. This includes trying to set read- only > properties." > > Is this error because I haven't been granted access on the server to do a > PROPPATCH, or perhaps I haven't formatted the request properly ? Well, I suspect that, for the Zope server, the "manage properties" permission is not set for the resource, since they claim support for PROPPATCH. You should ask them directly about this, at webdav@zope.org. As for Driveway and MyDocsOnline, I suspect that they have simply not implemented PROPPATCH, since the main motivation was to support Web Folders, which does not require PROPPATCH. You could send them email directly to confirm this. > Here is what my request looked like. > > PROPPATCH /test.txt HTTP/1.1 > .... > .... > > > > > > Here is my property > value > > > This request looks well-formed to me. As a style note, the DAV: namespace is intended for use by the WebDAV protocol -- new applications should use a non-DAV namespace. For you, I recommend using "http://www.riverfrontsoftware.com/", and hence your request would look like: PROPPATCH /test.txt HTTP/1.1 .... .... Here is my property value Of course, you could choose any URL for the namespace, and any prefix character that was unique within the message. - Jim