Schema

Der Rahmen

Jede TCPP-Nachricht ist ein JSON-Objekt mit denselben fünf oder sechs Elementen der obersten Ebene. Der Endpunkt bestimmt, was in record steht; alles darum herum ist identisch, ob die Nachricht einen Ladevorgang meldet oder einen Ping beantwortet.

Der Head

Zwölf Pflichtfelder. Eine Response wiederholt den Head des Requests mit umgekehrter Richtung, vertauschtem Ursprung und Ziel und dem eigenen Ergebnis in error_code.

Kennungen

Jede Kennung im Head (Ursprung, Ziel, Kontext, Beteiligte) trägt ein Präfix aus einem Buchstaben und einem Doppelpunkt, das ihren Namensraum benennt; damit ist nie unklar, was für ein Ding eine Kennung bezeichnet. Die ganze Kennung ist samt Präfix höchstens 120 Zeichen lang.

Modultypen

Drei Großbuchstaben sagen, was ein Beteiligter ist. Der Typ nennt die Rolle im Protokoll, die Kennung das konkrete Gerät oder den konkreten Dienst.

Vertrauenswürdige Dienste

Marktteilnehmer

Ladepunkte und lokale Geräte

Messung und Energiemanagement

Kontexttypen

context_type benennt die Art des Vorgangs, zu dem eine Nachricht gehört, und stammt aus einem eigenen Satz: CRG Laden · ENG Energiesteuerung · MNT Wartung · INF Information · DRR Data Request Record · TFF Tarif.

Fehlercodes

Sechs Hexadezimalstellen, verwendet im Head, im elementweisen parsed-Block einer Response und in Referenzen. Der Code wird in drei Teilen gelesen: die erste Stelle ist die globale Klasse, die beiden folgenden der genaue Status, die letzten drei ein modulspezifischer Status, FFF, wenn das Modul nicht bestimmt ist.

000000 bedeutet also Erfolg, FFFFFF einen unbekannten Fehler. Eine Response, die den Head angenommen, aber ein Element einer Liste abgelehnt hat, sagt das in parsed unter dem Pfad dieses Elements, statt die ganze Nachricht scheitern zu lassen.

Signatur

Eine TCPP-Nachricht reist als Compact JWS mit alg: ES384, also ECDSA über der NIST-Kurve P-384 mit SHA-384. Das oben gezeigte JSON-Objekt ist die Nutzlast; der Empfänger dekodiert sie, prüft sie gegen den öffentlichen Schlüssel des Senders und bewahrt Nachricht und Token gemeinsam auf.

JWS-Signaturen verwenden die feste R‖S-Kodierung nach IEEE P1363, die auch die Web Crypto API eines Browsers erzeugt. Bibliotheken, die DER ausgeben, darunter ecdsa.SignASN1 in Go, müssen zuvor umgewandelt werden, einschließlich der Linksauffüllung einer zu kurzen Koordinate.

Eine Signatur kann auch innerhalb einer Nachricht mitgeführt werden: Jeder Eintrag in references darf das jws des Datensatzes enthalten, auf den er verweist. So lässt sich eine Kette von Datensätzen als ein Dokument weitergeben und Glied für Glied prüfen. Dieses Element ist ein Objekt, nicht die kompakte Zeichenkette, als die eine Nachricht reist: innerhalb eines Datensatzes wird die Signatur in der JSON-Serialisierung von JWS geführt und bleibt damit als JSON lesbar statt als eine undurchsichtige Zeile.

Endpunkte

27 Request/Response-Paare. Jeder Name verweist auf seine beiden Schemadateien.

Laden

Messung

Identität, Schlüssel und Prüfung

Konfiguration

Betrieb

Archiv

Das Rahmenschema

all.json ist das Basisformat, das die übrigen ausprägen: Head, die Definitionen für Beteiligte und Referenzen und ein freier record. Dagegen wird geprüft, wenn eine Nachricht gelesen werden muss, deren Endpunkt nicht implementiert ist.

• all.json

Die Dateien beziehen

Alle 55 Dateien, wie sie hier ausgeliefert werden, gibt es auch als ein Archiv. Der Referenzknoten bringt denselben Satz mit und liefert ihn unter denselben Pfaden aus; eine Implementierung lässt sich also gegen eine lokale Kopie entwickeln und unverändert auf die veröffentlichten URLs umstellen.