Subject: Re: [idn] Document Status?

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 02 Sep 2002 13:23:04 +0200

Gentlemen,
I see three different problems discussed here.

1. wording of the process

On 04:40 02/09/02, James Seng said:
>These definition is a bit different from the layman defintion of 
>"international" and "local" in Jefsey's email. But we engineers have to be 
>more precise.

This is true. This why we engineers :-) cannot use inappropriate names. A 
word has a meaning by itself. This is all what this work is about. 
"international" cannot mean "using a particular scriptural form" in 
"ietf/idner". "Local" cannot mean anything else than related to a 
particular location.

It seems from the debate that "scripturalization" would be the intent. And 
that International Domain Names are the domain names containing "IESG--" 
labels.

2. readability of the proposed text.

I must say that with my limited French speaking IQ I tried to figure out 
the meaning of "ACE" in the proosed text: sorry, but I was totally unable 
to grasp it. The text seems often over complex to me, most probably from 
being a compromise between different visions of the target? I think it 
should not on a matter that many different cultures will consider as central.

3. layer violation

3.1. the DNS is to match immaterial domain names and numeric physical 
addresses. This permits applications and hypertexts to be independent from 
the actual configuration of the network.

3.2. mnemonics are a way to easily memorize something else like JFK for 
"Kennedy Airport". They are aliases. In very seldom occasions (famous 
names) the name itself has acquired enough recognition to be its own 
mnemonic. In other occasion (neighbor names) a simple mental transcoding 
permits to find the alias (ibm and ibm.com; or "ibm.net+not .com" ibm is 
not a real mnemonic for me for "ibm.tp")

Scripturalized and Internationalized strings are aliases. The transcoding 
is here usually complex (it can be very simple in the case of 
"jean-françois.fr" and "jean-francois.fr").

There are two different layers. Some questions belong to the DNS.2 layer: 
have we to enlarge the DNS character set? Others belong to the DNS+ layer 
(extended applications on top of the DNS) and may receive many different or 
even opposing responses as long as the result is what the user expects.

jfc

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 3 Sep 2002 02:24:33 +0000

"JFC (Jefsey) Morfin" <[email-masked]> wrote:

> I must say that with my limited French speaking IQ I tried to figure
> out the meaning of "ACE" in the proposed text: sorry, but I was
> totally unable to grasp it.

It is defined in the terminology section:

    An "internationalized label" is a label composed of characters from
    the Unicode character set; note, however, that not every string of
    Unicode characters can be an internationalized label.

That much is clear, yes?

    To allow internationalized labels to be handled by existing
    applications, IDNA uses an "ACE label" (ACE stands for ASCII
    Compatible Encoding), which can be represented using only ASCII
    characters but is equivalent to a label containing non-ASCII
    characters.

In other words, internationalized labels can contain non-ASCII
characters, which can't be handled directly by existing applications
that expect domain labels to be ASCII.  Therefore, we instead use an
"ACE label", which is an ASCII label that is equivalent to a non-ASCII
label.

    More rigorously, an ACE label is defined to be any label that the
    ToUnicode operation would alter.

That one sentence is the full and exact rigorous definition of the term
"ACE label".  The rest of the explanation is there only to provide
intuition.

    For every internationalized label that cannot be directly
    represented in ASCII, there is an equivalent ACE label.  An ACE
    label always begins with the ACE prefix defined in section 5.

Those are clear, yes?

By the way, the notion of "equivalent label" is also defined in the
terminology section:

    In IDNA, equivalence of labels is defined in terms of the ToASCII
    operation, which constructs an ASCII form for a given label.  Labels
    are defined to be equivalent if and only if their ASCII forms
    produced by ToASCII match using a case-insensitive ASCII comparison.
    Traditional ASCII labels already have a notion of equivalence: upper
    case and lower case are considered equivalent.  The IDNA notion of
    equivalence is an extension of the old notion.  Equivalent labels in
    IDNA are treated as alternate forms of the same label, just as "foo"
    and "Foo" are treated as alternate forms of the same label.

Is that clear enough?

Getting back to "ACE", maybe some examples would help:

The Japanese phrase <sono><supiido><de> (pretend I wrote it using kana,
which are non-ASCII characters) could be an internationalized label.  It
is not an ACE label, because it cannot be represented in ASCII.  If you
feed it to ToUnicode, it will not be altered, because the check for the
ACE prefix will fail.

There exists a label equivalent to <sono><supiido><de> that can be
represented in ASCII, namely IESG--d9juau41awczczp (where IESG-- means
the ACE prefix, whatever is eventually chosen).  This is an ACE label
because it can be represented in ASCII and it is equivalent to a label
containing non-ASCII characters.  If you feed IESG--d9juau41awczczp to
ToUnicode, it will be altered (it will become <sono><supiido><de>).

The label helloworld is not an ACE label, because it is not equivalent
to any non-ASCII label.  If you feed it to ToUnicode, it will not be
altered, because the check for the ACE prefix will fail.

Those are the three normal cases.  There are also a few corner cases,
labels that begin with the ACE prefix but are not ACE labels:

The label IESG--foo-bar-2 is not an ACE label, even though it begins
with the ACE prefix, because it is not equivalent to any non-ASCII label
(because the Punycode part is invalid).  If you feed it to ToUnicode, it
will not be altered, because the Punycode decoding step will fail.

The label IESG--3ba is not an ACE label, even though it begins with the
ACE prefix and the Punycode part is valid, because it is not equivalent
to any non-ASCII label (because it is not nameprepped; it decodes to a
capital A with grave accent).  If you feed it to ToUnicode, it will not
be altered, because the comparison in step 7 will fail.

AMC

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 03 Sep 2002 12:22:48 +0200

Dear Adam,
thank you for your response. I think you perfectly described the problem. I 
will then make a bore of myself and will list my exiting (increased) concerns.

After reading this mail and explanations which are not in he RFC I still do 
not know for sure what is intended to be written. You also refers to 
external knowledge such as "punnycode".

Should we not have a clear terminology section defining every word or 
concept we are going to use? All I know is semantically "international 
names" could only means the names which are unaltered by the ACE process. 
"Here I understand they mean the Unicode scripting which can be ACEd", so 
should it not be at least be "internationalizable" (no action occurred yet)?

Also I understand that that the RFC deals with the ACE process. Terminology 
section should therefore

1. define the ACE process
2. define the group of the applications requiring ACE
3. define the international names : left unchanged by the process
4. define the non ACEable names
5. define the ACE labels
6. define the the class of all the labels (ACE and International) which can 
be processed by an application requiring ACE

