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 |