Subject: Review: Redirect Reference Resources -- Part three

From: Juergen Reuter <[email-masked]>
Date: Tue, 22 Feb 2000 22:44:47 +0100

Following the working group's last call for comments, below is the
third and last part of a review of the Redirect Reference Resources
Protocol.  It covers chapters 12 to 24 of the protocol.

********

> 12 Properties
>
> 12.2 location Pseudo-Property
> ...         This pseudo-property is not expected 
>             to be stored on the reference resource.

..., but its value it computed directly from the value of the target
resource.  Hence, I would call it a live property (rather than a
pseudo-property).  But why should this property not be expected to be
stored on the reference resource for (just hypothetically) e.g.
caching purposes?  Anyway, I would prefer to see the location property
and the target resource property to be made a single property, even if
that means not allowing a relative URI as value of a target resource.

> 16 Security Considerations
>
> This section is provided to make WebDAV applications aware of the 
> security implications of this protocol. 

This protocol can not make WebDAV applications, that are not aware
of this protocol, aware of any implication of this protocol.  Hence I
suggest to replace the phrase "WebDAV applications" by "applications
that implement this protocol".

> 16.4 Private Locations May Be Revealed
>
> There are several ways that redirect reference resources may reveal 
> information about directory structures.  ...

I would like to suggest the term "directory" be replaced with
"collection".
In fact, this implication is not newly introduced in this protocol; it
holds for any protocol with hierarchical access paths (and hence
should not need to be mentioned in this protocol).

> In some environments, the owner of a resource 
> might be able to use access control to prevent others from creating 
> references to that resource.

That would not be consistent with the concept of redirect references
as weak links (e.g. think of moving a resource to a different
location that is already the target of some redirection reference).

> 17 Internationalization Considerations
> ...
> WebDAV applications MUST support the character set tagging, character 
> set encoding, and the language tagging functionality of the XML 
> specification.  This constraint ensures that the human-readable content 
> of this specification complies with [RFC2277].

This protocol is an extension for WebDAV; hence the above paragraph is
redundant.

> As in [WebDAV}, ...
               ^
A little typo.

> For error reporting, [WebDAV] follows the convention of HTTP/1.1 status 
> codes, including with each status code a short, English description of 
> the code (e.g., 423 Locked).  Internationalized applications will ignore 
> this message, and display an appropriate message in the user's language 
> and character set.
>
> This specification introduces no new strings that are displayed to users 
> as part of normal, error-free operation of the protocol.
>
> For rationales for these decisions and advice for application 
> implementors, see [WebDAV].

Once again, this is redundant.  Why not just saying:

"This specification does not introduce any new string that is
displayed to users as part of normal, error-free operation of the
protocol.  For error reporting, rationales on internationalization
considerations and advice for application implementors, see [WebDAV]."

> 18 IANA Considerations
>
> This document uses the namespaces defined by [WebDAV] for properties and 
> XML elements.  All other IANA considerations mentioned in [WebDAV] also 
> apply to this document.

As this protocol is an extension to WebDAV, I think it is sufficient
to mention that this protocol does not need any new considerations to
be applied.

> 22 References
> ...
> [B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. 
> Crawford, "WebDAV Bindings." Internet Draft (work in progress) draft-
> ietf-webdav-binding-protocol-02. Xerox, UC Irvine, CourseNet, Rational, 
> FileNet, IBM. December, 1999.

See the comments in part one of this review on referencing the
bindings protocol.

> 24 Appendices
>
> 24.1 Appendix 1: Extensions to the WebDAV Document Type Definition
> ...
> <!ELEMENT response (href, ((href*, status, prop?) | (propstat+)), 
> responsedescription?) >

It may be worth noting that, in contrast to what the headline says,
this element is not an extension to the WebDAV DTD, but a replacement
for the WebDAV DTD element with the same name.

********

Best regards,
                Juergen Reuter