I don’t view the use of a bare identifier as being a bad practice, since the goal is to ensure that the identifier is registered and there are no conflicts. If there are more than one property used for the identifier, then it would be best to include the use of the underbar and a value. This is planned for the versioning extension to include “versioning_data” and “versioning_help” in place of the bare identifier “versioning” and the non-bare “versioning_help”. For the “redacted” property in RFC 9537, I see no issue with the use of the bare identifier “redacted” when there is only one property used.
What concrete benefit is there to disallow bare identifiers when the extension identifier only has a single property? I personally don’t see a benefit that warrant’s a MUST NOT or even a SHOULD NOT in the extensions draft. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Pawel Kowalik <kowa...@denic.de> Date: Tuesday, May 20, 2025 at 4:57 AM To: "Hollenbeck, Scott" <shollenb...@verisign.com>, "a...@hxr.us" <a...@hxr.us>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] Re: On bare identifiers in Extensions draft Hi, <no hats> Refreshing this thread, as the show of hands in the interim meeting [1] showed no consensus for forbidding bare identifiers. IMHO the changes done in -05 draft and then made deeper in -06 should be reverted to reflect the current status quo of RFC 9083 until we have a clear consensus to change it. As the exchange so far on the topic only involved few WG members it would be good so see other pople speak up to have a wider perspective. [1] https://datatracker.ietf.org/meeting/interim-2025-regext-01/materials/minutes-interim-2025-regext-01-202505081700-00<https://secure-web.cisco.com/1JRlAuWqZLkDcA3n_AHm35yAqiv4uwlnGkJJjTQeqlQCywbK-1ZcaVORBopuoZtcxCIb0Aq3cQ7WLHcAapZrKt6BZE3z2uJDbXKA96lY3qYZIffOfF56fwJQDIQrRBprypDeGmYe-EWGJRDrEQ29V2DOPkNcwu2FPVxE4uIUjQ4aTEMeoEhB3lsnx4HDI3Zdt4ziJE5hyA-3fnm7inANItq0azGuLrsdCtdPDBtSMsijAxUBV4gb8NaPdbcVAy_h3Z2i8hcuAm2QLNCapIJYiWPbwenAQpFNnwnhIA1U9hgA/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2Finterim-2025-regext-01%2Fmaterials%2Fminutes-interim-2025-regext-01-202505081700-00> Kind Regards, Pawel On 12.02.25 18:14, kowa...@denic.de<mailto:kowa...@denic.de> wrote: Hi Scott, On 12.02.25 18:06, Hollenbeck, Scott wrote: From: Pawel Kowalik <kowa...@denic.de><mailto:kowa...@denic.de> Sent: Wednesday, February 12, 2025 11:59 AM To: Andrew Newton (andy) <a...@hxr.us><mailto:a...@hxr.us> Cc: regext@ietf.org<mailto:regext@ietf.org> Subject: [EXTERNAL] [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-05.txt Hi Andy, On 12.02.25 17:06, Andrew Newton (andy) wrote: Allowing bare identifiers still leave the choice open for extensions which have a potential of generic use. Why does requiring a prefix preclude generic use? Of course technically nothing, because syntactically a prefixed identifier is also an identifier. On the other side, if an extension only wants to add one single path segment /search/ what's good about forcing this extension to make it /s_search/ just for the sake of making "s_" a namespace with one single suffix in it? [SAH] Because there’s value in consistency. [PK] True. In this case by introducing consistency we actually break consistency with existing extensions, some of them being RFCs. So I argue it's not worth it. It's not something that is broken that needs to be fixed. Kind Regards, Pawel
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
