\# 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 2
Overstruck text
.PP
A U+007E TILDE character, followed by a sequence of characters terminated with another tilde SHOULD be
interpreted by rendering the characters between the delimiters overstruck, if applicable.
.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 2
Spoilers
.PP
A U+007C VERTICAL LINE character, followed by a sequence of characters terminated with another vertical line
SHOULD be interpreted by rendering the characters initially hidden, only revealing them when the user explicitly
interacts with the text area by e.g. clicking it or using a client command.
.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 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
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 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.