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

Requirements Open Issues

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Wed, 13 Aug 1997 02:51:12 -0700
Message-ID: <01BCA79F.C4D0FB00.ejw@ics.uci.edu>
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] 
> If you look at the new requirements, you will see that there are still 
> open issues listed.  We have to arrive at consensus on these before we 
> submit the requirements as an informational rfc.
> 1. Do we want to require that atomic locking of multiple resources be 
> My opinion is that this is desirable.  The rationale provided in the
> requirements draft seems compelling:  There will be situations where 
> want to insure consistency by locking a group of resources.  Suppose we 
> 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 
> that each author gets some of the locks he wanted, but neither of them 
> 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 
> there.  If we try to move the list of resources to be locked into the 
> 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 
- 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 
> My opinion is that we should not be talking about specific character sets 
> about language tagging, as the current requirement does (5.11.1).  These 
> design decisions to be made in the specification.  Rather, we should 
> what we are trying to achieve.  Some thoughts about this are now captured 
> the rationale section for internationalization (5.11.2), but it needs a 
> more work.
> Here's what the rationale says today:
> In the international environment of the Internet, it is important to 
> that any information intended for user comprehension will be transported 
> 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 
> resources, but also display names and descriptions of properties, 
> 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

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