[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

To evolve or not to evolve

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?


Reply to: