re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

On Aug 17 last year, in 
<http://lists.w3.org/Archives/Public/w3c-dist-
auth/2001JulSep/0141.html>, Jason closed this issue using the Geoff's 
language about "act as if a PUT of length 0 happened."

Since I was on vacation at that time, I missed this conclusion, but 
don't worry: I agree with it!!  (phew :^)  But it raises a question 
(other than the 201 status response Lisa already raised) and I believe 
it closes another issue I rasied:

The question: what's the mime-type of the newly-created resource?

Now I know that many servers use file extensions to determine mime-type, 
so the name of the resource could be used to provide a mime-type.  But 
for other servers that expect clients to supply a Content-type header on 
PUT (or at least pay attention to them), what should happen?

My proposal: do not mandate behavior around this; leave the spec 
silent.  That way the spec is silent about mime-type of LOCK created 
resources exactly as it's silent about the mime type of PUT resources.

The issue: LOCK_URL_WITH_NO_PARENT_COLLECTION

In <http://lists.w3.org/Archives/Public/w3c-dist-
auth/2001JanMar/0134.html> I asked that LOCK return 409 with no body 
when parent collections don't exist.  There was no discussion (which at 
the time I took to be assent but the issue was never closed), but with 
this change in LOCK semantics I believe the issue is forced: LOCK must 
return 409 (with no body) exactly as PUT does when there are missing 
parent collections.  So I think this issue should be closed as accepted, 
unless anyone has a problem with the language I specified in my original 
message.

     dan

Received on Thursday, 14 February 2002 19:57:58 UTC