Re: [guava] ICANN vs Private public suffix names for InternetDomainName

[Craig Berry]

That's a very interesting idea. The difficulty is that there is no
technical definition of a public suffix; see my document at
https://code.google.com/p/guava-libraries/wiki/InternetDomainNameExplained
for the depressing and scary details. ICANN doesn't actually manage
composite domains in any form. "co.uk", for example, is a
country-specific subdomain of the ICANN-managed domain "uk", and thus
"co.uk" is managed by the UK internet authorities. This calls into
question the usefulness of dividing up the domains based on who has
asserted that each is a public suffix.

As the document cited above explains, the only reasonably solid uses
of the "public suffix" system is to test whether a given string is a
plausible internet domain name, and to determine what portions of that
domain probably will or will not allow cookies to be set in most
browsers. Anything beyond that, e.g. figuring out who "owns" a domain,
is likely to work 99% of the time, and then fail dismally the other
1%, most likely in the midst of an important demo. :)

If I might ask, what are you trying to do with this distinction?

On Mon, Apr 15, 2013 at 4:58 PM, Ben Sanders <colo...@gmail.com> wrote:
> The Mozilla Foundation's Public Suffix List (publicsuffix.org) makes a point
> to differentiate between ICANN recognized public suffixes (like co.uk), and
> private entities that use their domains in a similar fashion (blogspot.com,
> dyndns.org, etc).
>
> Currently, the InternetDomainName class (which uses the data prepopulated in
> the TldPatterns class) uses the full list for any of its public suffix
> related functions. It would be nice (for me) to be able to choose whether
> or not to use the full list, or just the ICANN subset.
>
> For my purposes, I can generate my own TldPatterns class with just the data
> that I want, but I am guessing that other people may want to use the class
> in this way as well.
>
> --
> --
> guava-...@googlegroups.com
> Project site: http://guava-libraries.googlecode.com
> This group: http://groups.google.com/group/guava-discuss
>
> This list is for general discussion.
> To report an issue: http://code.google.com/p/guava-libraries/issues/entry
> To get help: http://stackoverflow.com/questions/ask (use the tag "guava")
>
> ---
> You received this message because you are subscribed to the Google Groups
> "guava-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to guava-discus...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
"Vetus est via abominandam, nova via non operetur."
Craig Berry
Software Engineer
Google Los Angeles

[Ben Sanders]

I agree that the situation is muddy, and me calling some of the domains "ICANN recognized" was a mistake.

I am basically just trying to identify the portion of a domain from a list that might have been privately registered with a registrar (if it even exists).  The goal would be to aggregate data from a single domain, regardless of the subdomains used.  The PSL is the best resource I've seen for offline filtering of this sort, even if it a bit of an abuse of the data.  Thinking about it more, it may make sense to still include the 'private' public suffixes, since the content is usually being controlled by different parties.

At first, I was thinking that grouping by 'owner' would make most sense because I don't particularly care about cookies, and the 'owner' is the one paying for a domain and setting up an authoritative nameserver for the domain. On the other hand, there are also TLDs like .tk ( http://en.wikipedia.org/wiki/.tk ), which make it just as easy to get a free domain as someone like dyndns.  So the distinction between the 'private' and 'icann' parts of the list is very fuzzy indeed.

I can see why it would be in the best interests of Guava to not encourage this type of use, when it is not what the list is for.

Thanks,

Ben