Change the ref grammar from RFC5646 to UTS35

[FrankYFTang]

This is following up #63 after the merging of #66

1. Change all the links from pointing to RFC5646 to pointing to UTS35 instead.
2. In Intl.Locale.prototype.baseName change langtag production -> unicode_language_id production.
3. Change all other 'XXX production' based on RFC5646 to 'YYY production' based on UTS35
   a. language production -> unicode_language_subtag production
   b. script production -> unicode_script_subtag production
   c. region production -> unicode_region_subtag production
   d. langtag production -> unicode_locale_id production (note: except 2 above)
   e. Remove the reference of "grandfathered production" (see 4 below)
4. Merge the step 4.a "If language does not match the language production, throw a RangeError exception." step 4.b "If language matches the grandfathered production, throw a RangeError exception." of ApplyOptionsToTag as only one 4.a "If language does not match the unicode_language_subtag production, throw a RangeError exception." since the definition of unicode_language_subtag in UTS35 already excluded ("4ALPHA" or "2*3ALPHA '-' extlang") and therefore all language which match grandfathered production is already "not match unicode_language_subtag)

@littledan @gsathya @zbraniecki @anba @macchiati @jungshik @aphillips @markusicu @nciric

[FrankYFTang]

@Ms2ger

[anba]

It doesn't seem like mentioning unicode_language_id is possible in all cases, because unicode_language_id doesn't include extension and privateuse sequences. There is also unicode_locale_id, which does include extension and privateuse sequences, but it also implies validating -t- transform extension sequences and I'm not sure we want to include this implied validation for -t- extensions in all cases.

[macchiati]

I agree that it should be unicode_locale_id instead. For -t- extensions, there are a few possible strategies. 1. explicitly say that -t- extension validity checking is optional (a complete "carve out") 2. require syntactic checking of -t- extensions (according the the EBNF), but not require validity checking of the keywords or values (I'd recommend this level; the data/code requirements are low.) 3. full validity checking of keywords & values Mark

…

On Wed, Dec 19, 2018 at 3:02 PM André Bargull ***@***.***> wrote: It doesn't seem like mentioning unicode_language_id is possible in all cases, because unicode_language_id doesn't include extension and privateuse sequences. There is also unicode_locale_id, which does include extension and privateuse sequences, but it also implies validating -t- transform extension sequences and I'm not sure we want to include this implied validation for -t- extensions in all cases. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJKyMMPkrKg3Kx4p3L4avkNB7ZDwkmJBks5u6kbqgaJpZM4ZZH-R> .

[FrankYFTang]

It doesn't seem like mentioning unicode_language_id is possible in all cases, because unicode_language_id doesn't include extension and privateuse sequences. There is also unicode_locale_id, which does include extension and privateuse sequences,

Opps ... good catch. I totally messed up. I intend to replace 'langtag' in RFC with 'unicode_locale_id' in UTS35 but somehow I messed up in this PR. Good catch. Will update my PR soon.

but it also implies validating -t- transform extension sequences and I'm not sure we want to include this implied validation for -t- extensions in all cases.

[FrankYFTang]

OK, I updated the PR to address the "unicode_language_id vs unicode_locale_id error" issues and also change the PR description to match the latest content in the PR.

The "validating -t- transform extension" issue is not yet addressed. Should we merge this PR without address that first? and handle that in a follow up PR?

[littledan]

This PR looks good to me. It seems reasonable to do some parts in a follow-on.

[littledan]

Nit: this seems to work as https, so let's use that.

[FrankYFTang]

DONE

[littledan]

You missed https here and in a few other places below

[FrankYFTang]

opps! sorry

[FrankYFTang]

ping. Can we merge this?

[littledan]

If anyone sees any issues with what's merged, please keep commenting.