Re: [dnsext] the same in old days, was making names the same NEED protocol changes?

[Doug Barton <[e-mail]>]

On 02/28/2011 09:38, Ted Hardie wrote:
> On Mon, Feb 28, 2011 at 7:07 AM, Phillip Hallam-Baker<[e-mail]>  wrote:
> <snip>
>
>> So attempting to make two names resolve alike without change at either
>> the application client or the application server is a fools errand.
>
> I'm not sure how you see this split based on the text above.  My
> personal take is that if you want two names be "treated the same" by
> an application, you can do one of three things:
>
> 1) Make one name refer to the other, transforming the problem of
> "treating the same" into "pointing to the canonical name".

I'm using some elements of this concept in my idea for CLONE. However 
the solution I'm going to propose is limited to the DNS layer.

> 2) Provide for all the names equally, so that the same resources are
> available at each name (this means not just things like
> name-to-address mappings but also certificates with the names used on
> them etc.).  This is expensive and difficult, but there may be some
> methods to reduce the pain (subjectAltName, provisioning-based
> mirroring of resources, new protocol methods).  I think a lot of the
> discussion so far has been of the "are there useful DNS mechanisms
> that could reduce this pain"?

Yes. I've been trying to get across the idea that _on the registrant 
side_ this problem is really no different than what registrants already 
deal with, both with the existing "IDN variants" problem and with the 
pre-existing problem of "aliasing" multiple spellings/TLDs, etc. for 
"the same" name. In that sense the color/colour problem is (IMO) the 
same problem space.

> 3) Create a method that allows applications to know which names should
> be treated as equivalent.  The difficulty here is primarily that any
> names which are not within the same administrative boundary cannot be
> treated as equivalent without the records related to both/N
> administrative boundaries confirming the equivalence. So the
> application would have to understand how to determine the
> administrative boundaries, check for the confirmation of equivalence,
> and then correctly apply whatever behaviors result from the two names
> being the same.  This is far from trivial, as the
> applications/protocols may have no defined behavior for "treat these
> as the same".  Knowing they are to be treated as equivalent doesn't
> help a lot for applications with no sense of what behavior should
> result.
>
>
>> is not going to work because that is simply not how the applications
>> see the world.
>>
>> <snip>
>>
>> If we decide we can change the application client, this whole problem
>> becomes pretty straightforward. Either adopt the 'did you mean'
>> pointer style approach or allow domains to nominate mappings of one
>> charset to another.
>>
> Please do not use "mappings of one charset to another" to represent
> this problem.   At this point, we are all mostly talking about the
> Unicode character set and how to map labels derived from sequences of
> Unicode characters.

Just to be clear, I'm not. I think the requirements document should 
describe the whole problem space, and then we can decide what problems 
we can provide DNS solutions for.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext