Differences between RFC 6067 and UTR 35 Unicode extension canonicalization

[anba]

When comparing https://tools.ietf.org/html/rfc6067#section-2.1.1 against https://www.unicode.org/reports/tr35/#u_Extension, UTR 35 contains the following two additional canonicalization steps:

• All keys and types use the canonical form (from the name attribute; see Section 3.6.4 U Extension Data Files).
• Type value "true" is removed.

The current proposal only implements canonicalization per RFC 6067. We should document the difference between RFC 6067 and UTR 35.

I'm not sure if we want to apply the canonicalization steps from UTR 35, because while removing "true" type values is easy, the requirement to replace deprecated keys and types requires more thought. For example when the time zone tz Unicode extension key is canonicalized, we may want to ensure the result is consistent with 6.4.2 CanonicalizeTimeZoneName.

[littledan]

It's curious that these don't quite match. Let's discuss the mismatches at the next Intl meeting for more context.

[srl295]

@yumaoka @aphillips ?

[yumaoka]

I agree 'Type value "true" is removed." is a mismatch. Not 100% sure the first point - related to deprecation - is a deviation, but I think it should be clearly stated somewhere.

[littledan]

@yumaoka Which alternative should ECMA-402 select among the mismatch about whether "true" is removed?

[aphillips]

I think ECMA-402 should remove true: it makes the tag longer and adds no value. The RFC was written before that behavior was defined.

[littledan]

OK, from @aphillips and @yumaoka's comments, it sounds like we should just reference UTS 35.

For example when the time zone tz Unicode extension key is canonicalized, we may want to ensure the result is consistent with 6.4.2 CanonicalizeTimeZoneName.

Not sure if here, you might be referring to possible slight differences between the time zone normalization from the tz database and CLDR (I don't know about these differences, but IIRC you've filed bugs about this sort of thing in the past). If so, I'd imagine that these edge case database differences don't matter so much and it should be OK to use the database of CLDR in an practical implementation. I'd be interested in any other thoughts on that topic.