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