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 have a little time before I need to start work so I thought I'd just reply now to the first post without having read anything else to share my initial and uninfluenced reaction (which I don't think will change, mind you). > 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 literally specced as being exactly that (well, without the modernized part). From section 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 for parsing MIME types to easily throw together Gemini software without having 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 media type, 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 allowed to define parameters for our media type, but we can't change the fact that it is a *media type*. It is information for clients about *what kind of thing* they're about to get, so they can determine how to handle it. It is *category* information. "English text with Gemini line types" is a sensible category. There can be infinitely many documents in that category and it makes sense for a user agent to treat them all identically, and to perhaps treat them a little differently from "Arabic text with Gemini line types" (by rendering text LTR instead of RTL). Those are genuine "types of stuff". But "28102 bytes of English text with Gemini line types written three days ago with the title Speculative specification" isn't a "type of stuff". It's not a sensible category. Information which is unique to a particular document is just wholly 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 I don't feel fit with the semantics of what a media type is. It's true that I can't stop servers from doing this (and the MIME RFC clearly says that clients must ignore parameters they don't recognise, so I can't even recommend that clients refuse to handle responses which do this as a kind of defensive measure). I hope people will be disuaded from doing this not just by virtue of it being against my wishes for and the intended spirit of Gemini, but also because it completely and clearly violates the intent of a much older and more established piece of internet infrastructure. It's double wrong! Cheers, Solderpunk
---
Previous in thread (8 of 17): 🗣️ poomklao (a) yahoo.com (poomklao (a) yahoo.com)
Next in thread (10 of 17): 🗣️ Petite Abeille (petite.abeille (a) gmail.com)