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 Wednesday, 16 February 2000 13:05:29 UTC