How to Separate Domain Status and Registration Events in RDAP
In an RDAP response, status describes the registered object’s state, while events describe occurred or future-dated events. Keeping them separate helps you read registration data carefully.
When you open an RDAP response for your domain, you may see status on one side and events on the other and assume they describe the same thing. Seeing a future expiration date can make it particularly easy to jump to a conclusion about the domain’s status. RDAP domain status and events are different kinds of information: status indicates the state of the registered object, while events record events that occurred on an object instance. Making that distinction helps you read the response more carefully.
At a glance
- Status is a list of strings indicating the state of a registered object; it is not an event log.
- Events represent events that occurred on an object instance, and every event includes eventDate with the event’s date and time.
- Future-dated events are allowed, and an expiration time can be one use case. A date in an event should not replace status information.
- Some registration-data members can be absent from RDAP responses, and unrecognized extra members should not be treated as status or events.
Start by separating two questions
When reading an RDAP response, ask two separate questions: “What is the state of the domain object?” and “Which events have been recorded for this object?” The answer to the first question is the status field. RFC 9083 defines the status structure as an array of strings indicating the state of a registered object.
The answer to the second question is the events field. This structure represents events that have occurred on an instance of an object class. Events are therefore not a historical copy of status or another name for it. Treating one as state information and the other as event information reduces interpretation errors.
- Status: a list of strings indicating the state of a registered object.
- Events: records of events that occurred on an object instance.
Source: [2]
Read status as state information
The purpose of status is not to tell you when an event happened. It is defined as a list indicating the state of the registered object. When assessing the domain’s status, examine status separately rather than replacing it with dates from the events list.
There is an important limit here. The supplied RDAP definition says that status is a state list; it does not mean that every possible operational conclusion can be drawn from that field alone in this article. Before planning an action based on a status value, keep the explicit information in the RDAP response separate from management information provided by your registrar.
- Do not read a date as though it were status.
- Do not merge the roles of status and events.
- Do not assume registration data that is not explicitly present in the response.
Source: [2]
Read events as a timeline
Each record in events concerns an event, and eventDate is a required part of that record. eventDate contains the date and time when the event occurred. You can therefore read the events section as time information for events associated with the domain object.
Example scenario: suppose an RDAP response shows a record with a date and time under events. That record tells you when the relevant event occurred or, if it is future dated, when it is specified to occur. The date alone does not replace the state information in status. Use status for status information and events for time-related records.
- Every event record contains eventDate.
- eventDate carries the event’s date and time.
- Event time and object state are different types of information.
Source: [2]
Do not confuse an expiration date with status
RDAP allows future-dated events. The standard identifies indicating when an object expires from a registry as one use case for future dating. A future expiration time can therefore appear under events.
That information matters, but the reading order matters too. A future date is information about a future event, while status is the field that indicates the registered object’s state. Example scenario: if a response shows a future expiration event, note it as upcoming time information. Then read status separately to assess the domain’s status. Avoid turning the two fields into one conclusion.
- Events can be future dated.
- An expiration time is an example use case for a future-dated event.
- A future event date does not replace status information.
Source: [2]
Be careful with absent fields and extra members
Some JSON members carrying registration data can be absent from an RDAP response. Servers can omit unrequired registration-data members according to their policies. If events is not shown, do not make a definite claim from that response that no event list exists; limit the conclusion to saying that the field is not present in that response.
RDAP servers can also insert additional JSON members that are not specified by the standard. Clients are advised to ignore members they do not recognize. The same approach is useful when reading a response: do not equate an unfamiliar field with status or events merely because its name looks similar. First establish whether it is a standard field.
- Unrequired registration-data members may be absent.
- An unrecognized JSON member does not mean the response is erroneous.
- Do not interpret a non-standard field as status or events.
Source: [2]
Use a practical reading order
When reviewing an RDAP response, first find status and note it separately as state information. Then, if events is present, review the event records and their eventDate values as time information. If you see a future-dated event, allow for the possibility that it concerns the future; in particular, remember that an expiration time can be expressed this way.
Finally, account for the possibility that the response includes absent or unrecognized members. This approach avoids assuming missing data and assigning too much meaning to extra fields. An RDAP response gives you two distinct kinds of information: state and events. A sound assessment starts by keeping them separate.
- Record status information separately.
- Review eventDate values in event records separately.
- Do not substitute future events for status information.
- Do not draw definite conclusions from absent or unrecognized members.
Source: [2]
Practical checklist
- Read status as a state list for the registered object, not as an event record.
- Review events, when present, for event records.
- Treat eventDate in each event record as the event’s date and time.
- Do not equate a future event date with status information.
- Allow for an expiration time to be expressed as a future-dated event.
- Do not assume optional registration data that is absent from the response.
- Do not interpret unrecognized JSON members as status or events.
In an RDAP response, status is a list indicating the state of the registered domain object, while events carry occurred events and their timing. Future-dated events can show information such as an expiration time. Read status information from status and historical or future event information from events, while allowing for absent or non-standard members in the response.
Frequently asked questions
Is the status field in RDAP an event log?
No. Status is an array of strings indicating the state of a registered object. Events is the structure that represents events.
Is the date field inside an events record required?
Yes. eventDate is a required string in an event record and contains the date and time when the event occurred.
Can an RDAP expiration time appear as a future event?
Yes. RDAP allows future-dated events, and indicating when an object expires from a registry is one stated use case.
What does it mean if an RDAP response has no events field?
Unrequired JSON members containing registration data may be omitted according to server policy. Its absence means the field is not present in that response.
Sources
[2] rfc9083.txt
