Hi Andy, On 02.04.25 16:31, Andrew Newton (andy) wrote:
[PK] 2.1 of RFC9083 does provide enough of qualification so doing nothing is also in my eyes a valid option.[...]In fact "the rules" set in 2.1 of RFC9083 are no rules, but a recommendation (SHOULD) itself. So I argument actually to keep the status quo of RFC9083 as opposed to defining new rules as now the change of -05 proposes.I agree that a SHOULD without a qualification as to the consequences of not following that SHOULD are not really rules. And that is the fundamental issue. We have to qualify that SHOULD otherwise it because a MUST.
Also in the original E-mail you mentioned "complex set of rules" that hinder interoperability without actually any evidence which these are or would be. I went though all changes in -05 and I didn't find any point where the rules got simplified in any way.The complex set of rules are upon the extension authors and the designated experts approving extension registrations. By simplifying the rules for writing extensions, we decrease the chance that an extension has interoperability issues.-05 does not contain the simplifications. This was a proposal I suggested after addressing the 22 issues that got us to -05. We can produce an -06 with the simplifications for comparison.
[PK]I think this would help the discussion to see those.Also talking about 22 issues seems an amplification to me, as one may think all those were related to bare identifiers. If I recall well, being an author of most of those reported issues, that maybe 2 or 3 of them were anyhow related. Worth noting that the most complex rules are defined to exclude conflicts of identifier prefixes (Section 2.2, paragraph 3, Issue #49). In my eyes still underspecified. Bare identifiers are very simple in handling in comparison - either they are registered or not... just saying.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
