- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Wed, 13 Aug 1997 02:51:12 -0700
- To: "'WEBDAV Mailing List'" <w3c-dist-auth@w3.org>
- Cc: "'Judith Slein'" <slein@wrc.xerox.com>
Some recommendations for how to settle the requirements open issues are presented below. On Monday, July 28, 1997 2:08 PM, Judith Slein [SMTP:slein@wrc.xerox.com] wrote: > 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. This issue was discussed during the WEBDAV working group meeting at the Munich IETF. I proposed the following way of handling this issue: - Keep the requirement as-is, since there is wide agreement on the need for the requirement - Try to develop a means for satisfying this requirement in the specification - Recognize that it may not be possible to satisfy this requirement, and move on Attendees at the meeting were in favor of this solution. > 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. Yesterday I attended a BOF on character set issues at which Harald Alvestrand gave a presentation on the proposed IETF policy for character set issues. Although this has not yet been approved, it appears likely that the policy will involve supporting UTF-8 encoding of ISO 10646 character set information, along with language tagging such information using RFC 1766 language tagging. The most recent draft of this policy is draft-alvestrand-charset-policy-00.txt available in the internet-drafts directory at ds.internic.net. Also at this BOF I was introduced to just how contentious these issues an be, and how carefully i18n requirements must be worded. As a result, I propose that our requirements document simply reference the (emerging) IETF charset policy, making the requirement something like, "Since web distributed authoring occurs in a multi-lingual environment, text data which is intended for human use must conform to the IETF Character Set Policy." - Jim
Received on Wednesday, 13 August 1997 07:23:10 UTC