Other protocols/file-formats include:<p>- Gemini<p>- Spartan<p>- Scorpion<p>Gemini and Molerat use mandatory TLS. Scorpion uses optional TLS (with the same port number for TLS vs non-TLS, since the Client Hello message can always be distinguished from a valid request). Spartan has no TLS.<p>Gemini and Molerat do not use the userinfo component of the URL. Spartan allows it but has no way to send it to the server (why is that? That doesn't make sense to me). Scorpion allows the userinfo and if it is included, it can be sent to the server.<p>Molerat specification says that the fragment part of the URL is included in the request. However, I think that the fragment part would be for the client's use only.<p>Of the above, only Scorpion supports range requests (which are optional to implement); however, unlike HTTP, you can only specify a single range in a request (I think that specifying multiple ranges would overcomplicate it and isn't very useful anyways).<p>Gemini and Spartan do not include the length of the response, but Scorpion and Molerat do. However, the specification of Molerat is unclear if the length is mandatory or not. (In Scorpion it is optional, since the length might not be known by the server in the case of dynamic files.)<p>Molerat doesn't seems to have a way to send data with file formats other than Molerat forms (although it seems simple enough to extend the existing format), although Titan and Scorpion allow it. Spartan has no way to specify upload format either, and Spartan cannot distinguish zero-length uploads from a get request.<p>Molerat specification also doesn't seems to say if keys are case-sensitive or not (I guess that they are, but it is unclear).<p>Spartan also cannot distinguish query strings from uploads, although all of the other ones can distinguish it.<p>It also seem strange to me that although it uses a key/value list for responses instead of all on one line (the other protocols listed above do all use a single line for the status), that the "message" is used for purposes other than merely the message.<p>Molerat has a hash included in the response (although it is unclear if it is supposed to be mandatory or optional). Spartan and Gemini don't have any such thing. Scorpion has an optional "version code", although it is not used for caching; the version code is only used for handling edit conflicts, and optionally the client might compare the version code after making a range request to check if it needs to start over.<p>Molerat file format is more complicated than the others mentioned above and some parts are not entirely clear. It seems to be a superset of the features of Gemini. (Spartan also uses Gemini file format but adds an extra link type for requesting input.) (Scorpion uses a different file format; it (deliberately) does not have many of the features of Molerat format, but it does allow the possibility of specifying a different character encoding for each paragraph, and is designed to be easier to parse than Markdown and HTML.)<p>The example Molerat request in bash is wrong. The correct way would be:<p><pre><code> echo -n $'get example.com/resource\r\n\r\n'
</code></pre>
MacWright's suggestions about a clean start for the web has three rules: Rule #1 is don't make a subset. Rule #2 is don't make it compatible. Rule #3 is make it better for everyone (authors, readers, programmers, etc).<p>It seems to me that only Scorpion meets all three of these rules, while Gemini, Spartan, and Molerat, are only #2 and #3 but are not also #1.<p>I also think that it is useful for specifications to not themself require too many complicated specifications (including HTTP(S) and HTML) in order to be accessible. (For this reason, I wrote the Scorpion specification as a pure ASCII plain text document, which is the most portable kind of document file format. Fortunately, Gemini is also simple enough, but it requires TLS.)