Subject: RE: [idn] Document Status?

From: Erik Nordmark <[email-masked]>
Date: Wed, 11 Sep 2002 10:31:27 +0200 (CEST)

> IMO, if this is the intention, then the document needs to be
> made crystal clear -- this is a really bad area in which to say
> something circumspect that people can interpret as they will.
> And, in particular, it needs to be clear that:
> 
> (i) No one can expect a client-side error message on the basis
> of any of these excluded characters, labels, or sequences.
> I.e., that one must look up a name and, if it isn't present,
> return a "nodomain" error and not be expected (or even
> permitted) to return "that isn't a valid string in Lower
> Slobbovian".
> 
> (ii) The _only_ thing a registry (or other form of zone
> administrator) is permitted to do is to specify what character
> content will not be accepted in labels being registered, or what
> specific labels will not be registered.  This does not make any
> of those characters or sequences "invalid" as far as the
> protocol is concerned, it is just a restriction on registration
> in that particular zone or set of zones.  Any notions of local
> (or per-zone) interpretation of what particular characters
> "mean", or how they are to be interpreted or mapped, are
> off-limits and seriously noncomforming -- so seriously so that
> the administrator of the parent zone should consider it grounds
> for considering redelegation as a threat to global Internet
> interoperability.

John,

Do you have a feel for how lengthy text is needed? I'd like to find the
actual text that can be put in the document to make this more clear.

For instance, would it be sufficient to add after 
     This document does not attempt to define an "internationalized host
     name".  It is expected that some name-handling bodies, such as large
     zone administrators and groups of affiliated zone administrators,
     will want to limit the characters allowed in IDNs further than
     what is specified in this document, such as to prohibit additional
     characters that they feel are unneeded or harmful in registered
     domain names.
this text:
     Such prohbitations are outside of the scope of the IDNA (and DNS)
protocol 
     specifications. They can only be applied at domain name registration
time. 
     In particular, they MUST NOT have any impact on the behavior of the
     on-the-wire protocol.

  Erik

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Sep 2002 06:47:32 -0400

--On Wednesday, 11 September, 2002 10:31 +0200 Erik Nordmark
<[email-masked]> wrote:

>> made crystal clear -- this is a really bad area in which to
>> say something circumspect that people can interpret as they
>> will. And, in particular, it needs to be clear that:
>> 
>>...
> Do you have a feel for how lengthy text is needed? I'd like to
> find the actual text that can be put in the document to make
> this more clear.
> 
>      This document does not attempt to define an
> "internationalized host      name".  It is expected that some
> name-handling bodies, such as large      zone administrators
> and groups of affiliated zone administrators,      will want
> to limit the characters allowed in IDNs further than      what
> is specified in this document, such as to prohibit additional
>      characters that they feel are unneeded or harmful in
> registered      domain names.
> this text:
>      Such prohbitations are outside of the scope of the IDNA
> (and DNS) protocol 
>      specifications. They can only be applied at domain name
> registration time. 
>      In particular, they MUST NOT have any impact on the
> behavior of the      on-the-wire protocol.

I think that would just about do it, modulo an issue about "on
the wire" (see below).  At worst, it would make things clear
enough that the text could be fine-tuned in the next cycle if
that proved necessary.

It could probably even be clarified and streamlined further,
e.g., after "does not attempt to define an 'internationalized
host name'"

	Just as has been the case with LDH names, some zone
	administrators may impose restrictions, beyond those
	imposed by the protocol, on the characters or strings
	that may be registered as labels in their zones.  Such
	restrictions do not impact the protocols themselves; a
	query for a name that does not exist will yield the same
	response regardless of the reason why it is not in the
	relevant zone.   Restrictions imposed on a per-zone
	basis MUST NOT have any impact on the behavior of the
	on-the-wire protocol, and MUST NOT assume that clients
	issuing queries or interpreting responses will have any
	knowledge of zone-specific restrictions or conventions.
	
That avoids opening up problems that we should not care about --
definitions of "name-handling bodies", relationships among zone
admins, reasons why someone might want to impose naming
restrictions -- and even avoids binding this issue to the "host
name"/ "domain name" mess.  It points out that these sorts of
restrictions are nothing new, which I think is helpful. It also
nails down the one piece of the issue that your text might be
construed as not covering: ultimately, nameprep, etc., aren't
on-the-wire protocols, but rather specifications about what
clients are supposed to do.  And that makes it important, I
think, to clearly prohibit anything resembling "clients are
expected to know that, in looking up names in _my_ domain, they
are to do the following variant steps".

   john

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 11 Sep 2002 13:02:01 +0200 (CEST)

