W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1997

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

From: Yaron Goland <yarong@microsoft.com>
Date: Sun, 21 Sep 1997 11:46:07 -0700
Message-ID: <11352BDEEB92CF119F3F00805F14F48503C26FBE@RED-44-MSG.dns.microsoft.com>
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."

> -----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"
> [...]
> > 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."
> > 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:11 UTC