Since this topic is coming up in the reverse search discussion, but isn't 
unique to reverse search, I thought it best to start another topic.

Section 6 of RFC 7480 introduces the concept of "an IANA registry for prefixes 
used in JSON [RFC7159] data serialization and URI path segments (see Section 
8)". "lunarNic" is given as an example in Section 8. I cannot, though, find 
any mention of a MUST when it comes to using these prefixes for data 
structures or URI path segments, though Section 8.1 says this:

"The extension identifier is used as a prefix in JSON names and as a prefix of 
path segments in RDAP URLs."

RFC 9083 is more definitive. From Section 4.1:

"When custom JSON values are inserted into responses, conformance to those 
custom specifications MUST use a string prefixed with the appropriate 
identifier from the IANA RDAP Extensions registry specified in [RFC7480].  For 
example, if the fictional Registry of the Moon wants to signify that their 
JSON responses are conformant with their registered extensions, the string 
used might be "lunarNIC_level_0"."

Note the use of MUST here. Section 5 of RFC 9082 contains similar text:

"Custom path segments can be created for objects not specified here using the 
process described in Section 6 of "HTTP Usage in the Registration Data Access 
Protocol (RDAP)" [RFC7480].

Custom path segments can be created by prefixing the segment with a unique 
identifier followed by an underscore character (0x5F). For example, a custom 
entity path segment could be created by prefixing "entity" with "custom_", 
producing "custom_entity"."

After re-reading all of this, my take is that extensions MUST tag new data 
structures and path segments with the prefix that's registered with IANA. That 
means I'm going to have to change the data structures and path segments in 
draft-ietf-regext-rdap-openid (I'm probably going to change the prefixes to 
something shorter to make them a bit less clunky). Other extension 
authors/editors should review their documents and provide their own 
assessments.

Scott

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to