On Wed, Jun 7, 2017 at 12:16 PM, Jet Villegas <jville...@mozilla.com> wrote: > SGTM,
Thanks. > Thanks for pushing on this one. > > One comment: although this is a proposed change to non-normative spec > text, it appears that several implementations already implement the > original (also non-normative) recommendation. Would it be worthwhile > to propose the reversal and also mark the section as normative? It seems to me that this episode has revealed that the Unicode Consortium doesn't have an objective way to deem one way of doing things as clearly the best one, so it seems to me that there's a better chance of Unicode toning down the language expresses a preference to make it a lesser preference (by calling it something lesser than "best practice" going forward) and it seems to me that there wouldn't be Unicode-level agreement of elevating the old or the new preference to a requirement on the Unicode level. The WHATWG spec would continue to make the old Unicode preference required, so I think it's an OK outcome for the requirement to live in the WHATWG spec and Unicode preferring the same thing (i.e. reverting the change to the preference) in weaker terms than so far. Letting it be this way wouldn't invite objections from non-Web-oriented implementors who implement something else that's currently within Unicode compliance and who don't want to change any code. > --Jet > > On Wed, Jun 7, 2017 at 2:11 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> (If you don't care about the details of UTF-8 error handling, it's >> safe to stop reading.) >> >> In reference to https://hsivonen.fi/broken-utf-8/ , I think it would >> be appropriate to submit that post to the Unicode Consortium with a >> cover note asking the Unicode Technical Committee to revert their >> decision to change the preferred UTF-8 error handling for Unicode 11 >> and to retract the action item to draft corresponding new text for >> Unicode 11 for reasons given in the post. >> >> I think it would be preferable to do this via Mozilla's liaison >> membership of the Unicode Consortium rather than me doing it as a >> random member of the public, because submission via Mozilla's liaison >> membership allows for visibility into the process and opportunity for >> follow-up whereas if I do it on my own, it's basically a matter of >> dropping a note into a one-way black box. (It seems that this kind of >> thing is exactly what Mozilla's liaison membership is for.) >> >> However, submitting via Mozilla's liaison membership raises the >> question of whether the submission would properly represent a Mozilla >> consensus. I estimate this to be noncontroversial, because deliberate >> effort has been expended to make the Mozilla-affiliated >> implementations that I am aware of (uconv, encoding_rs and the Rust >> standard library) behave according to the pre-Unicode 11 version of >> the guidance either directly by looking at the Unicode Standard or by >> the way of implementing the WHATWG Encoding Standard, which elevates >> the pre-Unicode 11 preferred approach into a requirement. >> >> If I have mis-guessed that the above-contemplated submission should be >> non-controversial from the Mozilla perspective and you believe that >> the above-contemplated submission should not be made via Mozilla's >> liaison membership, please let me know. >> >> (My understanding is that a reversal of the decision is quite >> possible, but actually making the above-contemplated submission is a >> process prerequisite for a reversal to take place.) >> >> -- >> Henri Sivonen >> hsivo...@hsivonen.fi >> https://hsivonen.fi/ >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
