Having previously 1, 2 pondered request and response formats for a hypothetical protocol which is a bit more powerful than gopher but a lot less powerful than full-blown HTTP, now I want to turn my attention to the question of navigation, or how documents served by this protocol can link to one another.
One option, which I briefly mentioned in Part II, is to keep something like the gopher menu, and give it an item type of some sort which is conveyed in the response header. This approach retains gopher's hard conceptual division between navigation and content which, as I wrote about yet earlier 3, I am not sure is something we necessarily want, but it's worthy of consideration. Even if we retain the idea of a "menu type", we don't necessarily need to user gopher's exact format. Let's think about that.
A standard gopher menu line looks like this:
Why aren't the item type and item name separated by a tab? I'm not sure. If you know, or even just have a hunch, please let me know!
UPDATE 17/06/2019: Visiblink has offered an explanation for this which is so obviously correct that I'm embarrassed for having asked! Gopher item types are guaranteed to be one character long, so there is no need for a tab to unambiguously signal the border between item type and item name. It'd just be a wasted byte.
An obvious update which could be made here is to take advantage of the fact that between now and gopher was first invented, URLs have been invented! We don't need to specify the selector (path), host and port separately, we have a standard way to build that into one string, and every modern programming language has libraries for parsing/buiding them. At first glance this might seem like pointless modernisation for its own sake, just replacing tabs with slashes and colons, but there's one very important extra bit of power that switching to URLs brings, and that's the ability to specify the protocol. Standard gopher menu items can only link to other gopher items, not e.g. to items shared via HTTP(S), FTP, or anything else. I don't think this is necessarily a bad thing, for the record, but there is good evidence that people want to be able to link to arbitrary non-gopher protocols, in the form of widely adopted ugly hack of 'h' type items whose selector is a URL with a "URL:" prefix. Sufficiently smart clients recognise these, extract the URL and act appropriately (if they support the additional protocol), while dumb ones ask the gopher server for a selector beginning with "URL:", which the server recognises and responds to by serving a tiny HTML page with a redirect to the URL. Just putting URLs directly into menus would let us side-step this little dance. It would also, incidentally, solve the problem that there's no way in a standard gopher menu to convey whether or not TLS should be used 4, by allowing the use of gophers:// URLs. So, we might use something like this as a menu item in a new protocol:
---------- <ITEM TYPE><TAB><ITEM NAME><TAB><URL> ----------
Yep, I put a tab between item type and item name. Not sorry.
In Part II I advocated for including item types in server responses, which arguably makes them redundant here. We could simplify these lines even further by just including a name and a URL. I actually kind of like the idea that you know what kind of thing a document is before you fetch it, so you can use that information to decide whether or not you want to fetch it. But it's also kind of weird. That information can only authoritatively come from the server hosting it, but having them in menus has arbitrary third parties declaring that information. I don't really know how I feel on this for now.
An alternative to keeping the menu system would be to take the web approach of drawing no distinction between content and navigation and using some kind of markup language with support for inline links which can facilitate both menus and content. I think this is conceptually simpler, although it brings with it the huge can of worms of choosing one particular markup language. If this new protocol is to be vaguely gopherlike I think we'd all agree the language should be simple and minimal and human-readable even when looked at as plain text. Something like, but not necessarily, MarkDown. With this approach you'd build a very gopher-like menu with something like this:
With this approach, there's no way to convey item type in a menu. This doesn't seem to be a big problem for the web, although it would stop us from easily keeping something like gopher's search system, which is based on a special item type. To implement searches without that item type would require something similar to HTML
Soweli Lukin Issues Alex Schroeder