TTYPE UND MTTS  [Protokoll]
Wie ein Client einem Server sagt, was er ist und was er kann — auch, sofern der
Client sich dafür entscheidet, dass ein Screenreader im Einsatz ist.
https://www.mudhalla.net/tintin/protocols/mtts/

Gemessene Verbreitung
  0 von 886 eingetragenen Spielen haben es in einem von uns beobachteten
  Handshake angeboten (0.0%)
  /de/games?protocol=TTYPE

  Die Spiele, die hier nicht mitgezählt sind, sind keine Spiele ohne das
  Protokoll. Ein Spiel zählt hier, wenn sein Server die Option in einem von uns
  beobachteten Handshake angeboten hat; der Rest sind Server, die sie uns nicht
  angeboten haben, und Server, deren Handshake wir nicht gelesen haben, und
  welches davon zutrifft, können wir Ihnen nicht sagen.

  Nach Codebase, unter den Spielen, die wir identifiziert haben
    AresMUSH             0 von 18 haben es angeboten
    CircleMUD            0 von 47 haben es angeboten
    CobraMUSH            0 von 2 haben es angeboten
    CoffeeMUD            0 von 32 haben es angeboten
    DikuMUD              0 von 35 haben es angeboten
    Evennia              0 von 11 haben es angeboten
    FluffOS              0 von 28 haben es angeboten
    MUCK                 0 von 24 haben es angeboten
    PennMUSH             0 von 34 haben es angeboten
    RhostMUSH            0 von 40 haben es angeboten
    ROM                  0 von 55 haben es angeboten
    SMAUG                0 von 20 haben es angeboten
    tbaMUD               0 von 5 haben es angeboten
    TinyMUSH             0 von 9 haben es angeboten

TTYPE ist Telnet-Option 24, aus RFC 1091: Der Server fragt den Client, was für
ein Terminal er ist, und der Client antwortet. Historisch lautete die Antwort
VT100 oder ANSI.

MTTS — der Mud Terminal Type Standard — legt darüber eine Konvention. Ein Client
antwortet dreimal: mit seinem Namen, mit seinem Terminaltyp und dann mit MTTS
<bitmask>, wobei die Bits Fähigkeiten angeben. 256 Farben, True Color, UTF-8,
MNES, MSP über den Out-of-Band-Kanal — und, bemerkenswert, MTTS_SCREEN_READER.

DAS SCREENREADER-BIT

Bei dem letzten lohnt es sich innezuhalten, denn es ist die einzige Stelle im
Protokollstapel dieses Hobbys, an der Barrierefreiheit ein Konzept erster Klasse
ist.

Ein Client, der es setzt, teilt dem Server mit, dass ein Screenreader im Einsatz
ist, und ein Server, der das bemerkt, kann sich anpassen: ASCII-Grafik
unterdrücken, den schmückenden Rahmen aus Linienzeichen um eine Raumbeschreibung
weglassen, eine Tabelle anders anordnen. Sowohl TinTin++
[/reference/clients/tintin] als auch Blightmud [/reference/clients/blightmud]
geben es an, und Mudlet [/reference/clients/mudlet] hat eine Einstellung dafür.

Ob ein bestimmtes Spiel darauf reagiert, ist eine andere Frage, und keine, die
diese Website messen kann — wir können einen Server nicht fragen, was er anders
machen würde.

WAS EIN CRAWLER HIER SCHULDET

Ein Crawler weist sich über TTYPE aus, und das soll er auch. Unserer tut es, mit
einer URL zur Information, damit ein Administrator beim Lesen seiner Logs
herausfinden kann, wer sich mit seinem Spiel verbunden hat und wie er uns bitten
kann aufzuhören. Ein Crawler, der ANSI antwortet und sonst nichts, ist von Haus
aus anonym, und dafür gibt es keinen guten Grund.

WAS WIR MESSEN

Server, die TTYPE mit uns ausgehandelt haben. Beachten Sie, dass dies eine der
wenigen Optionen ist, bei denen wir die gefragte Seite sind; ein Wert hier ist
also eine Zählung der Server, die überhaupt gefragt haben.

Siehe auch
  CHARSET — /de/reference/protocols/charset
  TinTin++ — /de/reference/clients/tintin
  Blightmud — /de/reference/clients/blightmud