Hi James,
On Mon, May 23, 2022 at 07:26:39PM +0000, Gould, James wrote:
> In reviewing the thread below, I'll summarize my thoughts below that
> goes along with my response with Approach C to Jasdip:
Thanks for this summary.
> 1. It looks like there is consensus that the existing language in
> the RDAP RFCs is unclear and there is a mix of cases that exist in
> the RDAP Extension Registry. Creating something like the
> Guidelines for Extending the Extensible Provisioning Protocol
> (EPP), in RFC 3735, is needed for RDAP.
> 2. It looks like there is consensus that the RDAP Extension
> Registry ensures uniqueness of the identifiers and prefixes used
> by the extensions for the rdapConformance, URI path segments, and
> JSON response members. I believe the values of the
> “objectClassName” needs to be included as well to support the
> definition of new RDAP objects.
> 3. It doesn’t look like there was an explicit attempt to define a
> namespace feature in RDAP, like what exists with XML namespace
> URIs and XML namespace prefixes. The only version signaling is
> handled by the rdapConformance member of the JSON response. Based
> on the practice that we followed with EPP extensions, we’ve been
> using pointed version numbers (“0.1”, “0.2”, “0.N”) for the
> namespace URIs up until the draft passed WGLC, resulting in
> bumping the version to “1.0”. Supporting pointed version numbers
> has proven to be useful during the development of the EPP
> extensions, but since the ABNF in RFC 7480 doesn’t support the use
> of a ‘.’, the ‘_’ needs to be used instead for pointed version
> numbers.
> 4. For draft-ietf-regext-rdap-redacted, I view the registration
> of the extension identifier “redacted_level_0_3” (target of
> “redacted_level_1” after WGLC) that is returned in RDAP
> Conformance as meeting the signaling needs. The registration of
> the prefix “redacted” ensures uniqueness of the member included in
> the JSON response. This could be addressed with the single RDAP
> Extension Registry registration of “redacted”, where the
> specification formally defines the full version included in the
> rdapConformance member, but I feel inclusion of the separate full
> identifier registration as being more explicit for signaling.
> What happens when there is version 2 of the redacted extension,
> should the RDAP Extension Registry only reference the latest
> specification for the “redacted” prefix used in the
> “rdapConformance”, or would it be better to include two versioned
> identifiers (“redacted_level_1” and “redacted_level_2”) that link
> to the associated specification in the RDAP Extension Registry? I
> believe having both versions in the RDAP Extension Registry
> provides benefit to the client. I recommend updating the
> registered prefixes for the extension with the latest
> specification.
Here is a summary of my thoughts:
- Clarifying/changing how extensions are supposed to work, and how
the relevant registry (or registries) function, are good ideas. At
least in principle, the suggestions you and others have made around
versioning, backwards compatibility, etc. sound reasonable.
- The current text appears to require that:
- only the extension identifier is registered;
- the exact value of the extension identifier is included as an
rdapConformance value in order to indicate conformance with the
extension;
- the extension identifier must be used as a prefix for new fields
and path segments defined by the extension; and
- path segments may have a 'null suffix'.
- In the absence of a document that clarifies/changes how extensions
work, extensions should conform with the existing text as far as
possible, even if that involves annoyances/limitations. In the
case of the redacted document, that points towards using 'redacted'
as the extension identifier and the rdapConformance value, and the
new 'redacted' field having its name changed to something like
'redacted_data'. Updates would be handled by registering a new
extension with a name like 'redacted_2' or similar (with the
rdapConformance value and field name changing accordingly).
- The 'simplest' path to getting most of what you're looking for is
to 'restore' the (apparent) original intent around extension
identifiers as prefixes, by submitting an erratum to 9083. There
doesn't appear to be much interest in this approach, though (and it
looks like there was a plan to remove it from the original
documents, too).
Regarding consensus, I can see the general interest in changing how
extensions are supposed to work, but I'm unsure if there is consensus
on not conforming with a 'strict' reading in the meantime, given e.g.
https://mailarchive.ietf.org/arch/msg/regext/7Rd2WidweaFtXdPlRlmSwO15BEw/.
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
