Re: To evolve or not to evolve
On Tue, Oct 25, 2022 at 06:59:11PM +0200, Mateusz Viste wrote:
> Hi all,
>
> Jame's recent question about TLS made me think. Not about TLS itself,
> because that's a topic that has been discussed many times in the past, but
> about a more general subject.
>
> We are a community of tinkerers, consequently we feel the urge to fiddle
> with bits and pieces whenever possible. This is obvious if we look at the
> currently existing gopher nodes: they are full of neat scripts and toys that
> display cool things. But what should be our approach to the protocol itself?
> Over the years, some "de facto standards" appeared: a couple of new item
> types here and there, some tolerance for missing "terminating dots" in menus
> or text files, flexibility over used charsets, and more.
>
> These are all things that were not part of RFC 1436, yet they are useful and
> work relatively well. So, where's the limit?
>
> My subjective opinion is that any improvement over RFC 1436 is fine, as long
> as it answers a practical need without degrading the service for legacy
> implementations. For example: introducing a new itemtype for PDF files is
> harmless, because old clients are unable to process PDFs anyway, so it makes
> no difference for them whether the file is advertised as "d", "9" or
> something else.
> Same for CAPS support: an old client won't look for it, so no harm done.
>
> What's your stance on this?
>
> Mateusz
> gopher://gopher.viste.fr
>
Hi,
On bitreich.org the community started documenting some common
addiions/extensions in use today. Note that the RFC1436 mentions extending
types are OK and mentions using file extensions. We have discussed this changes
in our small community at bitreichcon.
It describes the rationale and sometimes historic context of some additions:
The current version can be found here:
gopher://bitreich.org/1/scm/gopher-protocol/file/gopher-extension.md.gph
--
Kind regards,
Hiltjo
Reply to: