On 10/3/24 13:15, Mario Loffredo wrote:
Il 03/10/2024 14:39, Gould, James ha scritto:
Andy & Mario,
As far as how to handle “rdap_level_0”, this is applicable to both
draft-ietf-regext-rdap-x-media-type and
draft-ietf-regext-rdap-versioning, where we should be consistent.
Based on the possibility of draft-ietf-regext-rdap-extensions having
to update RFC 7480, RFC 9082, and RFC 9083, this raises the
possibility of needing “rdap_level_1” and supporting the signaling
capability. I believe it makes sense to register “rdap_level_0” in
the RDAP Extensions Registry as a special extension identifier, which
really represents the default namespace for all the objects and
members defined in RFC 9083. There is no implied relationship
between opaque versioning identifiers, so that may be something that
can be considered in draft-ietf-regext-rdap-versioning, since
“rdap_level_0” and “rdap_level_1” are mutually exclusive and there
needs to be a default defined by the server that can be reflected in
the versioning extension. The help response with the
draft-ietf-regext-rdap-versioning extension does include information
associated with the default version, but that currently applies to
the “semantic” versioning and not the “opaque” versioning. Should
draft-ietf-regext-rdap-versioning support the concept of
relationships between opaque version identifiers with the ability to
specific the default opaque version identifier?
Sounds reasonable to me.
Mario
TBH, it might be a good idea to expand the scope of this document
further to include other server info such as the software version and
something similar to NSID. Such things would greatly help with
troubleshooting.
-andy
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
