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

I agree with Roy and Larry on the issue of "requirements" vs "goals." We
will probably help reduce our own blood pressure if we change the
"requirements" to "goals."
			Yaron

> -----Original Message-----
> From:	Roy T. Fielding [SMTP:fielding@kiwi.ics.uci.edu]
> Sent:	Friday, September 19, 1997 11:06 AM
> To:	w3c-dist-auth@w3.org
> Subject:	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 Sunday, 21 September 1997 14:46:15 UTC