- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 8 Sep 1997 17:44:57 -0700
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Section 2: - As in RFC2068, the URI '*' refers to the server, independent of any specific resource. Any other URI refers to the resource normally identified by that URI. One of the lessons we have learned in DAV is that "*" is functionally useless. The reason is that the concept of a server is an empty one. Servers today are carved up into various namespaces, with the same host, which are actually "owned" by various plug-ins. Thus speaking to "*" really means speaking to some program which doesn't even control the distribution of information. So if "*" on foo.com says "No, I don't support DAV" that doesn't mean that http://foo.com/blah doesn't support DAV. What we really need is a way to identify an "owner" of a namespace. So a program could discover that http://foo.com/blah/bar is part of the http://foo/blah namespace which can be addressed as a whole, in the same sense as "*", at http://foo/blah/big-time-owner. In the degenerative case the "owner" of http://foo.com/blah/bar is http://foo.com/blah/bar. Section 3.4: I think it would be unfortunate to create yet another namespace in the compliance header. Efforts such as DAV, PEP, and XML, are all standardizing on URIs as the way to address namespaces, especially namespaces which are to be standardized by IANA. In addition I think we should avoid creating yet another structured data syntax. Especially one as complicated as compliance promises to turn out. The XML effort has provided a structured data syntax which can be leveraged here. Given the wide variety of functions that are to be served by the Compliance header I think it would be mistake to introduced yet another set of semi-structured, non-self describing, values. In fact I think the information which will potentially be returned in Compliance is so large that we probably need to move compliance into the body of the method. Also I think the modifiers of conditional and unconditional compliance are not sufficient to describe what is going on. A server can not support GET and still be unconditionally compliant with HTTP/1.1. I think we need much more detailed information. Also, how useful is a list of supported headers as headers, more likely than not, are supported only with certain methods. Do we not need the mapping between which headers are supported on which methods? Also, how useful is "when in doubt, do not claim compliance." If a client is trying to figure out what is going on and "*" says "I don't support this" then what the client REALLY knows is that the standard software doesn't support the particular feature but that says absolutely nothing for the resources on the server. Please see my previous point regarding the usefulness, or lack there of, of "*". Section 3.5: I think it would be useful to clarify the language for the non-compliance header to make it clear that the proxy should include all values of the compliance header that it does not recognize in the non-compliance header. Section 3.6: I think allow and public are kind of weird. Especially given that talking about "methods supported on a server", as public does, is fairly meaningless given that servers are really controlled by lots of different programs. It would seem more sensible to banish public and allow all together and to leverage the compliance mechanism. This also solves the problem of differentiating between support on the server and the proxies. Section 4: Another benefit of moving compliance into the body and expressing it in XML is that you can sign it. Proxies then add their own, signed, conformance information to the body as it passes back through them. This gives us a real security story. Yaron
Received on Monday, 8 September 1997 17:47:41 UTC