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 not necessarily 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 in nature. 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.
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
