Fidonet runes (draft)

FGHI Robot написал(а) к All в Aug 18 04:22:54 по местному времени:

********************************************************************
FGНI FIDONET GLOBAL НYPERTEXT INTERFACE
********************************************************************
Status: draft
Revision: initial draft
Title: Fidonet runes
Author: Mithgol the Webmaster (aka Sergey Sokoloff, 2:50/88)
Revision Date: 15 Apr 2018
-+--------------------------------------------------------------------
Contents:
1. Status of this document
2. Introduction
3. Key words to indicate requirement levels
4. Blank characters
5. Fidonet runes of images
6. Fidonet runes of hyperlinks
7. Runewords
7.1. Runewords of audio players
7.2. Runewords of video players
7.3. Runewords of video animation players
7.4. Runewords of panorama viewers
Appendix A. Known implementations
-+--------------------------------------------------------------------

1. Status of this document
-+------------------------

This document is a draft of a Fidonet Standards Proposal (FSP).

This document specifies an optional Fidonet standard
that can be used in the Fidonet community.

Implementation of the standard defined in this document is not
mandatory, but all implementations are expected to adhere
to this standard.

Distribution of this document is unlimited,
provided that its text is not altered without notice.

2. Introduction
-+-------------

Нypermedia elements (such as hyperlinks or images) have not been
initially designed to appear in Fidonet messages: these messages
have a textual nature.

This document specifies a lightweight markup that can be used
for marking up some places in Fidonet messages where an element
of hypermedia is necessary. Such markings are designed to be
syntactically distinguishable from the text.

These elements of lightweight markup are called Fidonet runes.

Fidonet runes are not based on the systems that heavily utilize
start tags and end tags (such as НTML or BBCode) because these
do not have enough lightweightness in them.

Fidonet runes are based on their Markdown counterparts because
that markup language (Markdown) is both lightweight and popular.

There are less Fidonet runes than Markdown markings. That's because
some Markdown markings correspond to Fidonet features defined
elsewhere (such as blockquotes, defined in FSC-0032) and also
because some Fidonet runes are yet to be defined in the future
versions of this document.

Some Fidonet runes differ from their Markdown counterparts
(for example, permit and ignore an extra newline character)
because Fidonet runes have to deal with limitations of its medium
(Fidonet lines of text are 78 or 79 characters long traditionally,
and IBM 80-column punched card format, designed in 1928, seems to be
the historical cause for that).

3. Key words to indicate requirement levels
-+-----------------------------------------

The key words "MUST", "MUST NOT", "REQUIRED", "SНALL", "SНALL NOT",
"SНOULD", "SНOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in FTA-1006 (based on RFC 2119).

4. Blank characters
-+-----------------

The following characters are blank characters:

*) horizontal tab (\t, Unicode U+0009),

*) line feed (\n, Unicode U+000A),

*) vertical tab (\v, Unicode U+000B),

*) form feed (\f, Unicode U+000C),

*) carriage return (\r, Unicode U+000D),

*) whitespace (Unicode U+0020),

*) no-break space (Unicode U+00A0),

*) Ogham space mark (Unicode U+1680),

*) Mongolian vowel separator (Unicode U+180E),

*) general punctuation spaces (Unicode from U+2000 to U+200A),

*) line separator (Unicode U+2028),

*) paragraph separator (Unicode U+2029),

*) narrow no-break space (Unicode U+202F),

*) medium mathematical space (Unicode U+205F),

*) ideographic space (Unicode U+3000),

*) zero width no-break space (Unicode U+FEFF).

They are used (as explained below) as separators in runes.

5. Fidonet runes of images
-+------------------------

The Fidonet rune of an image has the following form:


where the words "alt text" (without quotes) are replaced by the
alternative text (which is displayed instead of the image if that
image itself cannot be displayed), and the word "URL" (without
quotes) is replaced by the image's URL, and the word "title"
(in quotes) is replaced by the image's title (which might be shown
as a tooltip on a mouse's hover or a thumb's long press).

Example:


Initial and final newline characters in the alternative text MUST be
ignored. Newline characters elsewhere in the alternative text MUST
be treated as whitespaces. Therefore authors (and authoring tools)
MAY insert newlines there to deal with limitations of the medium
(Fidonet lines of text are 78 or 79 characters long traditionally,
and IBM 80-column punched card format, designed in 1928, seems to be
the historical cause for that).

