It might be an idea to explain what the purpose of text://protocol is to help others evaluate whether this is important to them. I found the description at
https://textprotocol.org to be ... opaque.
Something like this
text://protocol is a new URI scheme for HTTP-like client-server functionality, with a simpler client and server, and much reduced functionality.
A client connects to a text://protocol server at a specific network address (domain name or IP address and optional port).
- eg. txt.textprotocol.org, port 1961
The client sends a text://protocol request for a specific object. The request is always exactly 1 line, giving the full URI.
- eg. text://txt.textprotocol.org/icon.png
The server responds with a reponse-code line, then the data associated with the object. There are 3 types of response-code lines
- '20', followed by content-type, indicates success
- '30', followed by redirect destination, indicates a redirect
- '40 NOK', perhaps followed description, indicates a failure
There is no blank line after the response-code line; the data starts on the next line (and can be binary data).
Normally, the content-type of the response is 'text/plain; charset=utf-8' but the example server also serves an icon as an 'image/png: charset=binary'. Presumably, a different server could send other content-types too.
A link within the text data is introduced using the character sequence '=>'. (See note [1].)
Examples
- nc -C txt.textprotocol.org 1961 <<< 'text://txt.textprotocol.org/'
- Shows the full response at the 'home page'
- nc -C txt.textprotocol.org 1961 <<< 'text://txt.textprotocol.org/icon.png' | tail -n+2 | display
- tail -n+2 strips off the first line (response-code line) of the response
- display is part of the imagemagick suite, and automatically recognises the byte-stream as a PNG image
Note [1]: The home page suggests that there is a convention that a link within the text is indicated with the characters '=>'. This is a trivial amount of mark-up, but suggests that this is not actually Just Plain Text. The common content-types 'text/html', 'text/css', 'text/csv', 'text/xml' give a clue as to how to interpret the text. This suggests that the content type should not be 'text/plain', but rather something like 'text/x.textprotocol'
Hope this helps someone
Stephen Irons
