Comments on draft-ietf-webdav-requirements-02.txt

This is an excellent draft in general.

I do have a slight concern with calling an Informational document a
list of requirements, since the IESG used to frown on such things.
Jim should probably ask the A.D.'s about whether it should be
changed to Recommendations.  The document should at least highlight
at the beginning that these are functional requirements for a future
protocol, rather than compliance requirements for Internet applications.

Specific comments:

>5.2.2. Rationale 
>
>One type of link between resources is the hypertext link, which is 
>browsable using a hypertext style point-and-click user interface. Links, 
>whether they are browsable hypertext links, or simply a means of 
>capturing a connection between resources, have many purposes.  Links 
             ^^^^^^^^^^
should be "relationship"

[...]

>5.3.1.1. Independence of locks. It must be possible to lock a resource
>without re-reading the resource, and without committing to editing the 
         ^^^^^^^^^^
should be "performing an additional retrieval of"

>5.5.1. Functional Requirement
>
>The source of any given resource must be retrievable.

should be "The source of any given resource must be retrievable by
           any principle with authorization to edit the resource."

>5.7.1.2. Rationale
>
>There are many reasons why a resource might need to be duplicated, such 
>as changing ownership, preparing for major modifications, or making 
>a backup. Due to network costs associated with loading and saving a 
>resource, it is far preferable to have a server perform a resource copy
>than a client. If a copied resource records which resource it is a copy
>of, then it would be possible for a cache to avoid loading the copied 
>resource if it already locally stores the original.

The entire last sentence needs to be deleted.  In HTTP, a cache cannot
know the authentication requirements that may underly the location of
the copy destination, and therefore the cache cannot use the new resource
until a later request verifies that the new location is cachable, which
is equivalent to reloading the resource.

That's it,

....Roy

Received on Friday, 19 September 1997 14:25:11 UTC