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

Ted Hardie <ted.ietf@gmail.com> Thu, 04 February 2016 18:24 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: arcing@ietfa.amsl.com
Delivered-To: arcing@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90E1AC40D for <arcing@ietfa.amsl.com>; Thu, 4 Feb 2016 10:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 7nzy91JImRll for <arcing@ietfa.amsl.com>; Thu, 4 Feb 2016 10:24:21 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C89F1AC425 for <arcing@ietf.org>; Thu, 4 Feb 2016 10:24:21 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id o11so48523551qge.2 for <arcing@ietf.org>; Thu, 04 Feb 2016 10:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c59xc1xGyENoVDZzSaeTpzIVHpI1jH6qigKcmmbcX58=; b=DjmehepqJJm5ewmU/c/ccNck5X30CQRq9tMurCMXNNZB7Tfeft9MTgaJcDD2G1XOHr hcwbDuU7O8aZoNWSPwCVJXpai2BWV8P/vFCGjiN/Tx9obkuhfBw3hdTHeCCgsl1B4LcX iTJxQ/KFafbNEK5+jqJgbctLzVp5H3OCvNauIp1LW8XLx3wxMy6Uhbj2way2w/DOAoG7 kouu2wxTzNN9RpYrvon1t22MQl1Cvc4F199DCJAMroPKHmhws2OaPFfQXz7rep7TmrBm RHMeFzPuFFhE89KWqGoJoUuDAWJB9o79kOzRhFQY5JxMexPKpOb8Iu67tHqteTPWYqYH /Sfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=c59xc1xGyENoVDZzSaeTpzIVHpI1jH6qigKcmmbcX58=; b=mA5p+jA1MHyorQle448R7acOcBjNXX30XVq7lVp/SiZlucvPtBeBKy0Te5Ysy/sryn oo9wzdZDns7PpfehMUNuaoFxQ743f8LLTT4Kp+n1fn0mgjUeaSu4g108dWybn7sgfZYb HGMEvq7IS95NSsft4M/6qfddQVWgw2GRQwWDGwN3m4NLbJ9RF/v4xKsKuJDYN9S/KWPC brLEaDDP5UHxsDN8G1kcANoBgEdgkTcI9SqoHVHNHq+C1xbD07UqulYhCJ4qeC2nO2dL Rf67g6JzVYdFs2y5NkMZXlvDXFh3AvXOmHmGQ+4/YS6HRyqPoPfpk4beMS/6KMtZjsJW HJvA==
X-Gm-Message-State: AG10YOTB5PQZo78DJvOonsaNdFfml4iTkSoMasQ1ARZ00S6WqVGF8RM35CenT0ZHg8ci/CvHxIe/3lgzGAco6Q==
X-Received: by 10.140.163.6 with SMTP id j6mr11749871qhj.36.1454610260544; Thu, 04 Feb 2016 10:24:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.14.211 with HTTP; Thu, 4 Feb 2016 10:24:01 -0800 (PST)
In-Reply-To: <D22DCDE4-DB56-4BEB-BC09-47B1428E29EB@isoc.org>
References: <CA+9kkMDBPHYg3ENofdZ2jQxh=Wjv3KZXK+gw=5nYT0B=VL87Qg@mail.gmail.com> <D9D8AE6A-8B40-4DDA-B7FC-DC5C2D04997C@isoc.org> <D22DCDE4-DB56-4BEB-BC09-47B1428E29EB@isoc.org>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Thu, 4 Feb 2016 10:24:01 -0800
Message-ID: <CA+9kkMCBgsNRCd3UORM3xJWOc86Jy=fBPrLO34c=S+J-knGerg@mail.gmail.com>
To: Dan York <york@isoc.org>
Content-Type: multipart/alternative; boundary=001a1139d3fcddfb1d052af5d729
Archived-At: <http://mailarchive.ietf.org/arch/msg/arcing/LId-X_mqtesiAyfBLWsMBM-V49Q>
Cc: "arcing@ietf.org" <arcing@ietf.org>
Subject: Re: [Arcing] A bit more on the problem statement
X-BeenThere: arcing@ietf.org
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 <arcing.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/arcing>, <mailto:arcing-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/arcing/>
List-Post: <mailto:arcing@ietf.org>
List-Help: <mailto:arcing-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arcing>, <mailto:arcing-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 18:24:24 -0000

On Wed, Feb 3, 2016 at 6:07 PM, Dan York <york@isoc.org> wrote:

> Ted,
>
> 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 <ted.ietf@gmail.com> 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.
>
>
​I don't think there is any obvious way forward here; there are a lot of
trade-offs in adopting specific approaches or syntax.  The problem isn't
insoluble:  both URNs and Handles have multiple disjoint namespaces and a
way to disambiguate among them.  But getting the markers correct at this
point to allow new namespaces in existing, common protocol slots would
require a lot of analysis and 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).
>
> ​
So, I believe we could develop a common URL sysntax that permit a nested
URN/handle/other-identified-namespace, as you could stretch a point to
assert that those are reg​istered names and that any syntax that fell under
regname was fair game.  RFC 3986 says:

 This specification does not mandate a particular registered name
   lookup technology and therefore does not restrict the syntax of reg-
   name beyond what is necessary for interoperability.  Instead, it
   delegates the issue of registered name syntax conformance to the
   operating system of each application performing URI resolution, and
   that operating system decides what it will allow for the purpose of
   host identification.


But most approaches would upend every parser out there at the moment, which
is a big, hairy deal.  We'd have to be convinced that this was useful,
deployable, and the right choice before we did that, and, perhaps more
importantly, that the failures that would inevitably occur would be limited
to the new namespaces.

 ​

> 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?
>
>
​I think the nature of these names is that the ones that move from protocol
context to protocol context are the ones that present the real problem.  So
I'm not sure that the size of the ocean to be boiled can be restricted much
by limiting only to "successful, widely deployed protocols".  But I'm
certainly willing to listen if someone else has another way forward here.

regards,

Ted​




> Dan
>
> --
> Dan York
> Senior Content Strategist, Internet Society
> york@isoc.org   +1-802-735-1624
> Jabber: york@jabber.isoc.org
> Skype: danyork   http://twitter.com/danyork
>
> http://www.internetsociety.org/
>
>
>
>
>