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
"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".

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.

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.

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

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Thursday, 8 May 2003 00:24:40 UTC