💾 Archived View for satch.xyz › misfin › proposed-misfin-c-9th-draft.gmi captured on 2024-07-08 at 23:20:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
-=-=-=-=-=-=-
by Martin Keegan (mk270), 2024-02-06
This document is a draft of a proposed version of the Misfin protocol, called Misfin(C). It may be referred to by the title above.
The language in the proposed specification focuses on unambiguously defining a conformant implementation, and avoids discussions of other matters, such as the merits or reasons for characteristics of Misfin(C) or Misfin(B), and comparisons between the two.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14, except that these terms do not appear in upper case.
Conformant Misfin(C) servers and clients shall follow the Misfin(B) specification except as modified below.
A Misfin(C) transaction shall be conducted solely over a virtual circuit established over TLS. The minimum permitted TLS version shall be version 1.2.
During the TLS handshake, the server must accept TLS connections from clients which are not proffering a client certificate.
Once a TLS connection has been established, the server shall not transmit data to the client, except to indicate a request timeout, until it has received at least one byte from the client.
The client's request shall be in the following form:
misfin://<MAILBOX>@<HOSTNAME><TAB><CONTENT-LENGTH><CR><LF><MESSAGE>
The MAILBOX and HOSTNAME shall be in the format prescribed by Misfin(B).
CONTENT-LENGTH and MESSAGE shall be as defined in the corresponding sections below.
The <MESSAGE> shall comprise a series of lines in UTF-8 text.
Each line shall be terminated by a newline marker, which is either <CR><LF>, or <LF> alone. <CR> must not appear in the message except where immediately followed by <LF>.
The message must have at lease three lines. The first three lines are to be treated as the metadata section, and any subsequent lines as the body section.
The metadata shall be on three separate lines, each terminated by <LF> or <CR><LF>.
Metadata shall be sent in the following order:
Where there is no metadata in respect of any of these three types, the corresponding line shall be the empty string, followed by the line terminator.
Where a list of multiple items is to be provided for any of the metadata lines, the items shall be separated by a comma: ",". No comma shall otherwise appear in any Misfin(C)-conformant metadata line. Where one or more consecutive <SPACE> characters appears before an item on a line (including the first such item), conformant implementations must disregard them.
The senders list shall be ordered from most recent sender/forwarder to least recent sender (the original sender). The addresses of forwarders or mailing lists may be prepended to the sender list.
Items in senders and recipients' lines shall comprise one or more addresses. An address shall be an RFC822-style address, optionally followed by a blurb. Where a blurb is present, it shall be separated from the RFC822-style address by a single space. Blurbs shall not contain commas or "@" symbols.
Timestamps in the timestamp line shall be in ISO8601 format, as per Misfin(B). Conformant implementations must use "Z" offset for indicating the (absence of a) time zone.
The message body shall be in Gemini text format.
Conformant servers must reject a body section that is not encoded as valid UTF-8.
The content length indicator must be in ASCII, decimal form. This specifies the length of the <MESSAGE> section of the request, including the final line terminator.
The maximum content length for Misfin(C) messages shall be 16384 bytes.
Conformant servers shall reject requests where the portion of the request up to and including the first <CR><LF> exceeds 1024 bytes.
No metadata line shall be longer than 1024 bytes, including the trailing <LF>
Conformant Misfin(C) servers must send responses as per the Misfin(B) specification.
Success responses (code 20) shall send the META field with the hash in lower case, with no colons or other delimiters. For the avoidance of doubt, the hash must be the fingerprint of the public key of the recipient of the message, which in the general case will be a distinct public key from that of the sender of the message or the server which receives it.
The META field shall not otherwise be used for sending structured or other machine-readable data to the client.
Where a server deems the client to have taken too long to send a request, it may treat this condition as though the client had sent an invalid request, and respond accordingly.
This document has emerged from discussions on the ##misfin IRC channel on libera.chat. It simply constitutes a proposal for discussion, implementation and experimentation. It does not purport to be endorsed by (and was developed without input from) Lem, the creator of Misfin.
This document is available under almost the same terms as the Gemini specification: CC-BY-ND 4.0.
This is a stricter licence than that applicable to the Misfin(B) specification, but this document was written from scratch and is not a derivative work of that specification nor of earlier drafts relating to Misfin(C) by other authors.
The original Lem spec is under a CC licence:
https://git.sr.ht/~lem/misfin/tree/master/item/COPYING
This document derives from the following succession of write-ups of Misfin(C):
Note of IRC meeting held on 2023-12-31
jmjl draft e82fa2e9-a8e9-44f5-924c-77301643f5c2
clseibold draft (withdrawn from publication, subsubmed into satchlj draft)