- From: Judith Slein <slein@wrc.xerox.com>
- Date: Mon, 28 Jul 1997 14:07:37 PDT
- To: Jim Whitehead <ejw@ics.uci.edu>
- Cc: w3c-dist-auth@w3.org
If you look at the new requirements, you will see that there are still three open issues listed. We have to arrive at consensus on these before we can submit the requirements as an informational rfc. 1. Do we want to require that atomic locking of multiple resources be supported? My opinion is that this is desirable. The rationale provided in the requirements draft seems compelling: There will be situations where authors want to insure consistency by locking a group of resources. Suppose we do not provide atomic locking of multiple resources. Then if more than one author tries to lock some of the same resources at once, the result may be that each author gets some of the locks he wanted, but neither of them gets all of the locks he wanted. The technical difficulty we have run into in trying to satisfy this requirement is that a LOCK method, if it follows HTTP request syntax, can only take a single URI as its request URI. So we cannot list multiple URIs there. If we try to move the list of resources to be locked into the body of the request, then it is not clear what the request URI should be. 2. Do we want to require that it be possible to query properties? Links? The requirements do currently require both a property-based query capability and a link-based query capability. The spec authors have expressed a preference for removing this requirement, and setting up another working group to tackle the problem of property-based search. I believe that it would not be difficult to specify a simple property-based search. The authors have already specified a method that they call SEARCH, although it is really just a way to retrieve multiple properties of a single resource. Its syntax, however, is very close to what would be needed to search for resources based on their properties. The request URI would have to be the URI of the space to be searched (a collection, server, or URL hierarchy). The response would have to be a list of the URIs that had matching properties, together with the values of the matching properties. This would be an extremely limited, but useful, search capability. 3. We need to decide on language for the internationalization requirement. My opinion is that we should not be talking about specific character sets or about language tagging, as the current requirement does (5.11.1). These are design decisions to be made in the specification. Rather, we should state what we are trying to achieve. Some thoughts about this are now captured in the rationale section for internationalization (5.11.2), but it needs a lot more work. Here's what the rationale says today: In the international environment of the Internet, it is important to insure that any information intended for user comprehension will be transported in a form that makes it possible to display the information in any writing system and language agreeable to both the client and the server. The information encompassed by this requirement includes not only the content of resources, but also display names and descriptions of properties, property values, and status messages. --Judy At 12:56 PM 7/28/97 PDT, Jim Whitehead wrote: > >A new version of the requirements document is now available. It can be >retrieved at: > >HTML: >http://www.ics.uci.edu/~ejw/authoring/requirements/draft-ietf-webdav-require >ments-01.html > >Text: >http://www.ics.uci.edu/~ejw/authoring/requirements/draft-ietf-webdav-require >ments-01.txt >ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-requirements-01.txt > >Thank you Judith for your hard work on this draft! > >- Jim > > > > Name: Judith A. Slein E-Mail: slein@wrc.xerox.com Internal Phone: 8*222-5169 External Phone: (716) 422-5169 Fax: (716) 265-7133 MailStop: 105-50C
Received on Monday, 28 July 1997 17:04:42 UTC