Howdy Geminauts, The first quarter of 2021 is passing by rapidly, with less progress on finalising the few outstanding spec questions before the process of translating the specification to a more precise and formal format suitable for standardisation than I had hoped for. It has become clear to me that for a variety of reasons I am no longer able to effectively lead this process myself. Therefore, effective as of the sending of this email, I am delegating decision-making authority for finalising the spec to Sean Conner <sean at conman.org>. There is no change in my long-standing overall stance that Gemini requires no new features and that remaining work on the specification should be directed only toward addressing edge cases, removing ambiguities and increasing overall consistency. Several issues of this type have been in discussion on the mailing list for some time now, and I am empowering Sean to resolve those issues, not to add new features or make other major changes. I reserve the right to veto Sean's decisions, but I don't expect to need to. Sean is a natural choice for me to delegate this task to. He has been involved in the development of the Gemini specification for longer than anybody other than myself - he was the first person to actually implement the protocol in software, transforming it from the largely academic thought experiment that I had created it as into an actual real world project. He is the developer of a Gemini server (GLV-1.12556) and the admin of a server running it (gemini://gemini.conman.org), which means the details of the specification are of direct and practical relevance to him. He has a long-standing presence in Gopherspace, where the Gemini project was born, and therefore understands and appreciates the value of simple-by-design systems with limited scope. Finally, he has an excellent track record of constructively engaging with the mailing list even at its busiest and most frantic, which certainly can no longer be said for me. For all these reasons I trust him to make good decisions on the basis of careful consideration. I am hopeful that this change will bring us more quickly to a point where there is no more need for decision making and just the slow, quiet work of formalisation. I still hope to be actively involved in that process myself. Cheers, Solderpunk
> On Feb 28, 2021, at 13:02, Solderpunk <solderpunk at posteo.net> wrote: > > It has become clear to me that for a variety of reasons I am no longer > able to effectively lead this process myself. Therefore, effective as > of the sending of this email, I am delegating decision-making authority > for finalising the spec to Sean Conner <sean at conman.org>. Bravo, and congrats to both! ?0?
It was thus said that the Great Solderpunk once stated: > Howdy Geminauts, Greetings and salutations, Geminauts. > It has become clear to me that for a variety of reasons I am no longer > able to effectively lead this process myself. Therefore, effective as > of the sending of this email, I am delegating decision-making authority > for finalising the spec to Sean Conner <sean at conman.org>. I've been spending the day catching up on the list and thnking about what needs to be done. St?phane Bortzmeyer suggested setting up an issue tracker at some place like Gitlab, and I've done just that. I set up two repositories there: https://gitlab.com/gemini-specification/protocol https://gitlab.com/gemini-specification/gemini-text to track issues related to the protocol and the text format. I split them in two because it made sense to me---the issues of the protocol are largely orthogonal to that of text/gemini and not everyone has interest in both. A bit long term is to split the Gemini specification into two along those lines, so those that want to discuss content generation don't have to wade through technobabble of networks and ports and oh my! I've created a few issues already, but gitlab is apparently having issues of its own right now, so for now, the mailing list is still the place to bring these up. Anyway, while I'm here I might as well weigh in on some of the current proposals. First up is favicon.txt. In my opinion, it does NOT violate the letter of the spec, given that it doesn't require any changes to the protocol or text/gemini. It could be argued that it violates the spirit of the spec, but I am not willing to endorce nor condemn it. My decision would be that clients can support it, but it MUST be disabled by default and require user intervention in some form to enable it. On the flip side, those who run Gemini servers MAY configure their server to return "52 Gone" for requests to "/facicon.txt" if they do not want to participate in such nonsense (thank God I was able to convince Solderpunk to add this reponse code back in the day). Clients that receive a "52 Gone" for such a request SHOULD NOT make another request for it. But those who run Gemini servers SHOULD NOT expect to see no further requests from a given IP address---there might be several people sharing an IP, or one user might be using multiple clients. The whole intent of serving up a "52 Gone" is to add said server to a list of servers not to query. Yes, this is more of an "opt-out" than "opt-in" situation, but it's hard to opt in to a feature when it's distributed. This can be extended to further requests of a similar nature should they come up [1]. I would like to ask Michael Lazar to please add these changes to his favicon.txt specification to let others know of the options available. Second, alt-text for preformatted blocks. The original spec did not allow any text past the "```". It was later changed for reasons of accessibility, but intentionally left ambiguous for a consensus to form around it. I think disallowing text on the closing "```" is too excessive and I will most likely rescind that decision to allow more options. But as for specifying an actual format in the specification? No. Best practice, yes, but a solid convention needs to arise first. Third, meta data for text/gemini. Again, like alt-text for preformatted blocks, this isn't something for the specification. Again, it would be best for the community to define a convention first. My own opinion here is that meta data is always nice (Lord knows I have enough in my blog [2]) but having been through the "Sematic Web" era, not enough content creators care enough to actually do the work. Fourth, I would like to state that newcomers to the mailing list might not be aware of the history and context that Gemini was developed in, and think of Gemini as a "stripped down web" instead of the "souped up gopher" that it is. Please keep that in mind as new people make proposals, and instead of a "No" with no further conversation, say "No, because here's how you could do it" or "No, because we want a privacy-first stance". In other words, explain why the "no". Or, if nothing constructive comes to mind, don't say anything and let the proposal die quietly. -spc [1] This concept will be added to the "Best Practices" document. [2] Check the source for http://boston.conman.org/
> On Mar 1, 2021, at 03:48, Sean Conner <sean at conman.org> wrote: > > Greetings and salutations, Geminauts. Hail to the Chief we have chosen for the nation, Hail to the Chief! We salute him, one and all. Hail to the Chief, as we pledge cooperation In proud fulfillment of a great, noble call. Yours is the aim to make this grand country grander, This you will do, that is our strong, firm belief. Hail to the one we selected as commander, Hail to the President! Hail to the Chief! Hail to the Chief we have chosen for the nation, Hail to the Chief! We salute him, one and all. Hail to the Chief, as we pledge cooperation In proud fulfillment of a great, noble call. :D ?0?
> On Mar 1, 2021, at 03:48, Sean Conner <sean at conman.org> wrote: > > Anyway, while I'm here I might as well weigh in on some of > the current proposals. While you are at it... what about the URI ?? IRI mega thread of yore? What's the current thinking, if any? ?0?
On Sun, Feb 28, 2021 at 09:48:38PM -0500, Sean Conner <sean at conman.org> wrote a message of 79 lines which said: > I set up two repositories there: > > https://gitlab.com/gemini-specification/protocol > https://gitlab.com/gemini-specification/gemini-text Great. Can we assume that, when an issue will be closed, the text of the specification in <https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi> will be changed too so we can be sure that <https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi> is really the current state of the work?
It was thus said that the Great Petite Abeille once stated: > > > > On Mar 1, 2021, at 03:48, Sean Conner <sean at conman.org> wrote: > > > > Anyway, while I'm here I might as well weigh in on some of > > the current proposals. > > While you are at it... what about the URI ?? IRI mega thread of yore? > > What's the current thinking, if any? My current thinking is a switch to IRI once some details are ironed out. People who are concerned about this can voice their concerns on the list here, or (more preferrably) in the issue tracker for this: https://gitlab.com/gemini-specification/protocol/-/issues/1 Rational: Since Gemini is geared around UTF-8, it's weird that the only aspect that currently can't be UTF-8 are links. The change from URI to IRI is pretty minimal except for the use of IDN (International Domain Names) and DNS resolution. -spc
It was thus said that the Great Stephane Bortzmeyer once stated: > On Sun, Feb 28, 2021 at 09:48:38PM -0500, > Sean Conner <sean at conman.org> wrote > a message of 79 lines which said: > > > I set up two repositories there: > > > > https://gitlab.com/gemini-specification/protocol > > https://gitlab.com/gemini-specification/gemini-text > > Great. Can we assume that, when an issue will be closed, the text of > the specification in > <https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi> > will be changed too so we can be sure that > <https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi> > is really the current state of the work? That is the intent yes. For both the protocol and Gemini text specifications. -spc
On 2/28/21 8:48 PM, Sean Conner wrote: > > I've created a few issues already, but gitlab is apparently having issues > of its own right now, so for now, the mailing list is still the place to > bring these up. Anyway, while I'm here I might as well weigh in on some of > the current proposals. Regarding Gitlab issue #2 "TLS Close", may we ease client and server implementations by: 1. Not requiring client applications to send TLS close_notify, since they indicate end-of-data via the request <CR><LF> ? 2. Only requiring server applications to send TLS close_notify if all data has been sent? If the TCP or TLS connection is interrupted by the client or by an intermediary before the server application has transmitted all of its data, there doesn't seem to be a benefit to sending a close_notify to the client and it could also cause various delays which prohibit the server application from moving on to other work. For example, an unending streaming response would be closed by the client, in which case there is no need for a close_notify from the server.
On 2021-03-01 03:18PM, Scot wrote: > 1. Not requiring client applications to send TLS close_notify, since > they indicate end-of-data via the request <CR><LF> ? See this quote from the TLS 1.3 spec: > Each party MUST send a "close_notify" alert before closing its write > side of the connection, unless it has already sent some error alert. > This does not have any effect on its read side of the connection. https://tools.ietf.org/html/rfc8446#section-6.1 - TLS 1.3 The effect of this is that clients MUST send close_notify after writing their a request in order to properly comply with TLS 1.3. I would operate under the assumption that a server would not send a response until a close_notify is received (or the request would be allowed to time out). Obviously a robust server would work without a close_notify, but you should still operate within the spec because I'm wouldn't be surprised if at least one or two TLS implementations require it. There's even stronger wording for TLS 1.2 which requires a close_notify after writing is completed and for /both/ the sending and receiving parties to send a close_notify after the transaction is completed, so the client would have to send a close_notify after the both request and the response, not just the request. See: https://tools.ietf.org/html/rfc5246#section-7.2.1 On 2021-03-01 03:18PM, Scot wrote: > 2. Only requiring server applications to send TLS close_notify if all > data has been sent? If the TCP or TLS connection is interrupted by the > client or by an intermediary before the server application has > transmitted all of its data, there doesn't seem to be a benefit to > sending a close_notify to the client and it could also cause various > delays which prohibit the server application from moving on to other > work. For example, an unending streaming response would be closed by > the client, in which case there is no need for a close_notify from the > server. The whole point of close_notify is to indicate that the write has successfully been completed. I may be misunderstanding your question, but if the connection is interrupted then a close_notify should not be sent, as that would erroneously report that the transaction was successfully completed. For streaming data I assume that it would be properly terminated by the client closing the connection since the data is never completely sent (it's unending). I'm no TLS expert, I'm just reporting what I found after skimming the TLS RFCs, feel free to correct me if I'm wrong here. ~nytpu -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/
> On Mar 1, 2021, at 22:09, Sean Conner <sean at conman.org> wrote: > > My current thinking is a switch to IRI once some details are ironed out. Fantastic. Second question: is there any reasonable way to decouple the Transport Layer Security requirement from the Gemini protocol itself? ?0?
On 3/1/21 4:26 PM, Alex // nytpu wrote: > On 2021-03-01 03:18PM, Scot wrote: >> 1. Not requiring client applications to send TLS close_notify, since >> they indicate end-of-data via the request <CR><LF> ? > See this quote from the TLS 1.3 spec: >> Each party MUST send a "close_notify" alert before closing its write >> side of the connection, unless it has already sent some error alert. >> This does not have any effect on its read side of the connection. > https://tools.ietf.org/html/rfc8446#section-6.1 - TLS 1.3 > > The effect of this is that clients MUST send close_notify after writing > their a request in order to properly comply with TLS 1.3. I would > operate under the assumption that a server would not send a response > until a close_notify is received (or the request would be allowed to > time out). Obviously a robust server would work without a close_notify, > but you should still operate within the spec because I'm wouldn't be > surprised if at least one or two TLS implementations require it. > > There's even stronger wording for TLS 1.2 which requires a close_notify > after writing is completed and for /both/ the sending and receiving > parties to send a close_notify after the transaction is completed, so > the client would have to send a close_notify after the both request and > the response, not just the request. > See: https://tools.ietf.org/html/rfc5246#section-7.2.1 > Hi Alex. I would like to follow the RFC too. After writing C and Python client and server implementations last fall, and examing packet traces, my conclusion was that this does not work with most TLS libraries. Mostly, they will close the connection in both directions if they receive a close_notify. Some of this is documented here [1]. This in turn causes problems for programming languages which expect a given library to behave in a certain way. For example, Python still does not allow sending a close_notify from the client after the request has been delivered and before receiving the response [2]. So, in my opinion, the simplest thing would be to utilize the <CR><LF> of the Gemini request to indicate that the client is finished sending its request. Three benefits of this approach would be: 1. All Gemini clients will keep working right now without changes 2. Because the <CR><LF> can be explicitely sent by a client application and explicetely examined by the server application, without broken TLS libraries intervening, it is easy to correctly implement 3. Gemini client authors will not experience intense frustration at the sad state of TLS library support for half-open close_notify (this is the voice of experience speaking...) > On 2021-03-01 03:18PM, Scot wrote: >> 2. Only requiring server applications to send TLS close_notify if all >> data has been sent? If the TCP or TLS connection is interrupted by the >> client or by an intermediary before the server application has >> transmitted all of its data, there doesn't seem to be a benefit to >> sending a close_notify to the client and it could also cause various >> delays which prohibit the server application from moving on to other >> work. For example, an unending streaming response would be closed by >> the client, in which case there is no need for a close_notify from the >> server. > The whole point of close_notify is to indicate that the write has > successfully been completed. I may be misunderstanding your question, > but if the connection is interrupted then a close_notify should not be > sent, as that would erroneously report that the transaction was > successfully completed. For streaming data I assume that it would be > properly terminated by the client closing the connection since the data > is never completely sent (it's unending). > Yes I agree. It doesn't matter to me how it is worded, as long as its clear that a close_notify doesn't need to be sent from the server to the client unless the server application has been able to send all data that it wants to send first. So in the case of streaming, since the server didn't reach the end of the unending data stream, it would not send close_notify, it would just immediately close the TCP connection. [1] https://github.com/openssl/openssl/issues/11378 [2] https://bugs.python.org/issue39951
It was thus said that the Great Scot once stated: > > 3. Gemini client authors will not experience intense frustration > at the sad state of TLS library support for half-open close_notify > (this is the voice of experience speaking...) Frankly, half-open is borked for TCP pretty much as well, due to the semantics and operation of the Bezerkly sockets API, so that's not new. -spc
It was thus said that the Great Petite Abeille once stated: > > > On Mar 1, 2021, at 22:09, Sean Conner <sean at conman.org> wrote: > > > > My current thinking is a switch to IRI once some details are ironed out. > > Fantastic. > > Second question: is there any reasonable way to decouple the Transport > Layer Security requirement from the Gemini protocol itself? Short answer: no. Long anser: If you want to explore alternative transport security methods, go to town with an implementation, get the crypto community to pass it and *then* present it to the Gemini community. At that point, the discussion can commence. One of the primary motivations of Gemini was adding TLS to gopher, and to avoid the whole http: vs https: that infests the web. -spc
On 3/1/21 6:45 PM, Sean Conner wrote: > It was thus said that the Great Scot once stated: >> 3. Gemini client authors will not experience intense frustration >> at the sad state of TLS library support for half-open close_notify >> (this is the voice of experience speaking...) > Frankly, half-open is borked for TCP pretty much as well, due to the > semantics and operation of the Bezerkly sockets API, so that's not new. > > -spc I do vaguely recall seeing some funny things at the TCP level in those packet traces. If so, that could be be another reason to not require the server to send close_notify unless it is able to send all the data first.
To give the "TLS close" issue some context: The Gemini protocol does not indicate how big a given response is, mimicking gopher and the very early HTTP protocol. In gopher with a non-binary file being transferred, a "." on a line by itself indicates "end-of-file" and for binary files, it's up to the client to keep reading until the stream is closed (RFC-1436 states as much: " Note that for type 5 or type 9 the client must be prepared to read until the connection closes. There will be no period at the end of the file ..."). Gemini inherited this model and no attempts to include a reponse size has been accepted. So, all a client has to go by in Gemini that a file was sent correctly, is to wait for the server to close its side of the connection, as signaled by a "TLS close". This means that issues with the network between the two endpoints (a router crash) are caught, as well as the server crashing before it can send a "TLS close." Then someone noticed that TLS include semantics of "this side is closed" and thus, why the server is expected to close the connection, not the client. Also, it was never an expectation that the client close its side after making a request. Hopefully, this provides enough background on this topic from a Gemini perspective. -spc
On 02/03/2021 00:23, Scot wrote: >[...] > > After writing C and Python client and server implementations > last fall, and examing packet traces, my conclusion was that > this does not work with most TLS libraries. Mostly, they will > close the connection in both directions if they receive a > close_notify. Some of this is documented here [1]. This in > turn causes problems for programming languages which > expect a given library to behave in a certain way. For example, > Python still does not allow sending a close_notify from the > client after the request has been delivered and before > receiving the response [2]. > > So, in my opinion, the simplest thing would be to utilize the > <CR><LF> of the Gemini request to indicate that the client > is finished sending its request. > > Three benefits of this approach would be: > > 1. All Gemini clients will keep working right now without changes > > 2. Because the <CR><LF> can be explicitely sent by a client > application and explicetely examined by the server application, > without broken TLS libraries intervening, it is easy to correctly > implement > > 3. Gemini client authors will not experience intense frustration > at the sad state of TLS library support for half-open close_notify > (this is the voice of experience speaking...) I'm not in any way a TLS expert, but I think you're right: TLS 1.2 uses a duplex-close policy (while TLS 1.3 uses a half-close policy, so that should work better). IMHO the spec should probably refer to the RFC when available and perhaps make a recommendation, but getting into specific details on how the TLS implementation must behave is hairy and probably not practical. As long as the spec is clear, real world can differ and still work, and that's OK. Regards, Juan -- Website: usebox.net/jjm/ Twitter: @reidrac
> On Mar 2, 2021, at 01:52, Sean Conner <sean at conman.org> wrote: > >> Second question: is there any reasonable way to decouple the Transport >> Layer Security requirement from the Gemini protocol itself? > > Short answer: no. Let me rephrase the question: would it be possible to edit the Gemini specification in such a way that it makes TLS a SHOULD, not a MUST. This is purely an editorial adjustment, which would leave the door open for alternative transport layer beside TLS. Thoughts? ?0?
It was thus said that the Great Petite Abeille once stated: > > > On Mar 2, 2021, at 01:52, Sean Conner <sean at conman.org> wrote: > > > >> Second question: is there any reasonable way to decouple the Transport > >> Layer Security requirement from the Gemini protocol itself? > > > > Short answer: no. > > Let me rephrase the question: would it be possible to edit the Gemini > specification in such a way that it makes TLS a SHOULD, not a MUST. > > This is purely an editorial adjustment, which would leave the door open > for alternative transport layer beside TLS. > > Thoughts? If you want to explore alternative transport security methods, go to town with an implementation, get the crypto community to pass it and *then* present it to the Gemini community. At that point, the discussion can commence. Until such time and discussion show the new method to be viable, safe and easy to implement, TLS will remain a MUST. I do NOT want to encourage anyone to create some halfbaked crypto scheme and make things worse. -spc
> On Mar 2, 2021, at 09:21, Sean Conner <sean at conman.org> wrote: > > I do NOT want to encourage anyone to create some half-baked crypto scheme and make things worse. Very motherly of you. Thank you for your concern. :) As already mentioned several times over the last several months: in my case, everything runs over wireguard+tailscale [1][2] ? making TLS redundant and unwelcome. "Remembering the LAN" explains the operating principle: https://tailscale.com/blog/remembering-the-lan/ In short, this is not about (re)inventing some "half-baked crypto", but rather to use existing ones, which happen not to be TLS at all. No drama though... I do not mind one way or another as for as Gemini goes ? I have fully moved on and adopted+adapted Mercury for my own needs. Just thought it would be polite to explicitly point out the corner you are painting yourself into :) No worries though... all good :) Wish you a very pleasant day. [1] https://en.wikipedia.org/wiki/WireGuard [2] https://tailscale.com/blog/how-tailscale-works/ ?0?
It was thus said that the Great Petite Abeille once stated: > > > > On Mar 2, 2021, at 09:21, Sean Conner <sean at conman.org> wrote: > > > > I do NOT want to encourage anyone to create some half-baked crypto scheme and make things worse. > > Very motherly of you. Thank you for your concern. :) > > As already mentioned several times over the last several months: in my > case, everything runs over wireguard+tailscale [1][2] ? making TLS > redundant and unwelcome. I only have one question for you then---IF I allowed TLS to be optional, how would a client know to use TLS, Wireguard or say, Tor? > Just thought it would be polite to explicitly point out the corner you are > painting yourself into :) > > No worries though... all good :) Good luck with your endevours. And if I find myself painted into a corner with Gemini, I know who to call. -spc > [1] https://en.wikipedia.org/wiki/WireGuard > [2] https://tailscale.com/blog/how-tailscale-works/
> On Mar 2, 2021, at 10:32, Sean Conner <sean at conman.org> wrote: > > how would a client know to use TLS, Wireguard or say, Tor? multiaddr + dns-sd for example > And if I find myself painted into a corner with Gemini, I know who to call. Reasonable people can agree to disagree :)
On Tue, Mar 02, 2021 at 04:32:05AM -0500, Sean Conner <sean at conman.org> wrote a message of 28 lines which said: > I only have one question for you then---IF I allowed TLS to be > optional, how would a client know to use TLS, Wireguard or say, Tor? Note that HTTP has this issue (HTTP 1.1? 1.2? Soon 1.3 which does not even use TCP?) It is "solved" by some mixture of signaling in the DNS <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>, redirection when possible (Alt-Svc:) and intelligent guessing, probing and memorization by the client.
> On Mar 2, 2021, at 18:26, Stephane Bortzmeyer <stephane at sources.org> wrote: > > Note that HTTP has this issue (HTTP 1.1? 1.2? Soon 1.3 which does not > even use TCP?) It is "solved" by some mixture of signaling in the DNS > <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>, > redirection when possible (Alt-Svc:) and intelligent guessing, probing > and memorization by the client. wow. and we thought we had problems. well done http! ?0?
On Mon, Mar 01, 2021 at 07:52:41PM -0500, Sean Conner <sean at conman.org> wrote a message of 22 lines which said: > Long anser: If you want to explore alternative transport security > methods, go to town with an implementation, get the crypto community to pass > it and *then* present it to the Gemini community. At that point, the > discussion can commence. > > One of the primary motivations of Gemini was adding TLS to gopher, and to > avoid the whole http: vs https: that infests the web. Note that we may have to address the QUIC issue. The RFCs on QUIC (a transport protocol, alternative to TCP, with mandatory crypto) are almost published, and we may have to consider wether to use it. QUIC is very targeted towards the Web (for instance with multiplexing because, unlike Gemini, Web pages are made of several resources) so it may be better to ignore it, that's something to think about.
It was thus said that the Great Stephane Bortzmeyer once stated: > On Mon, Mar 01, 2021 at 07:52:41PM -0500, > Sean Conner <sean at conman.org> wrote > a message of 22 lines which said: > > > Long anser: If you want to explore alternative transport security > > methods, go to town with an implementation, get the crypto community to pass > > it and *then* present it to the Gemini community. At that point, the > > discussion can commence. > > > > One of the primary motivations of Gemini was adding TLS to gopher, and to > > avoid the whole http: vs https: that infests the web. > > Note that we may have to address the QUIC issue. The RFCs on QUIC (a > transport protocol, alternative to TCP, with mandatory crypto) are > almost published, and we may have to consider wether to use it. QUIC > is very targeted towards the Web (for instance with multiplexing > because, unlike Gemini, Web pages are made of several resources) so it > may be better to ignore it, that's something to think about. My stance on QUIC is the same replacing TLS. When someone finally gets Gemini running over QUIC, then we can discuss it. Until then, there's nothing to discuss. Besides, I doubt the Gemini community will go for it (famous last words). -spc
> On Mar 2, 2021, at 19:58, Sean Conner <sean at conman.org> wrote: > > I doubt the Gemini community Is the "community" sentient? Or is it more of a turn of phrase, such as "Company Policy"? Or perhaps ?That?s the Way We Do Things Around Here?? ?That?s the Way We Do Things Around Here?: An Overview of Organizational Culture M. Jason Martin, Spring 2006 https://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1060&context=ejasljournal ?0?
On 3/2/2021 10:58 AM, Sean Conner wrote: > > My stance on QUIC is the same replacing TLS. When someone finally gets > Gemini running over QUIC, then we can discuss it. Until then, there's > nothing to discuss. Besides, I doubt the Gemini community will go for it > (famous last words). > > -spc > One of the reasons I most admire your tact and approach to opportunities for solutions (aka: problems). "Show me. If it works, then let's talk." Case in point: BBN. Yeah, the IP stack that didn't stack up. Bill Joy is famous for answering the question posed to him with, "It's simple. You just read the specs and write the code" (paraphrased, of course). I'm confident that Solderpunk found this about your character as an important reason why he delgated AUTH to you for this part of the project. You put your keyboard where everyone's discussions were and wrote https://github.com/spc476/GLV-1.12556 It makes for a strong point of advocation when this happens, for pretty much anything. Kindest regards, -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
---