Subject: IETF meeting comments

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Jul 2004 21:57:43 +0200

Hi,

I'll not be able to attend the meeting, neither personally, nor using 
the text conferencing facilities. BTW: will the meeting actually take 
place? I'm asking because it's in one week, and no agenda has been posted.

Anyway, here's what I think *should* be discussed primarily:

The BIND spec has been stuck in it's current (IMHO finished) state for 
several months now, and the updated working group charter 
(<http://www.ietf.org/html.charters/webdav-charter.html>) says it should 
have been (wg-) last-called two months ago. This hasn't happened.

Note the current BIND spec is version 06 (HTML: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-06.html>, TXT: 
<http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-06.txt>, 
issues list: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>).

As far as I can tell, the only remaining open question is whether 
RFC2518's treatment of locks is sufficient to explain the relation 
betweem (multiple) bindings and locks. The (active) authors of the spec 
(Geoff and myself) agree that the BIND spec is compatible with what 
RFC2518 says about locks, and no further clarification is stricly 
required. Note that RFC2518 already talks about locking "replicated 
resources" 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3>), so 
this has been explicitly planned for even back then. The important fact 
here being that multiple bindings to a resource and locks are already 
compatible, and nothing needs to ne explicitly changed for that.

Now, how should that spec proceed? There seem to be several options, 
including:

#1) Just release the BIND spec as is (that is, immediately do a WG last 
call),

#2) Add locking specific clarifications to BIND, then release it,

#3) Release the BIND spec with a normative reference to RFC2518bis 
(essentially delaying it until RFC2518bis is finished) or

#4) Extract locking out of RFC2518bis into a separate spec, resolve all 
open locking-related issues, and submit this as a new specification 
(updating RFC2518) for publication as a proposed standard (note there's 
a long summary about this option posted by me in April (!): 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>). 
Note that none of these open locking issues (those listed on RFC2518's 
issues list at <http://www.webdav.org/wg/rfcdev/issues.htm> actually has 
*anything* to do with the relation to multiple bindings). BIND then can 
either be released independantly or with a normative reference to that 
new spec.

Personally I see nothing wrong with option #1. Several implementors 
already have BIND working experimentally as defined in the spec (for 
instance Apache Slide and SAP in Netweaver). More people seem to look at 
it but may be waiting for it to become an RFC. Unless there's an actual 
risk of people misunderstanding BIND and lock interactions (something we 
*could* take care of on this mailing list), having possible lock 
clarifications appear in something published slightly later doesn't seem 
to be any problem at all.

#2 IMHO would be an *extremely* bad idea, because it would duplicate 
specification text in several specs, so spec revisions either need to be 
100% compatible with it; or BIND would soon need to be updated itself by 
these revisions. So there'd be additional work and risk of being 
inconsistent with very little gain. Remember that support for multiple 
bindings and locking are completely separate things (you can have 
multiple bindings on a server without locking support because locking is 
an *optional* WebDAV feature).

#3 makes sense if RFC2518bis is actually going to be finished anytime 
soon. I made my contribution by pushing for resolutions for almost all 
locking-related questions; but it's up to the authors to give an 
estimate about when it can be done. (I'll try to review the new draft 
before next week; and it would be good if others would do that as well).

#4 is the option I've been working on the last three months (HTML: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-05.html>, 
TXT: 
<http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-05.txt>, 
issues list: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>). 
As far as I'm concerned, this spec is almost done (with the notable 
exception of finding the right place for the GULP summary and discussing 
the locking-related questions of "If" header semantics). Even if the 
working group decides not to adopt this as a WG document, the effort 
still will have been worth it for the progress we've been making on open 
locking issues. Of course I personally would like to see this to be used 
as a basis for a new specification so that the locking feature can be 
removed from RFC2518bis. This would actually make it *easier* for 
RFC2518bis to progress to a "draft" standard, because it would be 
significanly simplified.
In the case the WG makes that decision, I'll happily work together with 
volunteers to finish this as a working group document.

As far as other specs are concerned (SEARCH, REDIRECT), I expect to get 
back to them as soon as we have made progress on the BIND issue.

Best regards, Julian

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

---

From: Bob Denny <[email-masked]>
Date: Tue, 27 Jul 2004 16:22:14 -0700

Julian, et al. --

After a 2 year absence from working on DAV, I re-activated my project (a
DAV server-side package) and was quickly overwhelmed with more "gotchas".
The biggest one was an attempt to LOCK a non-existent file by Dreamweaver.

I know you all have put forth a big effort to get DAV into shape to support
it's mission, and it appears that you're about to release the definitive
spec to follow RFC2518.

But as an outsider trying to implement a server, I have once again given
up. The Microsoft "extensions" and quirks (still out there en masse), their
inability to use ISO dates, and the usage patterns that come from the many
DAV clients out there are really too broad-scoped to conceive when
designing a server.

