Requirements Open Issues

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