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, [email protected] 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 <[email protected]> *Sent:* Wednesday, February 12, 2025 11:59 AM *To:* Andrew Newton (andy) <[email protected]> *Cc:* [email protected]*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 -- [email protected] To unsubscribe send an email to [email protected]
