- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Wed, 26 Mar 1997 22:48:56 PST
- To: Jim Whitehead <ejw@ics.uci.edu>
- CC: w3c-dist-auth@w3.org
Jim Whitehead wrote: > > Larry Masinter writes: > >I wish I felt confident that WEBDAV actually had addressed these > >fundamental simple operations, before we went off onto long > >flights of design around COPY and MOVE and establishing metadata. > > I assumed that the semantics of PUT with respect to various media types had > already been addressed, either in the HTTP/1.1 specification, or by > convention. I am unaware of any satisfying implementation of "PUT" as specified in HTTP/1.1, even as it might be used for "replace the entity of the resource located by the request URI by the entity body", especially when it has come to dealing with the normal MIME semantics of the "special" MIME types of, say, multipart/related, multipart/alternative, etc. I suppose I have high requirements for "satisfying", but I mean one where the requirements necessary for reliable authoring are fully worked out and specified without the necessity of reverse engineering. If you were to order WEBDAV requirements from "fundamental" through "frequent" all the way to "esoteric", I think "store this object on in your server please" would be ranked as "fundamental". > It seems that the general issue here is: how should a DAV-capable server > handle PUT operations for certain MIME classes (multipart, message, etc.). Yes, a good, solid definition of PUT in the context of Distributed Authoring and Versioning would be very useful. > Would you do us a favor and describe the bounds of this issue (i.e., what > classes of MIME types you find to have troublesome semantics in the context > of DAV)? Well, actually, I have trouble with the semantics of PUT for any MIME type, as far as which invariants might be expected as a result. If I PUT an entity, should I expect the same entity the next time I GET the same resource? (Assuming, of course, no intervening PUTs?). What is the interaction or presumed interaction of PUT and cache validators, LINK tags, and other HTTP/1.1 objects? I think the HTTP/1.1 specification is pretty vague about this, mainly because HTTP/1.1 focuses on document access without dealing with the requirements of editing and update. The recent issue raised was over the interaction of PUT and those message encapsulation MIME types (message/*, multipart/*) that are presumed, at least in the mail context, to be processed somewhat automatically by the message user agents without affecting the semantics of the message itself. That is, if I send a multipart/alternative to a recipient, I don't expect the recipient to see "aha, an 'alternative'" but rather, one of the types that were enumerated in the alternative. The simple question of whether the body of a PUT is a message (intended to be decoded by the recipient resource) or a delegation (intended to be transferred identically to the next recipient who might request the resource) is not answered in HTTP/1.1. I suppose it's "up to the server", which I suppose is OK, but doesn't lead one to believe that PUT can be used reliably for site updating and maintenance. > However, it seems to me that this issue is largely orthogonal to copy, > move, and metadata operations. Well, not really. Unless you know what PUT means, there's not much point in knowing what COPY means. There's a sense in which you might be able to define COPY without defining PUT, but it wouldn't make a very useful "distributed authoring and versioning" system unless you could PUT new data. > I'm also not yet convinced this needs to be addressed by the DAV specification. I don't know about "the DAV specification", but I think that the semantics of PUT (or at least a definition that would allow for interoperable authoring clients) need to be addressed before you actually can do Distributed Authoring and Versioning. Larry -- http://www.parc.xerox.com/masinter
Received on Thursday, 27 March 1997 01:48:57 UTC