Re: New requirements draft!

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