RE: Some problems with the WebDAV protocol

> I fail to see what is the problem. If a server has a problem to
> create certain
> URI's, because that would conflict with namespace consistency,
> then it shouldn't
> allow *those* URIs to be created. Clearly in many cases, the
> server can create
> the "missing" collections without any namespace consistency problems.

This is discussed a bit in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0305.html

>
> > This would have required us to add a
> > requirement that a PUT to a URL would have to create all intermediate
> > collections.  But, this seemed to us to be adding excessive
> side-effects to
> > PUT, especially since a user might not even want those extra
> collections to
> > be created (i.e., they might have just committed an error).
>
> Why do you think that you must *require* things to be one way or
> the other?

In general, when we stated a requirement in the specification, we made it a
MUST, and then needed to be argued down from that level, rather than
starting at a MAY or SHOULD, and arguing up to a MUST.  A client can depend
on a MUST requirement, but it cannot depend on SHOULD or MAY requirements.
Furthermore, SHOULD and MAY requirements often lead to feature discovery,
which complicates a protocol.  MUST requirements generally increase
interoperability, since they are features which can be expected to be
present.

> > OK, so given that WebDAV has this extra requirement on PUT that HTTP/1.1
> > does not have, you are assering that a downlevel HTTP/1.1
> authoring client
> > would experience interoperability problems authoring against a
> DAV server
> > (or a DAV-capable portion of a server's namespace).  It seems
> to me that, if
> > users of these downlevel clients depend on the side-effect
> behavior of PUT
> > to create intermediate collections, they might indeed have some
> difficulty
> > authoring against a DAV-capable server.
> >
> > So, having agreed to your main point, we are now left to argue over the
> > severity of this interoperability problem.  I assert that it is
> minor, since
> > there are several existing workarounds.
> >
> > Workaround #1:
> > Use an existing DAV client as a helper to create the intermediate
> > collections.
> >
> > This addresses your question:
> > > And how do I do a MKCOL if I use Amaya, Netscape composer, AOLpress,
> > etc.,...?
> >
> > Use the helper to do the MKCOL (or create the collections in
> the underlying
> > repository, if you have access).
> >
> > Workaround #2:
> > Don't author in spaces where you don't already have an existing
> collection.
>
> A non technical user that is used to using a given application in
> a certain
> way is not going to be happy with any of that.

Agreed.  This is why I'm interested to know how many people might be
affected.

> Forced migration of large
> user populations to doing things differently is a big headache even when
> the new ways are more convenient than the old ones. Forced migration of
> large user populations to such awkward workarounds is pretty much out of
> the question.

But are these user populations large?  I doubt it.

> I don't have any statistical data how commonly people use PUT-based
> applications for web publishing, and how many of them have the habit
> of creating directories in this way. Nor do I have the slightest idea how
> one might be able to get such data in a reliable way.

How about starting with even a few actual use instances ("my friend Jake
uses authoring tool WebFoo all the time, and he uses HTTP PUT and depends on
the collection creating side effect"), and then moving on from there.  I
haven't even yet heard a *single* case of a person using and/or depending on
this capability.

> Surely, ftp is more
> popular, but given the large number of PUT-enabled applications and the
> convenience of using the same namespace for both viewing and uploading, I
> tend to believe *some* people are using it. If a large hosting operation
> has even a small percentage of its users relying on that functionality,
> they may run into a serious headache if they suddenly disable it. I think
> that breaking existing applications (and even more so breaking people's
> work habits) is something that should be avoided unless it is truly
> necessary or proven to be a non-issue (not the other way around).

Well I think that most people are completely unaware of this (for the user
population) undocumented feature, and don't use it.

> I agree that this whole thing is not such a "big" issue, but not for the
> same reason as you. The thing that makes it pretty benign is that nothing
> at all will happen to WebDAV interoperability if this requirement would
> be ignored.

My concern here is if a DAV client is written which depends on the
intermediate collections *not* being made (i.e., it depends on an error
being thrown if a user mis-types an intermediate collection name), then this
client would haev interoperability problems against a server which did
implement the intermediate collections.

> > Since RFC 2518 is now a Proposed Standard, you would have to provide an
> > extremely compelling argument, backed up with significant documentation,
> > that this document is causing common and widespread interoperability
> > problems for it to be modified, and re-issued.  At present, it
> is my opinion
> > that you have not done so.
>
> I do not consider this my personal problem. I'm basically just submitting
> a bug report. If you want to call it a feature, then fine. I feel like my
> moral duty was done. This particular bug, by the way, is very easy to fix.
> Assuming you want minimal disturbance to the protocol, then all it takes
> is changing one MUST to a SHOULD.

Actually, I do very much appreciate that you took the time to raise this
issue.  You've focused attention on a requirement that, until now, had been
considered to be harmless, and consistent with the namespace requirements.

> You don't say anything about the DELETE issue.

Believe it or not, I do have requirements on my time other than responding
to list mail (especially ones where my diligent work over the past two years
is maligned as  "arrogance").  I do intend to post on this issue, but it may
take several days. Thoughtful posts take time.

> What seems to really be going on here, is that some of you guys are
> basically saying: Look, we have this new protocol that is designed
> the way we think it should be, and we don't care all that much about
> other protocols and existing applications. So, unless someone *proves*
> that our protocol "is causing common and widespread interoperability
> problems" we don't really mind sending bogus response codes and breaking
> some functionality. People should just upgrade to use our new stuff.

The protocol has gone through extensive review on a mailing list of over 350
members, it went through *three* publically announced last call for comments
periods in 1998, and had 11 separate revisions over two and a half years.
Oh, and we also had 10+ face to face meetings where the specification was
discussed in public.  This was all done according to IETF process.  Your
ignorance of this process does not make it arrogant.

But, even after all this review, it is possible that problems will be
uncovered in the protocol specification. However, since several
organizations are investing tens of millions of dollars in developing
software which is compliant with the specification, I hope you'll understand
if more is asked of you than just personal opinion before starting a *very*
costly change process.

If you *really* think we're just being arrogant, why don't you take some
time and review the Advanced Collections protocol specification, or the DASL
protocol specification?  These are two new enhancements to WebDAV which are
currently being worked on (if you're an implementor, you may end up
implementing them both in the future), and they are close to being complete.
They haven't yet been approved, so they are still easy to change.  Both of
these specifications could certainly use a pass-over by someone like
yourself who can review a specification with a fine toth comb. The IETF is a
volunteer organization (I'm not getting paid for this), and hence the
quality of its specifications is directly related to the amount of time
people can volunteer to work on them.

The DASL specification can be found off of:
http://www.ics.uci.edu/pub/ietf/dasl/

The Advanced Collections specification can be found at:
http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/CollSpec032.txt

I look forward to your comments.

> As an implementor, *I* may decide that there are currently more
> HTTP/1.1 clients than there are WebDAV clients, and since I want to
> support both, I will simply ignore your prohibitions on PUT
> (which wouldn't cause any real problem)

I obviously do not have the power to change your code.

- Jim

Received on Tuesday, 20 April 1999 15:31:29 UTC