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

[Warren Kumari <[e-mail]>]

[ 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 <[e-mail]> wrote:
> On 2014-02-13 11:19, Olafur Gudmundsson wrote:
>>
>> On Feb 13, 2014, at 10:49 AM, Patrik Fältström <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop