Subject: Re: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 11 Nov 2008 15:12:36 +0100

On Tue, 11 Nov 2008 04:17:02 +0100, Dean Anderson <[email-masked]> wrote:

> On Sun, 9 Nov 2008, Yngve N. Pettersen (Developer Opera Software ASA)  
> wrote:
>
>> On Sun, 09 Nov 2008 00:30:54 +0100, Dean Anderson <[email-masked]> wrote:
>> > The TLD's cannot provide this information, since they don't know it
>> > themselves.  What you are trying to do with 'crowdsourcing' is no
>> > different from early anti-spam efforts (that also failed).  There is  
>> no
>> > reliable source of the information you seek outside the admin domains
>> > themselves. The TLDs aren't the same as the admin domains, and don't
>> > know if, say, bankamerica.com is the same as bankofamerica.com, nor if
>> > wachovia.com was bought by wellsfargo.com and so are now the same  
>> admin
>> > domain.
>>
>> As an example, the dot-UK registry _ought_ to know that all second level
>> domains in the dot-UK hierarchy are registry-like, except (possibly)
>> parliament.uk and maybe a few others, and should be able to create a
>> specification for that. Similarly, the dot-US registory should be able  
>> to
>> provide a list of all state.us, city.state.us, etc. registry-like  
>> domains.
>
> You didn't read my message. the dot-UK registry only knows the domains
> it registered; dot-uk doesn't know if a group of several domains are in
> the same admin control. See the wachovia/bankofamerica example.  Dot-uk

I am not interested in cross-domain ownership. I do not care if opera.com  
and operasoftware.com have the same owner and administrator. None of the  
currently envisioned uses for this spec will allow communication between  
those types of domain anyway (unrelated: The W3C is working on an XHR spec  
that will permit cross-site communication using scripting), nor do they  
consider such domains to be the same.

What I am interested in is whether or not example.co.uk and co.uk are  
administrated by different entities, and where the separation occur, and  
that that change in administration signifies that any x.co.uk and y.co.uk  
are not considered part of the same domain, but separate domains, and that  
as a consequence a.x.co.uk, b.x.co.uk, and x.co.uk are in the same domain  
and under the same administrator.

To put it in a different way: What the suggested specification file  
distributes is the vertical boundary separating domains acting effectively  
as TLDs (e.g. co.uk) and domains that are not acting as TLDs  
(example.co.uk). I have been calling these TLD-like domains "subTLDs", but  
others are calling them "Effective TLDs", "public suffixes" or  
"registry-like domains", and yet others call a domain immediately below  
such domains a "Base domain".

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 11 Nov 2008 15:12:36 +0100

---

From: [email-masked]
Date: Tue, 11 Nov 2008 16:14:30 +0000

> such domains a "Base domain".

Yngve

It's not at all clear to me if your draft has any solution for the many 
unofficial "registry-like domains" that exist, particularly if your 
protocol expects each TLD to know about each and every such domain that 
might exist within its namespace.

For example, I happen to know that 'demon.co.uk' has a separate sub-domain 
for each customer, and should probably therefore be included in your list 
- it's "registry-like".  However there's a (large?) unknown number of 
similar domains that I don't know about.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

[email-masked]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Errors-To: [email-masked]

> such domains a "Base domain".

Yngve

It's not at all clear to me if your draft has any solution for the many 
unofficial "registry-like domains" that exist, particularly if your 
protocol expects each TLD to know about each and every such domain that 
might exist within its namespace.

For example, I happen to know that 'demon.co.uk' has a separate sub-domain 
for each customer, and should probably therefore be included in your list 
- it's "registry-like".  However there's a (large?) unknown number of 
similar domains that I don't know about.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 11 Nov 2008 17:43:36 +0100

On Tue, 11 Nov 2008 17:14:30 +0100, <[email-masked]> wrote:

> -From [email-masked]  Tue Nov 11 08:43:36 2008
Date: Tue, 11 Nov 2008 17:43:36 +0100
To: [email-masked]
From: "Yngve Nysaeter Pettersen" <[email-masked]>
Organization: Opera Software
Cc: [email-masked]
Subject: Re: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt
Reply-To: [email-masked]
Sender: [email-masked]

> similar domains that I don't know about.

I am aware of the problem, and mention it in my original article on the  
subject: http://my.opera.com/yngve/blog/show.dml/267415

Any kind of shared hosting within a domain will have this kind of problem  
(in fact you have a similar problem for paths in same-host hosting); my  
cookie-v2 draft suggestions is really the best way to handle them (it does  
not permit distribution to parent domains); but as such within the  
demon.co.uk domain the situation is not any worse than it would be  
currently if they had used demon.com instead of demon.co.uk. I am aware  
that a couple of similar ones can exist in

AFAICT there are two basic ways to handle such a situation:

One is to let such domain owners register through their TLD to be listed  
in their database as a registry-like domain (or in cases such as  
PublicSuffix.org, submit a patch to them)

The other require a form of policy document that can be posted at a  
well-known location within the domain. It might use a variant of the  
format my subtld draft defines, or something else (although I see no real  
reason it should be significantly different). This would be somewhat  
similar to the full P3P policy file. This might particularly be useful for  
large organizations, like universities, or corporations, to limit  
"cross-departemental" impact.

 it's "registry-like".  However there's a (large?) unknown number of
> similar domains that I don't know about.

I am aware of the problem, and mention it in my original article on the  
subject: http://my.opera.com/yngve/blog/show.dml/267415

Any kind of shared hosting within a domain will have this kind of problem  
(in fact you have a similar problem for paths in same-host hosting); my  
cookie-v2 draft suggestions is really the best way to handle them (it does  
not permit distribution to parent domains); but as such within the  
demon.co.uk domain the situation is not any worse than it would be  
currently if they had used demon.com instead of demon.co.uk. I am aware  
that a couple of similar ones can exist in

AFAICT there are two basic ways to handle such a situation:

One is to let such domain owners register through their TLD to be listed  
in their database as a registry-like domain (or in cases such as  
PublicSuffix.org, submit a patch to them)

The other require a form of policy document that can be posted at a  
well-known location within the domain. It might use a variant of the  
format my subtld draft defines, or something else (although I see no real  
reason it should be significantly different). This would be somewhat  
similar to the full P3P policy file. This might particularly be useful for  
large organizations, like universities, or corporations, to limit  
"cross-departemental" impact.