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

I find myself also agreeing with just about all of Koen's comments, with
the exception of XML. =)

Either way I strongly encourage the group to decouple Options and
HTTP/1.1 specifications. The HTTP/1.1 spec, as is, provides compelling
functionality. As such it makes sense to ship it as is and to add
Options functionality later on.


> -----Original Message-----
> From: []
> Sent:	Tuesday, September 09, 1997 2:09 PM
> To:	Yaron Goland
> Cc:
> Subject:	Re: Comments on  I-D
> ACTION:draft-ietf-http-options-02.txt
> In general, I find myself agreeing to most of the comments Yaron made
> on the draft.
> I too think that `the whole server' is an empty concept.  It may make
> some sense for proxy servers, but not for origin servers.  Also the
> language of the draft in places like "a subprogram outside the control
> of the server itself (such as a CGI application)" clashes with
> HTTP/1.1
> terminology.  According to 1.1, a server is everything including its
> CGIs, so some new terminology is needed if distinctions inside the
> server are to be introduced.
> I am not very happy with the RFC= and HDR= method of labelling server
> features.  The draft asserts that `the meaning of an RFC is both
> well-defined and (more important) immutable.'.  This may be true, but
> for an RFC which defines three levels of compliance, like DAV does I
> believe, the defined syntax is insufficient for capturing all
> well-defined levels of this well-defined meaning.
> Also, the HDR= syntax has the problem that multiple RFC's may define
> different versions of an extensible header.  If HTTP/1.2 defines three
> new cache-control keywords, then HDR=cache-control becomes ambiguous.
> Also, what does it mean if a server says that it does not support, for
> example, the if-modified-since header?  Does this mean that the server
> does not support conditional gets, or does it mean that sending an
> if-modified-since header to it may lead to incorrect results?
> I do not think that the RFC= and HDR= problems can be solved by adding
> more details to the syntax, or by switching to XML syntax.  I think
> that the only way out is to set up a registry for feature labels,
> whose
> meaning is defined unambiguously by the registry entries.
> Other comments:
> On the issue of merging the Options draft with the 1.1 spec: I think
> this is a bad idea because it would delay the 1.1 spec too much.  I'd
> rather see the options draft progressing separately (or not
> progressing at all).  I would not like to be put into a position where
> I end up being screamed for delaying 1.1 over fixing flaws in the
> merged Options part.
> I'll repeat what I said in Munich: I do not agree with the claim in
> the draft that `there exists an immediate need to define a simple and
> well-specified OPTIONS mechanism for HTTP/1.1.'  
> If we end up putting proxy redirects, which currently use Options, in
> 1.1 (and I don't think we should) I'd rather put in a special-purpose
> mechanism for doing the feature discovery which is needed for
> proxy redirect security.
> About the Public header: is this header actually being sent by any
> existing server?
> The addressing mechanism in the options draft does not allow me to
> address the proxy if I have a (CERN) server which is both an origin
> server and a proxy on the same port.  So the sentence `This allows the
> sender to select the Nth proxy on a path, without knowing its
> hostname.' is wrong.
> The spec does not define clearly enough what a server should send in a
> (Non-)Compliance header if it does not know whether it complies.  The
> language about this is too distributed over the whole spec, and I
> cannot tell if it covers all cases.
> In the Non-Compliance header, there should be a way for a proxy to use
> an alias, like in the Via header.
> The spec says that, in proxies, `presumably any request using an
> unsupported method would immediately be rejected.'  I do not think
> this is the case, in fact I think that existing proxies would just
> relay the request towards the origin server, maybe switching to tunnel
> mode.  I think this is at least what 1.1 encourages them to do.
> In the security considerations section, add the consideration that
> options discovery makes attacks based on known security holes easier,
> and harder to detect.
> I do not think that there is a strong enough case for adding all the
> complexity which is currently present in the Options draft to the load
> of 1.1 server implementers.  I do not know whether the draft intends
> to
> require an origin server know whether all possible HDRs and RFCs are
> supported or not by its server core.  But if the draft does, I would
> object to it because this requires server core authors to waste lots
> of time writing and maintaining tables of headers and rfcs, with most
> of the table entries never being queried.  I would prefer a mechanism
> in which the server implementer only needs to keep tables of those
> things for which it makes sense, in his opinion, to do an options
> request.
> Koen.

Received on Tuesday, 9 September 1997 20:37:07 UTC