>     Unicode characters can be an internationalized label.

to me this is an Unicode label/script? No action occurred yet?

>     characters but is equivalent to a label containing non-ASCII

IMHO, let stop at "ACE label". And let define what an ACE label, without 
"can" which implies there would be other ways.

>"ACE label", which is an ASCII label that is equivalent to a non-ASCII

All this added explanation is external and only adds to the text. Let us 
try to compact it into one single initial crystal clear definition?

>     ToUnicode operation would alter.

So an ACE label is here defined negatively. Feeling is that it means "when 
ToUnicode will fail". When we mean that the ToUnicode (sucessfully) 
transform into an ACE label.

>     label always begins with the ACE prefix defined in section 5.

My first reading was puzzling: "whenever the ACE process will not work, 
there will be an pre-existing equivalent ACE label". This obviously does 
not make any sense.

>     operation, which constructs an ASCII form for a given label.

this means ACE label.

>    Labels

Then International names - ie non modified names by the ACE process (now 
reduced to ToASCII only(?), should it not also be reversible and the 
ToUNICODE results in the original scripting?) - cannot be compared (I know 
it is wrong, but this is what I read here. Again sorry for my Frenglish, 
but I think here it helps).

>     Traditional ASCII labels

What is "traditional". Has it been defined?

>     already have a notion of equivalence: upper
>     equivalence is an extension of the old notion.

Old notion? Is that the correct wording? Is that not the DNS current and 
stable notion?

>   Equivalent labels in IDNA

Unicode scriptings and ACE label + non modified scriptings.

>     are treated as alternate forms of the same label, just as "foo"

Sorry to be boring. My point is not that I do not understand, but that the 
reading seems confusing. I only try to help it to be clearer from my own 
personal reading difficulties.

>is not an ACE label, because it cannot be represented in ASCII.

Well I thought that ACE label resulted from the ACE process and not the 
labels left identical by the ACE process (IMHO both ways: "iesg---name.com" 
is perfect ASCII, but if ToUNICODEd it will have no meaning).

>If you feed it to ToUnicode, it will not be altered, because the check for 
>the ACE prefix will fail.

If the registering process has prevented the creation of the "iesg--" 
names. This is probably forbidden but it should be mentioned. Because when 
someone is going to use IDNA for a database entry, that filtering must be 
implemented in a consistent way.

>altered, because the check for the ACE prefix will fail.

see above about iesg--helloworld necessary filter reminder (please remember 
VRSN problems with ASCII preregistrations of iDNs).

>(because the Punycode part is invalid).

The punnycode is no part of the document and should be introduced.

>If you feed it to ToUnicode, it will not be altered, because the Punycode 
>decoding step will fail.
>
>to any non-ASCII label (because it is not nameprepped;

is namepreparation part of the process. If yes it has to be included in the 
ACE or ToASCII conditions above. If not this restriction does not apply as 
such, it can only be noted. There may be a lot of variations in the Unicode 
scripting the users/developers may want to result in the same ACE_label.

>it decodes to a

You understand that this is as long as DNS does not support &agrave; but 
that other applications may. The definition given above talking about 
"existing applications" - there are a lot of existing application 
supporting it, and at any given time in the future there will be more.

So it means that we also want to define the ACE character set.
jfc

---

From: "James Seng" <[email-masked]>
Date: Wed, 4 Sep 2002 08:42:05 +0800

Someone once told me "You know you are done when you couldn't find things to
take out".

You dont complete document by adding more stuff. You complete it by taking
out the noise and amplify the signal.

-James Seng

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 4 Sep 2002 01:51:09 +0000

Disclaimer:  In a few places in this message, when I ask if an alternate
phrasing would be less confusing, I am not offering to make changes to
the draft.  Paul and Patrik and I would have to discuss it, and I would
understand if they think it's too late for that.

"JFC (Jefsey) Morfin" <[email-masked]> wrote:

> You also refers to external knowledge such as "punnycode".

Punycode (one n).  It is used only inside the ToASCII and ToUnicode
operations.  If you are implementing those operations, or trying to
understand their internals, you will need to refer to the Punycode spec
and the Nameprep spec.  Otherwise, you can regard ToASCII and ToUnicode
as abstract operations, and still understand IDNA.

> concept we are going to use?

Yes.  That is what we intend section 2 to be.

> All I know is semantically "international names" could only means the 
> names which are unaltered by the ACE process.                         

Which ACE process?  There are two operations, ToASCII and ToUnicode,
which do very different things.  What they do is stated in the first
paragraphs of the sections where they are defined (4.1 and 4.2):

    The ToASCII operation takes a sequence of Unicode code points that
    make up one label and transforms it into a sequence of code points
    in the ASCII range (0..7F). If ToASCII succeeds, the original
    sequence and the resulting sequence are equivalent labels.

    The ToUnicode operation takes a sequence of Unicode code points that
    make up one label and returns a sequence of Unicode code points. If
    the input sequence is a label in ACE form, then the result is
    an equivalent internationalized label that is not in ACE form,
    otherwise the original sequence is returned unaltered.

> "Here I understand they mean the Unicode scripting which can be ACEd",
> so should it not be at least be "internationalizable" (no action
> occurred yet)?

Various arguments can be made that we are misusing the word
"internationalized".  For better or worse, we use it to mean roughly
"able to support the use of non-ASCII characters".  In any case, we give
definitions for "internationalized domain name" and "internationalized
label", so you can forget any preconceived ideas about what
"internationalized" ought to mean, and trust the definitions.

> Also I understand that that the RFC deals with the ACE
> process. Terminology section should therefore
>

I'm not sure what you mean by "the ACE process".  There are two
operations, ToASCII and ToUnicode, which are complex enough to warrant
their own section (section 4).

> 2. define the group of the applications requiring ACE

I think what is really needed is not the set of applications requiring
ACE, but rather the set of places where ACE is needed.  That is already
there in the terminology section, under "IDN-unaware domain name slot".
Requirement 2 of section 3 (3.1 in the forthcoming idna-11 draft) states
that only ASCII characters are permitted in IDN-unaware domain name
slots.

> 3. define the international names : left unchanged by the process

Which process?  The labels left unchanged by ToASCII are simply the
ASCII labels, so we don't need a special term for that.  The labels left
unchanged by ToUnicode are the non-ACE labels, so we already have a term
for that.

> 4. define the non ACEable names

I'm not sure what you mean by ACEable.  Every ASCII label is non-ACEable
in the sense that ToASCII will not alter it.  Some ASCII labels are ACE
labels themselves, and some are not.  But all of them are left unchanged
by ToASCII.

For every valid non-ASCII label, there is an equivalent ACE label.

Maybe you are asking for a definition of valid IDNs?  That is given.

> 5. define the ACE labels

Done.

> 6. define the class of all the labels (ACE and International) which
> can be processed by an application requiring ACE

I don't know what you mean by "an application requiring ACE".  We do
give a definition of IDN.

> to me this is an Unicode label/script?  No action occurred yet?

An internationalized label is a sequence of Unicode characters.  Given
a Unicode string, can it be an internationalized label?  The answer is
provided in the definition of IDN:

    An "internationalized domain name" (IDN) is a domain name for which
    the ToASCII operation (see section 4) can be applied to each label
    without failing.

"can be applied", not "has been applied".  A Unicode string X can be an
internationalized label if and only if ToASCII(X) does not fail.

Hmmm, one fact about internationalized labels is that every ASCII label
that can be used in ASCII domain names is also an internationalized
label that can be used in internationalized domain names.  In other
words, the set of internationalized labels is an extension (superset) of
the set of valid ASCII labels.  Would it have been helpful if this fact
were stated more prominently?

> IMHO, let stop at "ACE label". And let define what an ACE label,
> without "can" which implies there would be other ways.

I think the word "represented" is confusing you.  In my mind, "Foo"
cannot be represented using only lowercase ASCII letters, but "foo" is
an equivalent label that can be represented using only lowercase ASCII
letters.  Similarly, <sono><supiido><de> cannot be represented using
only ASCII characters, but IESG--d9juau41awczczp is an equivalent label
that can be represented using only ASCII characters.

Unfortunately, the document is not consistent in its usage of the word
"represent".  Would this sentence be less confusing if worded as:

    ...IDNA uses an "ACE label" (ACE stands for ASCII Compatible
    Encoding), which is composed of ASCII characters but is equivalent
    to a label containing non-ASCII characters.

?

That's less precise (because there are non-ASCII characters that can
be represented by ASCII characters, like the fullwidth characters
FF01..FF5E), but I suppose the imprecision might be tolerable, since the
rigorous definition immediately follows.

