- From: Yaron Goland <yarong@microsoft.com>
- Date: Thu, 31 Jul 1997 13:39:06 -0700
- To: "'Judith Slein'" <slein@wrc.xerox.com>
- Cc: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, "'WEBDAV Mailing List'" <w3c-dist-auth@w3.org>
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