W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: [DNSOP] Public Suffix List

From: Eric Brunner-Williams <brunner@nic-naa.net>
Date: Mon, 09 Jun 2008 14:29:59 -0700
Message-ID: <484DA0D7.1030908@nic-naa.net>
To: Kim Davies <kim.davies@icann.org>
CC: David Conrad <drc@virtualized.org>, Gervase Markham <gerv@mozilla.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>

Kim Davies wrote:
> On 9/06/08 11:56 AM, "David Conrad" <drc@virtualized.org> wrote:
>   
>> On Jun 9, 2008, at 9:34 AM, Gervase Markham wrote:
>>     
>>>> I'm curious: have you consulted with the various TLD-related
>>>> organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD,
>>>> etc.) on
>>>> how to solve this problem?
>>>>         
>>> No. What do you think they'd say that hasn't been said in this thread
>>> already?
>>>       
>> You're talking about essentially creating a registry of their registry
>> policies and distributing it statically via your product.  I would
>> imagine they might be interested and might even have some useful input
>> to provide.  Some might even think it rude (even Microsoftian :-)) not
>> to ask.  But perhaps I've been at layer 9 too long.
>>     
>
> This thread sounds remarkably like deja vu. Indeed, the TLD community was
> rather upset a few years ago by Mozilla taking unilateral action to
> introduce a hard-coded white-list of acceptable IDN TLDs without prior
> consultation. It is not unreasonable to think that doing so for a second
> time, with the benefit of hindsight, would be received negatively.
>
> I'd also speculate much of the pros and cons to this discussion are equally
> applicable to the IDN whitelist. (
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html)
>
> kim
>   
Putting on a different hat, browser vendors have no duty to market 
Verisign's product, in the original wrapping or the new and improved 
flavor, nor the Unicode Consortium's product. They do have the means to 
discover the native operating system's supported encodings, existing 
i18n/l10n add-ons, fonts and so on. They may have a view supported by 
user adoption that is not identical to the view adopted by namespace 
vendors.

In the fleeting moments when I personally enjoyed (or suffered) some TLD 
layer 9 and below responsibilities, I (and my peers concerned by the 
inherent problems and errors common to the ASCII-encoded-Unicode, also 
at L9 and below, for some other, profoundly concerned TLDs) was rather 
pleased by, not upset by, other stakeholders responsibly acting to limit 
the amount of damage done by the introduction of homographs.

In a nutshell, with whom should a browser vendor "consult", and, if 
browser vendors implement something proximal to the needs and desires of 
end-users, exactly where do they fit in the current "stakeholder", or 
reformed "contractual or non-contractual" model, for ICANN as an 
example? I've been "doing" ICANN for ages, and there's not much room at 
the table for browser vendors, or really anyone not a registrar, a 
registry, or an intellectual property lobbyist. So what part of "reform" 
or "stakeholder" is that 501(c)(3) supposed to avail itself to?

Rather than clutter up the lists with an additional message, to 
Stephane, whom I'll see soon anyway, the IE 5.5 beta semantic (drop all 
3rd-party cookies) was tightly held, at least initially.

Eric
Received on Monday, 9 June 2008 21:33:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:48 GMT