- From: John Turner <johnt@cgocable.net>
- Date: Tue, 07 Oct 1997 15:07:23 +0600
- To: w3c-dist-auth@w3.org
Hi I have a couple of questions/comments on the protocol-03 document. section 2.2.2.1 The first sentence reads "The requirement is to be able to associate a value with a property name on a resource and to BE ABLE TO DIRECTLY ADDRESS THAT VALUE" (caps added by me). Is the PROPFIND considered as fulfilling this? My reading of this is that it must be reachable by a direct URL (such as MAY be returned in the PROPLOC attribute). An adjustment to the wording might help. Properties The PROPSCHEMA element gives information on supported schemas. If a PROPPATCH method is sent, with a create element, what response would be sent if an unsupported property is specified? If the server wishes to let the client know why, the 403 does not seem ideal. Is 403 with an explanation in a ResponseDescription element the best response? I would guess that the allprop and propname type of PROPFIND requests should return all the properties that have values, not all that are supported for that resource. Saying something explicit about this would certainly have made it clearer for me. For the prop type of PROPFIND, what response should be returned for an unsupported property, assuming the server wants to tell the client. Should it be the same as for a property that is supported, but has not been set? section 3.1.1 The end of the second last paragraph refers to "a full hierarchy copy". Should this be removed with the current changes to copy? section 3.2.4 Which response indicates that the MKCOL fails because the Request-URI already exists? MKCOL in general. Any comments on what it should do with a Request-URI of /A/B rather than /A/B/? 3.6.3.3 This section refers to a conflict in the overwriting of properties when a resource is copied. This suggests that any destination properties that were not in conflict will still exist after the copy. Is this what was intended? 3.11.4 In the last paragraph, the first three choices in the grammer line for 'Choices' are defined, but what are token and URI about? In addition, could someone explain what is meant by the descriptive clause folowing the semicolon? I looked up RFC16 and don't think that is the right number. 5.2.2 The description for depth header values of 1 and infinity refer to 'propagate members'. This should probably be rewritten. 5.3 The last sentence of the last paragraph reads "In order to keep the behavior of locking containers consistent all locks on containers MUST contain a Depth header equal to infinity, any other value is illegal" Since the depth header means something only to collections I assume this should read "... all WRITE locks ...". Here again, could someone explain why this was done? John Turner johnt@cgocable.net
Received on Tuesday, 7 October 1997 15:19:35 UTC