Actually I would be in favour of restoring the text of -04 2.4.5 with an explicit update to RFC9083 allowing the bare identifier pattern (which also would solve the issue of justification when SHOULD NOT could be broken and DE review interpretation issue). Contrary to other cases brought up by Andy (I-JSON, Unichars) I think this update would be OK in this draft, as it only affects extensions.
Kind Regards, Pawel On 21.05.25 22:26, Gould, James wrote:
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 draftI 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/*
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
