Next message: Clemm, Geoff: "RE: Versioning TeleConf Agenda, 4/24/00 (Monday) *1-2pm*EST"
From: Jim Whitehead <ejw@ics.uci.edu>
To: David.Goodenough@dga.co.uk, ietf-dav-versioning@w3.org
Date: Mon, 24 Apr 2000 15:24:43 -0400
Message-ID: <NDBBIKLAGLCOPGKGADOJAEDCDCAA.ejw@ics.uci.edu>
Subject: RE: Collection Fetch/Save proposal
Hi David,
My apologies for the slow reply...
> Abstract:
>
> This proposal adds function to the GET and PUT methods to allow the
> fetching and saving of entire collections with a single operation.
>
First, while I'm in favor of the goals of your proposal (it would be nice to
have some methods that would allow the reading and writing of multiple
resources in one network request), I think there are a couple of technical
problems with the specific approach you outline. I detail these concerns
below:
1) In HTTP/WebDAV, each method can express preconditions, using the If*
headers. These can include items like lock tokens, to ensure that locked
resources can be written, and entity tags, to ensure that a resource is
retrieved only if it's a later revision of one the client already has. Your
proposal didn't have support for expressing If* header preconditions.
However, this could probably be remedied with some additional marshalling
mechanism, and so it isn't a showstopper for your proposal.
Range requests would also be troublesome to deal with.
2) There are no constraints on the content of an HTTP resource. In
particular, this means that HTTP resources can have 0x00, 0x0D, "<", and
"">" characters in them. This can cause trouble with XML parsing. While you
could encode the resource contents as XML CDATA, this still raises the issue
of how to handle the CDATA terminator sequence if it naturally occurs within
the resource contents. Furthermore, if the HTTP resource was itself XML,
this would raise additional encoding issues. What if the XML document
included some DTD language -- this would be a problem if it occurred
midstream in some other XML. While undoubtedly all of these issues could
eventually be dealt with by using various encodings, I don't think the final
result would be particularly elegant.
This same encoding problem plagues another similar proposal that was made on
the main WebDAV mailing list:
http://www.ics.uci.edu/pub/ietf/webdav/mime-res/draft-stracke-webdav-mime-re
source-00.txt
In my view, the best way to approach this problem is to use the MIME
multipart/related content type, as described in RFC 2387:
http://andrew2.andrew.cmu.edu/rfc/rfc2387.html
One of the original design goals of multipart/related was to describe Mac
files, with their resource and data forks. These are just like WebDAV
resources, with their body, and set of properties. So, multipart/related
could be used to represent a single WebDAV resource by placing the
properties in one MIME section, and the body in another. This would avoid
the encoding issues described above in #2. By nesting the MIME
multipart/related description of a single resource inside a larger multipart
structure, multiple resources can be encoded in a single MIME entity.
Then, since the semantics of PUT and GET are pretty hardwired to single
resource writing and retrieval, and since servers authors are typically very
hesitant to add extra functionality to GET, since this is the most commonly
accessed method, I recommend defining new methods, MPUT and MGET.
But, once this is done, I think it would be a useful set of functionality.
Alternately, you could create a BATCH method, which takes a multipart
message, where each part is of type message/http (i.e., a single HTTP
request, as defined in the HTTP/1.1 spec.). The response message would also
be a multipart, where each part is a message/http with the HTTP method
response. I'll leave it as an exercise to the spec. writer to figure out
how to handle the transactioning issues (i.e., if one message in the middle
of the batch fails, what happens next?) Your multi GET and PUT are just one
application of the BATCH method.
So, I'm in favor of the goal, but tend to think that your suggested
marshalling has some technical problems that make it an undesirable
approach.
Also, since this functionality isn't specific to versioning, it probably
belongs on the WebDAV working group list (w3c-dist-auth@w3.org), rather than
on this one. I'll reply either place, though :-)
- Jim