- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Wed, 16 Feb 2000 13:05:16 -0500
- To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
As long as we provide the location and resource type information somehow, I don't care how. So I'd be fine with adding a location XML element and refresource XML element to the response XML element as you propose. Note that this is already an issue for RFC 2518 (well, at least the need for the location information), since whether or not you can create redirect references, HTTP redirects can be encountered while processing a WebDAV collection. So whatever solution we end up with, it needs eventually to be incorporated into RFC 2518. -----Original Message----- From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] Sent: Friday, February 11, 2000 2:51 AM To: 'w3c-dist-auth@w3.org' Subject: Yaron.Redirect.NoPropsIn207 The third sentence of the third paragraph of section 7 currently reads: "Since a Location header and Redirect-Ref header cannot be returned for each redirect reference encountered, the same information is provided using properties in the response elements for those resources." As discussed in Yaron.Redirect.NoWebDAV#3 we should not be using WebDAV properties in the redirect draft. Therefore I move that this sentence be changed to read: "Following the conventions of the 207 (Multi-Status) format the equivalent of the redirect-ref and location header are included inside the response body." The fourth sentence of the third paragraph of section 7 currently reads: "The DAV:location pseudo-property and the DAV:resourcetype property MUST be included with the 302 status code." First, the use of a pseudo-property violates the integrity of the prop XML element of a multi-status response. One can today write a general tool that can process any multi-status response and draw property information from it. Such a tool need not even understand the particular context in which the multi-status was generated. The use of a "pseudo-property" violates this integrity be listing a value in a prop element, thereby stating it is a property, when it is in fact not. Second, it is almost always a bad idea to imply information rather than stating it. By requiring that the resourcetype property be included you are expecting that the client will understand that because the response is a 302 and because a Apply-To-Redirect-Ref header was not included and because the resource type is redirect resource therefore this is a blind 302 response. This is a lot of inferring to do. In addition the resourcetype of a resource could potentially be quite large. As such it is generally better to create a dedicated piece of information which states, exclusively and uniquely that the 302 is a blind 302 and leave it at that. As such I move that both the DAV:location "pseudo-property" and the resourcetype property be banned for the uses stated in the above mentioned sentence. I move that location information be returned in a location XML element included in the response XML element. I move that the Redirect-Ref header information be included in a refresource XML element also included in the response XML element. Based on the previous proposals I also move that the previously quoted sentence be changed to read: "The location and refresource XML elements MUST be included with the 302 status code returned in a response XML element in a 207 (Multi-Status) response." The fifth sentence of the third paragraph of section 7 currently reads: "This necessitates an extension to the syntax of the DAV:response element that was defined in [WebDAV]. The extension is defined in Section 14 below." This sentence either states something obvious or unnecessary, I can't figure out which. Regardless, it isn't needed. As such I move that it be deleted. The third paragraph of section 7 is not necessary if my previous proposals in this point are adopted therefore I move that it be deleted. The fourth paragraph of section 7 provides suggestions for future changes to the WebDAV standard. I really dislike language like this as it has no place in a standard. If changes are needed to the base WebDAV specification then put out a posting to the mailing list so they can be added to the issue list for consideration when WebDAV goes to Draft. But please leave them out of the standard. Standards are really not the proper forum for editorializing. As such I move that this paragraph be deleted. Section 7.1 of the specification basically just restates RFC 2518. Rather than clarifying the issue it just confuses the reader by forcing them to ask themselves what was so subtle in understanding the WebDAV spec that this paragraph was necessary. BTW, one should contrast section 7.1 with section 7.2. 7.2 points out a real subtly in the design of WebDAV and redirect resources that needs to be called out to implementers. I do not believe that 7.1 meets the quality bar set by 7.2. Therefore I move that section 7.1 be deleted from the specification.
Received on Wednesday, 16 February 2000 13:05:29 UTC