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

Hi Noah,

On Thu, May 08, 2003 at 03:01:42PM -0400, noah_mendelsohn@us.ibm.com wrote:
> I don't see the situation as being this difficult.  If I understand Roy, 
> the owner of the resource gets to decide on the nature of that resource, 
> what sort of state it accepts and stores, and how it deals with that state 
> over time.  Why not describe the situation this way:
> 
> "DAV is commonly used in conjunction with resources that have as their 
> semantic to store and faithfully return the pair {contentType, 
> octetStream}.   Users of DAV applications that expect such behavior would 
> do well not to use their applications in conjunction with resources that 
> have different behavior."

Sure, that would take care of it, but with the large cost of having
islands of interoperability; one island where PUT=store, and the
other where PUT=set.  How is a client supposed to know which one it's
dealing with, without out of band coordination?

REST requires that messages be self-describing to prevent this from
happening.  If a PUT message is sent with an intent incompatible with
what PUT means on the Web, then it is not self-describing, because HTTP
has no means to declare the extended intent (i.e. no mandatory
extensions) such that any party can know one is being requested.

It's very possible that I'm making a mountain out of a molehill here,
but I believe that will be determined by how well deployed the notion of
"PUT = bit-wise store" is on the Web today, which I've said that I don't
have first hand knowledge of.  But what I have seen and heard suggests
that it is widespread.  Can we change that while not breaking things?
I don't know.

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

Received on Thursday, 8 May 2003 15:54:15 UTC