RFC format - Revision history

Alexander: Add colours, tt, kbd and inline code

2026-02-13T01:25:01Z

Add colours, tt, kbd and inline code

@@ Line 248: / Line 248: @@
 | <tt>0051</tt>
 |-
-| colspan="2" style="background-color:rgba(162,169,177,0.5);font-style:italic;font-size:90%;text-align:center" | <tt>0052</tt>&ndash;<tt>0077</tt> are undefined
+| Start of explicit teletype
 |-
 | Figure 5 lines, &frac14; width

Alexander: /* General formatting */ add page breaks to even and odd pages

2025-04-03T16:08:04Z

General formatting: add page breaks to even and odd pages

← Older revision		Revision as of 16:08, 3 April 2025
Line 241:		Line 241:
	\| Whole paragraph indent		\| Whole paragraph indent
	\| <tt>0047</tt>		\| <tt>0047</tt>
			\|-
			\| Page break to even
			\| <tt>0050</tt>
			\|-
			\| Page break to odd
			\| <tt>0051</tt>
			\|-
			\| colspan="2" style="background-color:rgba(162,169,177,0.5);font-style:italic;font-size:90%;text-align:center" \| <tt>0052</tt>–<tt>0077</tt> are undefined
	\|-		\|-
	\| Figure 5 lines, ¼ width		\| Figure 5 lines, ¼ width

Alexander: rework the encoding format to be friendlier to combinatorial efficiency

2025-03-03T06:17:20Z

rework the encoding format to be friendlier to combinatorial efficiency

← Older revision		Revision as of 06:17, 3 March 2025
Line 14:		Line 14:
	! Enc.		! Enc.
	! Dec.		! Dec.
	\|-
	~~\| End of Text~~
	~~\| <tt>ETX</tt>~~
	~~\| <tt>0x03</tt>~~
	~~\| <tt>0x0</tt>~~
	\|-
	~~\| End of Transmission~~
	~~\| <tt>EOT</tt>~~
	~~\| <tt>0x04</tt>~~
	~~\| <tt>0x1</tt>~~
	\|-
	~~\| Enquiry~~
	~~\| <tt>ENQ</tt>~~
	~~\| <tt>0x05</tt>~~
	~~\| <tt>0x2</tt>~~
	\|-		\|-
	\| Data Link Escape		\| Data Link Escape
	\| <tt>DLE</tt>		\| <tt>DLE</tt>
	\| <tt>0x10</tt>		\| <tt>0x10</tt>
	\| <tt>~~0x3~~</tt>		\| <tt>0x0</tt>
	\|-		\|-
	\| Device Control 1		\| Device Control 1
	\| <tt>DC1</tt>		\| <tt>DC1</tt>
	\| <tt>0x11</tt>		\| <tt>0x11</tt>
	\| <tt>~~0x4~~</tt>		\| <tt>0x1</tt>
	\|-		\|-
	\| Device Control 2		\| Device Control 2
	\| <tt>DC2</tt>		\| <tt>DC2</tt>
	\| <tt>0x12</tt>		\| <tt>0x12</tt>
	\| <tt>~~0x5~~</tt>		\| <tt>0x2</tt>
	\|-		\|-
	\| Device Control 3		\| Device Control 3
	\| <tt>DC3</tt>		\| <tt>DC3</tt>
	\| <tt>0x13</tt>		\| <tt>0x13</tt>
	\| <tt>~~0x6~~</tt>		\| <tt>0x3</tt>
	\|-		\|-
	\| Device Control 4		\| Device Control 4
	\| <tt>DC4</tt>		\| <tt>DC4</tt>
	\| <tt>0x14</tt>		\| <tt>0x14</tt>
	\| <tt>~~0x7~~</tt>		\| <tt>0x4</tt>
			\|-
			\| Enquiry
			\| <tt>ENQ</tt>
			\| <tt>0x05</tt>
			\| <tt>0x5</tt>
	\|-		\|-
	\| Synchronous Idle		\| Synchronous Idle
	\| <tt>SYN</tt>		\| <tt>SYN</tt>
	\| <tt>0x16</tt>		\| <tt>0x16</tt>
	\| <tt>~~0x8~~</tt>		\| <tt>0x6</tt>
	\|-		\|-
	\| End of Transmission Block		\| End of Transmission Block
	\| <tt>ETB</tt>		\| <tt>ETB</tt>
	\| <tt>0x17</tt>		\| <tt>0x17</tt>
	\| <tt>~~0x9~~</tt>		\| <tt>0x7</tt>
	\|-		\|-
	\| Cancel		\| Cancel
	\| <tt>CAN</tt>		\| <tt>CAN</tt>
	\| <tt>0x18</tt>		\| <tt>0x18</tt>
	\| <tt>~~0xA~~</tt>		\| <tt>0x8</tt>
	\|-		\|-
	\| End of Medium		\| End of Medium
	\| <tt>EM</tt>		\| <tt>EM</tt>
	\| <tt>0x19</tt>		\| <tt>0x19</tt>
			\| <tt>0x9</tt>
			\|-
			\| End of Text
			\| <tt>ETX</tt>
			\| <tt>0x03</tt>
			\| <tt>0xA</tt>
			\|-
			\| End of Transmission
			\| <tt>EOT</tt>
			\| <tt>0x04</tt>
	\| <tt>0xB</tt>		\| <tt>0xB</tt>
	\|-		\|-