> All this added explanation is external and only adds to the text.  Let
> us try to compact it into one single initial crystal clear definition?

The only crystal clear definition is this one:

However, here's another attempt at providing some intuition:  All
non-ASCII internationalized labels are intended to be displayed to
users without change.  The same is true of most ASCII labels.  But
there are some ASCII labels, called ACE labels, that are not intended
to be displayed directly to users.  ACE labels begin with the ACE
prefix and look like gibberish.  Every ACE label is equivalent to a
non-ASCII label, which is what is intended to be displayed instead.
For every non-ASCII internationalized label there is an equivalent ACE
label.  [I'm being loose with the term "ASCII".  Unicode characters that
are compatibly equivalent to ASCII characters (like those fullwidth
characters) count as ASCII for the purposes of this paragraph.]

> So an ACE label is here defined negatively.  Feeling is that it means
> "when ToUnicode will fail".

I don't see what's negative about that definition.  I see no mention of
failure.  Indeed, the second paragraph of the ToUnicode section (4.2)
says "ToUnicode never fails."

> When we mean that the ToUnicode (sucessfully) transform into an ACE
> label.

ToUnicode can never output an ACE label.  The first paragraph of the
ToUnicode section says:

    If the input sequence is a label in ACE form, then the result is
    an equivalent internationalized label that is not in ACE form,
    otherwise the original sequence is returned unaltered.

Here is a math-notation version of the definition of ACE label:

    { ACE labels } = { X : X != ToUnicode(X) }

> >    represented in ASCII, there is an equivalent ACE label.
>
> My first reading was puzzling: "whenever the ACE process will not
> work, there will be an pre-existing equivalent ACE label".  This
> obviously does not make any sense.

Again, I think the word "represented" is confusing you, although I
thought the word "directly" would help.  Would it be less confusing if
reworded the same way as before [again using the loose sense of ASCII]:

    For every internationalized label containing non-ASCII characters,
    there is an equivalent ACE label.

?

> >    operation, which constructs an ASCII form for a given label.

