solderpunk solderpunk at SDF.ORG
Thu Jun 11 18:34:13 BST 2020
- - - - - - - - - - - - - - - - - - -
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 ofsemantic 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 appropriateinformation to attach to a MIME type. Nevertheless, it's still truethat we only get to dictate the permissible parameters for the one MIMEtype that we are actually defining ourselves. All other registered MIMEtypes, including all the image/*, audio/* and video/* types which areliable to be the most common large files, have their own pre-definedlist of registered parameters and we shouldn't be adding extras of ourown.
Maybe we just need to (continue to) let the file size issue go. I won'tdeny that it's useful, but (as so often) Gopherspace is the existenceproof that useful and valuable stuff can be built without it.
The concern about users without fast and cheap internet which was partof the motivation for my recent suggestion for more 2x codes wasgenuine, and it would have been one more nice utilisation of the "twodigit codes which degrade gracefully into one digit codes" philosophy(which I think is neat but worry that we perhaps don't utilise enoughto make it worth while), but as was pointed out in the ensuingdiscussion, most text/* content is likely to be quite small and clientscan already terminate connections early on the basis of a non text/*MIME type in precisely the way that I was proposing they should do onthe receipt of a 2x code above their threshold. So, they can get quitea lot of the benefit of that proposal with no changes required. I thinkI will add an option to quick-terminate on non-text content to AV-98.
Cheers,Solderpunk