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

Doug Barton <dougb@dougbarton.us> Sat, 12 March 2011 23:05 UTC

Return-Path: <dougb@dougbarton.us>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A49E3A6A15 for <dnsext@core3.amsl.com>; Sat, 12 Mar 2011 15:05:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6zkFswHwc+E for <dnsext@core3.amsl.com>; Sat, 12 Mar 2011 15:05:49 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id C57B33A69DA for <dnsext@ietf.org>; Sat, 12 Mar 2011 15:05:48 -0800 (PST)
Received: (qmail 29848 invoked by uid 399); 12 Mar 2011 23:07:04 -0000
Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 12 Mar 2011 23:07:04 -0000
X-Originating-IP: 75.60.237.91
X-Sender: dougb@dougbarton.us
Message-ID: <4D7BFC97.8050001@dougbarton.us>
Date: Sat, 12 Mar 2011 15:07:03 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9
MIME-Version: 1.0
To: dnsext@ietf.org
References: <EE8A5F5A-26CD-474A-B983-32948A06DEBD@icann.org> <4D77D2AF.7010203@abenaki.wabanaki.net> <4D77D6D8.9070609@dougbarton.us> <20110309201647.GJ32629@shinkuro.com>
In-Reply-To: <20110309201647.GJ32629@shinkuro.com>
X-Enigmail-Version: 1.1.2
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] BOF on variants for ICANN San Francisco
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Mar 2011 23:05:50 -0000

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/