No, ToASCII(helloworld) == helloworld, which is not an ACE label.  The
output of ToASCII is always an ASCII label, but not always an ACE label.
The output is an ACE label only if the input was non-ASCII, or the input
was an ACE label.  [Here again I'm using the loose sense of ASCII.]

> >   Labels are defined to be equivalent if and only if their ASCII
> >   forms produced by ToASCII match using a case-insensitive ASCII
> >   comparison.
>
> Then International names - ie non modified names by the ACE process
> (now reduced to ToASCII only(?), should it not also be reversible and
> the ToUNICODE results in the original scripting?) - cannot be compared
> (I know it is wrong, but this is what I read here.

That does not follow.  The definition of equivalence says:

    For all X,Y  define  X ~ Y  to mean  ToASCII(X) ~ ToASCII(Y)

You are wondering about "non modified names", that is, labels Z for
which Z == ToASCII(Z).  That does not impede us from performing the
comparison.  We compute ToASCII(X) (which returns X), and we compute
ToASCII(Y) (which returns Y), and we compare the results using a
case-insensitive ASCII comparison (which we can do because the output of
ToASCII is an ASCII string).

> What is "traditional".  Has it been defined?

Just a regular English word, not a term.  "Traditional ASCII labels"
means "the ASCII labels that we've all grown familiar with over the
years".

> >    already have a notion of equivalence: upper case and lower case
> >    are considered equivalent.  The IDNA notion of equivalence is an
> >    extension of the old notion.
>
> Old notion?  Is that the correct wording?  Is that not the DNS current
> and stable notion?

Yes, the current notion is old, having been with us for many years.
Would "older notion" be less alarming?

> > The Japanese phrase <sono><supiido><de> (pretend I wrote it using
> > kana, which are non-ASCII characters) could be an internationalized
> > label.  It is not an ACE label, because it cannot be represented in
> > ASCII.
>
> Well I thought that ACE label resulted from the ACE process and
> not the labels left identical by the ACE process (IMHO both ways:
> "iesg---name.com" is perfect ASCII, but if ToUNICODEd it will have no
> meaning).

ToUnicode will not alter the label IESG---name (remember that ToUnicode
takes a single label as input).  The output will be IESG---name.  In
this particular case, the Punycode decoding step will fail.  But see
below for a more interesting example, IESG--world.

> > If you feed it to ToUnicode, it will not be altered, because the
> > check for the ACE prefix will fail.
>
> names.

I was speaking of <sono><supiido><de>, which does not begin with the ACE
prefix.  It's true that if someone registers IESG--world, it will be
displayed by IDNA-conformant applications as three Chinese characters
(U+53DF U+53E0 U+53D9), because IESG--world is an ACE label.  Maybe
the user really wants a label that will display as "IESG--world", in
which case the user will be dismayed at the behavior of IDNA-conformant
applications.  Or maybe the user really intends to register the Chinese
label, but used the ACE form in the registration process because the
browser wouldn't let them enter Chinese characters, or because a clever
clipboard decided to paste the ACE form, or because the registrar has
not yet upgraded to support IDNA.  Those are all legitimate scenarios;
people who compute the ACE form themselves and register it directly
rather than relying on the registrar to compute it might in fact know
what they're doing.  Registrars that support IDNA and receive ACE forms
as input would probably do well to display them back in both ACE and
non-ACE forms and ask for confirmation.

When several labels are equivalent, you can regester any one of them
and you own them all.  If I register "example.com" or "Example.com"
or "EXAMPLE.com", no one else can register any of them, they're all
mine.  Similarly, no matter whether I register <sono><supiido><de> or
IESG--d9juau41awczczp, no one else can register either one, they're both
mine.

> The punnycode is no part of the document and should be introduced.

It is mentioned at the end of section 1, and in the steps of ToASCII,
and in steps ToUnicode.  Nameprep is mentioned in exactly the same
places, and nowhere else.  You don't need to understand them to
understand IDNA, you can think of ToASCII and ToUnicode as abstract
operations.

> > The label IESG--3ba is not an ACE label, even though it begins with
> > the ACE prefix and the Punycode part is valid, because it is not
> > equivalent to any non-ASCII label (because it is not nameprepped;
>
> is namepreparation part of the process. If yes it has to be included
> in the ACE or ToASCII conditions above. If not this restriction
> does not apply as such, it can only be noted. There may be a lot of
> variations in the Unicode scripting the users/developers may want to
> result in the same ACE_label.
>
> > it decodes to a capital A with grave accent).  If you feed it to
> > ToUnicode, it will not be altered, because the comparison in step 7
> > will fail.
>
> You understand that this is as long as DNS does not support &agrave;
> but that other applications may. The definition given above talking
> about "existing applications" - there are a lot of existing
> application supporting it, and at any given time in the future there
> will be more.
>

I don't understand what your concern is here.

IESG--3ba is not an ACE label because it is not equivalent to
any non-ASCII label.  We have defined equivalence.  IESG--3ba is
equivalent to X if and only if ToASCII(IESG--3ba) matches ToASCII(X).
ToASCII(IESG--3ba) is IESG--3ba, because ToASCII does not alter ASCII
labels.  So we're looking for a non-ASCII label X such that ToASCII(X)
is IESG--3ba.  There is no such X.  If you want to understand why there
is no such X, you'll need to examine the internal details of ToASCII,
and then you'll discover that ToASCII performs Nameprep, and Nameprep
can never output a capital A with grave (and to understand why that is
so, you'll need to examine the internals of Nameprep, and then you'll
discover that Nameprep performs case-folding).

By the way, even though there is no ACE label that decodes to a capital
A with grave, that doesn't mean ToASCII can't accept a capital A with
grave as input.  It can, and Nameprep will map it to small a with
grave.  The output of ToASCII will be IESG--0ca, which is an ACE label,
which ToUnicode will transform into small a with grave.  Notice that
ToUnicode(ToASCII(X)) is not always X, it is Nameprep(X) (which is
equivalent to X).

Another way to see that IESG--3ba is not an ACE label is to observe
that ToUnicode does not alter it.  If you want to understand why
ToUnicode does not alter it, you'll need to examine the internal details
of ToUnicode, and then you'll discover that ToUnicode decodes it to
capital A with grave, then applies ToASCII, which produces IESG--0ca (as
mentioned above), and then ToUnicode notices that IESG--0ca does not
match IESG--3ba, and so ToUnicode returns the original input.

AMC

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 04 Sep 2002 06:59:29 +0200

> understand if they think it's too late for that.

Adam, the documents are with IESG, and as that is the case it is
_extremely_ confusing and bad to have the wg continue to discuss wording
changes. The documents are worded as they are, period.

If issues are rised by the IESG, or by other means, which makes the AD
request wording changes, _then_ is the time to discuss wordings.

We in this wg should definitly not discuss wordings when the IESG is
already working on one specific version of the document.

Only on explicit request from the AD, which then have noticed IESG that "a
new version is coming".

I have, as document co-editor, not seen any such request from the AD.

    paf, as document editor, but with experience from IESG work

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 04 Sep 2002 13:13:16 +0200

Dear Patrick,
you say:
<quote>
paf
</quote>

I understand this and I am sorry for pushing for this review, very late. 
May I runderline that that this thread is "Document Status". It was about 
sending it to the IESG. It is not closed and is still very active on 
several points?

IMHO the text and concepts must be worded to support further developments 
in a stable direction, approved as a common draft by all the involved 
parties and a woring directin proposed to the pending points. This to avoid 
a possibly international split, the appearance of alternative propositions, 
and at least endless disputes and delays

I am sorry to be bluntly active. As long as you sorted the technial 
solution and the immediate process was in order it seemed OK to trust the 
effort. Now there are two possiblities:
- either I am wrong, I am the only one thinking the text confused and 
complex? Then I apologize.
- or I am right and the text should be recalled, worked out as a text, get 
approved by the Internet community (after all this is telling how the US 
Internet is going to be everyone's Internet and the adopted compromises 
accepted as the solution cannot even fully support French).

Open question?

jfc

==================================

Dear Adam,
thank you for the reply. As James Seng says:

<quote>
Someone once told me "You know you are done when you couldn't find things to
take out". You dont complete document by adding more stuff. You complete it 
by taking
out the noise and amplify the signal.
</quote>

This is the primary target. The second one IMHO is to phrase the document 
in such a way it is clearly understood that there are two layers.
- to use an ASCII subset as universal (international) support
- a second to manage users/applications requirements on top of it and not 
through further additions.

This way the users may decide on a case per case basis to use or not the 
ACE. We do not build a transition, and we do not prevent alternatives and 
innovations.

>as abstract operations, and still understand IDNA.

I know. What I underline is that you have to define the word - at least as 
in a related document - before using it.

>     otherwise the original sequence is returned unaltered.

I read three times that definitions. I fail to see how they are not 
balanced from ASCII to Unicode and from Unicode to ASCII, except that 
"iesg--" is removed by ToUnicode? Or is there other hidden cases I fail to 
see. IMHO a simple clear wording is prevented by the use of complex 
conditional concepts. If we only talked consistently of real things: 
scripts, ASCII scripts, aced ASCII scripts it would be simpler and would 
remove the feeling there are a lot of possible exceptions we do not think of.

(I do not propose a wording here, and further on, I just try to phrase in 
poor English, the way we could KISS it).

We want a clear, simple, terse text. Written for people using "Unicode 
scripts" all the day long in their day to day life. Not as if this was an 
exception. The exception (which permitted the development of the Internet) 
is the true "international names", ie the "late upper case roman character 
set plus figures". A to Z, 0 to 9, "-"  and ".". That character set must 
first be given a simple name. As it is an Unicode subset, its specific used 
is flagged ("iesg--"). All  is here. As it is the smallest common writing 
subset as Vint noted it, I will name it International character set.

IMHO we do not need anything more complex.

>"internationalized" ought to mean, and trust the definitions.

I am sorry but in my day to day live, as 90% of the people I use Unicode 
words and a language. I have difficulties communicating and understanding 
texts where the meaning is opposite to the commonly adopted meaning. We are 
not talking here of the concepts: we all agree upon. We are talking about 
them being described and understood.

"Internationalized" means that something occurred.
"able to" means that something could occur.

The result is something opposed. On one case it means that the 
transformation occurred. In the other case it means that the transformation 
has not occurred.

>their own section (section 4).

No. There is also the preparation of these two operations which makes them 
possible.

Globally that process must be reversible. So ToUnicode and ToASCII cannot 
be separated.
If these processes are complex and different, their description can be 
consistent (and must be consistent as they are to be reversible) if the 
inputs/outputs are consistently described as indicated above.

>that only ASCII characters are permitted in IDN-unaware domain name

I am just listing what is needed and where for reading simplicity. I am not 
criticizing. The target is to review that text for brevity, clarity, logic 
and consistency with reality. For peoples who know that ASCII is the 
exception and that reality is much richer.

>unchanged by ToUnicode are the non-ACE labels, so we already have a term

Again. I am not including new categories. I am trying to have a systematic 
way to present the concepts used in the document, so the reader understands 
that when the documents use three different way of describing the same 
thing it actually speaks of the same thing.

I am trying to help that document to be fluid to readers from China, 
France, Pakistan, Korea, Mexico, etc... without them having the feeling the 
author tried to complexity his solution rather than to simplify their usage.

>Maybe you are asking for a definition of valid IDNs?  That is given.

I am not asking. I say this is where the "internationalized name" 
definition - once properly worded into "internationalisable" is to be 
placed. One shot. And all the other complementary explanations using 
different words to be removed.

>give a definition of IDN.

This is only the place where I suggest to put the information. Applications 
requiring ACE are the applications we develop this process for. The ones 
which do not support Unicode or which need simple scripts. The huge number 
of information and security databases several talked about in here.

>that can be used in ASCII domain names

BTW, would "International label" instead of "ASCII label that can be used 
in ASCII domain names" not look more fluid, clearer, general and open to 
evolution). We could then scrap the rest of the explanation which is not 
necessary.

>is also an internationalized

I agree, understanding that you mean the opposite to what anyone not 
knowing you are discussing IDNA would understand?

I fully accept that living with this project make you to consider your 
wording as adapted. My only target is to make you aware that this dialog of 
ours, will be the "dialog" of most of the readers with that text. You will 
have IDNA "gurus" having (often partly) understood the special meanings of 
thsi document, and others who will be condused and say that the solution is 
confused ... developing their own and on top of their own.

>     to a label containing non-ASCII characters.

Let get my logical understanding of what was agreed in here (wording may 
oppose yours, but I do think we are in agreement):

1. there are standard names. They can only be written in Unicode set.
2. most of them can also be written in International set (0-9,A-Z,"-", ".") 
using ACE.
3. some are already International, because they only use characters from 
the International set.
4. there is a need to know which writing is used: the "iesg--" header tells 
that the writing is international.

The process permitting to translate Unicode writing in International 
writing is ToASCII (should be ToINTL) and the process to translate 
international writing to Unicode is ToUnicode. The ACE process consists in 
producing simultaneously and both ways the International and the Unicode 
writing of every name, with exceptions which have no International writing.

The names may include several labels. They have a semantic which calls for 
a preparation to make sure the ACE process will result in clear and 
reversible International writing.

In real life there are applications which need International writing 
(8bits) and others which can use standard writing (16 bits or more). All 
this because the human being, the current screen, keyboard system and 
current software applications do not support more than 8bits keys, as today.

So it is convenient for some applications to use an 8bits limited common 
character system.

I will take an example. We started the namespace with the International 
character set. As Vint quoted it for regular mail, we used uppercase what 
made clear that accents could not be used. TLDs for USA were the IRCs (ITT, 
RCA etc...) and names were such as RCAFORDSALES (no separation between 
rootname and name).

Then we switched to X.75 and X.121 to be compatible with ISO standards 
limited to telephone like digital logic (as the DNS is International 
Character set oriented).  We did it the same way IDNA, using  numeric 
names. We had a namepreparation and "ToISO" and "ToTymnet" function to 
translate "FRAELYSEESECRETARY" into the "208075081231" name and then 
into  208007508123. The same, we transformed "ARPAUCLA" or "123.23.28.82" 
into "ucla.arpa", but accepted "90777" as an US X.25 call to Dialog. We had 
no "iesg--" flag, we used either the final "." from Internet to indicate it 
was to be reversed or the numeric structure.

This type of parallel encoding is very common. You can write Japanese words 
into two character sets. There is no logical difference between IDNA and 
Katanaka. This process is basic in French where the upper cases may carry 
not accent nor cedilla. So "Jean-François" (my forename) is Unicode and 
"JEAN-FRANCOIS" is international. So everyone think "IDNA" all the day 
long. Hence the difficulty to even understand there is a (complex) There is 
just a (complex) simplifcation.

But I accept that this is a big thinking for people accustomed to use 
International names only. The same problem as translating English "you" in 
other languages: does it means "vous" or "tu".

>     ToUnicode operation would alter.

This is a loop definition. I talk about what I talk. It should be defined 
as the assignement to the WG. An ACE label is a label only containing 8bits 
characters of the "Late Roman Character set" or of  "International" 
character set as specified above. The WG has the mission to make possible 
every stanard real names to be writen with that character set.

>prefix and look like gibberish.

(except if they come from an International character set string).

>Every ACE label is equivalent to a

I do not mean in technical terms (if we can discuss all this it is because 
the technical issues are settled). I mean in term of reading. When you say 
A != B you do not really define A. unless you add more information.

So when you read such a definition as "if (A != ToUnicode(A)) True(A)=1, 
else True(A)=0;
you usually spend a few seconds trying to understand what it really means.

>     { ACE labels } = { X : X != ToUnicode(X) }

yeap. What I meant was: the part of the ACE Label after the ACE prefix. 
This kind of confusion will be over and over during decades with that 
wording. Saying there is an Unicode and an International writing and that 
due to the possible confusion when the Unicode writing only uses 
International characters, there is an International prefix, would probably 
be quicker, easier and clearer to understand. I suppose every little French 
or Japanese would not even understand there might be a problem.

>     there is an equivalent ACE label.

The phrase is simpler but the wording is complex and needs a ToIDNA / 
ToEnglish function.

My wording would be:

For every international writing there a standard writing.
There is not necessarily an international writing for every standard writing.

>was an ACE label.  [Here again I'm using the loose sense of ASCII.]

Here again you consider the result of the process. What matters is the reality.

1. is it standard writing (Unicode, 16 bits)
2. is it international writing (International, 8 bits)
3. or an Unicode writing using Interational characteirs only: the prefix 
tells it..

>ToASCII is an ASCII string).

I agree. What I said is what I tend to read.

>means "the ASCII labels that we've all grown familiar with over the

I am sorry, 90% of the mankind never grown familiar with any ASCII labels 
over the years. 90% of the mankind executes a double IDNO process to relate 
with you through a ToEnglish and a ToASCII operation.

Anyway, you cannot use the word "traditional" without defining the RFC 
where to find the table. When it comes to writing a program there is no C 
traditional(char *) routine.

>Would "older notion" be less alarming?

My objection was to the non definition of "old". For example there is a 
much older Roman notion about J and I being the same. An old military and 
Minitel user notion of a 34 character set where 0 and O and 1 and I are 
used the same.

The simpler is to define the character set (0-9, A-Z, "-","."). Maybe 
adding "@" and "_" (?).

>below for a more interesting example, IESG--world.

Again the difference between the label, the ACE label and the after the 
prefix label. There should be a word for the last meaning.

But you are true - as noted below the "iesg-world" is not an 
internationalisable name. It should be mentioned in the RFC.

>non-ACE forms and ask for confirmation.

You may also think about the thousands of key business names registered 
that way at Verisign. Unless there is no provision made that such names 
illegal - but on which ground the IETF is going to chose a 2 letters label 
(which can be confused with an existing or future ccTLD) to make its use 
illegal? This is why the whole story should be wrapped up asap with the 
support of the Minc, the Ainc and Eurolinc, main language authorities and 
we can proceed before UNESCO and ITU puts it at the WSIS agenda.

>IESG--d9juau41awczczp, no one else can register either one, they're both

That is the business fun!
and the International cybersquatting!!!
ask Verisign.

>understand IDNA, you can think of ToASCII and ToUnicode as abstract

True but when you peruse a document and you find a word you ignore, you 
look at the glossary. This is simple document presentation. But improves 
readability a lot and avoid endless questions/disputes.

>discover that Nameprep performs case-folding).

