- From: David Durand <dgd@cs.bu.edu>
- Date: Wed, 12 Feb 1997 13:23:05 -0500
- To: w3c-dist-auth@w3.org
I'm too busy to do more than dip into the traffic at the moment, so apologies for any errors or duplications in the following. At 8:34 AM 2/12/97, Judith Slein wrote: >I'd like to see more discussion of whether we are extending HTTP, and if so >what that means. Both the charter and the requirements describe what we are >doing as extending HTTP. > >At 05:05 PM 2/11/97 PST, Yaron Goland wrote: >> 3.2. Legacy Client Support >> >> WebDAV-compliant servers should be able to interoperate with >>non-WebDAV clients. >> >>Without a careful statement of the ramifications of this requirement I >>move that it be removed from the requirements. This would be foolish. If DAV servers are not required to work _at all_ with existing clients, we are begging for trouble. Of course, we almost certainly need to make this more precise. I think that one taks would be to say that any WEBDAV resource (in any version) should be _somehow_ accessible to ordinary browsers like today's IE or Netscape. That is basic HTTP 1.0/1.1 access should at least enable access to any resource. It might also be a goal that simple PUT at least be allowed to produce a meaningful result for servers that _can_ produce a meaningful result without locking operations. This should be a trivial requirement to state, but it is not trivial in its effect, I think. >> 3.4. HTTP Compatibility (new) >> >> Our aim is to make extended authoring capabilities available >>through >> HTTP. In extending HTTP, we are obligated to follow its design >> conventions and stay within its spirit. This means, for >>example, that >> methods should operate only on resources. It means that >>parameters >> should be communicated in headers. These and other conventions >>should >> be observed in the design of the extensions. >> >>HTTP has a spirit? Who will interpret this spirit? HTTP is a >>specification. Words written on a piece of paper. For us to declare that >>we are somehow the keepers of the spirit of HTTP is absurd. Our only >>obligation is to have this specification accepted by the IETF. If that >>should require changing HTTP and the IETF buys off on the idea, then so >>be it. We should not restrict ourselves when there is no compelling >>reason to do so. This is a rather disingenuous reading of the text. We are not actually staztring from a blank slate -- HTTP exists, and is in place. I take "the spirit of HTTP" to mean that HTTP has existing method-selection and parameter-passing facilities: Extensions to HTTP should use those facilities to represent their operations and parameters for the operations that they propose to support unless there is a knock-down-drag-out engineering argument that this is either impossible or performs so badly as to be prohibitive. The "spirit" should also, as far as possible, probably refer to the statelessness of operations -- since no versioning system can be completely stateless, we can only try to ensure that as much of DAV as possible _can be_ stateless where it makes sense. In other words we should not design any new general facilities that can already be accomodated by existing HTTP features. This is good engineering sense in any case. Arguments that things would be prettier if HTTP were different do not signify here, if the goals can be accomplished in the current framework without fatal performance flaws. The elegance of fully exploiting the existing HTTP infrastructure exceeds any elegance that we could gain from the prettiest separate system, if it duplicates existing functionality. Given the simplicity and generality of HTTP, I see few places where we might really need to extend it. The one extension argument that I remember from the before that seemed well-founded was the proposal for for something like HTTP/multi-part to accomodate transaction handling. I don't know the place of this in our current goals or framework, but at least that was addressed at accomplishing something that HTTP cannot currently do very well. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________
Received on Wednesday, 12 February 1997 13:22:15 UTC