W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1997

comment/questions on protocol-03

From: John Turner <johnt@cgocable.net>
Date: Tue, 07 Oct 1997 15:07:23 +0600
Message-Id: <199710071919.PAA06830@mail.cgocable.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:43 GMT