--On Wednesday, 23 July, 2014 07:12 +0200 Patrik Fältström <[email protected]> wrote:
> > On 22 jul 2014, at 20:27, Andrew Sullivan > <[email protected]> wrote: > >> On Tue, Jul 22, 2014 at 02:16:39PM -0400, Marc Blanchet wrote: >>> - maybe it will be better to have different experts so that >>> they look at the problem with different eyes (in this >>> context, more eyes is a feature). but they would be better >>> to coordinate. not sure it needs to be written >> >> I think it would be _terrible_ to have different experts >> here, unless there's an interlock between then registries. >> If there are two experts, they might draw different >> conclusions. Indeed, John, Patrik, and I all came to >> different conclusions about the most recent version of >> Unicode, and it was only after considerable discussion that >> Patrik and I understood what John was worried about. >> Different decisions between the experts would be extremely >> bad. >> >> I know there's a hurry to get this out, but hoping the >> experts get it right if there's no interlock is too dangerous. > > Being the appointed expert for IDNA, I would like to say I > would LOVE to have a 2nd person for among other reasons the > reasons Andrew list above. > > That said, I think the appointed experts should get > instructions to _communicate_with_each_other_ (!!!) and > synchronize in a coordinated way with IANA. This to solve the > issues I think Pete was thinking of addressing by having one > and only one person. > > I am expert on IDNA, and possibly one person with clue on > Unicode. > > Not Precis. > > But with that knowledge, of course I am happy to continue to > help IETF as much as I can. Let me suggest that everyone quoted above is correct, but the solution is a little bit different. I think the solution, hinted at in Andrew's note, is that "the expert" be a team of several people, with different but complementary knowledge, working together to conduct a review for IDNA and PRECIS together. They are finished only when they agree, either that no changes are needed or on a single set of changes. We have now discovered a Unicode change issue that requires careful human attention to detect and that cannot possibly be detected by simple running of different implementations of a test suite/ validation procedure. When we set up the expert procedure IDNA2008, we assumed that table-running with independent implementations would be all that is necessary, but that was based on assumptions that weren't true (sorry, but anyone who wants to understand that case needs to read draft-klensin-idna-5892upd-unicode70 -- I'd recommend waiting for -01, which should show up sometime next week (possibly sooner) with some additional clarifications). Because the algorithms are not sufficient (tghey are still necessary and very important), the need for multiple people, with multiple perspectives, to look carefully at new Unicode versions should be clear. I think experience from this round indicates that that expert pool be at least three people (again, with different backgrounds and perspectives). Probably more than five would become unwieldy. Because we seem to have disagreement on this subject, I believe there is now a requirement that the "IANA Considerations" section of "precis-framework" specify explicitly that: * There must be an expert team (or one expert and designated advisors), appointed as usual by the IESG, with at least three members, with diverse backgrounds and a recommended upper limit on membership of five or six. * That expert team is responsible for the reviews required by both PRECIS and IDNA, precisely because the base rules and categories, are expected/required to be the same (note Peter's comment yesterday that, if the copies of the rules and categories used in PRECIS IDNA were different from those of IDNA, that was a bug that needed fixing). * The experts are finished, and IETF protocols ready to safely use a new version of Unicode, without risk of strings that are valid being disallowed, only when they agree (even if that agreement requires agreeing to disagree on details but move forward). I'm happy to work with Peter on specific text for the document if needed. I can't stress how important this is. If we don't have agreement on it, some assumptions that were critical to yesterday's agreement and consensus are false and the consensus is meaningless. If we have different experts with nearly-final authority for different protocols, it takes us back into exactly the situation we discussed yesterday -- the base exception lists, tables, and allowable characters of IDNA and PRECIS will diverge (whether they are the same today or not). That is different from the "profiles", which I would like to think of as per-protocol exception lists from a base category and rule collection, being different -- that latter is something we have to live with for historical or specialty reasons. If our intent is to design things to allow that divergence to occur, then yesterday's discussions about avoiding divergence for user confusion and maintainability reasons and maybe the one about having a clear interface for applications developers haven't had any effect, perhaps suggesting that some of those who agreed to them didn't understand them. regards, john (even, if PRECIS persists in establishing mappings, pro _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
