# Structure and Components of Message Codes

Basic Information

Every message has a single unique 11-character code to go with it. This code remains unchanged even though it is possible to vary the text of the message over time. Members are thus strongly recommended to set their systems to parse on the basis of these 11-character codes.

The codes have been structured logically and systematically, making it possible for messages to be processed in a way permitting an automatic analysis, grouping or aggregation.

General Format

Each individual position or each group of positions of the 11-character codes has its own particular meaning. The individual positions are grouped into four blocks, which together comprise the code as a whole.

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

- A: Classification
- B: Interface
- C: Component
- D: Code

A - Classification (position 1)

The code's first position is used to classify the type of message. This is also an indication of how critical the message is.

1 | INFO, success
2 | INFO, failed
3 | WARNING, temporary error
4 | WARNING, permanent error
5 | ERROR, temporary error
6 | ERROR, permanent error
7 | TECHNICALERROR, temporary error
8 | TECHNICALERROR, permanent error

- INFO
  DENIC has carried out an instruction exactly as it was given, or DENIC provides information on its own initiative, not in response to an instruction.
- WARNING
  DENIC has executed a request, but has changed at least one detail compared with the content of the request.
- ERROR
  DENIC has not executed a request because there was at least one error.
- TECHNICALERROR
  DENIC has not been able to process the request for reasons not related to its form or content, but because of technical problems with request processing.

- temporary
  The error is of a temporary nature only. You may re-submit the request later. This category includes, e.g. errors due to name servers that are temporarily inaccessible.
- permanent
  The error is a fundamental one. For example: You will never succeed in registering a domain with the status "invalid", no matter when and how often you might try.

B - Interface (position 2)

Position 2 contains the code for the interface that is used.

1 | currently not used
2 | currently not used
3 | RRI (.de)
4 | RRI (.9.4.e164.arpa)
5 | whois
6 | not dependent on a particular interface
9 | web application

B - Interface (positions 3 to 5)

The next three positions characterize the corresponding module that processed the request. Generally speaking, the names given to the modules are close to the name of the particular request form or procedure.

The expression "not dependent on a particular module" means that the message does not refer to a particular request form but has something to do with the object of the request. For example: 300 refers generally to a domain request, irrespective of whether it is a CREATE (which would be 310), an UPDATE (which would be 320) or any other request form.

000 | Not dependent on a particular application
100 | LOGIN / LOGOUT
200 | Contact - not dependent on a particular module
210 | CREATE (contact)
220 | UPDATE (contact)
300 | Domain - not dependent on a particular module
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 - not dependent on a particular module
600 | QUEUE - not dependent on a particular module
610 | QUEUE-READ
650 | QUEUE-DELETE