Hi, On 03.01.25 22:52, Jasdip Singh wrote:
[PK] I do not have very hard feelings about changing this MUST NOT but there will be consequences, that MUST NOT will block those extremely marginal but VALID cases (like the one I mentioned above, but maybe some others that do not come to mind now) creating possibly more harm, like a very new identifier instead of an editorial case correction. Possible harm of "strong" and narrow defined SHOULD NOT seems to be less. This goes through DEs review anyway, so they can definitely make the right call.https://github.com/anewton1998/draft-regext-rdap-extensions/issues/50 >> Section 2.2, paragraph 4>> [RFC7480] does not explicitly state that extension identifiers are case-sensitive. This document updates the formulation in [RFC7480] to explicitly note that extension identifiers are case-sensitive, and extension identifiers MUST NOT be registered where a new identifier is a mixed-case version of an existing identifier. For example, if "lunarNIC" is already registered as an identifier, a new registration with "lunarNic" (note the lowercase if "ic" in "Nic") would not be allowed.> In the first reading of it, it seems inconsistent why one would want to have case-sensitive handling and on the other side forbid registering case-insensitive variants.[JS] We meant to note “extension identifiers are case-insensitive”.> It would be good to consider if defining them case-insensitive makes any harm and if yes state it here. Then forbidding registration of case-insensitive variants would only have a meaning of avoidance of potential miscommunication, but notnecessarily any technical rationale. Technical systems deal with it pretty well to make a difference and none of the places where extension identifiers are used (JSON elements, path segments, query parameter names) are case-insensitive innature. And if only human communication is concerned, the question remains why someone sane would ever try to do it. And if he tries maybe the reasons are valid ones, like re-thinking the naming strategy of the same extension from lunarNIC to lunarNic? Then maybe worth softening MUST NOT to SHOULD NOT?[TH] I think any potential benefits of SHOULD NOT here are extremely marginal, such that MUST NOT is fine.
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
