Proposal about content-size and hash

[Solderpunk]

On Fri Oct 30, 2020 at 11:06 PM CET, Sean Conner wrote:

> Ah yes ... this is something I proposed back in August of 2019:
>
> gemini://gemini.conman.org/gRFC/0003
>
> Solderpunk has always rejected it when it comes up, mumbling
> "simplicity"
> and "not HTTP again" under his breath.

Well, that's not quite fair.  What I usually mumble, in the context of
people wanting to add this stuff as part of the MIME type in a status 20
response, is something like this:

1) The parameters which may be legitimately appended to a MIME media
type are those registered in that media type's formal definition.
You can't just stick whatever you want on there.  We can define
parameters for text/gemini, but we can't do anything about other media
types whose definitions are beyond our control.

2) A media type is supposed to specify, well, what *type* of thing a
file is.  They are *categories*, which a client can use to decide how to
handle a given file.  From RFC 2045, section 5:

> The purpose of the Content-Type field is to describe the data
> contained in the body fully enough that the receiving user agent can
> pick an appropriate agent or mechanism to present the data to the
> user, or otherwise deal with the data in an appropriate manner.

It seems very clear to me that information which is unique to a specific
individual file - like its size, hash, last update time, etc. - is just
not semantically appropriate here.

TLDR; MIME types aren't big trucks that you just dump something on.
They have a clearly limited semantic scope, and each media type and
subtype is constrained by a formal definition.

Cheers,
Solderpunk