The spec currently mandates that $$ear-extension and $$ear-appraisal-extension are maps. The intent seems to be to encourage bunching of multiple claims under one top-level codepoint, to minimize registration namespace pollution.
However, the need to register claims already provides the pressure to do that, without needing to mandate it as a universal constraint. Additionally, this does not matter for private ranges. Finally, this is counter to how similar extension mechanisms work for CoRIM and PSA tokens (other EAT-based standards that allow extensions).
This constraint is unnecessary and should be removed. It should be replaced with a recommendation that for non-private claims, maps should be used to group multiple claims under a single top-level key (essentially, an application name space) to minimise the use of the public codepoint namespace.
The spec currently mandates that
$$ear-extensionand$$ear-appraisal-extensionare maps. The intent seems to be to encourage bunching of multiple claims under one top-level codepoint, to minimize registration namespace pollution.However, the need to register claims already provides the pressure to do that, without needing to mandate it as a universal constraint. Additionally, this does not matter for private ranges. Finally, this is counter to how similar extension mechanisms work for CoRIM and PSA tokens (other EAT-based standards that allow extensions).
This constraint is unnecessary and should be removed. It should be replaced with a recommendation that for non-private claims, maps should be used to group multiple claims under a single top-level key (essentially, an application name space) to minimise the use of the public codepoint namespace.