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

Behnam Esfahbod <> Tue, 19 July 2011 01:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03EFE21F8754 for <>; Mon, 18 Jul 2011 18:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[AWL=1.368, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1kRa-X53MFmc for <>; Mon, 18 Jul 2011 18:02:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B16A921F874C for <>; Mon, 18 Jul 2011 18:02:36 -0700 (PDT)
Received: by iwn39 with SMTP id 39so3884830iwn.31 for <>; Mon, 18 Jul 2011 18:02:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=6O/rhKc2iI6wgDI/t8wXkTNYrGh+6K9xEvFk+r7stWc=; b=iNCDS7pbOVtZMiOAI9yjJ/U67g4hlpcWML5FR+WOay2XBvdH2DaU6sXi+ZAOBSbfBA zBJ8XIzkQoyfL7NYorSjDFhZKHLxXh+KrDRcXP5se76582h9yGfmIokUcUNcortLYtXF s6xTXQfkyLXcwq8EFwCFGJv0TqUpho0+qGKks=
Received: by with SMTP id l7mr6092294ibs.150.1311037356269; Mon, 18 Jul 2011 18:02:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 18 Jul 2011 18:01:56 -0700 (PDT)
In-Reply-To: <B464B2C6607E04FD0572AA74@>
References: <B464B2C6607E04FD0572AA74@>
From: Behnam Esfahbod <>
Date: Mon, 18 Jul 2011 21:01:56 -0400
X-Google-Sender-Auth: J2kTH1pj3VcYfGkdWAWAWmiIjb8
Message-ID: <>
To: John C Klensin <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss <>
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Jul 2011 01:02:42 -0000

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.


On Mon, Jul 4, 2011 at 8:17 AM, John C Klensin <> wrote:
> --On Thursday, June 30, 2011 16:56 -0400 Behnam Esfahbod
> <> 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
  *  ..
 *  `  *
  * o *   3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B