When faced with LOCK on a non-existent resource, my design collapsed. I had
built the DAV server to use the NTFS file attributes (a separate place to
store info related to the main data in a file) so I could support moving
files around on the server machine with the local shell, and have the extra
DAV attributes and locks info move with the files and directories. The
operation of locking a non-existent file invalidates this approach, and
thus my entire design. It appears that a separate parallel universe like
mod-dav is required.

This was not at all obvious in RFC2518. And the "issues" lists are so full
of internals info and wording negotiations that guys like me give up trying
to mine useful implementation tips out of them too.

I know of several people who gave up on client side implementations of
WebDAV as well. Managing locks seems to be the land mine that ends
projects. Personally, I think it got beyond the 90/10 realm, and became
overly complex (hence your approach of dealing with it in a separate
document :-))). I doubt that most of the clients out there need/use but a
small part of the locking features.

Anyway, one thing I might suggest for the working group dinner at IETF is
to set aside some time to discuss how to lower the risks for implementation
of DAV clients and servers by people not actively participating in the WG.
Perhaps a survey of your members on the most common implementation issues,
and things that you probably won't think of when designing from the RFCs. A
"DAV Developer's Guide" (not related to Apache or mod-dav) would be a
wonderful addition to the documentation.

Respectfully,

  Bob Denny
  Mesa, AZ

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Jul 2004 01:35:07 +0200

> DAV clients out there are really too broad-scoped to conceive when

I think the latest Microsoft clients work just fine with a compliant 
WebDAV server, that is, no more problems with the correct date formats 
(in the past it would only work when the (proper) date would come with a 
datatype declaration).

> thus my entire design. It appears that a separate parallel universe like

Not really. In the meantime, the working group has agreed that "lock 
null" resources are just too complicated to justify them and has settled 
with something cheaper. Hence, if you LOCK an unmapped resource, this is 
equivalent to PUTting an empty resource, then locking it. This should 
make things *much* easier and works fine with the standard clients.

> to mine useful implementation tips out of them too.

That's why we have a mailing list and try to get out updated specs.

> small part of the locking features.

That's probably correct. In particular, I think having a RFC2518bis with 
locking removed (into a separate spec) may actually help adoption of 
WebDAV. It's important to realize that not to implement WebDAV locks is 
just fine; WebDAV consists of namespace operations (COPY/MOVE, Depth 
operations), metadata (PROPFIND/PROPPATCH) and locks (LOCK/UNLOCK). The 
latter are optional, and many interesting things can be done entirely 
without them.

> wonderful addition to the documentation.

This is probably a good idea. Did you take a look at the "WebDAV book of 
why" (<http://www.webdav.org/papers/#misc>) and Lisa's book 
(<http://www.amazon.com/exec/obidos/tg/detail/-/0130652083/002-9165843-0104803>)?

Best regards, Julian

---

From: Bob Denny <[email-masked]>
Date: Wed, 28 Jul 2004 09:38:01 -0700

Julian, et al. --

Thanks for your fast response. Lisa D. also answered privately. I do
appreciate the concerns of you both :-))

Creating an empty file when a lock null is received will certainly make
things possible again. I will try it, and press onward. My goal for the
moment is just to get DAV working with Dreamweaver, so that should reduce
the scope of patterns I must deal with :-)

One possibly useful thing would be to encourage the DAV client developers
to respect the DAV version and the list of DAV commands returned in an
OPTIONS request. It seems that at least some clients (GoLive and
Dreamweaver at least) don't look to see if LOCK and UNLOCK are in the
OPTIONS list. They send LOCK/UNLOCK regardless.

I got wound up tightly trying to support Microsoft's clients (with their
need for MS-Author-Via: DAV, non-standard dates, and crazy "extensions")
and gave up. I really don't care any more about Microsoft's DAV usage :-)))

Thanks also for the reference to papers. I'll review them.

  -- Bob

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Jul 2004 00:32:03 +0200

Bob Denny wrote:
> ...

That should be no problem as long as they handle "Method Not Allowed" 
properly.

> ...

Best regards, Julian

---

From: Frank Lowney <[email-masked]>
Date: Thu, 29 Jul 2004 13:19:57 -0400

>and gave up. I really don't care any more about Microsoft's DAV usage :-)))

I may be mistaken but wouldn't MS prefer that everyone use MS FrontPage extensions instead of WebDAV?  MS says 'embrace and extend' when perhaps they are thinking 'embrace, extend and wreck.'

-- 
=====================================================================
Dr. Frank Lowney  [email-masked]
    Director, Electronic Instructional Services, a unit of the
    Office of Information and Instructional Technology,
    Professional Pages: http://www.gcsu.edu/oiit/eis/
    Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
NOTICE: Please be advised that I am hearing impaired and communicate most effectively via e-mail.  Follow-up summaries of telephone conversations by e-mail are most appreciated.
=====================================================================
We don't make instruction effective, we make effective instruction more accessible.