Re: [dnsext] BOF on variants for ICANN San Francisco

[Doug Barton <[e-mail]>]

On 03/09/2011 12:16, Andrew Sullivan wrote:
> No hat.
>
> On Wed, Mar 09, 2011 at 11:36:56AM -0800, Doug Barton wrote:
>
>> Further, the term "variant" has a relatively well understood meaning in
>> the TLD policy context, where it is generally understood to be a
>> simplification of several thorny technical problems.
>
> I suspect I disagree with the above claim.  Specifically, I think I
> disagree with "well understood".

Specifically, please read what you quoted above again. :)  I stand by 
that statement.

> In my experience, terms that have inherently ambiguous meaning are
> almost never well understood.  It is of course possible to understand
> ambiguity -- we wouldn't the word if we couldn't -- but in a wide
> array of cases, I think ambiguous terms are badly understood by their
> users.

I think that a lot of the ambiguity in _this group_ about the term 
"variants" derives from attempting to define it with a sort of technical 
rigorousness that people in ICANN do not use (or in many cases, desire). 
That said, I studiously avoided use of the word "variant" in my CLONE 
draft because I know that it causes confusion here.

OTOH, if you were to sit down with people from the ICANN sphere, 
particularly those who are familiar with IDNs in the TLD context, you'd 
get a very consistent definition of the term "variant," whether you felt 
it was sufficiently technically precise or not. Thus my statement above.

> I also believe that part of the reason we are struggling with the
> aliasing discussion is exactly that very careful needs assessment is
> extremely hard.  It is made all the harder by the unfortunate re-use
> of the term "Variant", which has a well-defined meaning in the context
> of "Character Variant Table" from RFC 3743.  Attempting to simplify
> such thorny technical problems by lumping them all together under one
> term seems like a good idea, but it turns out not to be.

And I have argued in the past that while I'm fully supportive of 
defining requirements as rigorously as possible I think we may need to 
accept definitions of both "rigorous" and "possible" that may be "less" 
than what we're used to. OTOH I think that my experience dealing with 
the ICANN crowd gives me a pretty good understanding of the problems 
they are trying to solve, and I've already said that I think the new 
aliasing draft captures them pretty well.

> It is often useful to bundle together a bunch of topics and call them
> by a more generic name.  (Patents and copyrights are vastly different
> areas of the law, and yet it is sometimes useful to talk about
> "intellectual property".  Philosophers and English scholars can often
> barely stand to be in the same room with each other, and yet they can
> all be professors of the Humanities.)  For the present discussion
> about dealing with different labels (which happen to correspond to
> particular bits of natural language that "mean the same" or something
> like that), however, I think conflating these cases makes our task
> much harder.  It has caused no small degree of mischief in the TLD
> policy arena, where in-principle solvable and necessarily unsolvable
> problems are sometimes spoken of as though they were the same.

If your goal is to get the ICANN community to stop using the term 
"variant" to refer to the problem that they know to be defined by the 
term, you're going to fail. It's far better to try and understand what 
they mean by "variant" and then try to figure out if we can provide a 
technical solution for it.

> As perhaps the more technical end of an interchange with policy people
> at an ICANN meeting, those of us who care about this topic could help
> (in my opinion) a great deal just by teasing apart these ambiguities
> and trying to ensure that every time a term is used, it is used
> univocally.  It might be painful, but in anticipation of the
> conversation we plan to have in Prague, it will no doubt help
> crystallize which issues are clear (so we can decide whether we know
> what to do), and which issues we do not yet understand.

I agree that teasing apart the ambiguities is a good goal, however I 
hold absolutely no hope that any of "us" are going to get any of "them" 
to modify their language. It's too well ingrained at this point.


hth,

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/