I get the ease on development to identify an extension property, but I don’t view it as a showstopper. I would change the MUST NOT to a SHOULD NOT for providing guidance.
-- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: "Hollenbeck, Scott" <[email protected]> Date: Wednesday, May 21, 2025 at 3:14 PM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [EXTERNAL] [regext] Re: On bare identifiers in Extensions draft From: Gould, James <[email protected]> Sent: Wednesday, May 21, 2025 2:39 PM To: [email protected]; Hollenbeck, Scott <[email protected]>; [email protected]; [email protected] Subject: Re: [EXTERNAL] [regext] Re: On bare identifiers in Extensions draft 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. [SAH] One thought: it makes it easier to identify extension elements by being able to recognize the “_” character as a separator. When I wrote my federated authentication stub server, it made it a little easier to parse identifiers when there was a reliable character separator. Without that separator, I would have had to use explicit string pattern matching to separate extension elements from core elements. It wouldn’t have been impossible, but I would have found it slightly less efficient. Scott
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
