RE: comment/questions on protocol-03

2.2.2.1 - I agree that the language isn't as clear as it could be. A
better phrasing would be "The requirement is to be able to associate a
value with a property name on a resource. It must be possible to
associated a URL with the property name."
	That is why PROPFIND meets the requirement. Proploc from section
2.4.4 specifies how to include the URL, if the server so chooses.

Setting unsupported properties - As currently specified the system would
return a multiresponse with a 403 for the property in question. I'm not
clear as to why this is not sufficient. Could you please elaborate?

allprop and propname - Ahh, I think I see the source of confusion, the
use of the word "defined". For allprop, for example, how about removing
the word "defined" so it reads "Its presence in a PROPFIND request
specifies the name and value of all properties on the resource MUST be
returned"

Prop type of PROPFIND - I'm sorry, I don't understand your point. It
sounds like you are talking about live and dead properties. Currently
the server does not return any information in a PROPFIND identifying a
property as live or dead. At the Orem DAV meeting it was decided that
live/dead information would be retrieved through schema discovery.

3.1.1 - The sentence in question is "Once these objects have been
modeled with collections, a client may perform an INDEX, add and remove
external members using ADDREF and DELREF, and perform recursive
operations, such as a full hierarchy copy. " Recursive operations are
provided by DAV, just not in this spec. Later this week the first
version of the DAV TREE spec will be released which will specify exactly
how to perform recursive operations.

3.2.4 - The question regards what response code to return if a MKCOL
failed because a directory currently exists. The code would be a 405
Method Not Allowed. The resource, in it is current state, can't accept
the method. If, however, you DELETE the resource, then it can. I will
add this code and explanation to the list.

MKCOL on A/B vs. A/B/ - The next version of the draft will have language
on this issue. Specifically the following language has been added to
section 3.1.1 "To support methods which operate on collections, a server
SHOULD model its collection-like objects with collection resources.  For
example, a server which is implemented on top of a file system SHOULD
treat all file system directories exposed by the server as collection
resources.  The URI for a collection resource SHOULD have its "path"
component (as defined in [Berners-Lee et al., 1997]) terminate with a
"/", and references to the collection name where the terminating "/" is
omitted SHOULD be redirected to the URI with terminal "/"."

3.6.3.3 - There was some confusion as to what happens to properties that
already exist on the destination of a copy if none of the properties
from the source have the same name. The authors agreed that the language
was unclear and re-wrote it as follows: "A COPY on a collection causes a
new, empty collection resource to be created at the destination with the
same properties as the source resource.  All properties on the source
collection MUST be duplicated on the destination collection, subject to
modifying headers, following the definition for copying properties.  The
new collection MUST NOT contain any members, internal or external."
Notice that the conflict language has been removed. So the answer to the
question is that any properties that existed on the destination are
deleted because, as the first sentence says, "a new, empty collection"
is created.

3.11.4 - The following is the new text that is going into the next
version of the draft, I believe it addresses your questions:
When deleting a resource the client often wishes to specify exactly what
sort of delete is being enacted. The Destroy header, used with the
Mandatory header, allows the client to specify the end result they
desire. The Destroy header is specified as follows:
The Undelete token requests that, if possible, the resource should be
left in a state such that it can be undeleted. The server is not
required to honor this request.
The NoUndelete token requests that the resource MUST NOT be left in a
state such that it can be undeleted.
The VersionDestroy token includes the functionality of the NoUndelete
token and extends it to include having the server remove all versioning
references to the resource that it has control over.
		DestroyHeader = "Destroy" ":" #Choices
Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | token |"<" URI
">" ; a token extension MUST NOT be used unless it is specified in a
RFC, otherwise a URI MUST be used for extensions.

5.2.2 & 5.3 - The entire lock spec has been substantially edited. I
believe the upcoming release of the spec includes the new language. Both
issues have been resolved by removing all reference to the Depth header.

Thank you for your comments. The changes you have identified will appear
in the release after the next release of the DAV spec. The reason for
the delay is that the next release is already in the pipeline.

The length and complexity of the DAV drafts makes many people loath to
review them. So when someone takes the time to read and comment all the
authors really do appreciate it. We know what kind of effort is
involved.

	Thanks again and I look forward to your future comments,
		Yaron



> -----Original Message-----
> From:	John Turner [SMTP:johnt@cgocable.net]
> Sent:	Tuesday, October 07, 1997 2:07 AM
> To:	w3c-dist-auth@w3.org
> Subject:	comment/questions on protocol-03
> 
> 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 18:08:41 UTC