solderpunk solderpunk at SDF.ORG
Fri May 29 10:24:51 BST 2020
- - - - - - - - - - - - - - - - - - -
On Fri, May 29, 2020 at 04:10:40AM +0200, Petite Abeille wrote:
I can see this has triggered a thread of replies already but I only havea little time before I need to start work so I thought I'd just replynow to the first post without having read anything else to share myinitial and uninfluenced reaction (which I don't think will change, mindyou).
Presently, a successful status code may look like:
20 text/gemini; charset=utf-8
Would it be reasonable to consider the structure of <META> as equivalent to a modernized MIME header?
They're not "equivalent to a modernized MIME header", they are literallyspecced as being exactly that (well, without the modernized part). Fromsection 3.3:
Response bodies only accompany responses whose header indicates a
SUCCESS status (i.e. a status code whose first digit is 2). For such
responses, <META> is a MIME media type as defined in RFC 2046.
This is very deliberate! It lets people use pre-existing machinery forparsing MIME types to easily throw together Gemini software withouthaving to write any customised code.
We already have the charset, so... as we have 1024 bytes to play with...
Yes, it's true we are free to define additional parameters for our mediatype, and I *have* stressed out about this in the past. However...
... we could add a couple of further information such as Content-Length [1], Content-Disposition [2], Content-Language [3], and Date[4]..
Perhaps something like this:
20 text/gemini; charset=utf-8; length=28102; name="Speculative specification"; date=2020-05-26; language=en-US
...most of what is new here makes no sense whatsoever. We are allowedto define parameters for our media type, but we can't change the factthat it is a *media type*. It is information for clients about *whatkind of thing* they're about to get, so they can determine how to handleit. It is *category* information. "English text with Gemini linetypes" is a sensible category. There can be infinitely many documentsin that category and it makes sense for a user agent to treat them allidentically, and to perhaps treat them a little differently from "Arabictext with Gemini line types" (by rendering text LTR instead of RTL).Those are genuine "types of stuff". But "28102 bytes of English textwith Gemini line types written three days ago with the titleSpeculative specification" isn't a "type of stuff". It's not a sensiblecategory. Information which is unique to a particular document is justwholly inappropriate in a MIME media type, it's not the place for it.
I'm definitely not going to spec any parameters for text/gemini which Idon't feel fit with the semantics of what a media type is. It's truethat I can't stop servers from doing this (and the MIME RFC clearly saysthat clients must ignore parameters they don't recognise, so I can'teven recommend that clients refuse to handle responses which do this asa kind of defensive measure). I hope people will be disuaded from doingthis not just by virtue of it being against my wishes for and theintended spirit of Gemini, but also because it completely and clearlyviolates the intent of a much older and more established piece ofinternet infrastructure. It's double wrong!
Cheers,Solderpunk