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

[Patrik Fältström <[e-mail]>]

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