Alexander: /* Figures */ new section

2025-03-03T06:02:19Z

Figures: new section

Show changes

Alexander: /* Rendering */ typo

2025-02-21T13:54:40Z

Rendering: typo

← Older revision		Revision as of 13:54, 21 February 2025
Line 244:		Line 244:

	==Rendering==		==Rendering==
	Regardless of whether the target medium is print or digital, the RFC format is still meant to be a monospaced, paper-friendly medium that never exceeds 72 columns in width. Since RFC is page-aware, unlike TTY, it sets a maximum page height of 55 rows – this leaves 2 header rows with 1 spacer row and 1 footer row with 1 spacer row for 50 ~~columns~~ of content per page.		Regardless of whether the target medium is print or digital, the RFC format is still meant to be a monospaced, paper-friendly medium that never exceeds 72 columns in width. Since RFC is page-aware, unlike TTY, it sets a maximum page height of 55 rows – this leaves 2 header rows with 1 spacer row and 1 footer row with 1 spacer row for 50 rows of content per page.

	[[Category:Sirius DOS components]][[Category:Byblos components]]		[[Category:Sirius DOS components]][[Category:Byblos components]]

Alexander: /* Rendering */ new section

2025-02-21T09:17:19Z

Rendering: new section

← Older revision		Revision as of 09:17, 21 February 2025
Line 242:		Line 242:
	===Shadows===		===Shadows===
	The RFC format employs a simple rendering hatchet called '''shadows'''. The basic action of a shadow is, from its beginning mark to its end, it hides the text encased within from rich renderings of the document; this is called a '''hard shadow'''. A softer variant of this exists which are called '''shadow bridges''' – these are used to interlink a hyperlink or internal link's display text to its target destination, providing a semantic connection and a hiding of punctuation that would be needed in plain text for legibility, such as spacing and parentheses. Shadows provide a concise and simple way to hide plain text boilerplate from rich renderings of RFC documents while still providing them for dumb formatting strippers to create plain text renditions as the authors intended them without having to do any high-level reconstructions.		The RFC format employs a simple rendering hatchet called '''shadows'''. The basic action of a shadow is, from its beginning mark to its end, it hides the text encased within from rich renderings of the document; this is called a '''hard shadow'''. A softer variant of this exists which are called '''shadow bridges''' – these are used to interlink a hyperlink or internal link's display text to its target destination, providing a semantic connection and a hiding of punctuation that would be needed in plain text for legibility, such as spacing and parentheses. Shadows provide a concise and simple way to hide plain text boilerplate from rich renderings of RFC documents while still providing them for dumb formatting strippers to create plain text renditions as the authors intended them without having to do any high-level reconstructions.

			==Rendering==
			Regardless of whether the target medium is print or digital, the RFC format is still meant to be a monospaced, paper-friendly medium that never exceeds 72 columns in width. Since RFC is page-aware, unlike TTY, it sets a maximum page height of 55 rows – this leaves 2 header rows with 1 spacer row and 1 footer row with 1 spacer row for 50 columns of content per page.

	[[Category:Sirius DOS components]][[Category:Byblos components]]		[[Category:Sirius DOS components]][[Category:Byblos components]]

Alexander: Created page with "The '''RFC format''' is a renderer-agnostic structured document format built using ASCII C0 control codes as a superset of the TTY text format. It uses other C0 control codes not employed by printers (and thereby not known to TTY) to create rich document structure otherwise attained with advanced systems such as Troff and LaTeX. The format does this instead of providing a meta syntax like Markdown, RTF or HTML so that it can satisfy its design constraint o..."

2025-02-21T09:09:49Z

Created page with "The '''RFC format''' is a renderer-agnostic structured document format built using ASCII C0 control codes as a superset of the TTY text format. It uses other C0 control codes not employed by printers (and thereby not known to TTY) to create rich document structure otherwise attained with advanced systems such as Troff and LaTeX. The format does this instead of providing a meta syntax like Markdown, RTF or HTML so that it can satisfy its design constraint o..."

New page

The '''RFC format''' is a renderer-agnostic structured document format built using ASCII C0 control codes as a superset of the [[TTY format|TTY text format]]. It uses other C0 control codes not employed by printers (and thereby not known to TTY) to create rich document structure otherwise attained with advanced systems such as Troff and LaTeX. The format does this instead of providing a meta syntax like Markdown, RTF or HTML so that it can satisfy its design constraint of being legible as TTY formatted ASCII text if all superset control codes are blindly (as in, without any parsing knowledge required) stripped out.

The recommended file extension for these documents is <code>.rfc</code>. The magic number all RFC files should begin with is, in hexadecimal, <code>06 15 06 15</code>, representing two interleaved pairs of ASCII <tt>ACK</tt> and <tt>NAK</tt> C0 control codes. The RFC format reserves all C0 control codes not used by the TTY format except for <tt>NUL</tt> (<tt>0x00</tt>), <tt>BEL</tt> (<tt>0x07</tt>), <tt>SUB</tt> (<tt>0x1A</tt>) and <tt>ESC</tt> (<tt>0x1B</tt>).

The RFC format is called as such because it is designed to mimic the production of the [//archive.ph/3jZoc IETF's RFC XML]. It is not technically related to any of the IETF's tools for producing or validating RFCs.

==Embed encoding==
Sixteen extraneous ASCII C0 control codes are hijacked as a binary encoding medium so that each 7-bit ASCII character provides 4 bits of arbitrary binary data:

{| class="wikitable"
|-
! Character name
! Code
! Enc.
! Dec.
|-
| End of Text
| <tt>ETX</tt>
| <tt>0x03</tt>
| <tt>0x0</tt>
|-
| End of Transmission
| <tt>EOT</tt>
| <tt>0x04</tt>
| <tt>0x1</tt>
|-
| Enquiry
| <tt>ENQ</tt>
| <tt>0x05</tt>
| <tt>0x2</tt>
|-
| Data Link Escape
| <tt>DLE</tt>
| <tt>0x10</tt>
| <tt>0x3</tt>
|-
| Device Control 1
| <tt>DC1</tt>
| <tt>0x11</tt>
| <tt>0x4</tt>
|-
| Device Control 2
| <tt>DC2</tt>
| <tt>0x12</tt>
| <tt>0x5</tt>
|-
| Device Control 3
| <tt>DC3</tt>
| <tt>0x13</tt>
| <tt>0x6</tt>
|-
| Device Control 4
| <tt>DC4</tt>
| <tt>0x14</tt>
| <tt>0x7</tt>
|-
| Synchronous Idle
| <tt>SYN</tt>
| <tt>0x16</tt>
| <tt>0x8</tt>
|-
| End of Transmission Block
| <tt>ETB</tt>
| <tt>0x17</tt>
| <tt>0x9</tt>
|-
| Cancel
| <tt>CAN</tt>
| <tt>0x18</tt>
| <tt>0xA</tt>
|-
| End of Medium
| <tt>EM</tt>
| <tt>0x19</tt>
| <tt>0xB</tt>
|-
| File Separator
| <tt>FS</tt>
| <tt>0x1C</tt>
| <tt>0xC</tt>
|-
| Group Separator
| <tt>GS</tt>
| <tt>0x1D</tt>
| <tt>0xD</tt>
|-
| Record Separator
| <tt>RS</tt>
| <tt>0x1E</tt>
| <tt>0xE</tt>
|-
| Unit Separator
| <tt>US</tt>
| <tt>0x1F</tt>
| <tt>0xF</tt>
|}

This 4-bit medium is then employed to harbour an MSB sentinel variable-length integer encoding format: each 7-bit ASCII character contains 3 bits of meaningful information, while the high fourth bit is used to indicate whether the control character immediately following the current one should be collated with it as a single number. As with most variable-width binary encodings, it is invalid and undefined when control sequences are not properly encoded; they should always have zero or more of the above sixteen control characters with the high bit set in direct sequence followed by one and only one such control characters where the high bit is LOW.

==Rich format==
The rich format is paragraph-oriented and does not recognise any semantic distinction between whitespace characters; Line Feed <tt>0x0A</tt>, Carriage Return <tt>0x0D</tt> and Space <tt>0x20</tt> are all equivalent to one another. Parsing will collapse multitudes of such spaces into one inside paragraphs and conjoin source lines spanning many physical lines into one logical line before rendering them into monotype again with 72 characters/line.

===Header for metadata===
If an RFC format parser encounters an ASCII Start of Heading <code>SOH</code> before seeing any visible characters (including spacing) in the stream, it will parse it as a heading metadata block. Fields are simple ASCII text separated by CRLF pairs, making them dumb-printable:
# Full document title
# Author name
# Author address
# Author telephone
# Author e-mail
# Copyright date
# Copyright assignment
# Licence

Omitting any of the fields is done by leaving them empty. They are parsed in order, and therefore there should always be exactly '''seven''' CRLF pairs in a heading metadata block. This block is then terminated by an ASCII Start of Text <code>STX</code> character, after which the normal document text and whatever command formatting it bears appears immediately until {{expl|EOF|end of file}}. As a whole, this header is optional.

===General formatting===
The number encoded in this way is, once decoded and in memory, interpreted as a formatting command. Parsing at this point should be forgiving; for example, excessive closing commands should be ignored. Here is a table of commands with their encodings in octal:

{| class="wikitable"
|-
! Command description
! Number
|-
| Begin heading, level 1
| <tt>001</tt>
|-
| Begin heading, level 2
| <tt>002</tt>
|-
| Begin heading, level 3
| <tt>003</tt>
|-
| Begin heading, level 4
| <tt>004</tt>
|-
| Begin heading, level 5
| <tt>005</tt>
|-
| Begin heading, level 6
| <tt>006</tt>
|-
| End heading (relative)
| <tt>007</tt>
|-
| Begin code block
| <tt>010</tt>
|-
| End code block
| <tt>011</tt>
|-
| Begin block quote
| <tt>012</tt>
|-
| End block quote
| <tt>013</tt>
|-
| Begin block quote credit
| <tt>014</tt>
|-
| End block quote credit
| <tt>015</tt>
|-
| Begin hard shadow
| <tt>016</tt>
|-
| End hard shadow
| <tt>017</tt>
|-
| Begin hyperlink display text
| <tt>020</tt>
|-
| End hyperlink display text
| <tt>021</tt>
|-
| Begin hyperlink shadow bridge
| <tt>022</tt>
|-
| End hyperlink shadow bridge
| <tt>023</tt>
|-
| Begin hyperlink URI
| <tt>024</tt>
|-
| End hyperlink URI
| <tt>025</tt>
|-
| Begin centred text
| <tt>026</tt>
|-
| Begin right-aligned text
| <tt>027</tt>
|-
| Begin justified text
| <tt>030</tt>
|-
| Revert to left-aligned text
| <tt>031</tt>
|-
| Render table of contents
| <tt>032</tt>
|-
| Begin internal link target ident
| <tt>033</tt>
|-
| End internal link target ident
| <tt>034</tt>
|-
| Begin internal link display text
| <tt>035</tt>
|-
| End internal link display text
| <tt>036</tt>
|-
| Begin internal link shadow bridge
| <tt>037</tt>
|-
| End internal link shadow bridge
| <tt>040</tt>
|-
| Begin internal link reference ident
| <tt>041</tt>
|-
| End internal link reference ident
| <tt>042</tt>
|-
| Paragraph break
| <tt>043</tt>
|-
| Line break
| <tt>044</tt>
|-
| Begin all capitals
| <tt>045</tt>
|-
| End all capitals
| <tt>046</tt>
|-
| Whole paragraph indent
| <tt>047</tt>
|}

===Shadows===
The RFC format employs a simple rendering hatchet called '''shadows'''. The basic action of a shadow is, from its beginning mark to its end, it hides the text encased within from rich renderings of the document; this is called a '''hard shadow'''. A softer variant of this exists which are called '''shadow bridges''' – these are used to interlink a hyperlink or internal link's display text to its target destination, providing a semantic connection and a hiding of punctuation that would be needed in plain text for legibility, such as spacing and parentheses. Shadows provide a concise and simple way to hide plain text boilerplate from rich renderings of RFC documents while still providing them for dumb formatting strippers to create plain text renditions as the authors intended them without having to do any high-level reconstructions.

[[Category:Sirius DOS components]][[Category:Byblos components]]