> 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".
The recharter has been discussed for a while, some of them offline to me. The note on 23rd is a notice that there will be a new update, not a request for discussion. If you are surprised by it, then you have not follow the list. The idea is to explicitly limited the scope of work in IDN WG so we can actually produce something. We been on a very vague charter for a long time because we are exploring. But it is time to finish it up. > 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 text is extracted from the requirements doc. Your sentence is not incomplete without the second. "But such changes must be co-ordinated with the DNSEXT WG". Dont pull statement out of context. The intention: It is possible that an IDN solution (e.g. UTF-8 solution) would requires modify DNS protocol. However, such solution need to be co-ordinate with DNSEXT WG. And Olafur is already aware of this intention for a while (since San Diego?). > 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"? Because you are assuming that IDNA is the only one moving forward. I am assuming we will get other proposal. > 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? "Mappings between codepoints" refers to codepoint tables mapping. You are stretching the meaning. Of course, you can stretch anything you want. I could argue the existing charter allows us to redefine a new character code set for the purpose of IDN. > 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. I repeat the intention again: "The discussion to do reordering is within scope. The table for reordering in my view is a frequency analysis sorting and that maybe within scope. If reordering creates any codepoints tables, then that table is not. The discussion of whether to do TC-SC equivalent matching, and if so, where and how is also within scope. The tables of TC-SC is not." You have obviously twist my words, as usual. > 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. The ADs have seen the proposed changes. The removed work item is deem no longer neccessary or relevant at this moment in time. Some (or you) may still argue it is relevant but on the whole, the topic of comparsion have not and never been a focus of discussion in the group over the 24months. > 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. That is your opinion. I see no valid arguments in your comment. Thank you but i like to hear from others. -Jaes Seng
