- From: Yaron Goland <yarong@microsoft.com>
- Date: Thu, 31 Jul 1997 11:19:52 -0700
- To: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, "'WEBDAV Mailing List'" <w3c-dist-auth@w3.org>
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