W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RFC2518bis, was: [Moderator Action] WebDAV WG minutes

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 21 Mar 2002 09:56:21 +0100
To: "WebDAV" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEAJEEAA.julian.reschke@gmx.de>
> Minutes from WebDAV WG meeting
> March 19, 2002
> 53rd IETF, Minneapolis
> Reported by Larry Masinter, Adobe
> 
> Chair present: Lisa Dusseault, Xythos
> 
> 
> RFC 2518bis (potentially) closed issues
> ---------------------------------------
> 
> For moving to Draft, need two independent interoperable
> implementations of every feature: two clients & two servers for each
> feature.
> 
> Use and meaning of allprop? If allprop doesn't mean "all properties"
> what does it mean? Proposal: all properties defined in 2518 plus all
> dead properties client sets, but not live properties defined in other
> drafts. This has already been put into practice by servers, and that 
> wasn't an issue at the interop event.

We still have the open issue to define a protocol extension that allows to PROPFIND all dead properties plus a set of named live properties in a single call. Proposal at:

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-latest.html>

> Who controls lock owner field? Client does.  If a server-controlled
> field is needed, this will have to be done in a separate draft, not
> in RFC2518 bis.

Question: is there any intention to bundle all RFC2518 extensions (allprop behaviour, live deltaV properties, REPORT method, DAV:source property...) into a single WebDAV extension RFC? I think this would make a lot of sense. 

> When to refresh a lock timeout? Nobody implemented what the document
> said. New model: only a lock refresh request refreshes the lock.
> 
> Where root of repository may be? Some clients couldn't handle
> servers where path elements that aren't webdav resources.
> Some servers couldn't do what some clients wanted. This has
> been clarified, in http://host/a/b/c/d, http://host/a/b might
> not be a webdav resource.

...and should be clarified to Microsoft as well :-).

>  ...
> 
> Source Property
> 
> Another remaining issue: with the 'source' property. Have there
> been any implementations?  (appears to be none)
> 
> Proposal: remove 'source' property

...and attempt a new definition in a new document.

> Those against this proposal (not present but their arguments were
> recapped) say that one can't use WebDAV for what it was originally 
> intended to do, without source property
>   
> Those against this proposal fall into two camps.
> 1: source property is fine, we just need to put ourselves out to 
> demonstrate interoperability.
> 2: source is not fine, let's use replacement that actually works
>
> Does the source property actually works? One known problem with 
> source property: 2518 doesn't define how to present and describe 
> multiple sources

I think it does, but there are several other problems with the current definition (already captured in the issues list).
 
> Brief discussion of using (Microsoft) Translate header. It's a boolean
> flag in a header.  What it really means is "I'm in authoring mode" or
> "I'm in browsing mode".   If header is missing, browser is assumed.
> 
> "Translate: F" when present asks for source rather than result.  This
> is included in all authoring client requests.  
> 
> Although Translate doesn't handle multiple source files directly 
> either, it's possible that it addresses scenarios that are required to be
>  addressed.
> 
> May have some advantages.  For example, since it's present on all 
> requests, the server can infer other preferences like 
> 'PROPFIND returns size of original files'.

I don't want to restart the thread, but the "advantage" mentioned here is that the Translate header "solves" a problem that you wouldn't have in the first place when properly distinguishing source and output resources :-)
Received on Thursday, 21 March 2002 03:57:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:00 GMT