Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)

From: Behnam Esfahbod <[email-masked]>
Date: Mon, 18 Jul 2011 21:01:56 -0400

Hi John,

I think it is time to stop general pronouncements that have been repeated and
repeated so many times over these past years and get down to specifics.  Here
are two very concrete points you should note:

1. ZWNJ is not a special quirk of Persian language, it is not a mnemonic tool,
   nor is it an optional writing-style device.  ZWNJ is used in the writing of
   MOST languages using Arabic script. ZWNJ is a necessity for this script the
   same way that contextual joining is in the first place.

2. If ZWNJ is claimed to cause confusion and phishing problems beyond what is
   normally acceptable for other symbols, it is up to the claimants to
   demonstrate this claim.

3. Many security issues with Arabic PVALID characters have been identified by
   ICANN VIP Arabic team and many of them are more serious than the possible
   cases for ZWNJ.  If you decide to remove every character that "might" be
   confused with another one in some "defected font" or "small type size", you
   will end up with less than a dozen of characters for Arabic script, making
   it useless for all the users.

Let us stop talking about misleading generalities.

Thanks,
-Behnam

On Mon, Jul 4, 2011 at 8:17 AM, John C Klensin <[email-masked]> wrote:
>
>
> --On Thursday, June 30, 2011 16:56 -0400 Behnam Esfahbod
> <[email-masked]> wrote:
>
>> Hello,
>>
>> The restriction rules of the latest draft for "Top Level
>> Domain Name Specification", section 4 [1], is unfortunately
>> very restrictive for some languages, including Persian
>> language (in Arabic script).
>>...
>> Hereby, I would like to request reconsidering the restriction
>> rules of TLD DNS-Labels and to allow characters with CONTEXTJ
>> derived property value in the labels. (Of course the IDNA2008
>> contextual restrictions for CONTEXTJ characters must apply.)
>
>
> Behnam,
>
> (personal opinion only; not wearing any present or past "hats")
>
> ICANN makes up their own rules about this sort of thing, maybe
> with emphasis on "makes up".  They have fairly consistently told
> IETF participants that IETF opinions are relevant only if they
> impose clear technical restrictions (and maybe not then).   The
> degree of attention paid in ICANN to the arguments of either RFC
> 3675 or RFC 4185 are perhaps indicative.
>
> IDNA2008 imposes no special requirements on top level IDNs -- if
> a string is valid at any other level of the tree, it does not
> violate the protocol to use it at the top level.  So, from an
> IETF standpoint, there is nothing to reconsider in order to
> permit ZWNJ to be used in domain names.
>
> That said, let me provide a different perspective on the
> problem.  This perspective may be reflected in both current
> ICANN policy and in draft-liman-tld-names-05.   It certainly
> influenced the recommendations I made about the latter document.
>
> First of all, while various folks around ICANN seem to forget it
> regularly, there has never been an entitlement to use names or
> words in the DNS.  There are many words in English that cannot
> be written using the traditional "preferred name syntax" (often
> called "LDH") rules.  There are also many family names, business
> names, and so on that cannot be used.  While IDNs permit use of
> many characters that are not part of the basic Latin-derived
> alphabet, they don't change the fundamental principle that
> something being a valid word or phrase in a language does not
> create an automatic "right" to have it as a domain name.
> Instead, almost every decision as to what strings should be
> permitted to be used as labels within a given zone represents a
> tradeoff (either globally across zones or within a particular
> zone) because the desire to use a particular string as a
> mnemonic label and the risks that string might create when used
> for Internet references.
>
> The characters listed as CONTEXTJ and CONTEXTO are inherently
> tricky.  Used in the wrong context, they produce labels that
> don't compare equal but that have exactly the same appearance.
> To avoid those and other problems, the 2003 version of IDNA
> excluded them entirely from IDNs using the "map to nothing"
> technique that we now recognize as creating dangerous
> ambiguities.  While we decided to permit them in appropriate
> contexts in IDOA2008, the reality is that the contextual rules
> themselves aren't adequate without additional restrictions that
> go beyond anything we can do as a DNS or IDNA technical matter.
>
> If one were using, e.g., Persian strings in a domain whose use
> is largely limited to mnemonics derived from Persian and almost
> certain to be treated as Persian writing style and rendered with
> Persian-specific rendering engines, then there should be little
> problem using ZWJ and ZWNJ.  That situation would exist, or at
> least be manageable, in .IR and any Arabic script (and
> Persian-language-derived) variation on that name.   But the root
> zone (and hence TLD names) are inherently problematic because it
> has to available for labels in all scripts and because neither
> languages nor writing style can be encoded reliably in the DNS
> (at least without causing lots of other problems).  However, if
> a Persian string containing ZWNJ were rendered either by a
> rendering engine designed for the Arabic language (or one that
> was simply naive about Arabic script), the resulting situation
> would be an invitation to phishing, to fraudulent certificates,
> and so on.
>
> So, while permitting ZWNJ (and ZWJ) in top-level domain names
> seems attractive, it is not safe -- much less safe than
> permitting the PVALID characters that are always displayed.
> Striking the balance between safety and the desire to be able to
> include all mnemonics based on any language in the world will
> always be a difficult choice and, ultimately, a policy one, but,
> as long as the community believes that security, stability, and
> predictable behavior take precedence over the use of any given
> character in any given script, decisions that exclude
> problematic characters from the root will continue to be
> justified.
>
> best regards,
>   john
>
>
>
>
>
>
>
>