> the wire" (see below).  

Yes, I wasn't very comfortable with using that term in my text.

> At worst, it would make things clear

For "next cycle" = "when documents move to draft standard" I assume?

> 	knowledge of zone-specific restrictions or conventions.

Looks good to me.

Thanks,
  Erik

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Sep 2002 07:27:33 -0400

> For "next cycle" = "when documents move to draft standard" I

Or, if you publish this as Experimental, when they move to
Proposed :-)

>> 	knowledge of zone-specific restrictions or conventions.

Erik, as a meta-comment, the problem here, and the "what can be
displayed" one, are, I fear, symptomatic.  While there are some
other specific issues, the documents are just not very well
written _as a standard_.   In areas where we produce a document
for which there are no active competing ideas and
implementations, and in which there is clear consensus, we can
get away with such things, relying on good faith and the
robustness principle to pull us through.  

But, in the IDN area, we know that there are already operators
out there, selling names or tools that are not compatible with
one or more details of IDNA.  It is nearly certain that some of
them will try to claim conformance and argue that anyone who
doesn't interwork with them is non-conforming.  And some will do
almost certainly do that even if what they are doing requires
special DNS clients or servers, DNS middleboxes rewriting
queries, zone-dependent name interpretation rules, etc.   We can
(and should) head off a lot of problems by being very clear
about what problem is being solved, very clear about what we are
promising, and very clear about what behavior conforms and what
behavior doesn't.   The current document set doesn't do any of
those three as well as the situation appears to require.

regards,
    john

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 11 Sep 2002 13:43:08 +0200 (CEST)

> robustness principle to pull us through.  

I agree that the document could have been written differently.
But in my reading of the document(s) look clear enough to be implementable
from the specification. If there are specific points that are unclear
I don't have a problem with us collectively looking at text modifications
that try to clarify the document.
But I don't the benefits of a new document written in a different style
outweigh the delay.
Instead I think (except for specific clarifications) that the current
documents are good enough for proposed standard status and that
having them be implemented, as well as having folks work on applying IDNs
to application protocols in other WGs - such as URIs and email addresses, 
will give us feedback to produce a clearer draft standard down the road. 
A rewrite of the document would probably delay that part of the work
of internationalizing the IETF protocols.

> those three as well as the situation appears to require.

I think the documents must be clear enough so that they can be implemented
from the specification by an implementor who is trying to conform to
the specification and interoperate.
But for those that are more or less intentionally trying to misinterpret
the specification for their own purposes I fear that it will always be
possible for them to claim conformance and there is little the IETF as a 
standards producing organization can do; the IETF does not run a 
conformance testing and branding mechanism that prevents implementors 
from intentionally claiming conformance when they in fact do not conform.

So to the extent the point is to get an implementor to understand how IDNA
works I agree that the documents need to be clear.
But I don't think we can and should try to make the documents read like
protocol legal documents by trying to e.g. minimize the number of
intentional creative misinterpretations that can be made.
If it turns out that there are common intentional creative misinterpretations
it might make sense to have a separate document in the RFC series
documenting such bad ideas and why they are bad.

  Erik

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 12 Sep 2002 00:47:48 +0000

John C Klensin <[email-masked]> wrote:

>       administrators may impose restrictions, beyond those imposed
>       by the protocol, on the characters or strings that may be
>       registered as labels in their zones.  Such restrictions do not
>       impact the protocols themselves; a query for a name that does
>       not exist will yield the same response regardless of the reason
>       why it is not in the relevant zone.  Restrictions imposed on a
>       per-zone basis MUST NOT have any impact on the behavior of the
>       on-the-wire protocol, and MUST NOT assume that clients issuing
>       queries or interpreting responses will have any knowledge of
>       zone-specific restrictions or conventions.

Thanks John, that looks helpful.  I just have a few nitpicky comments
and questions about the precise wording.

    Just as has been the case with LDH names,

