RE: Yaron.Redirect.PUT

Right. This is definitely a mistake that needs to be fixed.
 
--Judy

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Friday, February 11, 2000 2:49 AM
To: 'w3c-dist-auth@w3.org'
Subject: Yaron.Redirect.PUT



The last sentence of the last paragraph of section 6.2 reads: "The result in
this case is that the reference resource is replaced by a non-reference
resource having the content submitted with the request."

If a Apply-To-Redirect-Ref PUT results in the reference resource being
replaced then the reference spec will have robbed its users of any mechanism
to specify the response to a Apply-To-Redirect-Ref GET. I can't find any
reason for requiring this behavior given that a Apply-To-Redirect-Ref DELETE
followed by a PUT can achieve the same result and still leave users the
ability to specify the results of a Apply-To-Redirect-Ref GET. As such I
move that this sentence be deleted.

BTW, the reason I suggest deleting the sentence rather than replacing it
with language specifying what happens when a PUT is applied is that there is
no requirement that a PUT set the GET result. For example, the user may do a
PUT with text/html and the server may choose to return it as text/plain. So
it is very difficult to precisely specify what the result of a PUT is. What
it is not, however, is a way to delete a resource. Otherwise it would make a
mockery of unique resource IDs. Imagine I create a document and want to
track it. What the document is created it is issued a resource ID that I
record. That way, even if the document is moved, I can find it through its
resource ID. If PUT worked as specified above then every time someone PUT to
the resource the old resource would be deleted and a new one would be
created with a new resource ID, so much for being able to track the
document. As such it is clear that a PUT should not cause an implied DELETE.

Received on Monday, 21 February 2000 14:38:16 UTC