RE: New requirements draft!

1. Atomic Locking - The problem is that a single server's namespace is
often controlled by many different programs. Therefore it is usually
impossible for any single program to enforce locking across all the
available namespaces. This forces us into an "arbitrator" model of
locking where an arbitrator accepts a request to lock a list of
resources and then locks those resources, atomically, on your behalf.
However, as previously pointed out, it may not be possible for any
single program to lock resources across the expanse of the namespace on
a single server. Thus the client will have to discover which arbitrators
handle which namespaces and then determine if any single arbitrator
covers all the resources the client wishes to atomically lock.
	As such I do not believe we will be able to resolve the atomic
locking issue until we have had a chance to write up some real code and
see just how ugly the problem really is. This probably means we should
put in some wishy washy language saying something like "It is a goal to
product an atomic multiple resource locking system if a reasonable
implementation can be agreed upon."

2. Search - I believe that we should remove this requirement and move
the issue to another group. There is no reason to separate the search
problem into two rather arbitrary partitions. We should keep the problem
whole and tackle it in either another requirement/protocol doc within
this group or in another group all together.

3. Internationalization - Agreed.

		Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Monday, July 28, 1997 2:08 PM
> To:	Jim Whitehead
> Cc:	w3c-dist-auth@w3.org
> Subject:	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 Wednesday, 30 July 1997 21:13:04 UTC