• FTSC_PUBLIC: MARKDOWN kludge

    From Vladimir Fyodorov@2:6035/3.1 to All on Mon Mar 2 09:11:52 2026

    Matthew Asham предложил ввести в Фидо-сообщения клудж ^AMARKDOWN:
    <version>, указывающий на то, что в письме использована
    MARKDOWN-разметка. Carlos Navarro предложил расширить возможности
    применения этого клужда, заменив его на ^aMARKUP:, в котором можно было
    бы указать не только Markdown, но и BBCode, Gemtext и т.п.
    =============================================================================
    * Area : FTSC_PUBLIC
    * From : Matthew Asham, 1:153/150 (27 Февраля 2026 09:39)
    * Subj : MARKDOWN kludge ============================================================================= Wanted to run this by you for feedback. I've recently added markdown support for LovlyNet - a dedicated FTN for BinktermPHP nodes.

    It basically works like this:

    - When posting to a network that has markdown enabled a new MARKDOWN kludge is added.

    - When the MARKDOWN kludge is seen, the message reader renders the markdown.

    It's pretty basic and is an attempt to provide richer text formatting in echo and netmail.

    Below is a specification proposal.

    Would appreciate feedback on this idea.

    Thanks

    Matthew

    **********************************************************************
    LOVLYNET STANDARDS COMMITTEE DOCUMENT LSC-001
    Document: LSC-001
    Title: MARKDOWN Kludge for FidoNet-Compatible Echomail and Netmail
    Author: LovlyNet Standards Committee
    Date: 2026-02-27
    Status: Proposed Standard **********************************************************************
    [...]
    **********************************************************************
    END OF DOCUMENT LSC-001 ********************************************************************** =============================================================================

    =============================================================================
    * Area : FTSC_PUBLIC
    * From : Carlos Navarro, 2:341/234.1 (01 Марта 2026 20:28)
    * To : Matthew Asham
    * Subj : MARKDOWN kludge ============================================================================= 27 Feb 2026 09:39, you wrote to All:

    Wanted to run this by you for feedback. I've recently added markdown support for LovlyNet - a dedicated FTN for BinktermPHP nodes.

    [...]

    Would appreciate feedback on this idea.

    My 2c: in case of something like that being implemented, could it be better to use a more general kludge, such as MARKUP?

    ^aMARKUP: Markdown 1.0

    That would allow for specifying other formats, like BBCode, Gemtext, etc. =============================================================================

    =============================================================================
    * Area : FTSC_PUBLIC
    * From : Matthew Asham, 1:153/150 (01 Марта 2026 13:40)
    * To : Carlos Navarro
    * Subj : Re: MARKDOWN kludge =============================================================================

    My 2c: in case of something like that being implemented, could it be
    better to use a more general kludge, such as MARKUP? ^aMARKUP: Markdown
    1.0 That would allow for specifying other formats, like BBCode,
    Gemtext, etc.

    This makes more sense to me.

    I've done up a second draft based on this this feedback.


    1. INTRODUCTION
    ---------------

    This document defines the MARKUP kludge line for use in FidoNet-
    compatible echomail and netmail messages. Its purpose is to indicate
    that the body of a message is formatted using a named markup syntax,
    allowing capable reader software to render the message with appropriate formatting while remaining fully readable by legacy software that does
    not support this kludge.

    Unlike a Markdown-specific kludge, MARKUP provides a general mechanism
    for identifying the body format of a message. This allows the same
    extension point to be used for Markdown, BBCode, Gemtext, and other
    formats without requiring a new kludge definition for each syntax.


    2. DEFINITIONS
    --------------

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in FTA-1006.

    "Kludge line": A line in a FidoNet message body beginning with the
    ASCII SOH character (0x01), used to carry machine-readable metadata
    not intended for direct display to the end user.

    "Markup syntax": A textual formatting language used within the visible
    message body to express structure or presentation, such as Markdown,
    BBCode, or Gemtext.


    3. THE MARKUP KLUDGE
    --------------------

    3.1 Syntax

    The MARKUP kludge line has the following syntax:

    ^AMARKUP: <format> <version>

    where ^A represents the ASCII SOH character (0x01), <format> is a
    registered or otherwise well-known markup format identifier, and
    <version> is a format version string meaningful within that format.

    Examples:

    ^AMARKUP: Markdown 1.0
    ^AMARKUP: BBCode 1.0
    ^AMARKUP: Gemtext 1.0

    3.2 Placement

    The MARKUP kludge line SHOULD be placed with other kludge lines at
    the beginning of the message body, before any visible text content,
    in accordance with common FidoNet kludge conventions.

    3.3 Format Identifier

    The format identifier MUST be a single token and SHOULD use a stable,
    widely recognized name for the markup syntax. Implementations SHOULD
    treat format identifiers case-insensitively for matching purposes,
    though they MAY preserve the original casing for display or logging.

    3.4 Version String

    The version string MUST follow the format identifier and SHOULD be
    included whenever the syntax has meaningful version distinctions. Implementations MAY treat the version as an opaque string. Software
    that recognizes a format but not its declared version SHOULD fall back
    to best-effort rendering or plain text display.


    4. BEHAVIOR OF CONFORMING SOFTWARE
    ----------------------------------

    4.1 Message Authors and Editors

    A message editor that supports composition in a named markup syntax
    MAY insert the MARKUP kludge line when the user composes a message in
    that format. It SHOULD NOT insert the kludge unless the message body
    actually contains content intended for that markup syntax.

    4.2 Message Readers

    A message reader that encounters the MARKUP kludge:

    - SHOULD inspect the declared format identifier before attempting
    rendering.
    - MAY render the body according to the declared format if that
    format is supported.
    - SHOULD provide plain text display when the declared format is not
    supported, not recognized, or cannot be safely rendered.
    - SHOULD provide a way for the user to view the raw source if
    desired.

    4.3 Unknown or Unsupported Formats

    Software that does not recognize the declared markup format MUST
    ignore the semantic meaning of the kludge and display the message body
    as plain text. The original body content MUST be preserved unchanged.

    4.4 Tosser and Packer Behavior

    Tossers, packers, and other mail-handling software MUST NOT alter,
    strip, or otherwise modify the MARKUP kludge line during normal
    message handling. The kludge MUST be preserved through the normal
    FidoNet message routing process.


    5. FORMAT-SPECIFIC GUIDANCE
    ---------------------------

    This document defines only the transport-level declaration mechanism.
    It does not standardize the parsing rules of any specific markup
    syntax.

    Implementors supporting a given format SHOULD document which variant
    they support. For example:

    - Markdown implementations SHOULD identify which dialect or baseline
    they follow, such as CommonMark.
    - BBCode implementations SHOULD document which tags are supported.
    - Gemtext implementations SHOULD follow Gemtext line-oriented rules.

    When possible, authors SHOULD choose markup syntaxes that degrade
    gracefully in plain-text environments, since many FidoNet-compatible
    systems may display the raw message body without rendering.


    6. SECURITY CONSIDERATIONS
    --------------------------

    Rendering software MUST treat the declared markup format as untrusted
    input. Implementations SHOULD sanitize or restrict active content,
    embedded HTML, unsafe URLs, and any construct that could execute code,
    load remote resources, or mislead the user interface.

    Software rendering marked-up messages MUST NOT automatically fetch
    remote resources without explicit user consent, in order to protect
    user privacy and avoid unexpected network activity.


    7. IMPLEMENTATION NOTES
    -----------------------

    The MARKUP kludge is intended as a general extension mechanism for FidoNet-compatible software. A given implementation MAY support only
    a subset of markup syntaxes and still conform to this specification,
    provided unsupported formats are safely treated as plain text.

    An implementation that currently supports only Markdown may still emit:

    ^AMARKUP: Markdown 1.0

    This preserves forward compatibility with other markup syntaxes while
    allowing immediate use for Markdown-aware readers.


    8. REFERENCES
    -------------

    [1] FTS-0001 - A Basic FidoNet(r) Technical Standard
    [2] FTS-0009 - The MSGID and REPLY kludges
    [3] FTS-5003 - Character set kludge (CHRS/CHARSET)
    [4] FTA-1006 - Key words to indicate requirement levels
    [5] CommonMark Specification
    https://spec.commonmark.org/


    9. REVISION HISTORY
    -------------------

    2026-02-27 Initial proposal for a Markdown-specific kludge.
    2026-03-01 Revised proposal to use the general MARKUP kludge. =============================================================================



    --- GoldED+/OSX 1.1.5-b20250409
    * Origin: Esquire Station (2:6035/3.1)