Re: Distributed Authoring Proposals

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