W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000


From: Yaron Goland <yarong@Exchange.Microsoft.com>
Date: Thu, 10 Feb 2000 23:49:01 -0800
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A168@BEG.platinum.corp.microsoft.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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 Friday, 11 February 2000 02:49:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:19 UTC