- From: Yaron Goland <yarong@microsoft.com>
- Date: Sun, 21 Sep 1997 11:46:07 -0700
- To: "'Roy T. Fielding'" <fielding@kiwi.ics.uci.edu>, w3c-dist-auth@w3.org
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