Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

[Andrew Newton <[e-mail]>]

On Tue, Jul 19, 2022 at 12:21 PM Mario Loffredo
<[e-mail]> wrote:
>
> HI Andy,
>
> In my opinion, it doesn't work when the extension is related to a
> specification defined out of the RDAP context but is used in RDAP such
> as JSContact or VCARD itself. In this case, a server can simply update
> the hint in rdapConformance to signal that a new version of the external
> specification is supported.

Excellent point. I need to read the existing drafts more carefully,
but my initial thought is that extensions created via IETF consensus
(i.e. this working group) can define JSON members that do not strictly
adhere to the prefix identifier if no other way can be found. We
really want to avoid ExampleNicA and ExampleNicB colliding with their
own custom extensions. However, the standards of this WG are
well-known so there should be some latitude.

Off the top of my head, the criteria needed for this exception should be:

1. standards track proposal with IETF consensus
2. does not conflict with any currently registered extensions
3. cannot be accomplished otherwise
4. specification must clearly enumerate this exception


> As a matter of fact, we have already done it (even if unconsciously)
> without either passing from "rdap_level_0" to "rdap_level_1".
>
> I'm referring to the fact that the RDAP response format has indirectly
> been extended to support the VCARD CC parameter when RDAP responses were
> already provided by servers and consumed by clients.

That's probably something that should be fixed if we care. I don't. :)

-andy