"Wide load" status code(s)?

[Ivy Foster]

On 10 Jun 2020, at  6:21 pm -0400, Sean Conner wrote:
> It was thus said that the Great solderpunk once stated:
> > Just throwing out a quick idea I had last night while trying to sleep,
> > to see how people feel about it.  It's simple and easily ignorable and I
> > think it's kind of neat.
> 
>   [ snip ]
> 
> > Naturally, deciding to do this will lead immediately to a weeks-long
> > heated debate on what the appropriate value of $THRESHOLD should be.  We
> > *could* wade into those waters, but I'll just also throw out that we
> > could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
> > 100MiB respectively and leave it at that.  Clients targetting
> > resource-limited environments could let their users configure their own
> > threshold for early termination of downloads.

>   Dispite being the one who pushed for larger status codes, I'm not a fan of
> this proposal, but I can't fully explain *why* other than to say "where does
> it stop?"  Like Tadeusz Sosnierz alluded too, what's huge today may be small
> tomorrow [1].  Personally, I think adding the filesize to the MIME type *is*
> the best answer, but I can see and even agree with the arguemnts against it.
> And I think I'm justified in saying that [2].

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

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.

Cheers,
Ivy