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 14:56:02 UTC