Gopher RFC update proposal

Encoding

N-001 (Clarification for "Line Terminators")

What is the "Gopher format" for line terminators? It is specified in the last paragraph that menus are required to use the CR/LF, but afterwards it is stated that other text resources should use the "Gopher format" (which wasn't defined).

N-002 (Proposal for "Gopher Menus")

I would personally state that UTF-8 should be allowed as an encoding for both menus and text files. It is backward compatible with ASCII, and non-UTF-8 capable clients can just display the bytes part of the non-ASCII characters which will either be understood by the terminal emulator or displayed as strange characters. (Such an extension will not break the protocol.)

Protocol

N-003 (Clarification for "Basic Gopher Transactions")

Shouldn't the client close the write side of the connection after writing the selector (and query parameters)? (TCP supports half-open connections.)

Symmetrically, what should the server do after reading the selector line?

• should it continue reading until the end-of-file (or a server defined limit), and either signal an error if any other content was read, either ignore the extra content;
• should it immediately close the read-side of the connection; (ignoring potential already buffered data, but impeding the client to send more data;)
• should it do nothing; (ignoring potential already buffered data, but blocking the client to send more data after the buffers fill;)

Such a clarification would allow further extensions, while not breaking the current clients and servers.

N-004 (Clarification for "Basic Gopher Transactions")

What is the absolute (i.e. MUST) and recommended (i.e. SHOULD) maximum sizes for a selector (including the query parameters)? (Perhaps 1024 bytes the absolute maximum, which will fit nicely in one packet.)

N-005 (Clarification for "Basic Gopher Transactions" and "Goher Menu")

What are the recommended syntaxes for selectors and query parameters? Perhaps state that they SHOLUD conform to an absolute path according to the URL specification, explicitly disallowing the plus + (used for Gopher+) or the hash # (used for anchors).

N-006 (Proposal for "Basic Gopher Transactions")

I would personally state that (in order to be compliant with Gopher+ clients) servers should ignore any extra tab-delimited fields (after the first one) in the request. Moreover I would state that if the query parameters start with a plus +, the server should issue an error.

Types

N-007 (Proposal for "Type Codes")

I would personally recommend a small set of currently useful item types that should be supported by clients, limited to those types that make sens in the current context (i.e. 2015) and excluding the historical ones.

For example I would limit to the following:

• MUST: 0 (text), 1 (menu), 7 (query);

• MUST: e (error), i (informational);

• SHOULD: 5 (binary archive), 9 (binary archive), h (HTML);

• COULD: I (image), s (audio), ; (video);

• COULD: 8 (telnet);

N-008 (Proposal for "Gopher Menus")

Given that now Telnet is almost obsolete, taken over by SSH, perhaps the item type 8 (Telnet) could be extended to allow other flavours of remote shell. For example the selector could be reused to specify the actual protocol, like say:

• telnet for actual Telnet sessions;

• ssh for SSH sessions;

If a client doesn't correctly interpret the selector, it will fallback to Telnet, and in case of SSH the server already sends a welcome message clearly identifying it as an SSH server.

N-009 (Proposal for "Type Codes")

Perhaps the maintenance of the types should be delegated to IANA.

Errors

N-010 (Clarification for "Errors")

It is unclear if the "error menu" is allowed to contain other entries beside the first one that must be of type 3 (error).

N-011 (Clarification for "Errors")

It is also unclear how an error response is to be detected by a client:

• Should the client grep through the incoming stream to see if it matches a line that resembles an error menu entry?

• Should the client read the entire contents (or perhaps until the first kilobyte) and if the **whole** content matches an error menu entry

Menus

N-012 (Clarification for "Gopher Menus")

Are the clients required to ignore any other fields after the port?

N-013 (Clarification for "Gopher Menus")

What are the absolute (i.e. MUST) and recommended (i.e. SHOULD) maximum sizes either:

• the name field (perhaps 1024 and 4096);
• the selector field (perhaps 1024 and 4096);
• the host field (perhaps 255 and 1024);
• the port field (perhaps 255 and 1024);
• the entire line (perhaps 4096 and 65536);

Similarly what are the absolute and recommended maximum number of menu entities? (Perhaps recommended up to 128 entities, or up to 128 KiB, without an absolute maximum.)

Host

N-014 (Clarification for "Gopher Menus")

Are IP's allowed? If so explicitly require the support for both IPv4 and IPv6 (full and shorthand syntax).

N-015 (Clarification for "Gopher Menus")

Require the support of "rooted" FQDN names (i.e. those terminating in a dot .). (Overbite seems to break on these.)

N-016 (Clarification for "Gopher Menus")

What are the absolute and recommended maximum sizes for host fields? (Perhaps 255 as recommended, the maximum size for a DNS record name, and 1024 the absolute maximum.)

N-017 (Proposal for "Gopher Menus")

I would personally state that host fields SHOULD not include a colon : (unless they are IPv6 addresses), leaving the door open to future extensions by using a URI-like syntax to denote how such a host should be resolved (like for example DHT: for some distributed hash-table like solution, etc.).

Port

N-018 (Clarification for "Gopher Menus")

Should the port field be parsed as a numeric value or as text (see the next note)? (If text what should be the absolute and recommended maximum sizes, perhaps similar to the host field, i.e. 255 and 1024 bytes.)

N-019 (Proposal for "Gopher Menus")

I would personally state that ports SHOULD be treated as strings for the purpose of parsing (else considered as 0), and only when actually used to be parsed as integers, thus leaving the door open to future extensions will allow further extensions by using URI-like syntax to denote the transport and / or protocol used to access the host (like for example Gopher over TLS by prefixing the port by tls:, etc.)

Miscellaneous

N-020 (Editorial)

Throughout the document, it is perhaps better to refer to "files" as "resources" (especially since some of them are dynamically generated).

N-021 (Editorial for "Line Terminators")

Perhaps the historical details about the line terminators could be trimmed as it doesn't contribute much to the Gopher standard. (I would just stick in listing the four possible line terminations, denoting which is the "standard" one, and how to handle the rest.)

N-022 (Editorial for "Gopher Policy Files")

Perhaps the section on policy files could be moved at the end (before the security considerations section which is currently missing), just listing which are the files and their selectors.

Meanwhile the actual description of these policy files could be moved into appendixes, especially since they are not mandatory nor part of the actual protocol.

N-023 (Correction for "Linking to Web Addresses")

The given example HTML response that should redirect the user, incorrectly uses the paragraph element <p> as a line break. Either use <p> just after the <body> (thus before the first text), or replace it with <br>. (There is an extra > at the end of the line The URL linked is: ....)

N-024 (Proposal about HTTP compatibility)

I would personally state that if servers encounter selectors that resemble HTTP requests, they should reply with a similar HTML page (like the above) stating that this is a Gopher server and pointing the user in the right direction (i.e. either a HTTP compliant server or a Gopher compliant client.)

N-025 (Proposal about caching)

I would personally state that the clients are allowed (i.e. COULD) cache the answer of a server (unless an error was identified) for a certain amount of time depending on the requested type and response size. (Obviously a client that implements caching should also give an option to the user to explicitly request a refresh.)

For example (first match wins):

• any response larger than 1 MiB, at least 1 hour; (or not cache at all)
• any response larger than 16 MiB, at least 6 hours; (or not cache at all)

• small menus (< 128 entries) and text files (< 16 KiB), about 30 seconds;

• any response smaller 16 KiB, about 1 minute;
• any response smaller than 128 KiB, about 6 minutes;
• any response smaller than 1 MiB, about 30 minutes;

This would save quite some load on servers while the users just "browse" around hitting the same menus again and again.

Perhaps such parameters could be encoded in the CAPS file.

N-026 (Editorial about updates to RFC)

It would be nice to have a whole section that quickly summarizes which are the main additions and differences vis-a-vis the existing RFC's (one phrase per item). (There is a paragraph in the "Goals" section, but everything is lumped together in there.)

For example:

• TITLE information lines;

• URL links;

• new item types;
• each of the policy files;
• Gopher+ compatibility;