Re: [DNSOP] Public Suffix List

[Paul Hoffman <[e-mail]>]

At 3:21 PM +0100 6/9/08, Gervase Markham wrote:
>I am not particularly interested in a long discussion about whether we
>need this data. Please be assured that we need it. I am, on the other
>hand, open to suggestions about better ways to obtain it.

One possible method is to start Firefox 3.0 with an empty registry, 
and fetch a registry update from Mozilla each time a user does either 
a manual or automatic "check for updates" on Firefox. Checking for 
updates (as compared to getting updates) happens often enough for 
users who care about updates to minimize the negative effects of TLD 
policy changes for those users. By starting with an empty registry, 
people who never update have the same interface issues they have 
today with Firefox 1 and 2. This proposal does not involve a 
per-domain lookup, thus avoiding a lot of overhead and privacy issues.

"Fixing cookies" is a wonderful idea, and basically impossible in the 
IETF (and probably in the W3C) in any reasonable amount of time due 
to proven repeated lack of consensus. In the meantime, having a 
browser manufacturer "fix cookies" locally may or may not be harmful; 
if it is harmful, hopefully that harm affects the browser maker more 
than the users (or, in this case, domain name holders).

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinFrom [e-mail]  Mon Jun  9 12:31:03 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 203D128C1AE;
	Mon,  9 Jun 2008 12:31:03 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2E00628C1AE
	for <[e-mail]>; Mon,  9 Jun 2008 12:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level: 
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 
	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 3aBu4C2f1aVR for <[e-mail]>;
	Mon,  9 Jun 2008 12:31:01 -0700 (PDT)
Received: from balder-227.proper.com
	(properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net
	[IPv6:2001:470:1f04:392::2])
	by core3.amsl.com (Postfix) with ESMTP id F267628C1A6
	for <[e-mail]>; Mon,  9 Jun 2008 12:31:00 -0700 (PDT)
Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59JVHPX073399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jun 2008 12:31:18 -0700 (MST)
	(envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240814c47332ebcd1e@[10.20.30.162]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>	<[e-mail]>
	<[e-mail]>
Date: Mon, 9 Jun 2008 12:31:13 -0700
To: Gervase Markham <[e-mail]>
From: Paul Hoffman <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

At 3:21 PM +0100 6/9/08, Gervase Markham wrote:
>I am not particularly interested in a long discussion about whether we
>need this data. Please be assured that we need it. I am, on the other
>hand, open to suggestions about better ways to obtain it.

One possible method is to start Firefox 3.0 with an empty registry, 
and fetch a registry update from Mozilla each time a user does either 
a manual or automatic "check for updates" on Firefox. Checking for 
updates (as compared to getting updates) happens often enough for 
users who care about updates to minimize the negative effects of TLD 
policy changes for those users. By starting with an empty registry, 
people who never update have the same interface issues they have 
today with Firefox 1 and 2. This proposal does not involve a 
per-domain lookup, thus avoiding a lot of overhead and privacy issues.

"Fixing cookies" is a wonderful idea, and basically impossible in the 
IETF (and probably in the W3C) in any reasonable amount of time due 
to proven repeated lack of consensus. In the meantime, having a 
browser manufacturer "fix cookies" locally may or may not be harmful; 
if it is harmful, hopefully that harm affects the browser maker more 
than the users (or, in this case, domain name holders).

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


fo/dnsop