RE: New requirements draft!

Comments 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.

So the essence of the problem is that a requirement which is 
unimplementable shouldn't be in the requirements document. This boils down 
to whether we should require server implementors to include an atomic 
locking capability in their systems.  I think we need some feedback from 
list participants with server experience to determine how to proceed.

>
> 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.

I have asked the Area Directors for their opinion on whether they would 
favor extending the charter of the working group to handle cross-resource 
searching, and Keith Moore's response was:

> My initial reaction is that this is best handled by a separate working 
group,
> as a follow-on to WEBDAV.  IETF groups tend to self-destruct after a 
time,
> and adding searching to WEBDAV's plate would extend WEBDAV's lifetime
> to an uncomfortable length.  Starting with a new group provides a chance 
to
> refocus ...

Based on this, and on the current wording of our charter, I feel that 
searching properties and links on a single resource is OK, but 
across-resource searching is beyond our scope, and is not likely not become 
part of our scope.  I feel the requirements should reflect this.

> 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.

The advantage of the current language is that people understand exactly 
what is required -- my fear is that if we relax the language on the 
requirement, we may bite off more than we expected.  However, I'm all in 
favor of more abstract language for the requirement, so long as the 
implementation only requires using ISO 10646 encoding.  Would someone like 
to take a stab at rephrasing the requirement?

- Jim

Received on Wednesday, 30 July 1997 21:26:42 UTC