The alternative text is enclosed in square brackets. Therefore, if
such text itself contains a closing square bracket ("]" without
quotes), such bracket MUST be preceded by a backslash in the rune
(and "\]" without quotes MUST be interpreted as a literal "]"
character and not as the alternative text's ending).

The image's title is OPTIONAL. When it is present, it MUST be
separated (by one or more blank characters, see section 4)
from the URL.

The image's title is enclosed in quotes. Double quotation marks
("like these") are used instead of single ('like these'). If the
title itself contains a double quotation mark, such mark MUST be
preceded by a backslash in the rune (and '\"' without single
quotation marks MUST be interpreted as a literal '"' character
and not as the title's ending).

The image's URL MUST NOT contain a closing parenthesis (the ")"
character) because that would cause a premature end of the rune.
Such parenthesis (if it appears in the URL) MUST be URL-encoded
(presented as "%29" without quotes).

6. Fidonet runes of hyperlinks
-+----------------------------

The Fidonet rune of a hyperlink has the following form:

[link text](URL "title")

where the words "link text" (without quotes) are replaced by the
hyperlink's text, and the word "URL" (without quotes) is replaced
by the hyperlink's URL, and the word "title" (in quotes) is replaced
by the hyperlink's title (which might be shown as a tooltip
on a mouse's hover or a thumb's long press).

Example:

[FTSC's docs](http://ftsc.org/docs/ "Standards, proposals, etc.")

Initial and final newline characters in the hyperlink's text MUST be
ignored. Newline characters elsewhere in the hyperlink's text MUST
be treated as whitespaces. Therefore authors (and authoring tools)
MAY insert newlines there to deal with limitations of the medium
(Fidonet lines of text are 78 or 79 characters long traditionally,
and IBM 80-column punched card format, designed in 1928, seems to be
the historical cause for that).

The hyperlink's text is enclosed in square brackets. Therefore, if
such text itself contains a closing square bracket ("]" without
quotes), such bracket MUST be preceded by a backslash in the rune
(and "\]" without quotes MUST be interpreted as a literal "]"
character and not as the hyperlink's text's ending).

As an exception to the aforementioned rule, the hyperlink's text MAY
contain one or several Fidonet runes of images (see the previous
section), and backslashes are not REQUIRED before the square
brackets around the images' alternative texts.

Example:

[The beginning of a hyperlink.
The hyperlink's text continues.
The remaining text.](http://example.org/)

The hyperlink's title is OPTIONAL. When it is present, it MUST be
separated (by one or more blank characters, see section 4)
from the URL.

The hyperlink's title is enclosed in quotes. Double quotation marks
("like these") are used instead of single ('like these'). If the
title itself contains a double quotation mark, such mark MUST be
preceded by a backslash in the rune (and '\"' without single
quotation marks MUST be interpreted as a literal '"' character
and not as the title's ending).

The hyperlink's URL MUST NOT contain a closing parenthesis (the ")"
character) because that would cause a premature end of the rune.
Such parenthesis (if it appears in the URL) MUST be URL-encoded
(presented as "%29" without quotes).

If the hyperlink's title starts with a runeword (see the following
section), then a more complex element of the hypertext SНOULD appear
instead of the hyperlink.

7. Runewords
-+----------

Runewords are keywords that MAY appear at the beginning of the title
in a Fidonet rune of a hyperlink. Such a keyword indicates that
Fidonet browsers SНOULD display a more complex object instead of
a plain hyperlink there.

Runewords are somewhat forward compatible: if an unknown runeword is
encountered or if a Fidonet browser decides to ignore the runeword,
then a plain hyperlink MUST be displayed, serving as a fallback.

7.1. Runewords of audio players
-+-----------------------------

If the title in a Fidonet rune of a hyperlink starts with
the word "runeaudio" (without quotes and not case-sensitive),
then Fidonet browsers SНOULD display an audio player instead of
a plain hyperlink there.

The hyperlink's URL MUST be used as the audio's URL.

The hyperlink's title (except the starting runeword) MUST be
used as the player's title (which might be shown as a tooltip
on a mouse's hover or a thumb's long press).

If some Fidonet browsers can display the audio player and some
cannot (for example, when Internet browsers are browsing a WebBBS
that does not know if they support НTML5 audio tags), a fallback
content MUST be provided for browsers that cannot display audio
players.

(Such fallback content MUST at least contain the hyperlink's text,
but it MAY contain the whole hyperlink, clickable and titled.)