But you will have to explain many French people why after three years work 
and the ability to support Chinese, their standard typing cannot be used 
and to some why they could not register their name. The Marquis d'Ö will be 
upset at that. Many keyboards supports accents separately from the letter 
and can put a grave at any character as required by the proper scripting of 
the language.

>grave.

This is a wrong preparation process.

>The output of ToASCII will be IESG--0ca, which is an ACE label,

Absolutely true. This is why the ACE process cannot be defined in relation 
to the ToASCII/ToUnicode functions only.

And here is the entire problem: toASCII/ToUnicode in the case of the DNS 
should be DNS.2 integrated tools at inter-application level. While nameprep 
is an extended service above the DNS layer (DNS+). The reason why is that 
nameprep may include many more functions related to input/output massaging 
and can be customized (like accepting abbreviated entries) at application 
level.

>match IESG--3ba, and so ToUnicode returns the original input.

True, but this is the same as my acceptation of "90877" as the US 
abbreviation for the X.121 address of Dialog instead of requiring 
"310690877" where "310" is the USA international prefix and 3106 the Tymnet 
DNIC. Is the ACE process global or not (including only ToUnicode/ToASCII)?

National consistency makes me feel that it should be semi-global ie 
including customizable nameprep.  a) If you look at you word; you will see 
that you different blend of English, French. b) we will probably support 
national root views soon enough and national DNS options will probably 
develop. They might also be supported there.

