"key" is defined as
key = alphanum alpha ; = alphanum ALPHA
But in page 4 of https://www.ietf.org/rfc/rfc6067.txt
" A. A 'key' is a subtag with a length of exactly two characters.
Each 'key' is followed by zero or more 'type' subtags.
Markus Scherer wrote in 27 Dec 2018, 12:27
"AFAIK the u key and the t tkey are deliberately disjoint.
A Unicode extension key is alphanum alpha, so always ends with a letter.
A Transform extension tkey is alpha digit.
Neither allows digit digit. I suppose that could be available for another future extension.
Frank: "Notice the title of https://www.ietf.org/rfc/rfc6067.txt is "BCP 47 Extension U". So the issue is two different spec BOTH about u extension- RFC6067 and UTS35, have different definition."
Markus Scherer wrote in 27 Dec 2018, 15:50
"That seems like a problem :-/
Please submit a CLDR ticket.
Although, "two characters" is vague, and the LDML spec is narrower rather than broader, so maybe it's ok."
Mark Davis wrote in 9 Jan 2019, 07:41
We decided in CLDR to make the u and t keys be disjoint, as Markus said.
key = alphanum alpha ;
tkey = alpha digit ;
key can be 0a or aa;
tkey can be a0;
We could allow key to also be 00 and still be disjoint. I'd have no objection if you want to file a ticket. However, 00 would still be invalid (though well-formed)."
"My point is the definition between RFC 6067 and UTS35 is now different. If CLDR decide to be more restrict, I think it is better to explicitly mention in UTS about that so reader will know it is an intentional decision not an error/typo. I am not suggesting to change the definition of UTS 35 one way or the other. "
Markus Scherer wrote in 9 Jan 2019, 11:34
"Good idea to document that UTS #35 is narrower than the RFC. That's what we would need a CLDR ticket for.
I agree that it's not necessary to broaden the LDML spec to allow "digit digit" for key or tkey. I would keep that combination reserved for some future use (e.g., another extension)."