Comments for 2019-07-07:

Sean Conner (WWW) 2019-10-02
 I don't agree with all of it.  I don't have a problem with the "i" item type (given that my own
 server [1] uses it).  I too, thought of doing what you do with multiresource articles, but in the
 end rejected.  I can't really justify why I rejected it other than the effort to do so was in my
 case, excessive to what I was trying to achieve [2].

 The URL: convention was a proposed extension [3] to enable a gopher server to be a form of proxy to
 clients that don't understand URLs.  A server doesn't have to support it [4] but yes, if you want
 to start selectors with "URL:" you are probably out of luck.  And yes, you are correct that this
 does violate the opaque nature of selectors.  I view this as "it is what it is".

 I do agree with your views that not all selectors start with '/' (a problem I have with my server
 which lead me to my proposal) and I too have issues with the gopher URL spec, but not because of
 the leading '/' issue, but because it didn't use the already existing query mechanism but invented
 its own.  That, and the fact that you need to include the gopher type as part of the URL.  But
 again, it is what it is and it had to support selectors that might not match up with the common URL
 format [6].

 I don't follow your arguments against the "caps.txt" file.  If the gopher server does actually use
 the file system as selectors, what problem is it that a file exists that describes it?  It's not
 limited to POSIX style paths:
        /source/gopher/server/main.c

 but Windows:
        \source\gopher\server\main.c

 or even Classic Mac OS:
        source:gopher:server:main.c

 Also, what's with the hate of comments?  Yes, "caps.txt" has comments.  But it's NOT a gopher
 map---it's a file of name/value pairs describing aspects of the server.  But in practice, while I
 have a "caps.txt" file on my gopher server, I haven't seen anything request it, so perhaps it's not
 worth getting angry over it.

 As far as "robots.txt" goes, I have that on my gopher server, but I've found other ways to deal
 with web bots that appear to work better [7].

 [1]    gopher://gopher.conman.org/
 [2]    gopher://gopher.conman.org/0Phlog:2019/08/08.1
 [3]    https://tools.ietf.org/html/draft-matavka-gopher-ii-03
 [4]    My gopher server [5] can be configured to proxy URL: selectors.
 [5]    https://github.com/spc476/port70
 [6]    I have code to parse gopher URLs:
        https://github.com/spc476/LPeg-Parsers/blob/master/url/gopher.lua
        as well as generic URLs:
        https://github.com/spc476/LPeg-Parsers/blob/master/url.lua
        I did that because the gopher URL is a poor fit for the generic URL scheme.
 [7]    gopher://gopher.conman.org/0Phlog:2019/08/06.1
        gopher://gopher.conman.org/0Phlog:2019/09/30.2

Prince Trippy () 2019-10-02
[I don't agree with all of it.  I don't have a problem with the "i" item type (given that my own
 server [1] uses it).                                                                              ]
I notice you also don't find the empty ``i'' item type to be among the more egregious uses.

[I too, thought of doing what you do with multiresource articles, but in the end rejected.  I can't
 really justify why I rejected it other than the effort to do so was in my case, excessive to what I
 was trying to achieve [2].                                                                        ]
That's understandable.  I like my Gopher hole far more than my website, so I've gone further and now
write the Gopher versions first, as there are some special considerations to be made if the document
is to look particularly pleasant.

[The URL: convention was a proposed extension [3] to enable a gopher server to be a form of proxy to
 clients that don't understand URLs.  A server doesn't have to support it [4] but yes, if you want
 to start selectors with "URL:" you are probably out of luck.  And yes, you are correct that this
 does violate the opaque nature of selectors.  I view this as "it is what it is".                  ]
I'm not disappointed that proposed extension document is dead.  I don't find everything inside of it
objectionable, but I dislike the WWW and like Gopher as a reprieve; regarding accepting of malformed
data, I'd much rather avoid that mess the WWW is from such and write only a strict Gopher client and
server pair.  I'm fond of the idea of what I call reprimanding behavior, which is when a server does
understand a request, but chooses to reprimand the user rather than fulfill it, so that the standard
continues to be relevant.

Regarding Gopher URLs, I tend to avoid them; I much prefer to list my domain and the selector to use
but that's understandably not always an option.

[I don't follow your arguments against the "caps.txt" file.                                        ]
I outline my qualms with this, from its name to its form to its intent.  It's an alien format I also
find lacks merit.  I see no particular reason it should exist and so I refuse to offer one.  Now for
comments, that's simply another alien quality of the format.  I'm not angry over it, it's simply one
of a few things I've noticed that I dislike and so don't support.  My server gets a decent number of
requests for it, which is how I believe I first became aware of it.

In closing, your Gopher server implementing IETF RFC 2324 is neat.

Copyright (C) 2019 Prince Trippy
Comments are owned by and the burden of their respective authors.
.