RE: New requirements draft!

So Spake Jim:
>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.

I disagree. Given that search is going to be dealt with, potentially in
another group, I do not believe we have the right to foist upon the
world a broken search which becomes obsolete legacy code before the spec
is even finished. All we are doing is forcing implementers to support a
search system that will most likely have nothing in common with the
search that will be specified by the IETF HTTP SEARCH group. I believe
the search requirement should be completely removed from the
requirements document.

			Yaron


> -----Original Message-----
> From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
> Sent:	Wednesday, July 30, 1997 6:22 PM
> To:	'WEBDAV Mailing List'
> Subject:	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 Thursday, 31 July 1997 14:20:03 UTC