On Sun Nov 1, 2020 at 3:47 PM CET, Solderpunk wrote: > The other option is to stick it *after* the MIME type, separated by a > tab or some other delimiter, and I don't like that idea because as soon > as the precedent is set that extra bits of optional information can be > tacked on after the MIME type and simpler clients can ignore them, it > opens the gateway to endless such extensions, and the risk that some of > them will become so popular and widely implemented that clients which > don't do so are considered "outdated" or "broken", and these "optional" > extensions are now de-facto obligatory spec features. ...I suspect I'll regret sharing this, but intellectual honesty compels me. It's just occurred to me that this problem can actually be avoided by having the <META> value for status code 20 be the content size in bytes, followed by arbitrary whitespace, followed by the MIME type. With this approach, the designated separator between the size and the MIME type is whitespace, but because MIME types may themselves contain whitespace (to e.g. separate type/subtype from parameter values), it would be extremely problematic to attempt to add any optional extensions on after the MIME type using that same designated separator. Having the separator possibly occur inside the final element of the list makes the list self-terminating, which completely addresses my greatest fear with having a list at all, as opposed to just a single bit of information. So, this is actually solvable, in principle. It would require a backward-compatibility breaking change to the protocol, which would probably throw the Geminiverse into a period of chaos as clients and servers made the change at different rates. I haven't done anything like this since the early days when you could count Gemini implementations on your fingers and I had pre-existing relationships with all the authors, so the chaotic period was measured in mere days before we achieved perfect unity again. I have no idea how it would go down this time now that everybody and their dog has written some Gemini tooling, and I'm not at all convinced that the lack of Content-Size is such a big practical problem that it's worth this kind of upheaval. But if content size is ever going to make it in, this seems like the best approach to me. It doesn't abuse MIME types at all and it doesn't provide an obvious place for would-be extenders of the protocol to add additional content to the response header. No other previous proposal has had both those properties, to the best of my knowledge. Cheers, Solderpunk
---
Previous in thread (19 of 48): 🗣️ Solderpunk (solderpunk (a) posteo.net)
Next in thread (21 of 48): 🗣️ Arav K. (nothien (a) uber.space)