- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 21 Nov 96 14:06:47 PST
- To: mcmanus@appliedtheory.com
- Cc: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
> 5.2 Abbreviations for Meter directives
> To allow for the most efficient possible encoding of Meter headers,
> we define abbreviated forms of all Meter directives. These are
Didn't we just go through this with 1.1? I think consistency in the
protocol is an important consideration. Either it should be a human
readable protocol, or a binary machine optimized protocol..
defining synonyms for terms seems to add nothing but confusion.
While I supported the proposal for abbreviations for HTTP headers,
I can see some merit in the opposing argument: because of the need
to interoperate with HTTP/1.0 (and earlier) systems, the use of
header-name abbreviations would have to be negotiated.
We do not, in this draft, propose abbreviating header names. But
since we are in a situation where backwards compatibility is
not an issue, there is no need to include a negotiation mechanism.
Therefore, the situation is not exactly analogous to the proposal
for abbreviating header names.
However, if we did NOT introduce the abbreviation mechanism in
the initial version of the Meter header, then (if/when it has
been deployed), if we later on decide that abbreviations are
desirable, we could not safely introduce them without a negotiation
mechanism.
Since it seems relatively easy to implement abbreviated Meter
directives now, and it would be much harder to do it later on,
and the bandwidth savings are clear (if perhaps small), I see
no reason not to do it.
-Jeff
Received on Thursday, 21 November 1996 16:53:43 UTC