"Wide load" status code(s)?

[solderpunk]

On Thu, Jun 11, 2020 at 12:52:36AM -0500, Ivy Foster wrote:
 
> I'm aware that this is a very contentious point, but just to throw a
> wrench into things...there actually is [an RFC precedent][rfc1341] for
> including size as a parameter to a MIME type, even though MIME type is
> generally intended to be a classification. Granted, it's intended
> specifically for external message bodies, so the user can decide
> whether it's worth their while to download...but isn't an external
> message body ultimately what any arbitrary file you fetch is anyway?
> 
> [rfc1341]: https://tools.ietf.org/html/rfc1341

Well, that is unexpected!  I guess practicality beats the idea of
semantic purity even in "real specs".

> I totally get it if the answer's still no to a size parameter; the
> "where does it end?" argument is a strong one. However, a precedent
> for including a very useful piece of information as a MIME type
> parameter is still something to consider.

It definitely weakens my argument that file size is not appropriate
information to attach to a MIME type.  Nevertheless, it's still true
that we only get to dictate the permissible parameters for the one MIME
type that we are actually defining ourselves.  All other registered MIME
types, including all the image/*, audio/* and video/* types which are
liable to be the most common large files, have their own pre-defined
list of registered parameters and we shouldn't be adding extras of our
own.

Maybe we just need to (continue to) let the file size issue go.  I won't
deny that it's useful, but (as so often) Gopherspace is the existence
proof that useful and valuable stuff can be built without it.

The concern about users without fast and cheap internet which was part
of the motivation for my recent suggestion for more 2x codes was
genuine, and it would have been one more nice utilisation of the "two
digit codes which degrade gracefully into one digit codes" philosophy
(which I think is neat but worry that we perhaps don't utilise enough
to make it worth while), but as was pointed out in the ensuing
discussion, most text/* content is likely to be quite small and clients
can already terminate connections early on the basis of a non text/*
MIME type in precisely the way that I was proposing they should do on
the receipt of a 2x code above their threshold.  So, they can get quite
a lot of the benefit of that proposal with no changes required.  I think
I will add an option to quick-terminate on non-text content to AV-98.

Cheers,
Solderpunk