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
Kind Regards, Pawel On 12.02.25 18:14, kowa...@denic.de wrote:
Hi Scott, On 12.02.25 18:06, Hollenbeck, Scott wrote:[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.*From:* Pawel Kowalik <kowa...@denic.de> *Sent:* Wednesday, February 12, 2025 11:59 AM *To:* Andrew Newton (andy) <a...@hxr.us> *Cc:* regext@ietf.org*Subject:* [EXTERNAL] [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-05.txtHi 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./*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
