I figure I could put my two cents worth in here.

For my part, the Gopher protocol is that which is rendered correctly by the final version of the UMN Gopher client, which can be found here these days: https://github.com/jgoerzen/gopher
I also stumble on it in a few modern distros for Linux and the BSDs.

If the UMN gopher client can't render something properly, that something isn't gopher, no matter if it is a "new" type or a different rendering of a menu that can be seen as an improvement. Gopher could be haltingly flexible in its design, but a lot of
that wasn't realized when most clients were written in their day. The point of using an older protocol (besides being a lot easier to code) is that older existing clients on older OSs and older machines can still make use of it. If you add new
functionality that breaks older clients or makes some menu items unusable or inaccessible to older clients, you are just not doing gopher anymore. I don't want to have to re-code a commodore 64 gopher client because someone decided to redefine gopher and
make everything more incompatible...

This isn't a call not to do cool new things, only not to call such new things *gopher* or imply that what you are doing is compatible with gopher. When what you do doesn't work with the UMN gopher client, just call the thing something else and make sure
you offer a reference client/server pair (as UMN did) that adheres to your new standard and then name it something else and then get a new port number assigned while you are at it. If it is on port 70, it should be gopher or gopher+ compliant so as not
to confuse existing clients by using the gopher port and then not conforming to the UMN client standard. This is why we create standards in the first place!

Though underdeveloped since infancy and practically abandoned not long after birth, the gopher protocol is de-facto defined by the last UMN client and that simply becomes "the" standard. Deviate if you like, but use a different name and port number to do
it, please.

Also, that means that there is no "secure" gopher protocol. The UMN client couldn't do SSL, so it ain't gopher. Besides, gopher was never conceived as secure - anyone could access it and it was read-only by design - what needed to be secured here?

Broadly, I personally see no problem with "gopher-ish" derivative protocols/clients/servers being advertised or discussed in this newsgroup. Anything like a simple, fast, and easy-to-code transport deserves a home here alongside gopher.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, May 4, 2018 at 2:42:53 PM UTC-6, Jason Nemrow wrote:

I figure I could put my two cents worth in here.

For my part, the Gopher protocol is that which is rendered correctly by the final version of the UMN Gopher client, which can be found here these days: https://github.com/jgoerzen/gopher
I also stumble on it in a few modern distros for Linux and the BSDs.

If the UMN gopher client can't render something properly, that something isn't gopher, no matter if it is a "new" type or a different rendering of a menu that can be seen as an improvement. Gopher could be haltingly flexible in its design, but a lot

of that wasn't realized when most clients were written in their day. The point of using an older protocol (besides being a lot easier to code) is that older existing clients on older OSs and older machines can still make use of it. If you add new
functionality that breaks older clients or makes some menu items unusable or inaccessible to older clients, you are just not doing gopher anymore. I don't want to have to re-code a commodore 64 gopher client because someone decided to redefine gopher and
make everything more incompatible...

This isn't a call not to do cool new things, only not to call such new things *gopher* or imply that what you are doing is compatible with gopher. When what you do doesn't work with the UMN gopher client, just call the thing something else and make

sure you offer a reference client/server pair (as UMN did) that adheres to your new standard and then name it something else and then get a new port number assigned while you are at it. If it is on port 70, it should be gopher or gopher+ compliant so as
not to confuse existing clients by using the gopher port and then not conforming to the UMN client standard. This is why we create standards in the first place!

Though underdeveloped since infancy and practically abandoned not long after birth, the gopher protocol is de-facto defined by the last UMN client and that simply becomes "the" standard. Deviate if you like, but use a different name and port number to

do it, please.

Also, that means that there is no "secure" gopher protocol. The UMN client couldn't do SSL, so it ain't gopher. Besides, gopher was never conceived as secure - anyone could access it and it was read-only by design - what needed to be secured here?

Broadly, I personally see no problem with "gopher-ish" derivative protocols/clients/servers being advertised or discussed in this newsgroup. Anything like a simple, fast, and easy-to-code transport deserves a home here alongside gopher.

For fun, you can access a UMN client, pointing at my gopher server ( gopher://quix.us ) by telnetting to quix.us. I haven't got the file downloads worked out yet, but you can play with it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/4/18 10:42 PM, Jason Nemrow wrote:

For my part, the Gopher protocol is that which is rendered correctly by the final version of the UMN Gopher client

If the UMN gopher client can't render something properly, that something isn't gopher, no matter if it is a "new" type or a different rendering of a menu that can be seen as an improvement.

If you add new functionality that breaks older clients or makes some menu items unusable or inaccessible to older clients, you are just not doing gopher anymore. I don't want to have to re-code a commodore 64 gopher client because someone decided to

redefine gopher and make everything more incompatible...


Dear Jason,

I know it's pretty old statement, but not much changed in Gopher RFC
from that time ;/

What happened to your gopher? What is that new "gopher-ish" derivate you invented there? I was not here in 2019 where you original post this
article, I Just assume and speculate that you had gopher which was
compatible with UMN gopher client and was RFC 1436 compliant.

I hope nobody and nothing forced you for this incompatibilities and it's
just matter of time to fix things.

May you be with gopher again

--
morena
gopher://morena.rip/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)