Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt

Warren Kumari <> Fri, 14 February 2014 01:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B5F51A0045 for <>; Thu, 13 Feb 2014 17:22:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uF6bvvio0ugW for <>; Thu, 13 Feb 2014 17:22:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 961E81A006A for <>; Thu, 13 Feb 2014 17:22:07 -0800 (PST)
Received: by with SMTP id e4so9440679wiv.10 for <>; Thu, 13 Feb 2014 17:22:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1pVRkwJOt3hsbYLZ4KaaSf8ZFguqrXLpcG99diei1dg=; b=nGC+q38BG6alA2ivODc5oeAYk08wn2BzKhcH3CmB94424h4xrTs+CRiiC6UHTmLlgd pQCUnTPevdj2XkPfCJ2pPt+JDjjl4hzbzUxpCRqHlufrmjFlrpKdeDErG/nDxlrgM66N jO9HkG1BO0mMMMeD6wCv76EtouDmWu4+7Vv4yDx1Ngzz7+13/Lvcx0T49wJ/oY8Vvbo1 6PbEo39Qmg9c1Vy9DSV4Ae22DMZ4TbM3cgSYcAaBnk2ia9vCZ6N5myhPyy6DQ1Z/geyf hpirN4tA/I7DNxTTxB9RRSRQr8QRjSR3rQyC5KMYTyw5XfBcyggjfrwMpkpN1RTTGVv7 eq6w==
X-Gm-Message-State: ALoCoQmsxLqCN046K5oPlDV1iPmr2hEa/7wHyEBmQITLJCjTNP/cI9DqTozVl60G1J4eEFmEsTGK
MIME-Version: 1.0
X-Received: by with SMTP id hh9mr42213wjb.89.1392340925627; Thu, 13 Feb 2014 17:22:05 -0800 (PST)
Received: by with HTTP; Thu, 13 Feb 2014 17:22:05 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Thu, 13 Feb 2014 20:22:05 -0500
Message-ID: <>
From: Warren Kumari <>
To: Patrik Fältström <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Marc Blanchet <>, dnsop <>
Subject: Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2014 01:22:10 -0000

[ Replying to a bunch of comments in one mail (not just Patrik's). I'm
stuck in the storm in ATL ( ), and so am behind
on mail, etc. ]

Just so folk know, Olafur and I chatted about this before he submitted
his draft. I think that we are in agreement that the two drafts are
complementary, not conflicting.
Using a URI / Prefix / <something> to indicate another namespace (to
me at least) seems like an elegant, clean, sane, "better" solution --
unfortunately it seems that making pseudo-TLDs has suddenly become
popular, and so I think that reserving .ALT is an important *tactical*
solution. It creates a safe area for people who want to do this sort
of thing to do so, and lets the IETF push back on people trying to
reserve .foo in the future. I think we should work on Olafur's
proposal in parallel.

On Stephane's terminology comments...
Yes, the terminology section sucks -- unfortunately it was the best I
could come up with.
I'm really bad at terminology thingie whatzits. Andrew made it better,
but it is still bad. Much of the problem is that we are talking about
somewhat squishy things -- people using names in places where you
would usually put a "DNS name" (whatever that means).
1:  'the DNS "standard" of a series of labels separated with dots' --
An earlier version of the doc had some long and contrived text about
"names that are comprised of short strings (<=63) of LDH characters,
separated by dots" until Andrew hit me with a stick and reminded me
about 1: IDNs and 2: DNS being 8bit clean. I'd put the word "standard"
in quotes to try and make it clear that this isn't really the DNS
2: 'DNS context: The namespace administered by ICANN.'  -- Yup, it's
not clear / correct. But I couldn't figure out how to make it better.
It's not really the 'DNS protocol', because some of these solutions
use the DNS protocol, and then intercept it. What I was aiming for was
something like "The thingie that most people would think of if you
asked them to go resolve a name".
Suggestions / text more than welcome!

On the "should e.g .onion move under this?" discussion...
Personally I think that the Right Thing(tm) would be for .onion / .bit
/ etc to move under .alt -- unfortunately they are already deployed in
the wild, and there is running code, etc. If I had a wand I'd wave it,
magic would happen, everyone would have a pony and .onion would
suddenly be under .alt. Unfortunately I think that the reality is
that, whether or not the IETF approves the grothoff names, they will
continue to be used. I'd rather that that is documented. The .ALT
proposal is largely a solution so that we don't end up in the same
place in the future.  Olafur's namespace prefix solution is *better*,
but is (IMO) much more of a long term solution.

On the "Should there be an IANA registry?" bit.
I have no idea. I'm very conflicted on this. There are definite
advantages and disadvantages to both.
I want it to be easy for someone to start using a name here, so that
they have no excuse not to, but I'm also concerned about the chaos /
anarchy. An option (but an ugly one!) would be that we reserve
something like unmanaged.alt (or u.alt or swamp.alt, or...) as
unmanaged space within the ALT TLD. Other SLD would require expert
review or something.

Well, I'm off to go see if I can find any food -- when I went for
lunch earlier in the day the restaurant had already run out of
french-fries, tomatoes and a number of beers...
Wish me luck.

On Thu, Feb 13, 2014 at 6:40 PM, Patrik Fältström <> wrote:
> On 2014-02-13 11:19, Olafur Gudmundsson wrote:
>> On Feb 13, 2014, at 10:49 AM, Patrik Fältström <> wrote:
>>> On 2014-02-13 10:23, Marc Blanchet wrote:
>>>> - why not just register a URN namespace and use it as they see fit?
>>> Because you only type in a string that "looks like a domain name" in
>>> applications (for example browsers) without the URI scheme nowadays, and
>>> people want that to work also with strings in other namespaces.
>>> I.e. it all, from my perspective, have to do with where the signalling
>>> is on what namespace to use. And if that signalling is inline, then we
>>> do have something that can be viewed as the equivalent of a namespace
>>> collision.
>>> If people had entered the URI scheme all the time, including "http",
>>> then we would have been in a different situation.
>> I think that the draft is not radical enough it is trying to provide some belt and suspenders to a
>> syntom rather than address the actual problem.
>> The Meta problem is Multiple Namespaces with different resolution technologies.
>> Addressing this via a SUFFIX in the domain name feels wrong,
>> What I will propose is a Namespace layer solution that is a prefix to the name presented,
>> thus names will be presented to the namespace layer as <namespace/name-encoding><space separator><name>
>> Examples using ## as the separator
>>    This is normal DNS name,
>>       GNU##eff
>>       DUTF8##..... (DNS name in UTF8 format)
>>    (by default the name is DNS)
>> With a namespace layer we can have the host reject lookup locally if it does not know how to handle the namespace,
>> rather than dump it out as ".alt" query.
>> I know this requires changes in lookup services and code, but it moves the effort to the people that want new namespaces.
>>       Olafur
>> PS: IANA should maintain a registry of namespaces
> This is to me approximately like the URI scheme idea, but a different
> syntax. Can fly, might not fly.
> The whole question is what the application developers and marketing
> people will print on bulletin boards and accept in input fields in
> applications (and their configurations).
> Which unfortunately means we do not know until some time after we have
> tried to standardize it... :-P
>    Patrik
> _______________________________________________
> DNSOP mailing list