James, Your note of the 23rd got exactly one response -- David Hopwood's, who offered the text present in your final version's first change, but has no compelling value to motivate a "rechartering".
Your second proposed change hasn't been discussed in the DNSEXT WG, has it? It really _is_ rechartering to add "the [IDN] WG may modify the DNS protocol and other work undertaken by the DNSEXT WG", neh? The ironic part is that having so avidly, even abusively, taken a apps path, infrastructure now pops up. Humor me. What is the rational again? What was "unclear" about the relation between IDN and DNSEXT? Since this WG isn't going to do anything but applications, by existing rough (wrong) consensus, what is the necessity for "clarification"? Your third proposed change really flatters the Unicadettes, but "mappings between codepoints are out-of-scope" is odd. What is an "ACE" if not a mapping from one range of integers (codepoints) into another, possibly identical, range of integers? If your point is to kill off reordering, and all the related hard items of living with rfc2130 on a diet of 63 octets, say so. Incidently, the "I18N group" is undefined. Similarly, the "other relevant expert group" is undefined. Your fourth change is an abuse of process. Individuals, and co-chairs, do not by themselves, add or delete work items from a working group, at least not according to rfc2026. Paul doesn't want to continue to edit draft-ietf-idn-compare, fine. Now it is time to look for a capable and interested editor, or bump this issue to the ADs and the appeals chain. Now everything in this item of mail is a repeatition of what I wrote, in my first note. If you want to maintain that I've not offered an explination for suggesting that these of your (and whomever) proposed changes are better not made than made, that's up to you. Eric P.S. All the co-chairs need to accomplish is to reconcile the timeline with their, and the WG's collective, hoped for future accomplishments. Actually attempting a re-chartering while attempting to get closure on complex and contentuous deliverables is risk-seeking, not risk-adverse. Then again, this is the WG that puts a recommendation into the scope statement of its requirements draft, so anything is possible.
