RE: New requirements draft!

My concern is that this will require us to allow for wild card matching.
I believe that FINDPROPS should just accept a list of property names
which should then be retrieved. The connotations of the word "search"
worry me.
		Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Thursday, July 31, 1997 11:59 AM
> To:	Yaron Goland
> Cc:	'ejw@ics.uci.edu'; 'WEBDAV Mailing List'
> Subject:	RE: New requirements draft!
> 
> I think what Jim advocates, "searching properties and links on a
> single
> resource," is what the spec provides now in the SEARCH method -- that
> is, it
> is really GETPROPS.  I agree with Jim that we should keep this in.  I
> see
> you and Jim agreeing that we should rule a true search capability out
> of scope.
> 
> --Judy
> 
> At 11:19 AM 7/31/97 PDT, Yaron Goland wrote:
> >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
> >
> >
> >
> 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 Thursday, 31 July 1997 16:39:31 UTC