Hi Tom,
I really appreciated your effort in grouping the rdapConformance tags
defined so far because I have always thought that there should be a
document addressing the relationship between the rdapConformance tags
and the proposed extensions.
Therefore, I encourage you to submit such document to the WG and I'll
support its adoption.
My opinion is that the part of the rdapConformance tag about the version
number (e.g. _0 or _level_0) should be left out from the possible rule
tying the tag and the related extension for the following reasons:
1) A version number can be (normally is) a sequence of numbers separated
by dots. The rdap-redacted document presents a similar case (i.e.
"redacted_0.1").
But a label including dots used as either the prefix or the exact match
of an RDAP response extension couldn't be deserialized
straightforwardly. Nothing particularly difficult to work around by
using annotations or custom deserialization but why should we introduce
such a complication?
2) Supposing that a subsequent version might change the structure of an
existing response extension (maybe by adding some members), the backward
compatibility should be guaranteed as much as possible.
It seems to me that including the version number as part of the name of
a JSON field could cause breaking changes in the response structure.
3) Any subsequent version of an extension to requests and responses
would cause both path segments and response fields to be renamed each
time even if the update involved only one of them.
My conclusion is that, at least as regards response extensions, your
rule could be arranged as in the following:
/- An rdapConformance tag contains the extension identifier and,
optionally, the version number separated by "_" or "_level_" //
/
/- New fields (if present) must be prefixed with the extension identifier/
Finally, I'm very doubtful if it's worth having a similar rule about new
paths but, at the same time, very curious to know others' opinions on
this topic.
If there was consensus on applying your rule, the rdap-reverse-search
document should be slightly changed, instead the rdap-openid document
should be updated much more.
Best,
Mario
Il 28/04/2022 02:45, Tom Harrison ha scritto:
Hi Mario,
On Tue, Apr 26, 2022 at 08:17:18AM +0200, Mario Loffredo wrote:
Il 25/04/2022 00:55, Tom Harrison ha scritto:
The structure looks fine to me, but assuming that the
"reverse_search_properties" field name is prefixed with
"reverse_search" because of the "reverse_search_0" rdapConformance
value, then either the field name should be
"reverse_search_0_properties", or the rdapConformance value should
become "reverse_search", so that the field is prefixed with the entire
rdapConformance value.
(Semi-related: on looking at the relevant rdapConformance content in,
7480 has (section 8.1):
The extension identifier is used as a prefix in JSON names and as
a prefix of path segments in RDAP URLs.
[ML] According to the response extension example in RFC9083 (see
"lunarNIC"), the prefix does not include the version info (in that case
"_level_0").
Therefore, it seems better to call the metadata field
"reverse_search_properties".
The same rule has been followed for the "redcated" extension.
I'm not sure this is the right way to go. The current set of
registered extensions can be grouped together like so:
- 1.
- rdapConformance is an exact match for the extension identifier
- 1.1
- New fields are prefixed with the extension identifier
- New paths are prefixed with the extension identifier
- arin_originas0
- 1.2
- New fields are prefixed with the extension identifier
- No new paths are defined
- cidr0
- paging
- sorting
- subsetting
- 1.3
- rdapConformance is an exact match for the extension identifier
- No new fields are defined
- No new paths are defined
- icann_rdap_response_profile_0
- icann_rdap_technical_implementation_guide_0
- nro_rdap_profile_0
- nro_rdap_profile_asn_flat_0
- nro_rdap_profile_asn_hierarchical_0
- rdap_objectTag
- redirect_with_content
- 2.
- rdapConformance is prefixed with the extension identifier
- 2.1
- New fields are prefixed with the extension identifier
- New paths are prefixed with the extension identifier
- fred
- 2.2
- New fields are prefixed with the extension identifier
- No new paths are defined
- artRecord
- platformNS
- regType
The extensions in category 2 are not registered correctly, inasmuch as
the rdapConformance value used for the extension must be an exact
match for the extension identifier in the registry, as opposed to
being prefixed with the extension identifier (see e.g.
https://www.rfc-editor.org/errata/eid6310). If the rdapConformance
value in each of those cases were updated to be the extension
identifier, then each extension in category 2 would fall into the
corresponding subcategory in category 1, and the rules followed by
every extension would then be:
- rdapConformance is an exact match for the extension identifier
- New fields (if present) are prefixed with the extension identifier
- New paths (if present) are prefixed with the extension identifier
which aligns (IMHO) with the previously-quoted text from RFC 7480, as
well as the following:
6. Extensibility
For extensibility purposes, this document defines an IANA
registry for prefixes used in JSON [RFC7159] data serialization
and URI path segments (see Section 8).
as well as guaranteeing that different extensions occupy different
namespaces, which has other positive effects (e.g. a client seeing an
unknown rdapConformance value could extract all fields/paths prefixed
with that rdapConformance value from the response, for further review
by a user).
It's true that the above reading does not accommodate the use of
lunarNIC in RFC 9083, where the rdapConformance value includes
_level_0 but the fields are prefixed with lunarNIC only. However, an
alternative set of rules which covered the use of lunarNIC in that
document would be:
- rdapConformance is an exact match for the extension identifier
- New fields are prefixed with an arbitrary string, defined in the
extension
- New paths are prefixed with an arbitrary string, defined in the
extension
which is considerably less useful for clients. Since the lunarNIC
case seems like the exception rather than the rule, I think it makes
sense to use the former reading, at least for extensions that are yet
to be finalised. (Assuming the lunarNIC text is incorrect, possibly
it can be addressed by an erratum, and even if the category 2
extensions can't be changed now, at least the set of extensions in
that category doesn't have to expand.)
-Tom
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