The phrase "LDH name" or "LDH label" appears nowhere in the document, so
let's not introduce it now.  Let's say "ASCII names".

    some zone administrators

Let's say "DNS zone administrators".  This text would be going into
section 2, which currently does not talk about DNS at all, so we need to
establish that context for this paragraph.

    may impose restrictions, beyond those imposed by the protocol,

Which protocol?  Maybe you mean "imposed by DNS or IDNA".

    on the characters or strings that may be registered as labels
    in their zones.  Such restrictions do not impact the protocols
    themselves;

Which protocols are not impacted?  Recently you were saying how
important it is for DNS update protocols to have distinct return codes
for "invalid name" versus "inadmissible name", so this part of the DNS
protocol *would* be impacted by per-zone name restrictions.

    a query for a name that does not exist will yield the same response
    regardless of the reason why it is not in the relevant zone.

Okay.

    Restrictions imposed on a per-zone basis MUST NOT have any impact on
    the behavior of the on-the-wire protocol,

Again, which protocol?

    and MUST NOT assume that clients issuing queries or interpreting
    responses will have any knowledge of zone-specific restrictions or
    conventions.

I'd rather not insert requirements into the terminology section.
Couldn't we say "have no impact" and "cannot assume that clients"?

Here's a stab at addressing these concerns, although you might be able
to come up with something better:

    Just as has been the case with ASCII names, some DNS zone
    administrators may impose restrictions, beyond those imposed by
    DNS or IDNA, on the characters or strings that may be registered
    as labels in their zones.  Such restrictions have no impact on the
    syntax or semantics of DNS protocol messages; a query for a name
    that does not exist will yield the same response regardless of
    the reason why it is not in the zone.  Clients issuing queries or
    interpreting responses cannot be assumed to have any knowledge of
    zone-specific restrictions or conventions.

AMC

---

From: [email-masked] <[email-masked]>
Date: Thu, 12 Sep 2002 16:29:15 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Adam M. Costello
....
> 
> Here's a stab at addressing these concerns, although you 
> might be able to come up with something better:
> 
Hi Adam !
        Sorry,  I have a  confusing in the statement :
"a query for a name that does not exist will yield the same response
regardless of  the reason why it is not in the zone. "  
        A  *  label in zone record will  response to a specified FQDN.
Does
 a  specified FQDN  response is also means a non-existed name ? 
Or  the * case is still  in the meaning "the same response" ?

Best  regards

L.M.Tseng,

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 12 Sep 2002 11:04:49 +0200 (CEST)

> Couldn't we say "have no impact" and "cannot assume that clients"?

Makes sense, but then I think we need to find a different place in
the document where it makes sense to state the requirement.

Perhaps we can find a new place in the document outside of the 
terminology section where all of this text can be put with the requirements
language.

 Erik

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 Sep 2002 08:12:17 -0400

--On Thursday, 12 September, 2002 00:47 +0000 "Adam M. Costello"
<[email-masked]> wrote:

>>       query for a name that does not exist will yield the
>>       same response regardless of the reason why it is not in
>>       the relevant zone.  Restrictions imposed on a per-zone
> Thanks John, that looks helpful.  I just have a few nitpicky
> comments and questions about the precise wording.
> 
> The phrase "LDH name" or "LDH label" appears nowhere in the
> document, so let's not introduce it now.  Let's say "ASCII
> names".

I was trying to convey the gist of an approach.   As far as I'm
concerned, one of the problems with the document is that it
suffers from too many writing styles already; you don't need
mine too.  But "ASCII names" doesn't quite do it either: if you
want to be precise, probably the right thing is to refer to the
definition.  E.g., "Just as has been the case with the
'preferred syntax' of the DNS specification [RFC1035, Section
2.3.1]",...   Those who know what this points to will know;
those who don't may benefit from looking it up.
 
>     some zone administrators
> 
> Let's say "DNS zone administrators".  This text would be going
> into section 2, which currently does not talk about DNS at
> all, so we need to establish that context for this paragraph.

ok
 
> Which protocol?  Maybe you mean "imposed by DNS or IDNA".

that would be ok

>     on the characters or strings that may be registered as
> labels     in their zones.  Such restrictions do not impact
> the protocols     themselves;
> 
> important it is for DNS update protocols to have distinct
> return codes for "invalid name" versus "inadmissible name", so
> this part of the DNS protocol *would* be impacted by per-zone
> name restrictions.

