RE: Draft TAG finding available: Client handling of MIME headers

> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf Of
> Mark Baker
> Sent: Thursday, May 08, 2003 6:27 AM
> To: www-tag@w3.org
> Subject: Re: Draft TAG finding available: Client handling of MIME
> headers
>
>
>
> I like Noah's analysis very much, but I think it's missing an important
> consideration that effects the conclusion.
>
> I agree that it would be great if PUT meant (in practice) "set the state
> of this resource", as that would allow nice things like a SOAP binding
> to HTTP which used PUT, as well as just making the method more general.
> But the bulk of the use of PUT is with DAV, and DAV uses it to mean
> "store".  Unfortunately, it's problematic to have it mean "store" and

Well, RFC2518 is silent about that. Indeed most uses of WebDAV *currently*
are basically network filesystems, but there already examples to the
contrary (for instance, there are servers that do not persist the octet
stream but the XML infoset of XML entities, thus do not round-trip things
like whitespace within tags or attribute quotation styles). This is a
perfectly legal implementation of PUT and is both in line with HTTP and
WebDAV (in fact, WebDAV doesn't say anything particular about PUT).

Maybe the WebDAV WG should consider mechanisms for clients to discover the
server's expected behaviour, but so far nobody seems to have asked for that
(in fact, observing the entity tag returned upon PUT may do -- if it's a
strong etag, the server must have done a "store").

> "set" at the same time on the public Web, as there's no way for a PUT
> message with "set" intent to be distinguished from one with "store"
> intent, and "set" is incompatible with "store" (as it's more general,
> not less).  If it were the other way around, and "set" semantics were
> commonplace, then there would be no issue.  Or, if HTTP had mandatory
> extensions, then I could use PUT with "set" intent without confusing
> components that only knew about "store".

Can you give an example where this kind of confusion arises?

> Now, that said, it may well be that use of PUT is not widespread
> enough, so that the cost of changing common practice is less than the
> value gained from doing so.  I don't know enough about that to say.

Even if "store" is common practice, IMHO that doesn't mean there's a problem
with "set".

> But back to Julian's "Issue #2".  I agree with Roy; a server owner
> should be allowed to do whatever they want, since the representation
> crossed a trust boundary.  But on the other hand, there's a cost to
> changing it, as described above, that needn't exist.  I'd offer this
> as a TAG issue, but it's rather esoteric.

On the contrary, I think it's pretty urgent. In authoring scenarios such as
WebDAV, we can only get clients to properly MIME-label their PUT requests if
there's some hope that the remote server will care about that. We still
don't know yet, but this may have been the reason why Apple invented the
"ical" URI scheme instead of relying on content types, and I think we all
agree that we want to avoid abuses like that.

> BTW, I think this draft is *very* well done.

Yes.


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

Received on Thursday, 8 May 2003 03:57:35 UTC