Re: [DNSOP] Public Suffix List

[Gervase Markham <[e-mail]>]

Andrew Sullivan wrote:
> Because what you are proposing to do adds special meaning to certain
> labels (and their relative position) and not to others, in exactly the
> way that previously people had special interpretations of certain
> labels and their positions in the set of labels. 

Right. But they did things like throw error messages saying "That's an
invalid domain name because it has too many characters in the extension.
Please enter a valid one." We aren't planning anything like that.

> What you're really
> trying to do here is extract meaning from the domain name, but you
> can't do that reliably.  Previous efforts in that direction have
> failed in unexpected ways; and given that you seem to have multiple
> ways you want to use this feature, I don't see any reason to believe
> you won't have surprising failures too.

I think your statements of doom need to be more specific.

> The plan is both too narrow and too wide.  First, it will almost
> certainly fail to capture 100% of the cases you currently don't want
> to succeed. 

That's true. It's an improvement to privacy and UI, not a magic bullet.

> Second, it will (as we've been arguing in this thread)
> not work for new TLDs and other cases.

It will work perfectly for any new TLD which allows registration
directly below the root.

Of the seven new gTLDs introduced in 2001/2, this is true (as far as I
can see) of .biz, .info, .name and .coop. So those four would have
worked fine if this From [e-mail]  Mon Jun  9 08:53:38 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 B18373A6C8C;
	Mon,  9 Jun 2008 08:53:38 -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 0F6993A6C88
	for <[e-mail]>; Mon,  9 Jun 2008 08:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.37
X-Spam-Level: 
X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=-1.371, 
	BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
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 NJNNqrkNhTqX for <[e-mail]>;
	Mon,  9 Jun 2008 08:53:37 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com
	[91.135.15.56]) by core3.amsl.com (Postfix) with ESMTP id E20FC3A6C7F
	for <[e-mail]>; Mon,  9 Jun 2008 08:53:36 -0700 (PDT)
Received: from grmarkham.plus.com ([80.229.30.161] helo=[192.168.1.6])
	by haggis.mythic-beasts.com with esmtpsa
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63)
	(envelope-from <[e-mail]>)
	id 1K5jey-0008Ks-Fl; Mon, 09 Jun 2008 16:51:53 +0100
Message-ID: <[e-mail]>
Date: Mon, 09 Jun 2008 16:53:42 +0100
From: Gervase Markham <[e-mail]>
User-Agent: Thunderbird 3.0a1 (X11/2008050714)
MIME-Version: 1.0
To: Andrew Sullivan <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>
	<[e-mail]>
In-Reply-To: <[e-mail]>
X-BlackCat-Spam-Score: -18
Cc: [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]

Andrew Sullivan wrote:
> Because what you are proposing to do adds special meaning to certain
> labels (and their relative position) and not to others, in exactly the
> way that previously people had special interpretations of certain
> labels and their positions in the set of labels. 

Right. But they did things like throw error messages saying "That's an
invalid domain name because it has too many characters in the extension.
Please enter a valid one." We aren't planning anything like that.

> What you're really
> trying to do here is extract meaning from the domain name, but you
> can't do that reliably.  Previous efforts in that direction have
> failed in unexpected ways; and given that you seem to have multiple
> ways you want to use this feature, I don't see any reason to believe
> you won't have surprising failures too.

I think your statements of doom need to be more specific.

> The plan is both too narrow and too wide.  First, it will almost
> certainly fail to capture 100% of the cases you currently don't want
> to succeed. 

That's true. It's an improvement to privacy and UI, not a magic bullet.

> Second, it will (as we've been arguing in this thread)
> not work for new TLDs and other cases.

It will work perfectly for any new TLD which allows registration
directly below the root.

Of the seven new gTLDs introduced in 2001/2, this is true (as far as I
can see) of .biz, .info, .name and .coop. So those four would have
worked fine if this sysystem had been in place and there had been no
update. .museum and .name have sub-structure, but we haven't found a
definitive list.

If .pro were not present in the list, then people within the
professional subdomains such as bar.pro could conspire to share cookies.
The end-user effect of this is a minor loss of privacy, but none of
function.

> Your counterargument is that
> the behaviour will then fall back to the current arrangement.  This
> means that different domains behave in different ways, and the user
> can't rely on any behaviour consistently.

But if consistent behaviour was the goal, then we _would_ allow
privacy-busting cookies for .co.uk and .com.au, because those domains
are "just the same" as foo.com, and we want "consistency".

Who is "the user" in your statement?

>> This isn't just about cookies. For example, we would like to group
>> together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
>> history. Grouping together all sites in ".co.uk" does not provide for an
>> optimum user experience.
> 
> It seems to me that what you want is metadata about certain domains.
> Therefore, what you need is a mechanism for publishing metadata, not a
> magical list of domains about which you'll have hard-coded
> information. 

As I have mentioned earlier in the thread, Yngve is proposing a scheme
were every TLD operator publishes this information using a web service,
and clients can look it up (and cache it). I personally think the
chances of that happening are very slim. But if I am proved wrong, we
can happily switch over to using it.

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


stem had been in place and there had been no
update. .museum and .name have sub-structure, but we haven't found a
definitive list.

If .pro were not present in the list, then people within the
professional subdomains such as bar.pro could conspire to share cookies.
The end-user effect of this is a minor loss of privacy, but none of
function.

> Your counterargument is that
> the behaviour will then fall back to the current arrangement.  This
> means that different domains behave in different ways, and the user
> can't rely on any behaviour consistently.

But if consistent behaviour was the goal, then we _would_ allow
privacy-busting cookies for .co.uk and .com.au, because those domains
are "just the same" as foo.com, and we want "consistency".

Who is "the user" in your statement?

>> This isn't just about cookies. For example, we would like to group
>> together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
>> history. Grouping together all sites in ".co.uk" does not provide for an
>> optimum user experience.
> 
> It seems to me that what you want is metadata about certain domains.
> Therefore, what you need is a mechanism for publishing metadata, not a
> magical list of domains about which you'll have hard-coded
> information. 

As I have mentioned earlier in the thread, Yngve is proposing a scheme
were every TLD operator publishes this information using a web service,
and clients can look it up (and cache it). I personally think the
chances of that happening are very slim. But if I am proved wrong, we
can happily switch over to using it.

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