If the IDNA spec has any impact on any [other] DNS-related
protocol, it falls outside the WG's scope.  So, either the
sentence as I wrote it is correct, or you have just supplied the
petard on which you would presumably like to be hoisted.

>     a query for a name that does not exist will yield the same
> relevant zone.
>     Restrictions imposed on a per-zone basis MUST NOT have any
> impact on     the behavior of the on-the-wire protocol,
> 
> Again, which protocol?

See above, but I would welcome better text for this.
 
>     and MUST NOT assume that clients issuing queries or
> interpreting     responses will have any knowledge of
> I'd rather not insert requirements into the terminology
> section. Couldn't we say "have no impact" and "cannot assume
> that clients"?

See comment above about writing styles.

> Here's a stab at addressing these concerns, although you might
> be able to come up with something better:
> 
> imposed by     DNS or IDNA, on the characters or strings that
> may be registered     as labels in their zones.  Such
> restrictions have no impact on the     syntax or semantics of
> DNS protocol messages; a query for a name     that does not
> exist will yield the same response regardless of     the
> reason why it is not in the zone.  Clients issuing queries or
>     interpreting responses cannot be assumed to have any

Modulo comments above, probably close enough.

     john

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 12 Sep 2002 21:16:53 +0000

"tsenglm@?p??????.???j.tw" <[email-masked]> wrote:

> Does a specified FQDN response is also means a non-existed name ? Or
> the * case is still in the meaning "the same response" ?

The intended meaning of "does not exist" was "matches no records".
Maybe we should say "matches no records".

AMC

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 12 Sep 2002 21:25:45 +0000

John C Klensin <[email-masked]> wrote:

> > document, so let's not introduce it now.  Let's say "ASCII names".
>
> "ASCII names" doesn't quite do it either: if you want to be precise,
> probably the right thing is to refer to the definition.  E.g., "Just
> as has been the case with the 'preferred syntax' of the DNS
> specification [RFC1035, Section 2.3.1]",...

I think "ASCII names" is sufficient.  Zone administrators have had the
ability to impose additional restrictions on all ASCII names, both ASCII
names that use the preferred syntax and ASCII names that don't use the
preferred syntax.

> > important it is for DNS update protocols to have distinct return
> > codes for "invalid name" versus "inadmissible name", so this part of
> > the DNS protocol *would* be impacted by per-zone name restrictions.
>
> If the IDNA spec has any impact on any [other] DNS-related protocol,
> it falls outside the WG's scope.

True, but irrelevant.  The impact in question is the impact of
restrictions imposed by zone administrators, not the impact of IDNA.
Those restrictions are independent of IDNA.  IDNA is not creating a new
power for zone administrators, they have always had this power to impose
additional restrictions.

AMC

---

From: Soobok Lee <[email-masked]>
Date: Fri, 13 Sep 2002 09:07:01 +0900

> restrictions imposed by zone administrators, not the impact of IDNA.

What if the restrictions imposed by zone admin are  to enforce the
unifications which were not covererd by NFKC/casefolding of IDNA?
For example, purely font-variant char pairs( e.g., some TC/SC ), 
look-identical-pairs of chars within a script, and 
thousands of pairs of look-similar chars. Those were not in ASCII
names and were introducedd into DNS by IDNA'a nameprep component.

Personally, i haven't seen any zone admin who enforces '1' and 'l' equivalence
in his ASCII zone.
But wrt IDN, i guess most (or all) zone admins will show serious concerns 
about ununified  latin 'i' and cyrillic 'i'. And that is why some folks
are working on 'IDN registration tool', as a post portem remedy, which
cannot help dynamicly-updated-zones whose admins are trusting the ASCII and
inadvertently the ASCII-tunneled IDN as well.

I think this impact on DNS-protocols is caused by IDNA, not by zone admins
who may not even get noticed of the introduction of IDN space in ASCII.

Soobok Lee

---

From: [email-masked] <[email-masked]>
Date: Fri, 13 Sep 2002 08:19:43 +0800

....
> The intended meaning of "does not exist" was "matches no 
> records". Maybe we should say "matches no records".
> 
       Thanks , that is fine .  A    *   label  is a special case  but
used in many web virtual hosts.

