W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

Comments on I-D ACTION:draft-ietf-http-options-02.txt

From: Yaron Goland <yarong@microsoft.com>
Date: Mon, 8 Sep 1997 17:44:57 -0700
Message-Id: <11352BDEEB92CF119F3F00805F14F48503A15771@RED-44-MSG.dns.microsoft.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4377
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

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.

Received on Monday, 8 September 1997 17:47:41 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC