RFCs/rfc-0002.ms

@@ -0,0 +1,200 @@
+\# This is a groff_ms(7) document. Render it with nroff -ms rfc-0002.ms | less.
+.TL
+MEOW RFC 0002: Text Formatting
+.AU
+afiw
+.AI
+MEOW Working Group
+.DA last edited on \*[DY]
+.nr PS 10
+.nr GROWPS 3
+.nr PSINCR 1.5p
+.AB
+This document describes a draft version of the text formatting language used by the MEOW messaging protocol.
+.AE
+.SH 1
+Status of this memo
+.PP
+This document is a draft and has not been adopted as part of the final MEOW specification. If adopted, it would
+obsolete the
+.CW Client-Text-Formatting.md
+proposal.
+.NH
+Introduction
+.PP
+Instant messaging protocols often provide a simple language for text formatting. The most common format
+used is a variant of Markdown. There are several problems with Markdown; it is underspecified and complex,
+and its origin makes it more suited to outputting HTML documents as compared to messages, which are usually
+short and unstructured. This document attempts to specify a simpler alternative to be used by MEOW clients.
+.NH
+Conventions used in this document
+.PP
+The term \*[Q]IETF RFC\*[U] followed by a number is to be interpreted as a reference to a RFC published by the
+Internet Engineering Task Force, as opposed to a MEOW Working Group RFC.
+.PP
+The key words \*[Q]MUST\*[U], \*[Q]MUST NOT\*[U], \*[Q]REQUIRED\*[U], \*[Q]SHALL\*[U], \*[Q]SHALL NOT\*[U],
+\*[Q]SHOULD\*[U], \*[Q]SHOULD NOT\*[U], \*[Q]RECOMMENDED\*[U], \*[Q]MAY\*[U], and \*[Q]OPTIONAL\*[U] in this
+document are to be interpreted as described in IETF RFC 2119.
+.NH
+Encoding
+.PP
+MEOW clients and servers MUST transmit all message data in the Network UNICODE format as described by IETF RFC
+5198. In addition, problematic UNICODE characters as defined by IETF RFC 9839 SHALL NOT be used.
+.NH
+Compatibility
+.PP
+MEOW clients SHOULD implement the following formatting directives, unless unable to do so due to limitations of
+the platform (e.g. for command-line clients). If a client does not implement a formatting directive, it SHOULD
+display the character sequences that would introduce or terminate it as ordinary characters.
+.PP
+MEOW clients SHOULD NOT implement any additional formatting directives not specified by this document, in order
+to prevent ecosystem fragmentation and display incompatibilities between clients.
+.NH
+Basic text styles
+.NH 2
+Italic text
+.PP
+A U+002A ASTERISK character, followed by a sequence of characters terminated with another asterisk SHOULD be
+interpreted by rendering the characters between the delimiters with an italic typeface, if applicable.
+.PP
+Clients running in a terminal emulator SHOULD use the
+.CW sitm
+terminfo capability string to determine the correct escape sequence.
+.NH 2
+Bold text
+.PP
+A U+0021 EXCLAMATION MARK character, followed by a sequence of characters terminated with another exclamation
+mark SHOULD be interpreted by rendering the characters between the delimiters with a bold typeface, if
+applicable.
+.PP
+Clients running in a terminal emulator SHOULD use the
+.CW bold
+terminfo capability string to determine the correct escape sequence.
+.NH 3
+Rationale
+.PP
+Using two asterisks for bold text is more common in other markdown languages, but as asterisks are already used
+for italic text, this would substantially complicate parsing.
+.NH 2
+Underlined text
+.PP
+A U+005F LOW LINE character, followed by a sequence of characters terminated with another low line SHOULD
+be interpreted by rendering the characters between the delimiters underlined, if applicable.
+.PP
+Clients running in a terminal emulator SHOULD use the
+.CW smul
+terminfo capability string to determine the correct escape sequence.
+.NH 2
+Monospace text
+.PP
+A U+0060 GRAVE ACCENT character, followed by a sequence of characters terminated with another grave accent
+SHOULD be interpreted by rendering the characters between the delimiters with a monospace typeface, if
+applicable. Other formatting directives in the sequence SHOULD NOT be interpreted in any way.
+.PP
+Clients running in a terminal emulator MAY instead display the text with a changed background colour, or
+without any special markup.
+.NH
+Advanced text styles
+.NH 2
+LaTeX
+.PP
+A U+0024 DOLLAR SIGN character, followed by a sequence of characters terminated with another dollar sign MAY be
+interpreted as LaTeX markup and rendered as such by the client.
+.NH 2
+Colour
+.PP
+A U+0025 PERCENT SIGN character, followed by a three- or six-digit hexadecimal colour code, or an
+implementation-defined symbolic colour name SHOULD be interpreted by changing the foreground colour of the
+following text to the closest possible shade, until the closing sequence consisting of two closing percent signs
+is encountered. Six-digit hexadecimal colour codes SHOULD be treated as sRGB web colours according to the W3C
+HTML and CSS specifications, and three-digit ones SHOULD be treated as shorthands for equivalent six-digit
+codes with every digit doubled.
+.PP
+The same holds for sequences beginning with the U+0026 AMPERSAND character and ending with two ampersands,
+except that the background colour should be changed instead.
+.PP
+Implementations SHOULD support the following symbolic colour names if they support displaying coloured text at
+all: black, red, green, yellow, blue, magenta, cyan, and white.
+.NH
+Links and references
+.NH 2
+User mentions
+.PP
+Clients SHOULD interpret a U+0040 COMMERCIAL AT character, followed by a sequence of characters forming a
+legal MEOW account name or identity name (to be defined in a future RFC) by notifying the user in some manner
+if the mention corresponds to their account name or one of their identity names. Clients MAY display the
+mention with an altered background or foreground colour, or apply other formatting changes.
+.NH 2
+Channel references
+.PP
+Clients SHOULD interpret a U+0023 NUMBER SIGN character, followed by a sequence of characters forming a legal
+MEOW channel name (to be defined in a future RFC) by navigating to the specified channel upon click or
+interaction. Clients MAY display the reference with an altered background or foreground colour, or apply other
+formatting changes.
+.NH 2
+URI links
+.PP
+Clients MAY interpret a sequence constituting a valid URI as specified by IETF RFC 3986 by opening or
+navigating to the specified resource upon click or interaction. Clients MAY display the reference with an
+altered background or foreground colour, or apply other formatting changes.
+.PP
+URIs with the
+.CW https://
+scheme SHOULD be supported, and SHOULD be visually distinguished.
+.NH
+Block formatting
+.NH 2
+Block quotes
+.PP
+A U+003E GREATER-THAN SIGN as the first character of a line SHOULD be interpreted by formatting the content
+of the line as an indented block quote, if applicable. Any UNICODE whitespace characters directly following it
+SHOULD be interpreted, and multiple consecutive lines beginning with the character SHOULD be treated as a single
+block.
+.NH 2
+Unordered lists
+.PP
+A U+002B PLUS SIGN as the first character of a line SHOULD be displayed as a bullet point (possibly as U+2022
+BULLET), if applicable. Any UNICODE whitespace characters directly following it SHOULD be intrepreted, and
+multiple consecutive lines beginning with the character MAY be visually grouped as a list.
+.NH 2
+Ordered lists
+.PP
+A sequence of lines beginning with strictly increasing numbers followed by a U+002E FULL STOP character MAY be
+visually grouped as a list by clients. The numbers themselves SHOULD NOT be changed.
+.NH 3
+Rationale
+.PP
+Using asterisks for bullet points/unordered lists is more common in other markdown languages, but as asterisks
+are already used for italic text, this would substantially complicate parsing.
+.NH 2
+Code blocks
+.PP
+Three or more U+0060 GRAVE ACCENT characters at the beginning of a line should be interpreted as starting a
+code block. A code block is terminated by an equal amount of grave accents on a line by itself, and should be
+rendered with a monospace typeface, if applicable. Other formatting directives in the block SHOULD NOT be
+interpreted in any way.
+.PP
+As per section
+.B 5.4 ,
+clients running in a terminal emulator MAY instead display the text with a changed background colour, or
+without any special markup.
+.PP
+The characters following the opening graves on the same line MAY be interpreted as a tag describing the
+programming language of the code block. Clients MAY higlight syntax elements within the code block according to
+the programming language tag.
+.NH
+The escape character
+.PP
+The U+005C REVERSE SOLIDUS character should be interpreted in the following way:
+.IP \[bu]
+When followed by a formatting character, that is a character that would have cause special formatting to be
+applied, the function of the formatting character SHOULD BE suppressed and the character SHOULD BE displayed
+normally, without the preceding reverse solidus;
+.IP \[bu]
+When followed by another reverse solidus character, a single reverse solidus SHOULD BE displayed as an ordinary
+character;
+.IP \[bu]
+When followed by an ordinary character, that is a character that this document does not specify a special
+formatting for, or a character indicating a formatting directive from this document that is unimplemented by
+the client due to platform limitations, both the reverse solidus and the character SHOULD both be displayed
+normally.