Re: Content-MD5

> So because there were a mere 70 lines document (headers dropped)
> written in 1993 (Rfc1544 (hmm, reissued with almost no changes as
> rfc1864 very recently)) *suggesting* the use of a *specific*
> algorithm, for Email should imply that world stopped and that for a
> new proposed protocol (http/1.1) you have to use the same buggy
> specific definition ? No evolution possible ? No new ideas/fixes ever
> allowed ?

Short specs are better than long ones, and stable standards are better
than those which change frequently.  No bugs in that.

> And you make htpp/1.2 when MD6 or something else pops out ?

No.  If you read the HTTP specifications, you will notice that the version
number is not changed for additional message components which only add
to extensible field values.  You will also notice that Entity-Header is
an extensible field, and thus anyone may add Content-Fred at any time
without changing the standard.

 >> Using separate header fields for different
 >> algorithms is just as applicable (and easier to parse) as any
 >> parameterized generic header field.
> Why not using Accept-Gif: Accept-jpeg:,... headers ? would be
> easier... 

Using separate header fields for the *same* algorithm is a different matter.

 ...Roy T. Fielding
    Department of Information & Computer Science    (
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

Received on Friday, 3 November 1995 08:54:24 UTC