Re: [idn] Update Charter revision 2

["James Seng/Personal" <jseng@pobox.org.sg>]

> 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