L.M.Tseng

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 13 Sep 2002 01:12:56 +0000

Soobok Lee <[email-masked]> wrote:

> But wrt IDN, i guess most (or all) zone admins will show serious
> concerns about ununified latin 'i' and cyrillic 'i'.  And that is why
> some folks are working on 'IDN registration tool', as a post portem
> remedy, which cannot help dynamicly-updated-zones whose admins are
> trusting the ASCII and inadvertently the ASCII-tunneled IDN as well.
>
> I think this impact on DNS-protocols is caused by IDNA, not by zone
> admins who may not even get noticed of the introduction of IDN space
> in ASCII.

It is caused by IDNA, but it's not an impact on DNS protocols, it is an
impact on filters that restrict the names admitted into zones.  These
filters will have to be revised if they want to filter out some IDNs.
These filters are not part of the DNS protocol; the DNS standard makes
no mention of them.

AMC

---

From: "James Seng" <[email-masked]>
Date: Fri, 13 Sep 2002 10:09:13 +0800

First, the point you raise is related to Nameprep/Stringprep, not IDNA.
Please dont confuse the two document.

If the registry choose to do additional mapping which will cause
incompatible with the Nameprep, then two things should happen:

a) The registry should revise its policy to be compatible with Nameprep
   (It is possible. See
    http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-00.txt)

b) If they choose not to, then they choose not to be compatible with
Nameprep. In such case, they shouldnt complain. (Beside, IETF does not
enforce anyone on compatibility)

But lets get back: Nameprep is a client-side normalization. It is not
designed to handle the registry issues . Registry issues should be handled
in other sets of documents.

-James Seng

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 13 Sep 2002 11:50:41 +0900

----- Original Message ----- 
From: "James Seng" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "IETF idn working group" <[email-masked]>
Sent: Friday, September 13, 2002 11:09 AM
Subject: Re: [idn] Document Status?

> Please dont confuse the two document.

Nameprep/stringprep's NFKS/Casefolding introduced the ambiguity into the DNS
and IDNA's ACE concept tunneled "that different beasts" through the trusted or
unsuspected ASCII namespace for which existing dns/application protocols 
have no filtering mechanism, while some of them have builtin filtering machanisums for
non-ASCII 8-bit strings now, like BIND or SENDMAIL.

If this IDNA were introduced in early 1980 or 1990, at that time, many protocols 
authors would have wanted to insert some sphiscatred filtering mechanisms for 
ambiguous IDNs in their drafts.

Soobok Lee

---

From: "James Seng" <[email-masked]>
Date: Fri, 13 Sep 2002 11:02:55 +0800

Change topic again? How typical :-)

Lets get back: There is two topic here.

1. registry vs Nameprep

I have already answered you the Nameprep is okay. You have not make a case
registry mapping is going to be a problem.

2. "ambiguity" of Nameprep/IDNA

You have only stated your opinion it is ambigous. You have absolute right to
do so.
But you have not stated any technical reasons why.

-James Seng

> > > > > If the IDNA spec has any impact on any [other] DNS-related
protocol,
> > > But wrt IDN, i guess most (or all) zone admins will show serious
concerns
> > > cannot help dynamicly-updated-zones whose admins are trusting the
ASCII
> > and
admins

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Sep 2002 00:30:53 -0400

--On Friday, 13 September, 2002 09:07 +0900 Soobok Lee
<[email-masked]> wrote:

>> > > Which protocols are not impacted?  Recently you were
>> > > saying how important it is for DNS update protocols to
>> > > have distinct return codes for "invalid name" versus
>> > > "inadmissible name", so this part of the DNS protocol
>> > > *would* be impacted by per-zone name restrictions.
>> > 
>> > protocol, it falls outside the WG's scope.
>> 
> What if the restrictions imposed by zone admin are  to enforce
> the unifications which were not covererd by NFKC/casefolding
> of IDNA? For example, purely font-variant char pairs( e.g.,
> some TC/SC ),  look-identical-pairs of chars within a script,
> and 
> thousands of pairs of look-similar chars. Those were not in
> ASCII names and were introducedd into DNS by IDNA'a nameprep
> component.

Normally, what the term "restriction" would refer to would be
rules that say "you cannot use that character at all" or "we
won't register any of the strings on this list as labels".
Precisely the case that is being excluded is one in which the
zone admin attempts to say "we are adding the following mapping
to those specified by nameprep" or "we are using the following
mapping instead of those specified by nameprep".   Mapping rules
-- rules that force one code point (or sequence of code points)
to be transformed into another to to be treated as equivalent to
another are not possibilities for local (or zone) variations.

If two code point sequences are different after nameprep is
applied, then the only way in which they can be made
"equivalent" in a given zone is by multiple registrations that
are connected by having identical targets (e.g., one is a DNS
CNAME pointing to the other or one has exactly the same RRs and
data as the other) or by mechanisms external to the DNS and
IDNA(e.g., if all URLs containing one of the FQDNs involve
protocols that can do redirects and that cause such redirects to
sites/ locations that have content for URLs with the other FQDN
substituted.

If the revised language doesn't make this clear enough, then
someone should propose other language.

> Personally, i haven't seen any zone admin who enforces '1' and
> 'l' equivalence in his ASCII zone.
> But wrt IDN, i guess most (or all) zone admins will show
> serious concerns  about ununified  latin 'i' and cyrillic 'i'.

That is probably not the best of examples, but, ignoring that,
any zone admin who has those concerns and wants to do something
about them is permitted only the following choices:

(i) Ban any registrations that contain latin 'i'

(ii) Ban any registrations that contain cyrillic 'i'

(iii) Ban both characters

(iv) Ban all IDN/ ACE-based registrations (of course, (iii) is a
special case of this.

(v) Insist, or automate a rule in which every registration of a
string containing latin 'i' be matched to one containing
cyrillic 'i' and vice versa.

> And that is why some folks are working on 'IDN registration
> tool', as a post portem remedy, which cannot help
> dynamicly-updated-zones whose admins are trusting the ASCII and
> I think this impact on DNS-protocols is caused by IDNA, not by
> zone admins who may not even get noticed of the introduction
> of IDN space in ASCII.

I don't understand this comment and its relevancy to the IDN WG.

     john

---

From: "Soobok Lee" <[email-masked]>
Date: Sat, 14 Sep 2002 09:20:40 +0900

----- Original Message ----- 
From: "James Seng" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "IETF idn working group" <[email-masked]>
Sent: Friday, September 13, 2002 12:02 PM
Subject: Re: [idn] Document Status?

> Change topic again? How typical :-)

What change ? Track the history of ambiguity and zone admin problems in
this list.

> registry mapping is going to be a problem.

I and others already listed the case in this list.
the mapping won't be reflected in protocols and application comparisons
unlike that caseinsensitive matching of ASCII names.

> But you have not stated any technical reasons why.

You keep on insisting that IDN introduces no new security problem than that of
'0' and 'o' in ASCII names. But that is not correct. IDN introduce the problem
of look-exactly-identical chars. That was not in ASCII names.

Soobok Lee

---

From: "James Seng" <[email-masked]>
Date: Sat, 14 Sep 2002 09:49:58 +0800

> unlike that caseinsensitive matching of ASCII names.

I did not hear other but I certainly hear you.

And I responsed to you why your "mapping" problem isnt a problem. You have
not stated why my reasoning is wrong or otherwise.

> '0' and 'o' in ASCII names.

Did I insist that IDN introduce no new security? I think you hear it in your
dreams. I suggest you read the new security consideration in the existing
drafts (Stringprep particularly).

> But that is not correct. IDN introduce the problem

And your proposal draft is...?

-James Seng

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 14 Sep 2002 18:17:29 +0200

I was mislead by the text of the scope into believing that seeked user 
inputs could be formulated in the user plain language. I understand now 
that we developers, users, DNS Managers are to follow the IETF rules to 
permit this WG to fulfill its mission to repot on us. Because these rules 
prevent external pressures and help you determining real life needs.

I therefore try to gather enough expertises in these areas and to make them 
write a draft document. I have no resource for such an endeavor and very 
little time. So I will continue only if it would be of help?

The first inputs and meetings, lead to questions that a reveiw of the WG 
mandate helps listing. What do you think covered, you want to disregard and 
you would wish we focus on?

<quote>
The goal of the group is to specify the requirements for internationalized 
access to domain names and to specify a standards track protocol based on 
the requirements.
</unquote>

We have problems with an International Standard constistent definition of 
"internationalized", "access" and "domain names". Is there an IETF, ISO, 
CEI definition we could use? Is there a more complete documentation of the 
posed problem?

<quote>
The scope of the group is to investigate the possible means of doing this 
and what methods are feasible given the technical impact they will have on 
the use of such names by humans as well as application programs, as well as 
the impact on other users and administrators of the domain name system.
</quote>

this group has determined that Unicode was to be used to support natural 
names into the DNS. We do not find a discussion of the alternatives. A part 
from being in the charter, it is the only way to foster innovation and/or 
evolutions in continuity.

our target is to help this group's investigation concerning the impact on 
humans and applications as well as on computer and network services 
including DNS, OPES, mail, web services ..administrators.

We understand that no questionnaire has been sent yet to the Internet 
community to gather the necessary information and comments. Current group 
exchanges show there is a lack of agreement among the WG on the needs and 
impacts. Also that "technical impact" is understood in extremely 
restrictively (within the proposed solution, not as all the technical 
impacts of a proposed solution).

no user, developer, administrator group should impose its requirements, and 
impact the global solution. So we are only ready to share, with other user 
groups, in the drafting of a questionnaire to poll the Global Internet 
Community.

- Is this an acceptable approach?
- Is it technically feasible?

<quote>
A fundamental requirement in this work is to not disturb the current use 
and operation of the domain name system, and for the DNS to continue to 
allow any system anywhere to resolve any domain name.
</quote>

we feel that the currently proposed solution affects the current operations 
and management of the DNS system due to:

1. the lack of documented separation between the domain name as an 
alphanumeric pointer to an IP address, and as a mnemonic. The only current 
response are the US ACPA and to some extent the ICANN UDRP. We do not think 
they are technical responses matching the IDN additional concerns.

2. the non documented (analyze, rational, nature, evolution) introduction 
of a "prefix" in DNS names. At minimum we understand it as a second 
parallel namespace, unrelated to the first namespace by any existing rule 
from the first namespace. But, based upon pragmatic experience, we 
understand it as the introduction of a cross hierarchy in the namespace.

3. the lack of proposed solution to separate IDN zones in DNS files.

We may be wrong, but we feel that should the IETF work on the first very 
basic point, every other point we rise would be easy to solve, or would 
even not exist.

<quote>
The group will not address the question of what, if any, body should 
administer or control usage of names that use this functionality.
</quote>

We agree as no one should be made in position to maintain a second DNS 
cross-hierarchy. This is why we feel the prefix proposition may result from 
some existing administration. The solution should be global. If 
pre-existing practices are supported: all the better, but this should not 
limit the thinking.

<quote>
The group must identify consequences to the current deployed DNS 
infrastructure, the protocols and the applications as well as transition 
scenarios, where applicable.
</quote>

As a particular group, we may have a solution to propose. We believe it is 
transparent to the existing DNS infrastructure and requires no protocol and 
minimal application changes; and no transition as it only calls on 
progressives updates of the applications software on a per keyboard basis.

This proposition would motivate our effort. But our main target would be to 
help this group to better understand the needs and the impacts on the 
users. How should we proceed?

<quote>
The WG will actively ensure good communication with interested groups who 
are studying the problem of internationalized access to domain names.
</quote>

This is the problem we want to help addressing.
For that we need the help and the understanding of this group.
I would suggest that other groups do the same.

<quote>
The Action Item(s) for the Working Group are
1. An Informational RFC specifying the requirements for providing 
Internationalized access to domain names. The document should provide 
guidance for development solutions to this problem, taking localized (e.g. 
writing order) and related operational issues into consideration.
</quote>

This is where we want to help.
May be as co-author?

<quote>
2. An Informational RFC or RFC's documenting the various proposals and 
Implementations of Internationalization (i18n) of Domain Names. The 
document(s) should also provide a technical
evaluation of the proposals by the Working Group.
</quote>

This is where we would like to see our proposition evaluated. This is why 
it would be really useful to us if a definition of the different layers 
involed could be made. We trust the expertise of this group for the inner 
Unicode/Ascii "black-box": we are interested in the management of its "I/O".

<quote>
3. A standards track specification on access to internationalized domain 
names including specifying any transition issues.
</quote>

it seems that a rough consensus here is that a solution could go in 
operations and to be tuned further on. This cannot be: one cannot repel 
millions of names. To avoid "babelnet" the alternative is:
- to proose a very limited IEFT experiment (aside of the other test beds),
- to get a solution universally endorsed by users, developpers, admins and 
lawyers .

Question: would that effort of ours be of any worth to you?
If yes, I will try.

thank you.
jfc

---

From: "James Seng" <[email-masked]>
Date: Sun, 15 Sep 2002 01:46:26 +0800

Jefsey,

Offline again: I really really advise you to go to www.i-d-n.net and revise
the archives we have for the last 3 _years_.

-James Seng

---

From: Rick Wesson <[email-masked]>
Date: Tue, 17 Sep 2002 21:04:29 -0700 (PDT)

Ok I haven't made a post for some time, i hope this one makes up for it.

comments in line...

-rick

> CEI definition we could use? Is there a more complete documentation of the

all other participitants understood the terms as did the IESG when the wg
was chartered. This is the first note I've read bashing a charter
developed over 3 years ago.

> impacts of a proposed solution).