IMHO the whole problem is to make sure that the wording is clear enough to 
protect the toASCII and ToUnicode processes as usunversal and permanent 
(otherwise we cannot industialize and export). To be sure they can be 
adapted at uppser level to respect the real life needs (like grave capital 
A?). And to support extended functions in a way not endangering the 
stability of the process and the stability of the applications 
(abreviatinos, synonisms, etc..)

Also, let remember this is no temporary patch. This is way of writing real 
words in using a minimum character set. That character set and ToAscii and 
ToUnicode functions will most probably be engraved in silicon chips and 
used worldwide in many applications from Keyboards to telephone etc. as 
providing a larger number of alternative than digital (0-1) and numeric 
(0-9) encoding. We must make sure we protect that universal industrial 
solution, but do not limit our capacity for innovation.

Thank you for your time/
jfc

---

From: "James Seng" <[email-masked]>
Date: Wed, 4 Sep 2002 22:48:13 +0800

Most are threads here are over (a) the content (b) the direction (c) the
abstraction (d) the technical specification etc. Many of them are religious
in nature, an

Your thread, however is the only one I seen (or heard) from all who has read
the draft to say they dont understand it.

So either the draft is really hard to understand and all those who are read
it (including non-english speaker) have either somehow able to understand it
or keep silent, or there might some other problem with the only one who
fails to understand it.