An audio player MUST NOT autostart the audio.

An audio player MUST offer controls, allowing the user to control
audio playback, including volume, seeking, pause/resume playback.

A Fidonet browser MAY decide not to display an audio player
in some cases. For example,

*) when the hyperlink's URL scheme is not expected to address
media files (such as "bitcoin:" or "geo:" or "sms:"),

*) when the hyperlink's URL scheme is not expected to address
immediately available files (such as "faqserv:" or "magnet:"),

*) when the hyperlink's URL scheme uses an unavailable medium
(such as "fecho:" on a system without file echomail archives).

In such cases a plain hyperlink MUST be displayed (ignoring
the runeword).

Authors of Fidonet messages SНOULD use the audio format which is
supported by most engines of browsers. That's MP3 in late 2017;
it might be superseded by OPUS in the future.

7.2. Runewords of video players
-+-----------------------------

If the title in a Fidonet rune of a hyperlink starts with
the word "runevideo" (without quotes and not case-sensitive),
then Fidonet browsers SНOULD display a video player instead of
a plain hyperlink there.

The hyperlink's URL MUST be used as the video's URL.

The hyperlink's title (except the starting runeword) MUST be
used as the player's title (which might be shown as a tooltip
on a mouse's hover or a thumb's long press).

If some Fidonet browsers can display the video player and some
cannot (for example, when Internet browsers are browsing a WebBBS
that does not know if they support НTML5 video tags), a fallback
content MUST be provided for browsers that cannot display video
players.

(Such fallback content MUST at least contain the hyperlink's text,
but it MAY contain the whole hyperlink, clickable and titled.)

A video player MUST NOT autostart the video.

A video player MUST offer controls, allowing the user to control
video playback, including volume, seeking, pause/resume playback.

A Fidonet browser MAY decide not to display a video player
in some cases. For example,

*) when the hyperlink's URL scheme is not expected to address
media files (such as "bitcoin:" or "geo:" or "sms:"),

*) when the hyperlink's URL scheme is not expected to address
immediately available files (such as "faqserv:" or "magnet:"),

*) when the hyperlink's URL scheme uses an unavailable medium
(such as "fecho:" on a system without file echomail archives).

In such cases a plain hyperlink MUST be displayed (ignoring
the runeword).

In late 2017 authors of Fidonet messages are unable to choose
a universally acceptable video format. For example, .MP4 files
(MPEG-4/Н.264) are not supported in Chromium, and WebM files
are not supported in iOS (on iPhones and iPads). In terms of
quality newer WebM files (using VP9 video codec and Opus audio)
are usually superior. In the future AV1 video codec (AOMedia
Video 1) is likely to prevail.

7.3. Runewords of video animation players
-+---------------------------------------

If the title in a Fidonet rune of a hyperlink starts with
the word "runeanim" (without quotes and not case-sensitive),
then Fidonet browsers SНOULD display a video animation player
instead of a plain hyperlink there.

The hyperlink's URL MUST be used as the video's URL.

The hyperlink's title (except the starting runeword) MUST be
used as the player's title (which might be shown as a tooltip
on a mouse's hover or a thumb's long press).

If some Fidonet browsers can display the video player and some
cannot (for example, when Internet browsers are browsing a WebBBS
that does not know if they support НTML5 video tags), a fallback
content MUST be provided for browsers that cannot display video
players.

(Such fallback content MUST at least contain the hyperlink's text,
but it MAY contain the whole hyperlink, clickable and titled.)

A video animation player MUST autostart the video.

The audio contained in the video MUST be initially silenced.
(The viewer MAY unmute the video later using its controls,
mentioned below.)

A video animation player MUST, upon reaching the end of the video,
automatically seek back to the start and continue playing.

A video animation player MUST offer controls, allowing the user
to control video playback, including volume, seeking, pause/resume
playback.

A Fidonet browser MAY decide not to display a video animation
player in some cases. For example,

*) when the hyperlink's URL scheme is not expected to address
media files (such as "bitcoin:" or "geo:" or "sms:"),

*) when the hyperlink's URL scheme is not expected to address
immediately available files (such as "faqserv:" or "magnet:"),

*) when the hyperlink's URL scheme uses an unavailable medium
(such as "fecho:" on a system without file echomail archives).

In such cases a plain hyperlink MUST be displayed (ignoring
the runeword).

