David, At this point, there isn't even _one_ way that is experimental, informational, draft standard, or standard. The shibboleth of interoperability is reasonable to raise, when, even if, we get to one "standard" (other than ASCII-as-ASCII).
Could we, using the rational offered, fix the requirements draft? Someone (guess who) is rather likely to claim there is consensus for the current draft as is. Ergo, it can never be fixed, even if 21 contributors ask nicely. Personally I don't think that first-come, first-served works well enough to bother with in consensus-rigging. Taken in self-evident bad faith, it leads to rubber-stamps, and premature versioning. If you want to observe that there was consensus prior to there not being consensus, and therefore that there is consensus, be my guest. Fixing the process is in 2026, and anyone can assert that something we could have fixed _in_ the working group, must be fixed _in_ the IESG, (or the IAB), or not in the IETF at all. Longer route, same end. I like the style of "This idea is totally without merit." Feel free to use it again in the future. > This idea is totally without merit. None of the proposed IDN protocols > work if there are two ways to do ACE encoding, and not specifying which > will be used would be disastrous for interoperability. > > Since the current specification for the concensus ACE algorithm > (draft-ietf-idn-amc-ace-z-01.txt) does not include reordering, and there is > no concensus on adding it, that document should remain as it is. (If AMC-Z > is used, that is the only document that depends on a decision about > reordering.) Cheers, Eric
