RE: Yaron.Redirect.NoPropsIn207

Agreed. 

BTW 302_AND_MULTISTATUS in
http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html identifies this
problem so we will make sure to address it when WebDAV goes up for draft.

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Wed, February 16, 2000 10:05 AM
> To: Yaron Goland; w3c-dist-auth@w3.org
> Subject: RE: Yaron.Redirect.NoPropsIn207
> 
> 
> 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 Thursday, 24 February 2000 00:56:10 UTC