-- 
    '     بهنام اسفهبد
    '     Behnam Esfahbod
   '      http://behnam.esfahbod.info
  *  ..   http://zwnj.org/
 *  `  *  http://persian-computing.ir
  * o *   3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 19 Jul 2011 07:25:45 +0200

>   normally acceptable for other symbols, it is up to the claimants to

Actually, no.

When discussing security and stability of the Internet as a whole, it is the other way around. The first general principle is to ensure you do no harm. Then one can discuss whether the change is actually valuable.

So the burden of convincing the community is on the ones that do think a character like ZWNJ is to be allowed or not that the need for the character is greater than the potential harm in _any_ context it might be used in.

Yes, I am chair of ICANN Security and Stability Advisory Committee, and this I say is just a hint of what kind of statement and question will be asked when/if a proposal about the use of ZWNJ will actually reach ICANN pdp. This statement of mine does not of course preclude any kind of potential SSAC statement. Just a hint of what questions SSAC might ask.

For the rest of your points, including how difficult this discussion has ended up being -- I agree with you.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Tue, 19 Jul 2011 09:24:04 -0400

Behnam,

I'm sorry I was not clear.   Let me try again, first by
reference to Patrik's comment: independent of how ICANN has
formulated the variant investigation, the question remains "what
is safe across all scripts" and not "what does a particular
language need".  The ASCII ("English") examples were not
intended to justify the situation, only to point out that
restrictions have been with us for a very long time and that one
of those restrictions is that a string being a valid word in
some language does not create an entitlement to use that string
as a DNS label... and never has.  In retrospect, the terms
"domain name system", and the earlier "hostname" are misleading.
Precision would have called for substituting something like
"mneumonic" for "name".

Second, while your detailed explanation is appreciated, we fully
understand the importance of ZWNJ to writing Persian (and most
non-Arabic language use of Arabic script) and, although the use
is a little different, the importance of ZWNJ and ZWJ in writing
most Indic scripts.  CONTEXTJ was not included in IDNA2008 by
some magical accident: we (including both Patrik and myself)
fought to include it in the standard precisely to facilitate
those uses.

But, examples, explanations, and language requirements aside,
the issue remains one of whether those characters are safe in
the root.  With the understanding that this is just my opinion,
part of that safety evaluation is that the root zone almost
certainly should have a clear and simple set of rules, rules
that are easily checked and enforced by the various types of
(language-independent) software that call on the DNS.  While one
could imagine a large collection of rules based on a model of
"determine the script, guess at the language, and then interpret
and render accordingly", it is almost certainly not feasible
even if ICANN agrees to use self-discipline about single-script
labels.  First, the DNS and IDNA do not support explicit
language information and heuristics to determine language that
work well with moderate or large blocks of text are not reliable
when strings are only a few characters long.  Second, and
equally important, we know that complex procedures based on
layers of tables are rarely implemented correctly.

So, again returning to one of the implications of Patrik's note:
please assume that we understand the importance of this
character to most of the languages that use Arabic script (and
to most of the languages that use several of the Indic scripts)
and that, in case knowing this is helpful, we understood it long
before ICANN created the VIP program.  We also understand its
importance regardless of how (or whether) "variants" (whatever
that means in the general case) are supported.  The question is
whether the use of characters that, among other things, become
invisible if the wrong rendering engine is chosen, is safe in a
root context or can be made safe by a plausible, understandable,
and, if appropriate, enforceable set of rules.

regards,
   john

--On Monday, July 18, 2011 21:01 -0400 Behnam Esfahbod
<[email-masked]> wrote:

> Hi John,
> 
> I think it is time to stop general pronouncements that have
> been repeated and repeated so many times over these past years
> and get down to specifics.  Here are two very concrete points
> you should note:
> 
> 1. ZWNJ is not a special quirk of Persian language, it is not
> a mnemonic tool,    nor is it an optional writing-style
> device.  ZWNJ is used in the writing of    MOST languages
>...

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jul 2011 07:55:44 -0700

> So the burden of convincing the community is on the ones that do think a character like ZWNJ is to be allowed or not that the need for the character is greater than the potential harm in _any_ cont…

I am going to push back here, hard. The draft is about names used in exactly one zone, and that zone has exactly one administrator. Your statement about "_any_ context" is inappropriate for this draft.

As a zone administrator considers what it can safely put in its zone, it follows policies. Most zone administrators in the world have no policies whatsoever, and thus the IETF should make it less likely that they will do something dangerous. However, that is not a concern for this zone administrator. They have policies up the wazoo and literally hundreds (probably thousands) of people helping make those policies and being sure they are implemented.

So, for this draft, restrictions that are being made because that one administrator might make an unnoticed mistake are harmful. It is fine to give advice about security and stability; in fact, Patrik is already doing this in his role on SSAC. This draft, however, is exactly the wrong place to make statements that apply to any zone other than the one in the title.

Bullet points 2 and 3 in section 4 should be removed.

--Paul Hoffman

---

From: John C Klensin <[email-masked]>
Date: Tue, 19 Jul 2011 13:53:44 -0400

--On Tuesday, July 19, 2011 07:55 -0700 Paul Hoffman
<[email-masked]> wrote:

>...
>>> 2. If ZWNJ is claimed to cause confusion and phishing
>>> problems beyond what is normally acceptable for other
>>>  symbols, it is up to the claimants to demonstrate this
>>>  claim.
>> 
>> Actually, no.
>...

> I am going to push back here, hard. The draft is about names
> used in exactly one zone, and that zone has exactly one
> administrator. Your statement about "_any_ context" is
> inappropriate for this draft.

That zone is also the root.   While asking narrow questions
about the "can you put something in and get it back out"
performance of the DNS produces a different answer, any
considerations of actually being able to use the DNS to navigate
the Internet do make the root particularly important and
different.  In particular, while one can imagine blacklisting an
entire TLD because of bad policies or bad behavior, the only way
to do that to the root is to find, organize, or configure an
alternate root.

> As a zone administrator considers what it can safely put in
> its zone, it follows policies. Most zone administrators in the
> world have no policies whatsoever, and thus the IETF should
> make it less likely that they will do something dangerous.
> However, that is not a concern for this zone administrator.
> They have policies up the wazoo and literally hundreds
> (probably thousands) of people helping make those policies and
> being sure they are implemented.

Hmm.  I don't know if you have been following the activities of
that particular zone administrator, but, its policies are
rarely, if ever, enforced.  In particular, top-level domains
(root entries) that have been created with restrictions on use
who have then decided to eliminate those restrictions have, as
far as I know without exception, been permitted to make those
changes.   The problem is especially severe with any TLD that
can claim linkage to a government because claims are made of
national sovereignty and the impossibility of applying or
enforcing any policy the zone administration doesn't like.

> So, for this draft, restrictions that are being made because
> that one administrator might make an unnoticed mistake are
> harmful. It is fine to give advice about security and
> stability; in fact, Patrik is already doing this in his role
> on SSAC. This draft, however, is exactly the wrong place to
> make statements that apply to any zone other than the one in
> the title.

Just to keep this in context, note that these restrictions are
not new or unique to the current zone adminstrator.  They are
relaxations of restrictions that go back well over 20 years.

     john

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 19 Jul 2011 19:26:48 +0200

> I am going to push back here, hard. The draft is about names used in exactly one zone, and that zone has exactly one administrator. Your statement about "_any_ context" is inappropriate for this dr…

We just misunderstand each other.

Yes, this is about only this zone, so what I meant with "_any_ context" was still "within this single, very special zone".

So not really "_any_".

But, as John wrote, together with any character, regardless of language, etc...that was what I intended to mean by "_any_ context".

Still in THIS zone, the root zone.

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jul 2011 12:46:35 -0700

On Jul 19, 2011, at 10:53 AM, John C Klensin wrote:

> different.  

True, and completely irrelevant to *this* discussion.  We are discussing restricting some characters from an encoded form. How does that affect "actually being able to use the DNS"?

> In particular, while one can imagine blacklisting an

And, as you say below, you truly don't like the way ICANN makes and enforces policies. The rest of live with them, usually with less complaining.

> rarely, if ever, enforced.  

Stating a policy and not enforcing it is making another policy. Again, it is irrelevant to this discussion.

> In particular, top-level domains

That can't be your whole list of things that have nothing to do with this draft that you dislike about ICANN. Please go on. :-(

> relaxations of restrictions that go back well over 20 years.

Hogwash. Those restrictions have *never* been part of the DNS protocol. Nothing in those two restrictions affect the DNS at all, only the way that some people interpret some DNS strings in applications. The design of both IDNA2003 and IDNA2008 insulate the DNS from this.

To be more blunt, the restrictions in this draft imply that the protocol of which you are co-author sucks badly: you either left out of the protocol "these characters are unsafe" or you left out "there are special rules that apply to the root zone".

I don't believe either is true. The protocol we all worked on is just fine. You, and we, didn't leave anything out. Trying to jam this into the DNS after the fact is just wrong. It's fine if ICANN wants to make its own policy on this; it is wrong for the IETF to pretend that this is our policy that we forgot to put in IDNA2008.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jul 2011 12:49:15 -0700

> Yes, this is about only this zone, so what I meant with "_any_ context" was still "within this single, very special zone".

Ah, good.

> Still in THIS zone, the root zone.

We have already seen the perceived need for these characters in the root zone, and we have not seen any statement of how they can cause harm *in the root zone*. "Phishing" in the root zone, given the horrendous weight of the process for getting new names put in the root zone, is not a threat. Which others do you believe that need to be weighed against the value of the characters?

--Paul Hoffman

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 20 Jul 2011 08:34:04 +0200

> We have already seen the perceived need for these characters in the root zone, and we have not seen any statement of how they can cause harm *in the root zone*. "Phishing" in the root zone, given t…

Yes, phishing in the root zone. People putting URLs on web pages that you click on.

It is tons of code easier in various applications to "know" that a code point is either allowed or not allowed in the TLD than having context dependent rules that otherwise is the option.

So the question is whether security software can filter out URLs with ZWNJ in the TLD as dangerous or not.

   Patrik

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 20 Jul 2011 16:40:56 +0900

> So the question is whether security software can filter out URLs with ZWNJ in the TLD as dangerous or not.

I'm with Paul on this here. The root zone is really special. Look at .py 
(Paraguay) vs. .ру (Cyrillic, .ru when transliterated to Latin, probably 
the first candidate everybody was thinking about for Russia) and .рф 
(Cyrillic again, .rf when transliterated, standing for 'Russian 
Federation').

Phishing wasn't avoided by any specific rule except "check 
manually/visually if there's a potential for confusion, and if there is, 
try something else".

Labels in a TLD postition that contain a ZWNJ are either existing in the 
root zone, or they are not. If they are not actually existing in the 
root zone, then there is no danger of phishing. If they are actually 
existing, then they either have been checked using the rule in the 
previous paragraph, or they haven't been checked. If they have been 
checked, then they can't be used for phishing (*). If they haven't been 
checked, then there's a potential for phishing, but that's because due 
diligence was neglected, completely independent of ZWNJ.

The draft in question basically says: "We had this implicit rule that 
TLDs don't contain digits or hyphens. For IDNs, we need to relax it on 
the A-Label level, but introduce it on the U-Label level." It then goes 
and translates that into "general category { Ll, Lo, Lm, Mn }". This 
essentially means that virtually nobody in the IETF or ICANN (and very 
few people on the Unicode side) can understand that, or can judge the 
consequences. Also, while I don't think there is any need whatsoever to 
have TLDs with digits in them, I don't really see any technical need to 
prohibit those (except for all-digit TLDs, which would be a really bad 
idea).

Regards,   Martin.

(*) There's also the case that people confuse totally different things 
by accident and get phished that way. An example would be somebody 
spamming www.aoyama.ac.jp with www.aoyama.ac.ja (jp vs. ja). But this 
kind of stuff is already possible now, and excluding ZWNJ doesn't make 
it better.

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jul 2011 08:18:57 -0400

Paul,

I think we are going to need to agree to disagree about several
aspects of this, including especially your apparent impression
of my attitude toward ICANN and the degree to which you
apparently believe that is driving my conclusions.  While I find
many aspects of how ICANN does business extremely frustrating, I
simply do not believe your characterization of my attitude is
correct.

However, one of your comments may deserve some calibration...

--On Tuesday, July 19, 2011 12:49 -0700 Paul Hoffman
<[email-masked]> wrote:

>...
> "Phishing" in the root
> zone, given the horrendous weight of the process for getting
> new names put in the root zone, is not a threat. Which others
> do you believe that need to be weighed against the value of
> the characters?

ICANN has agreed to change the process for getting new names put
in the root zone.  The new (and approved) model for obtaining a
TLD as of next year is essentially "pay your application fee
and, unless a very narrow range of objections occurs, you get
the name".  All, or substantially all, of the requirements for
staff or third-party review that carried, in your words,
"horrendous weight", have been eliminated.  The proposed
application fee (USD 180000) is high enough to discourage some
types of applicants, but that does not make the process
"horrendous" -- one can either decide the TLD is important
enough pay it or not.

    john

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Jul 2011 07:07:34 -0700

> Yes, phishing in the root zone. People putting URLs on web pages that you click on.

This is an argument about disallowing labels with non-PVALID at any level, not just in the root. Prohibiting non-PVALID in the root will do nothing to prevent those attacks; an attacker just puts the phishing label in a different part of the domain name.

> It is tons of code easier in various applications to "know" that a code point is either allowed or not allowed in the TLD than having context dependent rules that otherwise is the option.

Such a rule just begs for various applications to "know" that non-PVALID codepoints are illegal anywhere. This was discussed in the INDAbis WG, and the WG decided that the root zone was not special.

> So the question is whether security software can filter out URLs with ZWNJ in the TLD as dangerous or not.

This truly sounds like a re-assessment of non-PVALID in IDNA2008. I'm willing to have that discussion if you are, but trying to say that it somehow applies only to the root seems misguided.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Jul 2011 07:16:08 -0700

> "horrendous" -- one can either decide the TLD is important

How does buying a domain name for a large amount of money, using a stable corporate address, and doing the hosting using well-known servers constitute phishing? The argument you give here suggests that draft-liman-tld-names should add a new prohibition on TLDs that could be considered confusing; I hope you don't mean that.

--Paul Hoffman

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jul 2011 12:10:59 -0400

--On Wednesday, July 20, 2011 07:16 -0700 Paul Hoffman
<[email-masked]> wrote:

>> ICANN has agreed to change the process for getting new names
>> put in the root zone.  The new (and approved) model for
>> obtaining a TLD as of next year is essentially "pay your
>> application fee and, unless a very narrow range of objections
>> occurs, you get the name".  All, or substantially all, of the
>> requirements for staff or third-party review that carried, in
>> your words, "horrendous weight", have been eliminated.  The
>> proposed application fee (USD 180000) is high enough to
>> discourage some types of applicants, but that does not make
>> the process "horrendous" -- one can either decide the TLD is
>> important enough pay it or not.

> How does buying a domain name for a large amount of money,
> using a stable corporate address, and doing the hosting using
> well-known servers constitute phishing? The argument you give
> here suggests that draft-liman-tld-names should add a new
> prohibition on TLDs that could be considered confusing; I hope
> you don't mean that.

Paul, all I said, and all I meant, is that one cannot assume
that the process of obtaining a TLD involves the complex review
for appropriateness (of the name, the operator, or the planned
use) that was ICANN's norm in the first or second rounds of TLD
applications.  That is simply no longer the case: to a very
large extent, the new model is "pay your money, get your name,
do what you like with it".  My note deliberately did not comment
on whether I thought that was good or bad, much less about
whether it "consistute phishing" or anything else.

   john

---

From: Behnam Esfahbod <[email-masked]>
Date: Wed, 20 Jul 2011 13:41:29 -0400

Dear John,

I trust you understand the fact that Persian language and Arabic
script has already faced much more problems than other major scripts
(left-to-right ones) because of it's nature, being a bidirectional
script and it's contextual joining property.  I believe we have
sacrificed enough and there should be a good reason for further
limitations on these script and language.

We greatly appreciate the work that has been done by you all in
IDNA2008, but let's not forget that IDNA2003 *were broken* for many
languages and IDNA2008 was *fixing* it.  I think IDNA2003 was broken
because it was not challenged enough.  In fact, this is a very good
example to see that RFCs should not "simply" (or "blindly") ignoring
characters in each level of protocols and standards.

The other issue is that, in IDNA2003, at least there was the
possibility to have users write a word that included ZWNJ (like
[ARABIC BEH, ZWNJ, ARABIC ALEF]) as a label and ZWNJ was "removed"
before the label was resolved. Yes, the final label would not be the
same as the one entered, but users "could" use words with ZWNJ in URLs
or browsers' address-bar.

Now let me explain why I believe there is no "good reason" to not have
ZWNJ in the TLD labels:

1. We know that in many parts of the DNS technology, TLD labels are
"used" (evaluated, cached, etc) in A-label forms. I think we all agree
that there is no different between PVALID and CONTEXTJ characters in
A-label forms, thus there is no problem with ZWNJ in A-labels.

2. TLD labels are evaluated and delegated in both A-label and U-label
forms. We should note that we don't expect everybody responsible in
these processes (evaluation, deligation, root-zone management, etc) be
able to understand all the languages that will be used in Internet
TLDs ever, and that's why A-labels are very important in Root-Zone.

3. Now let's consider the cases that Arabic TLDs will be "used" in
U-label forms.

3.1. User's understanding of Arabic script:
3.1.1. If the user understands Arabic script, then there wouldn't be
any problem, as IDNA2008 rules for ZWNJ makes sure that ZWNJ is
"visible", thus user can "read" the label correctly.
3.1.2. If the user does not understand Arabic script, still the shape
of the letters would be different (thanks to IDNA2008's rules for
ZWNJ), thus the result would still be "visible".

3.2. Suitable font and rendering engine:
3.2.1. If there is no suitable font with Arabic support, or the
rendering engine does not support Arabic, user would have problems
with any Arabic IDN, no matter if it includes ZWNJ or not.
3.2.2. If there is a suitable font and the rendering engine
impolements the Arabic Contextual Joining algorithm, then there would
not be any problem with ZWNJ and it would be "visible" to user.

4. And finally, as I mentioned in the other thread (sharing with
VIP-Arabic team), there are much more possible security risks using
only PVALID Arabic characters.  So, why do you start with CONTEXTO
(ZWNJ and ZWJ) and stop right there?
4.1. If this RFC is required to make sure TLD labels are secure "all
the way", there is still a lot of work to be done and we should extend
it to cross-script issue, (like the case for .py) as well.
4.2. If we agree that it is not possible to take care of all the
security risks of the characters of all major scripts/languages in
some RFCs, why ZWNJ is different from the other characters?

I hope these make it clear that why there is no good reason to
"disallowed" CONTEXTO characters (specially ZWNJ) in TLD labels in
general, and security risks should be considered in a case-by-case
manner, like what would happen for many of PVALID characters (in
Arabic script, and most probably every other script).

Thanks all for the comments and supports,
-Behnam

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 21 Jul 2011 10:24:19 +0900

> some RFCs, why ZWNJ is different from the other characters?

I fully agree with Behnam here. Disallowing ZWNJ is just scratching the 
surface of the actual problem, but on the other hand is damaging in 
cases where it the character is needed. Pretending to solve a problem by 
finding a scapegoat is never a good solution.

Regards,   Martin.