W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Content-MD5

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Fri, 03 Nov 1995 08:41:36 -0800
To: Laurent Demailly <dl@hplyot.obspm.fr>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9511030841.aa27070@paris.ics.uci.edu>
> 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    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/
Received on Friday, 3 November 1995 08:54:24 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:34 EDT