Subject: FW: [Moderator Action] WebDAV WG minutes

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 20 Mar 2002 13:11:13 -0800

Accidentally caught by the spam filter. I have added <[email-masked]> to the accept2 list.

- Jim

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 5:47 PM
To: [email-masked]; [email-masked]
Subject: [Moderator Action] WebDAV WG minutes

Minutes from WebDAV WG meeting
March 19, 2002
53rd IETF, Minneapolis
Reported by Larry Masinter, Adobe

Chair present: Lisa Dusseault, Xythos

Status of Various Efforts
-------------------------

DeltaV: The DeltaV working group is closed, however issues are
still being discussed actively on the working group mailing list.
No interop events are planned as yet.

Q: Any clients for DeltaV? TeamStream (Xythos web file client) is a
very limited client. Might assume that server vendors have
clients. SubVersion has a client, but will only work with SubVersion
for a while.

Interop Plans: WebDAV to Draft Standard requires demonstration
of interoperability of various features between independent
implementations. First interop was last August, another last fall,
want to start again this spring.

Suggestion from Brotsky: schedule rolling, round-robin, server 
interops, e.g., server-client pair have dates for focus on interop 
issues. Match servers with clients every month. Some folks were 
interested.

Access control: in last call. Some discussion of special-purpose
principal search reports. 

DASL draft: Revived in WebDAV WG rather than defunct DASL WG.  Julian
Reschke planning 2 separate drafts. The framework draft will cover the
model and the request/response syntax.
A separate mailing list exists for DASL, but some comments are 
mirrored on the WebDAV mailing list. Search framework issues: 
character comparison, how to discover what search arbiter to search 
namespace portion, what are search arbiters? Not special resources. 
Is any collection a potential search arbiter? Need for "more results" 
query.

Issue: there is some overlap of issues between DASL and XML Query. 
However, XML Query doesn't handle marshalling, for example. 
Coordination between DASL and XML is needed.
Query: member of XML Query working group will review DASL.

Individual drafts related to WebDAV:

- tickets (proposal to support tickets for access control by
  unnamed users)
- quota (proposal to expose 2 named properties to handle
  quota on collections: size and quota limit in bytes)
- property datatypes
  Proposal to W3C to do XML element datatyping, predated
  XML schemas
- Ordering

Long list of dead drafts & proposals
  either dead or sleeping
  - bindings, redirect references, ordered collections,
   property registration proposal, property namespace and
   allprop, use of dublin core metadata in dav,
   additional webdav ...
   (take from slide)

comment: since drafts expire after 6 months, these proposals are dead unless
re-raised.

Issue of differing use models driving WebDAV development in different
directions
 - use WebDAV as a file system. 
 - Use to work on local repository and publish/share to WebDAV. 
 - Synchronized use model, work on local store and sync, work from any
machine, online or offline.
 - Acrobat use webdav repositories for annotations when not for the
documents themselves.  
 - Webdav for Web Site authoring and not for much for file sharing.

Some evidence: webdav getting more interest from PC users, increasing
press. WebDAV tutorial at AIIM (document & content management folks).
Many document management tutorials. Article in PC magazine.

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.

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.

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.

lock-null resources were removed from the spec. Most of the 
complex lock-null features weren't being used. A simpler model
of creating a locked empty regular resource seems to be 
interoperable, it even work with clients that can lock unmapped URLs.

Removed propertybehavior feature.

Open issues in RFC2518bis
-------------------------

If header

Don't know what to do with the 'if' header.
Ambiguities in the specification lead to clients not
implementing complex behavior. The syntax doesn't support 
multiline values, which could mean problems when large
header values must appear all in one header.  

E.g. IIS5 locks only resources, not collections, which 
results in many more locks in some situations.  Operating 
on a collection containing many locked resources requires 
specifying different tagged lock tokens for each resource
in If header.  This results in such header length that web
intermediaries cause problems.

How to apply with Depth and Destination headers?

"If" header confuses two purposes:
 - conditional which clients requires to be met
 - provision of lock token, which server requires to be there
Implementations seem to be more forgiving than spec suggests.
Can we demonstrate use or interoperability for
Tagged production? boolean combination logic support?
Use of ETags in "If" header?

Proposal: only use "if" header for a list of lock tokens.

Possible fix: add a header that does only one thing well,
comma-delimited lock tokens?

Possible fix: describe current behavior of the if header, and leave it
at that.

Dirk: If no-one is using the original if-header as originally
specified: it's like there are two 'if' headers, maybe would allow
existing syntax that clients use to be continue to be used, but in a
more liberal way.

This is one of the thorniest issues.

Source Property

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

Proposal: remove 'source' property
 
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

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

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 21 Mar 2002 09:47:01 +0100

(I am splitting my comments into separate mails so that we get distinct discussion threads)

> Status of Various Efforts

- I happen to have tested the TeamStream client two days ago (with our server). It's good that there *is* a versioning-aware client, but the current implementation shows that it's not trivial to support the more advanced features. As far as I understand, it currently can *show* a (linear) version history (minus DAV:comment property), but it doesn't really support actions on the version resources (like opening, deleting and so on...)

- Technically, our remote WebDAV adapter *is* a DeltaV client, and it's goal is to interoperate with any RFC3253 server. So far, we haven't found any server to test against except our own (Subversion and Xythos interop fails for various reasons). So I think an interop testing event with a special focus on deltaV would be extremely useful.
 
> issues. Match servers with clients every month. Some folks were 

- I think it would be a good thing to automate as much as possible. Test suites like Litmus are welcome and server developers should have a public test site for their latest code.

> model and the request/response syntax.

- Clarification: I'm not planning separate drafts. The plan is to issue new drafts as each of the sections becomes stable (framework, basicsearch, QSD...). Right now, the framework (SEARCH method, grammar discovery, error reporting) seems to be stable. The first draft will be submitted as soon the IETF accepts them again.

> Query: member of XML Query working group will review DASL.

- That would be welcome. Ideally, DASL would just be about *applying* the basics from XML Query / XSLT to the WebDAV specific case.

>   Proposal to W3C to do XML element datatyping, predated

- Clarification: it doesn't predate XML Schema -- it's completely in sync with it:

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html>

> - Ordering

- Draft 03 will be submitted next week (unless problems with the draft are reported before):

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest.html>

>   - bindings, redirect references, ordered collections,

- We would be interested to revive the BIND protocol / draft.

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 21 Mar 2002 09:56:21 +0100

> RFC 2518bis (potentially) closed issues

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>

> field is needed, this will have to be done in a separate draft, not

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. 

> not be a webdav resource.

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

>  ...

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

> source property: 2518 doesn't define how to present and describe 

I think it does, but there are several other problems with the current definition (already captured in the issues list).
 
> '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 :-)