Therefore, I think we should drop this thread as I do not seen any rough
consensus that there is anything unclear about the specification.

-James Seng

---

From: "James Seng" <[email-masked]>
Date: Wed, 4 Sep 2002 23:10:15 +0800

Dear all,

It is apparent from this long mail that there is are some misunderstand of
how Unicode works, how accents is combine via NFKC among other things.

I would strongly suggest Jefsey to get the latest copy of Unicode book from
the Unicode Consortium to understand the basic terminology and principles.
It would also be useful if everyone involved in this discussion take a break
before continuing again with this discussion.

This is an IETF working group so I hope participants could argue in a
logical and technically correct (as much as possible) manner. This is not a
political forum. I hope we dont degrade ourselves to derailing the process
for a sake of winning a word-war.

-James Seng

---

From: Soobok Lee <[email-masked]>
Date: Thu, 5 Sep 2002 01:52:38 +0900

Personally, i appreciate Jefsey's, as one of regular @LARGE member, showing
interests in tough IDN technical details and its implications to end user 
experiences.  I hope more @LARGE members to come here and look into various 
aspects of IDN deployments and its cost and social effect issues that are 
relevant to consumer interets.

As far as i know, this WG (and the chairs) had been originated from IDN WG of 
MINC which was a consortium of commercial IDN vendors. This WG , as i feel 
for one year of regular participation, has been biased in favor of 
commercial IDN vendors and their agendas. of course, some participants have
stand on the comsumer/end user side and tried to neutralize this WG.

Don't be disappointed at hearing "out of scope!" sometime from someone. When DNS
and the internet came out from ISI labs and later from US boundaries, DNS become
the internationally shared, unique and precious resources. Every internet
user in the world has sole rights to see mature and long-term safe 
solutions for IDN, because they paid for the internet and its standards technologies.

Fortunately, this WG discussion is open and I believe IESG and IAB would
oversee IDN standardization for the interest of the public, not for some
commericial driving forces of IDN.

Soobok Lee

On Wed, Sep 04, 2002 at 10:48:13PM +0800, James Seng wrote:
> > not accent nor cedilla. So "Jean-Fran?ois" (my forename) is Unicode and
> > and to some why they could not register their name. The Marquis d'? will
> be

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 4 Sep 2002 20:40:39 +0000

Patrik Fältström <[email-masked]> wrote:

> _extremely_ confusing and bad to have the wg continue to discuss
> wording changes.
>

Okay, sorry, this is my first time through the process.

AMC

---

From: "James Seng" <[email-masked]>
Date: Thu, 5 Sep 2002 06:24:52 +0800

I think you got this part of the history part seriously wrong. This working
group existed even before MINC is formed.

And no, I don't work for any IDN vendor or any IDN related business anymore.

-James Seng

---

From: Soobok Lee <[email-masked]>
Date: Thu, 5 Sep 2002 08:24:37 +0900

> group existed even before MINC is formed.

Ah, MINC is not the one, Sorry. But many of us know what the history is about.
Any "groups" of people and commerical organization have proper rights to make 
their voices organized in this WG. My concern is about the attitude and spirit 
of those groups.

> And no, I don't work for any IDN vendor or any IDN related business anymore.

I am not saying about your affiliations. I understand your jealousy for IDN.
I hope you also pay full respects to other one's jealousy for IDN, which may
have different angles and viewpoints than yours.

Cheers,

Soobok lee

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 05 Sep 2002 11:29:22 +0200

Dear Seng,
you read me wrong since we probably agree on most. My intent was not to 
start a dispute but to see completed a job well done, while the question is 
"is the text describing it OK?" and my position is "no".

On 16:48 04/09/02, James Seng said:
>Your thread, however is the only one I seen (or heard) from all who has 
>read the draft to say they dont understand it.

I dont say that. I say it is not properly worded to serve its purpose, at 
least the way I personally see such a purpose from my own needs. Thats all.

That alone would be a reason to discuss the wording. But I also see 
disagreements in this WG that partly match my own disagreements. And I see 
that a response to most is to put that text into a global wording 
perspective. Only this will  permit this work to foster innovation as a 
basic building block at a well identified place. Rather than to be 
considered by most as a transition and to lead to endless sterile and 
absurd conceptual disputes over wording misunderstandings and usage 
duration. This work is well done, has a definitive purpose and will be with 
us for a long. But it will be built coherently on top and aside: it must 
not prevent or harm such a development process due to a standalone word use.

I plan to extensively develop network system solutions based upon that RFC. 
The current wording and lack of insertion into a global architecture 
description will make it extremely difficult for human reasons. This will 
also make it extremely difficult for every other Registry, Industry, 
developer, governance body, other IETF WG, only because we will all talk 
about the same things but in using our own layer's  words - different from 
the words (even apparently opposing) used to described the core of our system.

This will lead many gurus, trolls, politician, ignorant etc. to make us 
fight, then try to concert over a common wording, etc.. until someone 
rewrite that RFC in our common words. ie waste years and efforts for nothing.

All this can be prevented in the simple way I document: this WG has solved 
a problem; now it is to say the people going to use the solution and build 
for it, on top or around what it does, what it does not, from where to 
where. In using the same words that the people producing its inputs and 
that the people using its outputs use, so they all understand clearly each 
other.

>So either the draft is really hard to understand and all those who are 
>read it (including non-english speaker) have either somehow able to 
>understand it or keep silent, or there might some other problem with the 
>only one who fails to understand it.

I do not think you need to be personal. All the more than I certainly 
proposed that my position could be wrong and did joke about my Frenglish 
and low IQ. And apologized for that.

I think that those who read it either did not dare to comment because the 
matter is complex and they feared to be responded as you does. The 
difference with me is that I am one of the probably very few who wait for 
the RFC. To build on top of it, with systems and users waiting for that. 
For me the product of this WG is not its solutions - I take for granted 
they are good ones - but the very text of the RFC. This is what we will use.

If I gather developers, meet customers, lobby politicians and tell them "we 
are going to use the RFC solutions which is perfect, but in a global 
perspective they missed", I will have to convince them I am right. If I 
succeed, I will then have to convince them that I however right to use such 
a solution.

>consensus that there is anything unclear about the specification.

If you mean the way the process is technically described and the way the 
process works, you are right. This is my premise.

If you mean the way its description can be used to describe a key building 
block in the global Internet architecture, as far as my own developments 
are concerned, I disagree.
jfc

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Sep 2002 09:18:27 -0400