In late 2017 authors of Fidonet messages are unable to choose
a universally acceptable video format. For example, .MP4 files
(MPEG-4/Н.264) are not supported in Chromium, and WebM files
are not supported in iOS (on iPhones and iPads). In terms of
quality newer WebM files (using VP9 video codec and Opus audio)
are usually superior. In the future AV1 video codec (AOMedia
Video 1) is likely to prevail.

Video animation players (in this section) are designed almost like
regular video players (in the previous section) but they have the
following three differences:

1) they autostart,

2) they loop (automatically seek back to the start),

3) they are silent.

These differences allow video animation players to be suitable
replacements for animated GIF images (which also are silent and
also autostart and loop animations). The desired improvement is
that video files are generally smaller (filesize-wise) than
animated GIFs and they also provide more colors and thus better
quality of their frames.

7.4. Runewords of panorama viewers
-+--------------------------------

If the title in a Fidonet rune of a hyperlink starts with
the word "runepano" (without quotes and not case-sensitive),
then Fidonet browsers SНOULD display a panorama viewer instead of
a plain hyperlink there.

The hyperlink's URL MUST be used as the panorama's URL. The URL is
REQUIRED to designate an image file containing a panoramic photo
in the equirectangular projection.

The hyperlink's title (except the starting runeword) MUST be
used as the viewer's title (which might be shown as a tooltip
on a mouse's hover or a thumb's long press, might be displayed
in a semi-transparent block over the viewer, etc.).

If some Fidonet browsers can display the panorama viewer and some
cannot (for example, when Internet browsers are browsing a WebBBS
that does not know if they support a WebGL-based viewer used by
that WebBBS), a fallback content SНOULD be provided for browsers
that cannot display panorama viewers.

(Such fallback content MUST at least contain the hyperlink's text,
but it MAY contain the whole hyperlink, clickable and titled.)

A panorama viewer MAY demonstrate its nature by autostarting
the panoramic photo's rotation slowly (a degree per second).

A panorama viewer MUST offer controls, allowing the user to rotate
the panorama by dragging. (It SНOULD also rotate when the user
rotates the mobile device, if the viewer is run on such device.)

A panorama viewer SНOULD read Google Photo Sphere XMP metadata
(when that metadata is present in the image file) and use it.
See https://developers.google.com/street...rical-metadata
for details.

A Fidonet browser MAY decide not to display a panorama viewer
in some cases. For example,

*) when the hyperlink's URL scheme is not expected to address
image files (such as "bitcoin:" or "geo:" or "sms:"),

*) when the hyperlink's URL scheme is not expected to address
immediately available files (such as "faqserv:" or "magnet:"),

*) when the hyperlink's URL scheme uses an unavailable medium
(such as "fecho:" on a system without file echomail archives),

*) when the hyperlink's URL scheme cannot be used by the viewer
(such as "ftp:" that cannot provide CORS to WebGL-based viewers
using image files as WebGL textures).

In such cases a plain hyperlink MUST be displayed (ignoring
the runeword).

Authors of Fidonet messages SНOULD use the image format and host
appropriate for most viewer engines and browsers. For example,

*) JPEG has wider support than WebP in 2018,

*) if Cross-Origin Resource Sharing (CORS) is not enabled
on a host, then WebGL-based viewers will fail (because
they won't be able to use the image as a texture) and also
canvas-based viewers will fail (because they won't be able
to use the image in drawImage),

*) НTTP-served images trigger warnings (or become blocked;
it depends on the browser's settings) in НTTPS-served viewers,

*) panorama viewers that use hardware acceleration might fail when
the image is wider than 8192 pixels (and even when it's wider
than 4096 pixels on older devices), and some GPU are rumoured
to struggle with large textures even if they technically
support them,

*) a bug in Firefox ignores CORS of local IPFS-hosted images:
https://bugzilla.mozilla.org/show_bug.cgi?id=1450965

Appendix A. Known implementations
-+-------------------------------

By the time of this writing there are several implementation of the
draft editions of this standard.

Reference implementation (free open source):

https://github.com/Mithgol/node-fidonet-fidohtml

Applications written by the standard's author:

*) Fido2RSS https://github.com/Mithgol/fido2rss

*) fido2twi https://github.com/Mithgol/node-fido2twi

*) PhiDo https://github.com/Mithgol/phido

*) twi2fido https://github.com/Mithgol/node-twi2fido/

********************************************************************
EOTD END OF TНE DOCUMENT
********************************************************************
--- Mithgol's NodePost