Re: [DNSOP] Some distinctions and a request

str4d <str4d@i2pmail.org> Wed, 01 July 2015 08:50 UTC

Return-Path: <str4d@i2pmail.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2450C1A1A52 for <dnsop@ietfa.amsl.com>; Wed, 1 Jul 2015 01:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.59
X-Spam-Level: *
X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek1koIad7pCt for <dnsop@ietfa.amsl.com>; Wed, 1 Jul 2015 01:50:23 -0700 (PDT)
Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DA01A1A4A for <dnsop@ietf.org>; Wed, 1 Jul 2015 01:50:22 -0700 (PDT)
Received: by mail01.sigterm.no (Postfix, from userid 1006) id 03F1D2E3426; Wed, 1 Jul 2015 10:50:20 +0200 (CEST)
Received: from smtp.postman.i2p (i2p-outproxy01.privacysolutions.no [193.150.121.66]) by mail01.sigterm.no (Postfix) with ESMTP id 683242E3427 for <dnsop@ietf.org>; Wed, 1 Jul 2015 10:50:18 +0200 (CEST)
X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: str4d <str4d@i2pmail.org>
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20150623160722.GA26267@mx2.yitter.info> <D1B17D4F.C773%edward.lewis@icann.org> <20150629174259.GE29767@mx2.yitter.info> <D1B7EDC5.C8A6%edward.lewis@icann.org> <20150630151951.49F9DAE448@smtp.postman.i2p>
In-Reply-To: <20150630151951.49F9DAE448@smtp.postman.i2p>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Message-Id: <20150701054744.6CF00AE444@smtp.postman.i2p>
Date: Wed, 01 Jul 2015 05:47:44 +0000
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/kXWQFb9BXJ976dqFs3hNI1XxNBE>
Subject: Re: [DNSOP] Some distinctions and a request
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2015 08:50:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Andrew Sullivan wrote:
> On Tue, Jun 30, 2015 at 11:43:42AM +0000, Edward Lewis wrote:
>> I'm not aware of "the rule" that declares Onion names as part of
>> the domain name space.  Not an argument, just a data point.  I've
>> always heard, and have been running on this, that Onion names are
>> not part of the DNS name space.
> 
> You're conflating "DNS name space" and "domain name space" again.
> I didn't say they're part of the DNS name space; and given what
> the top-level label onion. does, they can't possibly be.  At the 
> beginning, I claimed that the domain name space was all the
> logically possible domain names, not all the ones in fact possibly
> in the DNS. Under this definition, local. is part of the domain
> name space and not part of the DNS name space (because of local.
> being registered in the special use names registry).
> 
> When I asked about this before, one of the onion proponents told
> me that onion names have to conform to DNS (and, he claimed, LDH)
> rules right now, though that is a possibly temporary convention.

.onion and .i2p (and to my knowledge, the other proposed P2P-Names
TLDs too) have to conform to DNS rules in order to be usable in legacy
applications that expect domain names. In some future where the
percentage of apps requiring this is much lower (by most apps natively
supporting Tor/I2P/etc), the restriction could be removed. But while
domain names are the de-facto standard, I don't see it changing.

>> Alain Durrand and I talked about this a few weeks back.  He made
>> the point that you can distinguish the namespace of an identifier
>> "on the right" or "on the left" imaging the use of names in URLs.
>> I.e., there could be a "http-tor://tor-name.onion/path" and use
>> http-onion to tag this as a Tor identifier or
>> "http://tor-name.onion/path" and assume it's Tor because of the
>> onion where I'd expect(*) a domain name to be.
> 
> I think this is a terrible confusion of URI schemes vs. name-space 
> switches.  It's true that if you treat the URI as an unformatted 
> string you can parse it this way; but there are already rules for 
> that.  But I think anyway that's a distraction.  We don't need 
> uri-schemes to creep into this.

+1. Besides the confusion, this would require native app support,
because URI schemes are generally handled separately to name
resolution - you couldn't just use a SOCKS/HTTP/DNS proxy to handle
legacy applications, like Tor/I2P/GNUnet do now.

str4d

> 
> Best regards,
> 
> A
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVk371AAoJEBO17ljAn7PgmpgP/RXlwq9LVkKCkY8Ldk/QMo2z
zFc2P1E7mO2JmNrkt4d77l+mzWNz3Ne0LMRen5mnJMvl+LitsF62kM3DJ+J9P0EZ
9MFt+WkpkYa+Jz1pMvTaR18Z5uZg8MAJB/qui/0xpTx2FPg02aNWyeroS32nX5Lo
TCx4YgVxBdQYKjXzg9t57+5t+CgcNVu9/YBVuJfEj+Isu/GZHr4ElstVtVrv50zq
1U3UycHA9HWdTjKU1zE6f3IrZXIzNpQGDXwjdhYySpGK1nKwTVRBEJFDsz2JDtyc
fu8gVsMPvvmqDwDYOJCqxvB5Ko/bF2PehtdtGY82qJBdtE5w+/Rbtu5mdZeupcU3
Ps74fZk6zHEZzzbbJjvwDHHG4oE/AmhLRZp9fylhzabCCElGNZ8Uuc4Fz7ZuXFsn
ngg+9ANVl10JFv+RkKjKEbyyoUKDvd69d7TxAv11wR+OIhnchCFFRyU3YVlEuuK5
g5WMCQyhb010Wa5QasoQH2OAlhKQPsDtN2WbLoljqyptmIJ4TU2dej/EJSYSvX1M
kbkj005GFm0jv4rVRja7dgkmrErxH9tJq0HwcIsQPe+KaIHWmeR2BwTbxXiQtjBr
gb6bGc5EO1GakxARefvHSLjag/iFuOjJ8M6kU8IKb2gemzXpOPA4ocfF3GwajcXi
+uWyxB0slKYUiBUNxFzw
=67PO
-----END PGP SIGNATURE-----