💾 Archived View for gemi.dev › gemini-mailing-list › 000146.gmi captured on 2023-11-04 at 12:28:38. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hi!
I find gemini very exciting, bringing back some fun in network
programming!
I have some small suggestions to spec style, i apologize if this was
already addressed in a previous message (i am lazy and i did not
searched archive, sorry).
--------------
1.3.1
Gemini response headers look like this:
<STATUS> <META><CR><LF>
[...]
--------------
In my opinion the space character between <STATUS> and <META> could be
a symbol not the character itself something like:
<STATUS><SPACE><META><CR><LF>
this way it is much more difficult that the reader could miss or
misunderstand the single space in the response line.
--------------
1.4.2
[...]
1.4.3
--------------
I think would be a good idea to include some code snippets (maybe in C
with libssl?) to illustrate how to do server validation or make client
certificate.
I the code was too long could be added in an appendix or some code
form an existing implementation can be linked, i do know.
I think there is a minor typo in the FAQ:
--------------
### 1.3 Where can I learn more?
[...]
Official discussion regarding Gemini hapens on a mailing list.
[...]
--------------
Bye and thank you for gemini!
C.
On Mon, May 25, 2020 at 06:33:57PM +0200, cage wrote: > Hi! Howdy! > I find gemini very exciting, bringing back some fun in network > programming! Happy to hear it! :) > 1.3.1 > > Gemini response headers look like this: > > <STATUS> <META><CR><LF> > > [...] > > In my opinion the space character between <STATUS> and <META> could be > a symbol not the character itself something like: > > <STATUS><SPACE><META><CR><LF> > > this way it is much more difficult that the reader could miss or > misunderstand the single space in the response line. This makes sense, I will make the change. > I think would be a good idea to include some code snippets (maybe in C > with libssl?) to illustrate how to do server validation or make client > certificate. > > I the code was too long could be added in an appendix or some code > form an existing implementation can be linked, i do know. I think code examples are beyond the scope of a specification, and would be far too long if we tried to provide good coverage. But I've thought for a while now some kind of "implementer's guide" as a separate document would be a good idea. Specifically, it would be nice to have code in many languages / libraries for setting up TLS 1.2 to use only the more secure cipher suites. > I think there is a minor typo in the FAQ: > > ### 1.3 Where can I learn more? > > [...] > > Official discussion regarding Gemini hapens on a mailing list. > > [...] > Fixed! > Bye and thank you for gemini! Thanks for taking the time to make these suggests. Cheers, Solderpunk
Would <SINGLE SPACE> be useful here? If I recall it had gone from any whitespace to single whitespace? so that might make it unambiguous? J On Tue, May 26, 2020, 13:07 solderpunk <solderpunk at sdf.org> wrote: > On Mon, May 25, 2020 at 06:33:57PM +0200, cage wrote: > > Hi! > > Howdy! > > > I find gemini very exciting, bringing back some fun in network > > programming! > > Happy to hear it! :) > > > 1.3.1 > > > > Gemini response headers look like this: > > > > <STATUS> <META><CR><LF> > > > > [...] > > > > In my opinion the space character between <STATUS> and <META> could be > > a symbol not the character itself something like: > > > > <STATUS><SPACE><META><CR><LF> > > > > this way it is much more difficult that the reader could miss or > > misunderstand the single space in the response line. > > This makes sense, I will make the change. > > > I think would be a good idea to include some code snippets (maybe in C > > with libssl?) to illustrate how to do server validation or make client > > certificate. > > > > I the code was too long could be added in an appendix or some code > > form an existing implementation can be linked, i do know. > > I think code examples are beyond the scope of a specification, and would > be far too long if we tried to provide good coverage. But I've thought > for a while now some kind of "implementer's guide" as a separate > document would be a good idea. Specifically, it would be nice to have > code in many languages / libraries for setting up TLS 1.2 to use only > the more secure cipher suites. > > > I think there is a minor typo in the FAQ: > > > > ### 1.3 Where can I learn more? > > > > [...] > > > > Official discussion regarding Gemini hapens on a mailing list. > > > > [...] > > > > Fixed! > > > Bye and thank you for gemini! > > Thanks for taking the time to make these suggests. > > Cheers, > Solderpunk >
On Tue, May 26, 2020 at 02:16:47PM -0500, ??? wrote: > Would <SINGLE SPACE> be useful here? If I recall it had gone from any > whitespace to single whitespace? so that might make it unambiguous? > It's disambiguated a few words further down: "<STATUS> and <META> are separated by a single space character." Cheers, Solderpunk > > On Tue, May 26, 2020, 13:07 solderpunk <solderpunk at sdf.org> wrote: > > > On Mon, May 25, 2020 at 06:33:57PM +0200, cage wrote: > > > Hi! > > > > Howdy! > > > > > I find gemini very exciting, bringing back some fun in network > > > programming! > > > > Happy to hear it! :) > > > > > 1.3.1 > > > > > > Gemini response headers look like this: > > > > > > <STATUS> <META><CR><LF> > > > > > > [...] > > > > > > In my opinion the space character between <STATUS> and <META> could be > > > a symbol not the character itself something like: > > > > > > <STATUS><SPACE><META><CR><LF> > > > > > > this way it is much more difficult that the reader could miss or > > > misunderstand the single space in the response line. > > > > This makes sense, I will make the change. > > > > > I think would be a good idea to include some code snippets (maybe in C > > > with libssl?) to illustrate how to do server validation or make client > > > certificate. > > > > > > I the code was too long could be added in an appendix or some code > > > form an existing implementation can be linked, i do know. > > > > I think code examples are beyond the scope of a specification, and would > > be far too long if we tried to provide good coverage. But I've thought > > for a while now some kind of "implementer's guide" as a separate > > document would be a good idea. Specifically, it would be nice to have > > code in many languages / libraries for setting up TLS 1.2 to use only > > the more secure cipher suites. > > > > > I think there is a minor typo in the FAQ: > > > > > > ### 1.3 Where can I learn more? > > > > > > [...] > > > > > > Official discussion regarding Gemini hapens on a mailing list. > > > > > > [...] > > > > > > > Fixed! > > > > > Bye and thank you for gemini! > > > > Thanks for taking the time to make these suggests. > > > > Cheers, > > Solderpunk > >
Thanks, sorry I missed that from just following the email discussion. J On Tue, May 26, 2020, 14:19 solderpunk <solderpunk at sdf.org> wrote: > On Tue, May 26, 2020 at 02:16:47PM -0500, ??? wrote: > > Would <SINGLE SPACE> be useful here? If I recall it had gone from any > > whitespace to single whitespace? so that might make it unambiguous? > > > > It's disambiguated a few words further down: > > "<STATUS> and <META> are separated by a single space character." > > Cheers, > Solderpunk > > > > > On Tue, May 26, 2020, 13:07 solderpunk <solderpunk at sdf.org> wrote: > > > > > On Mon, May 25, 2020 at 06:33:57PM +0200, cage wrote: > > > > Hi! > > > > > > Howdy! > > > > > > > I find gemini very exciting, bringing back some fun in > network > > > > programming! > > > > > > Happy to hear it! :) > > > > > > > 1.3.1 > > > > > > > > Gemini response headers look like this: > > > > > > > > <STATUS> <META><CR><LF> > > > > > > > > [...] > > > > > > > > In my opinion the space character between <STATUS> and <META> could > be > > > > a symbol not the character itself something like: > > > > > > > > <STATUS><SPACE><META><CR><LF> > > > > > > > > this way it is much more difficult that the reader could miss > or > > > > misunderstand the single space in the response line. > > > > > > This makes sense, I will make the change. > > > > > > > I think would be a good idea to include some code snippets (maybe in > C > > > > with libssl?) to illustrate how to do server validation or make > client > > > > certificate. > > > > > > > > I the code was too long could be added in an appendix or some code > > > > form an existing implementation can be linked, i do know. > > > > > > I think code examples are beyond the scope of a specification, and > would > > > be far too long if we tried to provide good coverage. But I've thought > > > for a while now some kind of "implementer's guide" as a separate > > > document would be a good idea. Specifically, it would be nice to have > > > code in many languages / libraries for setting up TLS 1.2 to use only > > > the more secure cipher suites. > > > > > > > I think there is a minor typo in the FAQ: > > > > > > > > ### 1.3 Where can I learn more? > > > > > > > > [...] > > > > > > > > Official discussion regarding Gemini hapens on a mailing list. > > > > > > > > [...] > > > > > > > > > > Fixed! > > > > > > > Bye and thank you for gemini! > > > > > > Thanks for taking the time to make these suggests. > > > > > > Cheers, > > > Solderpunk > > > >
On Tue, May 26, 2020 at 06:07:28PM +0000, solderpunk wrote: Hi solderpunk! > > > > I the code was too long could be added in an appendix or some code > > form an existing implementation can be linked, i do know. > > I think code examples are beyond the scope of a specification, and would > be far too long if we tried to provide good coverage. That is a fair point. :) > But I've thought > for a while now some kind of "implementer's guide" as a separate > document would be a good idea. I think this is an excellent idea! :D > Specifically, it would be nice to have > code in many languages / libraries for setting up TLS 1.2 to use only > the more secure cipher suites. I am quite busy with another project at the moment, but if interested (and if i succeed) i could contribute showing some code in common lisp in the future. I actually do not know very well the current status of TLS libraries in this language but peraphs this could be a chance to improve the libraries too, who knows! :) > > Thanks for taking the time to make these suggests. I am happy i was able to give a contribute to this project even if (given my modest skills) just minimal! :) Bye! C.
---
Previous Thread: Split the spec into two
Next Thread: jetforce security vulnerability, affecting versions < 0.2.3