# Neocast Message Exchange Protocol – NCMEP/1.0

## Einleitung
Das Neocast Message Exchange Protocol (NCMEP) oder Neocast-Nachrichtenaustauschprotokoll
dient dem Übertragen von Neocast-Nachrichtenpaketen und verwendet zumeist WebSocket
oder HTTP Polling als zugrundeliegende Protokolle, wenngleich keine standardisierte
Implementierung oder Einordnung in das OSI-Modell existiert. Diese Norm legt nur die
Struktur des Protokolls fest.

# Neocast Message Exchange Protocol - NCMEP/1.0

## Einleitung
Das Neocast Message Exchange Protocol (NCMEP) oder Neocast-Nachrichtenaustauschprotokoll
dient dem übertragen von Neocast-Nachrichtenpaketen und verwendet zumeist WebSocket
oder HTTP-Polling als zugrundeliegende Protokolle, wenngleich keine standardisierte
Implementierung oder Einordnung in das OSI-Modell existiert. Diese Norm legt nur die
Struktur des Protokolls fest.

## Paketstruktur
Jedes NCMEP-Paket besteht aus einem Statuscode, einem Nachrichtenkörper und einem Header,
durch welchen Metadaten im Schlüssel-Wert-Format kodiert werden können. Darüber hinaus
existieren Kontrollelemente, die durch das Backend interpretiert werden KÖNNEN.
Die Paketstruktur ist wie folgt definiert:

struct {
    char* key;
    char* value;
} HeaderEntry;

struct {
    uint8         version;     // Protokollversion (0-255)
    char*         username;    // Senderidentifikation
    uint128       checksum;    // Signierte Prüfsumme aus Benutzername, Körper, Statuscode und Header.
    uint8         statusCode;  // Statuscode (Abschnitt 4)
    char*         body;        // Nachrichtenkörper (variable Inhalte)
    HeaderEntry*  header;      // Header-Dictionary (Schlüssel-Wert-Paare)
} Packet;


version: Ganzzahlige Protokollversion (s.u.). Clients und Server SOLLTEN Versionsunterschiede problemlos handhaben.

username: UTF-8-kodierte Zeichenkette zur Identifikation des Senders.

checksum: Eine signierte Prüfsumme aller Parameter außer der `version` zur Authentifizierung.

statusCode: Beschreibt den Status des Nachrichtenaustauschs (s.u.).

body: Nachrichtennutzlast als Zeichenkette.

header: Metadaten oder zusätzlicher Kontext, strukturiert als Schlüssel-Wert-Paare.

## Statuscodes
NCMEP definiert folgende dreistellige Statuscodes, die Server wie Client verwenden SOLLTEN, um Logik zu implementieren.
enum {
    awaitingResponse(101),   // Kommen
    exchangeComplete(200),   // Austausch erfolgreich abgeschlossen
    redirected(201),         // Erfolgreicher Austausch mit Redirect
    badRequest(240),         // Fehlerhafte oder nicht interpretierbare Anfrage
    notAuthorised(241),      // Authentifizierung erforderlich
    forbidden(243),          // Zugriff verweigert
    notFound(244),           // Ressource nicht verfügbar
    internalError(250),      // Interner Serverfehler
    rejected(252),           // Verbindung abgelehnt
    (255)                    // Für zukünftige Nutzung reserviert
} StatusCode;

## Das Handshake-Protokoll
1.  Client-Initialisierung
    Der Client stellt eine Verbindung zum Server her.
2.  Serverantwort ("Pförtner")
    Der Server antwortet mit einem der folgenden Statuscodes:
    (a) 101: Die Verbindung wird zugelassen
    (b) 252:  "      "       "   abgelehnt
3.  Kanalanfrage
    Der Client übermittelt ein Paket mit leerem Körper und dem gewünschten Kanal in einem Header kodiert.
4.  Serverantwort ("Operator")
    Der Server überprüft den Benutzernamen und die Prüfsumme sowie die Verfügbarkeit des gewünschten Kanals.
    Einer der folgenden Statuscodes wird zurückgesendet:
    (a) 200: Der Client wird dem Kanal zugewiesen; der Austausch ist abgeschlossen.
    (b) 241: Authentifizierung nicht erfolgreich; Verbindung wird unterbrochen.
    (c) 243:        "          ist        "     , Zugriff zum Kanal ist jedoch verweigert.

## Sicherheitsüberlegungen
* Prüfsummenvalidierung. Die signierte Prüfsumme (s.o.) stellt sicher, daß Benutzernamen authentifiziert werden
  und Nachrichten nicht leicht gefälscht werden können. Implementierungen SOLLTEN starke Schlüsselpaare potenter
  asymmetrischer Verschlüsselungsverfahren verwenden.
* Verschlüsselung. Die Transportschicht SOLLTE Transport Layer Security [TLS] implementieren, um das Abfangen von
  Nachrichten zu verhindern.

## Referenzen
* [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.