On 2/1/23 6:17 AM, Corey Bonnell wrote:
I think it would be unfortunate if the usage of terms that are defined in RFC 5890 is not aligned with their definitions.If we are not opposed to introducing new terminology to the document, then I suggest the following: 1. Replace all instances of "A-label" with the term "P-label" from the CABF Baseline Requirements [1]: "P-Label: A XN-Label that contains valid output of the Punycode algorithm (as defined in RFC 3492, Section 6.3) from the fifth and subsequent positions." 2. For U-label: a. Punt and call it "Unicode representation" instead (this is what the CABF Baseline Requirements does, although that may not be appropriate for this document). b. Create a new term that is defined as "A non-LDH label that contains valid output of the decoding algorithm for Punycode (as defined in RFC 3492, Section 6.2)." and use this new term instead of "U-label". I'd be happy to work on concrete text to this effect if there's agreement this is a good path to resolve the issue.
I would very much like to hear what John Klensin and Patrik Fältström (cc'd) think about this proposal.
As noted in my other message <https://mailarchive.ietf.org/arch/msg/uta/92tKoHT3Kjll1o_mCYQYQT8xON4/> I'm not immediately comfortable with referencing a CA/Browser Forum document instead of RFC 5890.
Having looked at Corey's proposal more closely, I'm doubly unsure because (a) it is not fully clear to me how the P-label construct differs from the A-label construct in RFC 5890 and (b) coming up with new DNS-related terminology in a late-stage document about certificate validation just seems like a bad idea (e.g., I'm not sure how to get proper review) even if it were necessary (which I'm not sure it is).
Peter _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
