Re: DRP and content identifiers.

Sorry for the slow response ... I was in France.

    Jeff's proposal is similar to the solution proposed by DRP.
    Although there are a lots of similarities, there are also some
    differences.  The DRP proposal suggests some new HTTP headers, like
    the "Delta-base" header, we suggest the use of "Differential-ID".
    This, combined with the "Content-ID" header gives us a way to make
    delta caching work on existing HTTP/1.1 servers (the details are
    described in the DRP proposal). Unfortunately, it appears that
    defining new headers is not acceptable to the HTTP working group,
    so we are moving away from that.

I think this last sentence represents a misimpression.  I don't
think that the HTTP Working Group wants to add any new headers
to the HTTP/1.1 specification, except if someone can prove that doing so
would be absolutely necessary to correctly implement an existing
feature of the protocol.  This means that one cannot add a new
HTTP header that would be mandatory for an HTTP/1.1 implementation.
(However, very few HTTP/1.1 headers are truly mandatory, except for a
few like Host and Connection.)

On the other hand, there is no reason (that I can think of) not
to define news headers that can be used as an add-on to HTTP/1.1.
I.e., if you can live with the basic rule that an HTTP implementation
simply ignores a header that it doesn't understand, then you can
design an arbitrarily complex protocol with a large set of new
headers, and nobody will really care (except for some purists
who would rather see a generalized "extension protocol").

The proposal in our delta-encoding paper is of this form: there
are new headers, but if the recipient doesn't implement them 
then there is no harm done; one just reverts to normal HTTP/1.1
(or even HTTP/1.0) behavior.

Of course, one would want to ensure that there is no confusion
over the meaning of new header names.  It would be best if there
were an IANA registry of extended HTTP headers, but (failing that)
an RFC should be sufficient to establish a binding between header
name and meaning (presumably subject to first-come, first-served
priority).

I should also note that it is probably a good idea to keep new
header names as short as possible.  In particular, if one is
designing a new protocol whose goal is to reduce the size of
HTTP messages, it doesn't make sense to use bulky header names!

Some people seem to have the mistaken impression that HTTP
header names are meant to be human-readable ... this is bogus.
To be sure, a badly chosen name can go a long way towards misleading
an implementor into writing the wrong implementation, but they
seem to be perfectly capable of doing that on their own initiative.

I would suggest that if "Delta-Base" and "Differential-ID"
are more or less the same thing, then one should perhaps favor
the shorter name (or an even shorter one, e.g., "D-Base" or
whatever).  In fact, it probably would have solved a lot of
past problems if the HTTP protocol had, from the start, used
header names like "J13" so that the only meaning one could
infer from the header name would be what was written in a specification.

-Jeff

Received on Tuesday, 14 October 1997 17:07:31 UTC