I'm going through the various issues of this draft in the issue tracker and think this conflicts with a previous change here: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/33
Also, I disagree with extension identifiers being case-insenstive. They very much are case-sensitive as they can often be found prepended to JSON names and in query paths, etc... Saying they are case-insensitive would cause interoperability issues. -andy On Thu, Jan 16, 2025 at 11:44 AM Jasdip Singh <jasd...@arin.net> wrote: > > Hi, > > > > From: kowa...@denic.de <kowa...@denic.de> > Date: Friday, January 10, 2025 at 12:58 PM > To: Andrew Newton (andy) <a...@hxr.us> > Cc: regext@ietf.org <regext@ietf.org> > Subject: [regext] Re: Extensions: Extension identifier case-insensitivity #50 > > Hi Andrew, > > On 10.01.25 17:54, Andrew Newton (andy) wrote: > > On Mon, Jan 6, 2025 at 8:53 AM <kowa...@denic.de> 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. > >> > > Unless I misread the thread, you gave a hypothetical scenario but not > > an example use case. Can you spell out something more concrete? > > Otherwise, I cannot see the value in having both "DeNic" and "DENic" > > registered as two separate identifiers. > > Maybe hypothetical, maybe not - depending where we land in all > discussions around camel case, all lowcase etc. > > [JS] IIUC, per our discussion on camel-casing so far, object class names will > also be camel-cased, like JSON names, to help differentiate better from the > extension identifier prefixed with an underscore. > > If the recommendation > would turn some of existing extensions to be on the wrong side then > changing case of an existing registration may be a real scenario. > > Anyway I don't want to spend too much time on this issue. > > [JS] To summarize our discussion on this topic so far: 1) Change “extension > identifiers are case-sensitive” (inadvertent) to “extension identifiers are > case-insensitive”. 2) Leave “extension identifiers MUST NOT be registered > where a new identifier is a mixed-case version of an existing identifier” > as-is since the marginal cases justifying a SHOULD NOT seem highly unlikely. > > > > Jasdip > > > > _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
