RFC Errata
Found 5 records.
Status: Verified (2)
RFC 9083, "JSON Responses for the Registration Data Access Protocol (RDAP)", June 2021
Source of RFC: regext (art)
Errata ID: 7094
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Scott Hollenbeck
Date Reported: 2022-08-17
Verifier Name: Murray Kucherawy
Date Verified: 2022-11-29
Section 2.1 says:
If The Registry of the Moon desires to express information not found
in this specification, it might select "lunarNIC" as its identifying
prefix and insert, as an example, the member named
"lunarNIC_beforeOneSmallStep" to signify registrations occurring
before the first moon landing and the member named
"lunarNIC_harshMistressNotes" that contains other descriptive text.
Consider the following JSON response with JSON names, some of which
should be ignored by clients without knowledge of their meaning.
{
"handle" : "ABC123",
"lunarNIC_beforeOneSmallStep" : "TRUE THAT!",
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"lunarNIC_harshMistressNotes" :
[
"In space,",
"nobody can hear you scream."
]
}
Figure 2
It should say:
If The Registry of the Moon desires to express information not found
in this specification, it might select "lunarNIC_level_0" as its
identifying prefix and insert, as an example, the member named
"lunarNIC_level_0_beforeOneSmallStep" to signify registrations occurring
before the first moon landing and the member named
"lunarNIC_level_0_harshMistressNotes" that contains other descriptive
text.
Consider the following JSON response with JSON names, some of which
should be ignored by clients without knowledge of their meaning.
{
"handle" : "ABC123",
"lunarNIC_level_0_beforeOneSmallStep" : "TRUE THAT!",
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"lunarNIC_level_0_harshMistressNotes" :
[
"In space,",
"nobody can hear you scream."
]
}
Figure 2
Notes:
The original text uses the string identifier "lunarNIC" as the prefix for an example extension. This is inconsistent with the example given in Section 4.1, where "lunarNIC_level_0" is used as an example of a registered identifier for an RDAP extension. This inconsistency can lead implementers to believe that the registered identifier and the extension prefix can be inconsistent, when the intent of the specification is that they should be consistent. This inconsistency can cause significant misunderstanding of the technical specification and might result in faulty implementations if not corrected. Changing the examples in Section 2.1 aligns the text with the example in Section 4.1, demonstrating that the extension prefix and the registered identifier should be one and the same.
Errata ID: 7986
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Gavin Brown
Date Reported: 2024-06-12
Verifier Name: Orie Steele
Date Verified: 2024-06-13
Section 9 says:
The following is an elided example of an entity truncated data.
{
"objectClassName" : "entity",
"handle" : "ANENTITY",
"roles" : [ "registrant" ],
...
"entities" :
[
{
"objectClassName" : "entity",
"handle": "ANEMBEDDEDENTITY",
"roles" : [ "technical" ],
...
},
...
],
"networks" :
[
...
],
...
"remarks" :
[
{
"title" : "Data Policy",
"type" : "object truncated due to unexplainable reason",
"description" :
[
"Some of the data in this object has been removed."
],
"links" :
[
{
"value" : "https://example.net/help",
"rel" : "alternate",
"type" : "text/html",
"href" : "https://www.example.com/data_policy.html"
}
]
}
]
}
It should say:
The following is an elided example of an entity truncated data.
{
"rdapConformance" :
[
"rdap_level_0"
],
"objectClassName" : "entity",
"handle" : "ANENTITY",
"roles" : [ "registrant" ],
...
"entities" :
[
{
"objectClassName" : "entity",
"handle": "ANEMBEDDEDENTITY",
"roles" : [ "technical" ],
...
},
...
],
"networks" :
[
...
],
...
"remarks" :
[
{
"title" : "Data Policy",
"type" : "object truncated due to unexplainable reason",
"description" :
[
"Some of the data in this object has been removed."
],
"links" :
[
{
"value" : "https://example.net/help",
"rel" : "alternate",
"type" : "text/html",
"href" : "https://www.example.com/data_policy.html"
}
]
}
]
}
Notes:
RFC 9083 4.1 states that the rdapConformance data structure MUST appear in the topmost JSON object of RDAP responses. The example error response provided in Figure 33 should include the rdapConformance property but does not.
Status: Reported (2)
RFC 9083, "JSON Responses for the Registration Data Access Protocol (RDAP)", June 2021
Source of RFC: regext (art)
Errata ID: 7093
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Hollenbeck
Date Reported: 2022-08-17
Section 4.1 says:
The data structure named "rdapConformance" is an array of strings, each providing a hint as to the specifications used in the construction of the response.
It should say:
The data structure named "rdapConformance" is an array of strings, each identifying a registered specification used in the construction of the response.
Notes:
The original text uses the word "hint", which some people have interpreted to mean "not normative" and/or "can be ignored". This misinterpretation will likely cause significant misunderstanding of the technical specification and might result in faulty implementations if not corrected. The intention and meaning of this sentence is more clearly specified with the corrected text, noting that the array of string identifiers is directly associated with the set of specifications used to construct an RDAP response.
Errata ID: 7340
Status: Reported
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Rudi Floren
Date Reported: 2023-02-07
Section Appendix F says:
* Noted that all members of the "events" and "Public IDs" arrays are
REQUIRED.
It should say:
* Noted which members of the "events" and "Public IDs" arrays are
REQUIRED.
Notes:
According to the "events" array, not all members are REQUIRED.
Status: Rejected (1)
RFC 9083, "JSON Responses for the Registration Data Access Protocol (RDAP)", June 2021
Source of RFC: regext (art)
Errata ID: 7985
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Gavin Brown
Date Reported: 2024-06-12
Rejected by: Orie Steele
Date Rejected: 2024-06-13
Section 6 says:
This is an example of the common response body.
{
"errorCode": 418,
"title": "Your Beverage Choice is Not Available",
"description":
[
"I know coffee has more ummppphhh.",
"Sorry, dude!"
]
}
It should say:
This is an example of the common response body.
{
"rdapConformance" :
[
"rdap_level_0"
],
"errorCode": 418,
"title": "Your Beverage Choice is Not Available",
"description":
[
"I know coffee has more ummppphhh.",
"Sorry, dude!"
]
}
Notes:
RFC 9083 4.1 states that the rdapConformance data structure MUST appear in the topmost JSON object of RDAP responses. The example error response provided in Figure 28 should include the rdapConformance property but does not.
--VERIFIER NOTES--
The example cited in Figure 28 is described in the text as a "common response body", not a complete RDAP response. The error response body is described in the context of a complete RDAP response in Figure 29, which includes an rdapConformance data structure. As such, the examples in the two figures are fine as-is.