💾 Archived View for gemi.dev › gemini-mailing-list › 000212.gmi captured on 2024-05-26 at 15:30:13. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hey folks, At gemini://gemini.circumlunar.space/docs/specification-modified.gmi you will find a modified version of the current spec. If you download it, along with the current spec from gemini://gemini.circumlunar.space/docs/specification.gmi, you can `diff` them to see the changes. These changes are a tentative version of those I want to make before making a new official update and then, at last, freezing the spec again. I'm making them available now so people can point out oversights or suggest improvements. The changes are:
Looks good to me. I noticed there's a lone tab on row 322; maybe fix that too. On Sat, 13 Jun 2020 at 21:16, solderpunk <solderpunk at sdf.org> wrote: > Hey folks, > > At gemini://gemini.circumlunar.space/docs/specification-modified.gmi you > will find a modified version of the current spec. If you download it, > along with the current spec from > gemini://gemini.circumlunar.space/docs/specification.gmi, you can `diff` > them to see the changes. These changes are a tentative version of those > I want to make before making a new official update and then, at last, > freezing the spec again. I'm making them available now so people can > point out oversights or suggest improvements. > > The changes are: > > * Fix a section numbering error > * Define the gemini URI scheme, and explicitly disallow the userinfo > subcomponent of the authority component, protecting us from Petite > Abeille's "auto cookie" construct. > * Add a minimal definition of alt text to the definition of preformatted > mode toggle lines, to address accessability and searchability > concerns, as well as to close, or at least ameliorate, the > extensibility loophole identified by Katarina Eriksson. > * A simplification of the client certificate status codes and details, > including removing transient client certificates as a formally defined > construct with prescribed behaviour. > > I hope that the alt text and client certificate stuff can be augmented > by best practices established outside the spec itself to fill in > details. > > If people think we can do a better job of the above changes, I'm happy > to hear about it, but I don't want to consider any non-trivial changes > other than the above before a nice long freeze. > > Cheers, > Solderpunk > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200613/a51b 8430/attachment.htm>
On Sat, Jun 13, 2020 at 11:06:34PM +0300, Hannu Hartikainen wrote: > Looks good to me. I noticed there's a lone tab on row 322; maybe fix that > too. Got it, kiitos! Cheers, Solderpunk
On Sat, Jun 13, 2020 at 2:16 PM solderpunk <solderpunk at sdf.org> wrote: > > Hey folks, > > At gemini://gemini.circumlunar.space/docs/specification-modified.gmi you > will find a modified version of the current spec. If you download it, > along with the current spec from > gemini://gemini.circumlunar.space/docs/specification.gmi, you can `diff` > them to see the changes. These changes are a tentative version of those > I want to make before making a new official update and then, at last, > freezing the spec again. I'm making them available now so people can > point out oversights or suggest improvements. Nice work! I appreciate all of the effort that you are putting into making the spec more clear and readable. A few comments: > 5.4.2 Link lines > > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF> I am confused that the <CR><LF> is explicitly called out here and not for any of the other line types. It makes me think if my client sees a link without the <CR> in it, I should treat it like a text line instead of a link. There is also an edge case where the last line of a text/gemini contains a link, but doesn't have a newline at all. I suggest removing the newline from the link definition all together since line breaking behavior is already defined elsewhere. =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>] > 61 CERTIFICATE NOT AUTHORISED > > The supplied client certificate is not authorised for accessing the particular requested resource. The problem is not with the certificate itself, which may be authorised for other rsources. Spelling error, "rsources" > 62 CERTIFICATE NOT VALID > > The supplied client certificate was not accepted because either its validity start date is in the future or its expiry date has passed. This indicates a problem with the certificate in and of itself, with no consideration of the particular requested resource. This wording implies that the validity/expiration date are the ONLY two errors that should ever trigger this error code. There are probably other certificate errors that should fall into this category like corrupt certificates or invalid self-signatures. Astrobotany returns a 6x error message if you attempt to sign-in using a TLS certificate that does not contain a subject CN field. What error should that return with the new spec, 61 or 62? Best, Michael
On Sat, Jun 13, 2020 at 10:50:16PM -0400, Michael Lazar wrote: Thanks a lot for the feedback! > > 5.4.2 Link lines > > > > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF> > > I am confused that the <CR><LF> is explicitly called out here and not for any > of the other line types. It makes me think if my client sees a link without the > <CR> in it, I should treat it like a text line instead of a link. There is also > an edge case where the last line of a text/gemini contains a link, but doesn't > have a newline at all. I suggest removing the newline from the link definition > all together since line breaking behavior is already defined elsewhere. > > =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>] Good catch, this makes perfect sense. This probably should have been spotted and changed at the same time as clarifying CR/LF requirements. > > 61 CERTIFICATE NOT AUTHORISED > > > > The supplied client certificate is not authorised for accessing the > particular requested resource. The problem is not with the certificate itself, > which may be authorised for other rsources. > > Spelling error, "rsources" Fixed, thanks! > > 62 CERTIFICATE NOT VALID > > > > The supplied client certificate was not accepted because either its validity > start date is in the future or its expiry date has passed. This indicates a > problem with the certificate in and of itself, with no consideration of the > particular requested resource. > > This wording implies that the validity/expiration date are the ONLY two errors > that should ever trigger this error code. There are probably other certificate > errors that should fall into this category like corrupt certificates or invalid > self-signatures. Yep, very true, I will fix this. > Astrobotany returns a 6x error message if you attempt to sign-in using a TLS > certificate that does not contain a subject CN field. What error should that > return with the new spec, 61 or 62? Hmm. The subject field itself is actually allowed to be empty, I think. So strictly speaking such a certificate is not "invalid" in any absolute sense. Sice a non-empty subject CN is a requirement of Astrobotany, I guess 61 is the correct code. The CN requirement should be made clear in the META. Cheers, Solderpunk
---