The IETF didn't send out a questionnaire to see if TCP would be best over
IP. The IETF does not send out questionnaires.

> groups, in the drafting of a questionnaire to poll the Global Internet

IETF standards do not impose, that is for people to do. IETF documents
stand for themseleves on the mantle of the participiants that wrote them.

> - Is this an acceptable approach?

yes, you provide no alternative.

> - Is it technically feasible?

it appears to more successfull than any other technology built by humans.

> they are technical responses matching the IDN additional concerns.

out of scope for the IETF. If we would have disussed Intelectual Property
in RFC883 we would not be communicating via email today. Its not the
IETF's problem, see how governments have delt with ENUM.

> understand it as the introduction of a cross hierarchy in the namespace.

smoke less grass, or mabe move from hash to grass. I prefer hash but it
fucks up my writing too.

> basic point, every other point we rise would be easy to solve, or would

out of scope, IDN deals with whats on the wire, not whts on the disk
drives. Formats of application data is not in scope for this working
group. Pick an open source application and write the code, or roll your
own ( you can sing allong if you like... roll roll roll your joint gentley
down the stream...)

> pre-existing practices are supported: all the better, but this should not

well call me limited, you're just going to have to restate that one for
me. as for the quote, dam right we are not making any more global
monopolies or borides that need to manage or administrer them. proven to
be a bad idea.

