- From: J.P. Martin-Flatin <martin-flatin@epfl.ch>
- Date: Wed, 29 Jul 1998 18:10:42 +0200
- To: http-wg@cuckoo.hpl.hp.com
- Cc: Jim Gettys <jg@pa.dec.com>, martin-flatin@epfl.ch
On Fri, 17 Jul 1998 11:02:55 -0700, Jim Gettys wrote: > > A couple things wrong with this suggested rewrite: > > 1) saying it is vague is unfair; the spec says that 1.1 defines the > token "close" very clearly. I agree that the token "close" is defined clearly. > 2) Keep-Alive is a header. You missed my point: in RFC 2068, section 19.7.1 states that Keep-Alive and Persist are connection-token's. Here's the original text: When it connects to an origin server, an HTTP client MAY send the Keep-Alive connection-token in addition to the Persist connection- token: Connection: Keep-Alive > 3) as HTTP/1.1 may be extended in ways that are just as valid as > the base spec, saying that close is the only connection token is > I believe misleading, as others may want/need to define other tokens; > I don't want the base spec to imply that some other spec isn't as valid > that is extending HTTP/1.1. I disagree: I don't think different implementations should be allowed to use their own proprietary tokens. Allowing this would result in interoperability issues. > I did add cross references in the section to section 19.6.2, and > vice versa, where persistent connection compatibility with HTTP/1.1 > is discussed, which should reduce confusion. Thanks Jean-Philippe ____________________________________________________________________ Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland Email: martin-flatin@epfl.ch Fax: +41-21-693-6610 Web: http://icawww.epfl.ch/~jpmf/
Received on Thursday, 30 July 1998 09:12:49 UTC