Submit RFC 0002
This commit is contained in:
parent
3d0d5b2251
commit
05e73ad3c0
1 changed files with 200 additions and 0 deletions
200
RFCs/rfc-0002.ms
Normal file
200
RFCs/rfc-0002.ms
Normal file
|
|
@ -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.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue