Re: [Arcing] A bit more on the problem statement

Dan York <> Thu, 04 February 2016 02:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B687E1B3854 for <>; Wed, 3 Feb 2016 18:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kmLAb7_4qSY3 for <>; Wed, 3 Feb 2016 18:08:23 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::1:605]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDEF11B380A for <>; Wed, 3 Feb 2016 18:08:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uqnJtxcyMJGZSttbqTyx5MWf6HpdG2oWfkucPt+U/5k=; b=1BYYc5sjmmOgP44MK8+m8udK+URFW2Yc+sVIcE8CLX41zmHd3dFZ7u6x4rGmefI1k8f2AnzvUezUpPO3rdY/R8lvhctHl7ox4vcNPU0YNFO3KUszgTFH0UVovih5qaVkMGuPXWNgqIoG/SRoZzzBbLUv1T/NXi2+QLzFRBNmdWk=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.396.15; Thu, 4 Feb 2016 02:07:59 +0000
Received: from ([]) by ([]) with mapi id 15.01.0396.020; Thu, 4 Feb 2016 02:07:59 +0000
From: Dan York <>
To: Ted Hardie <>
Thread-Topic: [Arcing] A bit more on the problem statement
Thread-Index: AQHRXrSc5VAnQ03hhUeE6omrlyIJ0w==
Date: Thu, 4 Feb 2016 02:07:58 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1659; 5:EpXfrY9EBTvAIIrAunc5kqv2tkq2GTo2tLbVVyrFkzI+mtNLi1VySgSt8QKUtMBQW76KGr8dzQ/QIjydpsBo/p9unqKkJmXyveUQWN78AKZrENO5MBOkLbiMPtt+0nsceZxGjAiBaBlnUZkl4h5Diw==; 24:4BhLfOh8P2qbGMC40TPN37gdSEArPbTPjnUyAk+yUAO/ZdxkOcrdN7vLv57gAs6zZybbKhlAofmtbtq/Nr84bCFZUpxu+cVqjKPZmWeplsU=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1659;
x-ms-office365-filtering-correlation-id: 5b0a3245-7ac6-4fe7-e45a-08d32d08010e
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0601MB1659; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1659;
x-forefront-prvs: 084285FC5C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(1096002)(1220700001)(102836003)(2906002)(92566002)(586003)(50986999)(76176999)(36756003)(83716003)(5008740100001)(6116002)(189998001)(19617315012)(3846002)(5004730100002)(54356999)(77096005)(15975445007)(4326007)(87936001)(10400500002)(2950100001)(66066001)(19580395003)(19580405001)(5001960100002)(82746002)(106116001)(99286002)(11100500001)(2900100001)(3660700001)(5002640100001)(3280700002)(33656002)(122556002)(15395725005)(40100003)(86362001)(16236675004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1659;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D22DCDE4DB564BEBBC0947B1428E29EBisocorg_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2016 02:07:58.6050 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1659
Archived-At: <>
Cc: "" <>
Subject: Re: [Arcing] A bit more on the problem statement
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Feb 2016 02:08:25 -0000


Hmmm... I wrote the message as a draft and then went looking to finish it up... and seem to have sent it!  Sorry for filling your inboxes with an incomplete message!  Picking up where I left off...

On Feb 3, 2016, at 1:56 PM, Ted Hardie <<>> wrote:

If we shift to an explicit set of markers, we get the following advantages:  we can use syntax different from the syntax of the DNS; we can avoid collision at the level of the tuple of namespace, name; we can avoid conflating resolution context and namespace.

Can you give a more

Can you give an example of what you are thinking about with regard to an "explicit set of markers"?

I ask because...

The disadvantage is that every protocol that works across namespaces must now be updated to recognize both the explicit markers and the namespaces themselves.  That's a lot of work and, as IPv6 taught us, the network effects run against you the whole way.  It may, however, be something that is significantly easier to deploy incrementally than the core IP layer is.

... I think deployment of any solutions may be a huge issue, but I'm not clear about what you are thinking about as a solution.  I'm guessing you have *some* idea of how you might like to see it work.

If we think of different kinds of namespace identifiers, we have the example of the URI/URL/URN kind of notation with a protocol first.  And certainly in the earlier days of the Internet that was one mechanism we've had.  And yes, it still works today... BUT... today we're seeing so much of Internet traffic going over HTTP(S) ... and devices and applications *assuming* traffic will be going over HTTP(S)... that we can't rely as much on the protocol portion of the URI.  Thus in a world of HTTP/HTTPS it's not surprising that people are overloading existing systems (TLDs) to identify different namespaces (ex. .onion).

Another examples that occurs to me is the separate namespaces used in XML with the xmlns attribute and appropriate prefixes before elements.  But that's obviously within an XML *document* versus a network protocol.

And, most importantly, which level of the problem do we think we can solve:  the multiple namespaces one or the unitary namespace/multiple resolution contexts one?

I guess a more basic question is - are you suggesting we try to solve this problem for ALL protocols?  for just a select set of protocols (HTTP, HTTPS?)?  Or something else?


Dan York
Senior Content Strategist, Internet Society<>   +1-802-735-1624
Skype: danyork