W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

Re: Comments on Section 3 of the Requirements Document

From: David Durand <dgd@cs.bu.edu>
Date: Wed, 12 Feb 1997 13:23:05 -0500
Message-Id: <v0213050baf27b51bcdac@[205.181.197.71]>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:42 GMT