Soobok,

This note demonstrates an almost-astonishing level of confusion
and misinformation.  I don't know whether to respond to it or to
assume that, having run out of technical arguments, you have
decided to resort to innuendo, conspiracy theories, and ad
hominum attacks and just start ignoring all traffic from you.

Some highlights for latecomers...

* This WG was originated as an IETF effort.  The charter was
constructed by people who are still active in the WG, most of
whom did not (and do not) work for organizations with a strong
commercial interest in IDN issues.  And it predates MINC by some
time.

* My recollection of the early months of MINC was that
registries and academic institutions were perhaps
overrepresented, but that interests with particular commercial
plans that they expected to push into the IETF were not.

* While I have often been unhappy with the WG and its processes
and conclusions, I have seen no evidence of dominance by
commercial IDN technology interests.  Certainly people with
those interests have participated --we would be in bad trouble
and out of touch with reality with they did not-- but I don't
believe their interests have been dominant at any stage.  It is
interesting to note that few, or none, of the authors of the
important documents come from such companies.

* I don't have any idea what you are talking about when you
describe Jefsey as a "regular @LARGE member".  We are all here
as individual experts.  Jefsey brings an historical perspective
that is different from that of most IETF participants (and that
is, I believe, factually wrong in many important respects).  I
believe that all such perspectives are useful.  But he is coming
in quite late to these discussions and I don't believe he has
yet raised an issue that was not raised by someone when the
documents were still under development.

* I can barely parse your paragraph about ISI, who "paid for"
the Internet, etc., but, to the extent to which I understand it,
I think it is largely incorrect as well.

I could go on, but I think it would be pointless.  Let's focus
on the issues and stop constructing theories about where things
have come from as a substitute for that focus.   Such theories
are, especially at this stage in the process, fairly useless
even if 
they are correct.  And yours, in the note below, do not appear
to be correct.

Fortunately, we are in agreement about your last paragraph.

regards,
        john

--On Thursday, 05 September, 2002 01:52 +0900 Soobok Lee
<[email-masked]> wrote:

> Personally, i appreciate Jefsey's, as one of regular @LARGE
> member, showing interests in tough IDN technical details and
> its implications to end user  experiences.  I hope more @LARGE
> members to come here and look into various  aspects of IDN
> deployments and its cost and social effect issues that are 
> As far as i know, this WG (and the chairs) had been originated
> from IDN WG of  MINC which was a consortium of commercial IDN
> vendors. This WG , as i feel  for one year of regular
> participation, has been biased in favor of  commercial IDN
> vendors and their agendas. of course, some participants have
> Don't be disappointed at hearing "out of scope!" sometime from
> someone. When DNS and the internet came out from ISI labs and
> later from US boundaries, DNS become the internationally
> shared, unique and precious resources. Every internet user in
> the world has sole rights to see mature and long-term safe 
> Fortunately, this WG discussion is open and I believe IESG and
> IAB would oversee IDN standardization for the interest of the
> public, not for some commericial driving forces of IDN.
> 
> Soobok Lee
> 
> 
>> Most are threads here are over (a) the content (b) the
>> direction (c) the abstraction (d) the technical specification
>> etc. Many of them are religious in nature, an
>> 
>> Your thread, however is the only one I seen (or heard) from
>> all who has read the draft to say they dont understand it.
>>...

---

From: Soobok Lee <[email-masked]>
Date: Thu, 5 Sep 2002 23:13:35 +0900

> hominum attacks and just start ignoring all traffic from you.

Thank you to decide to respond me. :-)

> plans that they expected to push into the IETF were not.

This come just from my mistake. 
I know well that MINC was formed in 2000, about
one year  later after IDN WG begins.
I just pointed to that pre-MINC IDN community around the world.
I know what was going on at the time. but i won't say much
about that here, really.

> important documents come from such companies.

I used "biased in favor of" and  that does not mean someone "work for" some
company. Without any money/salary involved, someone may favor one solution
over others for purely techincal reasons ("that idea is my inception!" and the
like).  Still i feel unhappy with the WG, as you often did. Why so?
I feel string pressure to hasten up the standardization process for a year, 
But, IETF/IESG seems not to follow the pressure. That's why i am still here now.

> documents were still under development.

I just tried to point out that trying to quenching discussion by chairs 
is not desirable. I have allergy with blunt "out of scope!", really.
That seems to have made me upset and mad in this thread.

> I think it is largely incorrect as well.

Yes, i have some bad memeory about the early history of DNS.
But the meaning what i try to carry will be clear, whether or
not you and all accept it or not. If DNS is not ours, why am i
here ?

> Fortunately, we are in agreement about your last paragraph.

That is why i am still here. :-)

Soobok Lee

---

From: "James Seng" <[email-masked]>
Date: Fri, 6 Sep 2002 08:23:48 +0800

I have already response to you in private but just like to highlight one
point:

"Lastly, and most importantly, IDN is an IETF working group. We move
forward with Internet Drafts, rough consensus and running code. We focus on
technical and we weight arguments on technical merits. Non-technical
argument (such as "world-peace") unfortunately is not relevant."

-James Seng

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Thu, 5 Sep 2002 20:33:07 -0400 (EDT)

Hmm.  RAVEN didn't work quite like that.

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   [email-masked]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                      -->It's very hot here.<--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 05 Sep 2002 18:29:26 -0700

>Hmm.  RAVEN didn't work quite like that.

Michael, thank you for raising an issue that has absolutely nothing at all 
to do with IDN.  It typically constructive of you to aid in maintaining 
working group focus in this fashion.

As to the topic that you would like to distract us with:  If you feel that 
IETF process has been violated, there are well-documented procedures for 
seeking remedy.  Since you train nascent lawyers, one presumes you have 
some respect for following well-documented procedures.

d/

> > > are concerned, I disagree.

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 06 Sep 2002 04:59:12 +0200

This is an out of context response quoting publicly a private mail where I 
aluded to your "world-war" unappropriate remark. I closed that thread in a 
private response where, I think, both parts should be at peace; after the 
sophomore welcome I was reserved.
jfc

---

From: "James Seng" <[email-masked]>
Date: Fri, 6 Sep 2002 11:23:39 +0800

It is not out of context. It is reminder that discussion on this working
group should be on technical merits.

Non-technical issues on IDN, e.g "world-peace" or solve the world-hunger or
that it revive the world economic etc, should be brought elsewhere.

ps: No, I say "world-war" -- I said "word-war".

-James Seng