> users. How should we proceed?

ok, clue me on the solution, you provide no refrence, we require at least
an Internet-Draft. You appear to be capable of writing one. Without an I-D
you have no soap-box to stand on in the IETF.

don't like that, then go play at the ITU.

> I would suggest that other groups do the same.

you sound like you want to chair the IETF, maybe you should talk to Harold
about that...

> This is where we want to help.

ok, i can actually add some content here insted of wipping you with a wet
noodle. We did discuss the requirements draft, we had one, it expired. the
group discussed writing one on how we got to the place we were; atlast we
decided that documenting the convluted process we went through could a
destructive process and not one willing soul stood up to take on the
project.

so we won't meet that goal. sure it sucks, but sometimes working groups
don't meet all their goals. the process is imperfict -- we are humans,
should you expect more?

> Unicode/Ascii "black-box": we are interested in the management of its "I/O".

I'd propose you read the archives of the list and the numerous I-Ds
proposed. there was even a design team that reviewed many of the proposals
and wrote up their view. It was posted to the list, read the archives.

Again, make a draft, post it to the list; we don't write them for you.

> - to get a solution universally endorsed by users, developpers, admins and

no.

> Question: would that effort of ours be of any worth to you?

I don't think your effort would be of any use at all. I care not what
lawyers think of this. It is not the IETFs job to reach out an educate
those, like you, that need be educated; especially when they have been
instructed on how to self educate and have chose not to do so.

Making posts such as you have do nothing for us, this is not constructive,
you offer us nothing but words, unconnected dots.

-rick

---

From: "James Seng" <[email-masked]>
Date: Wed, 18 Sep 2002 19:16:14 +0800

I have spoke to both Jefsey & Rick on this. Certain words Rick used was in
humor rather than meant as a personal attack, altho his point is well-taken.

As such, on Jefsey's request, I am writing this mail to close this thread.

-James Seng