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

Olafur Gudmundsson <ogud@ogud.com> Fri, 14 February 2014 21:54 UTC

Return-Path: <ogud@ogud.com>
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 EDDDB1A03C8 for <dnsop@ietfa.amsl.com>; Fri, 14 Feb 2014 13:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ucl1TdpqiF7t for <dnsop@ietfa.amsl.com>; Fri, 14 Feb 2014 13:54:31 -0800 (PST)
Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) by ietfa.amsl.com (Postfix) with ESMTP id D1D801A0455 for <dnsop@ietf.org>; Fri, 14 Feb 2014 13:54:25 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 379001B8135; Fri, 14 Feb 2014 16:54:24 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id CBBD41B8099; Fri, 14 Feb 2014 16:54:22 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_844867F8-09CE-4D53-A626-EDC7213F1023"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <CAHw9_iKEuOf+AZpDfB0EUsU9uVvGcAXJVs6DDTD1XsjkOp+_MQ@mail.gmail.com>
Date: Fri, 14 Feb 2014 16:54:22 -0500
Message-Id: <163BA378-C0DF-4067-938E-81ED4E0FC087@ogud.com>
References: <20140210205838.15973.63281.idtracker@ietfa.amsl.com> <E63B37B9-EFA0-43A5-9AC5-81CEC23C342C@viagenie.ca> <00BDA580-984F-41D1-8659-04278737A526@hopcount.ca> <20140213145932.GE25409@mx1.yitter.info> <BA548E83-4D14-4A08-A958-190F541D2337@viagenie.ca> <52FCE993.3070005@frobbit.se> <D38F596A-9DC3-49A1-A4D7-FF86F3AC1FBD@ogud.com> <52FD57D7.30004@frobbit.se> <CAHw9_iKEuOf+AZpDfB0EUsU9uVvGcAXJVs6DDTD1XsjkOp+_MQ@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/aDy2eCZH2D36LfNOk1SB_bX900g
Cc: Marc Blanchet <marc.blanchet@viagenie.ca>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt
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: <http://www.ietf.org/mail-archive/web/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: Fri, 14 Feb 2014 21:54:35 -0000


I posted my draft on this this topic, 
I do not think it is a DNS topic thus I put the appsawg in my draft name: 

A new version of I-D, draft-ogud-appsawg-multiple-namespaces-00.txt
has been successfully submitted by Olafur Gudmundsson and posted to the
IETF repository.

Name:		draft-ogud-appsawg-multiple-namespaces
Revision:	00
Title:		Providing support for multiple namespaces to Internet protocols.
Document date:	2014-02-14
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-ogud-appsawg-multiple-namespaces-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ogud-appsawg-multiple-namespaces/
Htmlized:       http://tools.ietf.org/html/draft-ogud-appsawg-multiple-namespaces-00


Abstract:
  Over the years there have been various proposals as to use namespaces
  other than the DNS/IN namespace that is under ICANN administration.
  Some of these were simple DNS competitors others use different lookup
  technologies.  In addition it is hard to supply different character
  encodings to DNS as each application needs to provide the translation
  between the encoding used and the format expected by DNS.

  This draft proposes a new service layer to provide multiplexing of
  different namespaces into appropriate function calls.

Olafur


On Feb 13, 2014, at 8:22 PM, Warren Kumari <warren@kumari.net>; wrote:

> [ Replying to a bunch of comments in one mail (not just Patrik's). I'm
> stuck in the storm in ATL (
> http://www.cnn.com/2014/02/13/us/winter-weather/ ), 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
> standard.
> 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.
> W
> 
> 
> On Thu, Feb 13, 2014 at 6:40 PM, Patrik Fältström <paf@frobbit.se>; wrote:
>> On 2014-02-13 11:19, Olafur Gudmundsson wrote:
>>> 
>>> On Feb 13, 2014, at 10:49 AM, Patrik Fältström <paf@frobbit.se>; 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
>>>      DNS##www.example.com    This is normal DNS name,
>>>      GNU##eff
>>>      DUTF8##..... (DNS name in UTF8 format)
>>>      www.example.net    (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
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop