> Howdy! Ahoy! > I understand that there may be some aversion to changing things that > are already pretty well established, but I hope it's not too late and > my arguments will be at least a little bit convincing. :) I do kind of worry that the time to propose changes to "core" stuff is passed or passing. New implementations are being written at an astonishing rate and with so many clients and servers out there, every substantial change runs the risk of fracturing the nascent Geminispace into incompatible subspaces. Stuff that is very poorly implemented, like client certificiate stuff, doesn't have this risk so much, but anything fundamental I worry is already more or less "set" now. It's the downside to unexpected explosive growth! > Suggestion #0: Strengthen language around status codes I'm totally open to rewording parts of the spec to make stuff clearer if people think what's there now is confusing. I will take this into consideration, and please look out for a post to the list sometime this coming weekend about people being able to more conveniently make suggestions for changes to the spec and other docs. > Suggestion #1: Remove proxy related codes > Current spec is already something that is likely to be two IETF RFCs > in the future (protocol and document format). I like your optimism!!! > Adding proxy support into > the mix complicates things even further. Problems with proxy IMO start > with the fact that it's not clear (to me at least) what sort of proxy > gemini would benefit from; nor is it stated in the spec. The most compelling case, IMHO, is proxies which are protocol-translating gateways. One of these already exists (https://tildegit.org/solderpunk/agena), it answers queries for gopher:// URLs by fetching the original content over gopher and translating it to text/gemini (which is, by design, very easy to do). AV-98 can be given the host and port of such a proxy and then it will automatically use it to follow Gopher links. Any other client could add this support to become a combined Gemini-Gopher client without the author having to write a line of Gopher-related code. In principle this could be done for HTTP too, but converting websites to text/gemini is less straight forward (and likely to result in something ugly to look at anyway because all sorts of irrelevant crap will be converted too, minus some Herculean effort to detect what the actual content is). One could also simply run a straight Gemini proxy which listens on a port other than 1965 in order to circumvent a filter on outgoing traffic on that port. There are definitely useful things which can be done. Perhaps "proxy" is a misleading word to have used for this. I was never imagining anything super complicated with expiration mechanisms, or a proxy server which basically acts as a packet router. They would be very explicitly MITM operations, and you couldn't use them to access services which relied on client cetificiatees - which should really end up being a small minority of content. Nothing that would actually require anything in the way of a formal spec. Should these be called something else? > Suggestion #2: Deduplicate client cert errors > Only a single client cert can be sent when establishing the communication > channel. My mental model (correct me if I'm wrong!) is that transient > cert is a session substitute and permanent cert is authentication > mechanism (roughly speaking at least). That model is totally accurate (roughly speaking at least), I'm glad people get this! > Current spec has 3 cert request mechanisms, 3 rejection codes and > a revocation code. This creates numerous corner cases for clients > to handle properly, e.g. > * what do you do if you get 21 in response to a request that included > your permanent key? I sure hope the browser doesn't actually delete > the permanent key from the store :) > * what do you do if you get 64 but your cert is not from the future? > * what do you do if you get 65 but your cert hasn't expired? > > I'd like to see a single "client certificate rejected" code eliminating > responses that would potentially make no sense. I'm not really convinced these are serious problems. If you get a 64 or 65 but you know your cert is temporaly, you display an error message suggesting perhaps the server's clock is faulty. I mean, what do you do if you get your proposed "client certificate rejected" status code in response to a request which was made without a client certificate? > Suggestion #3: Change end of cert session (21) into a redirection > > This will probably be a very controversial one but the way I see it > the end of session typically results in the redirection. This lets you > chain requests on logout in a way that enables permanent client key > delivery or temporary key replacement. With current design you serve > a page in a response to a request that displays something and asks > the client to delete the transient cert. If you want to re-establish > some sort of validation from the client, you need a manual intervention > from the user to do that. I'm not sure if my explanation is clear enough, > I can try and expand upon it if needed. I'd appreciate it if you tried, I'm not sure I really understand what you are proposing here. > Suggestion #4: Merge different types of server error to prevent leaking > what happened under the hood > > a planned maintenance. Basically I'm sort of allergic to disclosing > information about the server state. I don't think it would be any probem at all for a server admin who was conerned about the security implications of this to configure their server so that it logged the full two-digit codes for the sake of log monitoring and debugging, but exclusively sent x0 codes to the client. I think actually in the very early days of Gemini when debate raged over how many status codes we need and how many digits was enough, I made the case that there was no point at all in having codes that distinguish situations which clients can't possibly react to in meaningfully different ways. I was convinced (and rightly so, I think), that it's good to be able to make these distinctions on the server side. The strategy outlined above is kind of like an encoding of this principle. Of course, no off-the-shell servers support this mode of operation yet, but if people like the idea that could change... > Suggestion #5: A comment, really > > 5x codes are by design permanent errors but 51 (HTTP 404 equivalent) is > actually a temporary problem according to the spec. > In fact this is precisely what differentiates it from HTTP 410 GONE > (gemini 52). So there seems to be a design error here but I don't really > know what the correct solution is. Either 5x aren't really permanent > errors (how would they be called then?) or 51 shouldn't be a 5x error > to begin with. It's true that "not found" is, in principle, temporary, or at least non permanent, in the sense that, yes, maybe tomorrow or next month or next year there will be something at that address. The temporary/permanent error distinction in Gemini is intended mostly to be useful for non-human user agents, like search engine crawlers or feed aggregators or things like that, rather than people sitting in front of something like Bombadillo or Castor. If a bot tries to fetch a feed from a bad URL, it would be nice if it didn't continually try again every hour on the hour thinking that it's only a temporary failure and one day the feed will appear! > This sums up my thoughts about the status codes. I know this reads very > much like "too complex, cut!" and that kinda is exactly that. But if you > can make things simpler, why not do it? :) It's very refreshing to see discussion on this mailing list aimed at taking stuff away, not adding it! :) > Thanks for reading this, cheers! Thanks for sharing your thoughts! Cheers, Solderpunk
---
Previous in thread (2 of 4): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (4 of 4): 🗣️ jan6 (a) tilde.ninja (jan6 (a) tilde.ninja)