# Aufbau und Bestandteile einer Meldungskodierung

Grundlegendes

Jede Meldung entspricht einer eindeutigen, 11-stellige Kodierung. Diese Kodierung bleibt unverändert, auch wenn der Text der Meldung mit der Zeit variiert werden kann. Es wird daher ausdrücklich empfohlen, auf diese 11-stelligen Kodierungen zu parsen.

Die Kodierungen sind in sich logisch und systematisch aufgebaut, so dass auch eine automatische Analyse, Gruppierung oder Zusammenfassung bei der Bearbeitung der Meldungen möglich ist.

Generelles Format

Bei diesem 11-stelligen Format haben einzelne Felder oder Gruppen von Feldern jeweils eine eigene Bedeutung. Die Kodierung unterscheidet dabei vier Blöcke, die zusammengefasst die komplette Kodierung bilden.

0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
A | B | C | D

- A: Klassifizierung
- B: Interface
- C: Komponente
- D: Code

A - Klassifizierung (Spalte 1)

Im ersten Feld findet sich die Klassifikation. Daraus ist ersichtlich, wie kritisch die Meldung ist.

1 | INFO, Success
2 | INFO, Failed
3 | WARNING, temporärer Fehler
4 | WARNING, permanenter Fehler
5 | ERROR, temporärer Fehler
6 | ERROR, permanenter Fehler
7 | TECHNICALERROR, temporärer Fehler
8 | TECHNICALERROR, permanenter Fehler

- INFO
  DENIC hat einen Auftrag exakt so ausgeführt, wie er gestellt wurde oder DENIC informiert von sich aus, nicht als Rückmeldung auf einen Auftrag.
- WARNING
  DENIC hat einen Auftrag ausgeführt, aber mit Abweichungen vom gestellten Auftrag.
- ERROR
  DENIC hat einen fehlerhaften Auftrag nicht ausgeführt.
- TECHNICALERROR
  Der Auftrag wurde nicht verarbeitet aus Gründen, die nichts mit Form oder Inhalt des Auftrags zu tun haben, sondern aufgrund von technischen Problemen bei der Auftragsverarbeitung.

- temporär
  Der Fehler ist von vorübergehender Natur. Der Auftrag kann zu einem späteren Zeitpunkt noch einmal gestellt werden. In diese Kategorie fallen z.B. Fehler aufgrund von Nameservern, die vorübergehend nicht erreichbar sind.
- permanent
  Der Fehler ist von grundsätzlicher Art. Beispiel: Eine Domain im Status „invalid" kann nicht registriert werden.

B - Interface (Spalte 2)

In Feld 2 ist die genutzte Anwendung kodiert.

1 | Frei
2 | Frei
3 | RRI (.de)
4 | RRI (.9.4.e164.arpa)
5 | whois
6 | schnittstellenunabhängig
9 | Webapplikation

B - Interface (Spalten 3 bis 5)

Die nachfolgenden drei Felder kennzeichnen das entsprechende Modul der Anwendung. Im allgemeinem sind die Modulbezeichnungen an die jeweilige Auftragsform oder Prozedur angelehnt.

Modulunabhängig bedeutet, dass die Meldung sich nicht auf eine bestimmte Auftragsform bezieht, sondern mit dem Objekt des Auftrags zu tun hat. 300 bezieht sich also z.B. generell auf einen Domainauftrag, unabhängig davon, ob es sich um ein CREATE (das wäre 310), ein UPDATE (das wäre 320), oder eine andere Auftragsform gehandelt hat.

000 | anwendungsunabhängig
100 | LOGIN / LOGOUT
200 | contactmodulunabhängig
210 | CREATE (Contact)
220 | UPDATE (Contact)
300 | domainmodulunabhängig
310 | CREATE (Domain)
320 | UPDATE (Domain)
330 | CHHOLDER
340 | RENEW (ENUM- Domain)
345 | Expire (ENUM- Domain)
348 | Expire (DE- Domain)
350 | DELETE
360 | TRANSIT
370 | CHPROV
391 | CREATE-AUTHINFO1
392 | DELETE-AUTHINFO1
393 | CREATE-AUTHINFO2
394 | AuthInfo-expire
400 | CHECK
450 | INFO
500 | RAI-modulunabhängig
600 | QUEUE-modulunabhängig
610 | QUEUE-READ
650 | QUEUE-DELETE