660215 - Remove .local from PSL

Status: RESOLVED FIXED

(Core Graveyard :: Networking: Domain Lists, defect)

Description

[Gervase Markham [:gerv]]

Currently, .local is in the PSL. The front page of publicsuffix.org says "A "public suffix" is one under which Internet users can directly register names." (Implicitly, in the IANA DNS root.)

So, we should remove .local. Then, the PSL will again be useful for checking whether a domain name is publicly registrable or not.

Gerv

Comment 1

[Jothan Frakes]

In a clinical sense, for purity of the premise of "Public", I agree.  I did a little more research on .local and found a few spots to see if I could backfill my institutional knowledge on why this was listed in the first place.

I am new as a volunteer here, but I wonder if consideration for RFC 2965 http://www.ietf.org/rfc/rfc2965.txt counts in the approval process for this change as treating 'public' with respect to how local behaves as a special case to respect interoperability with Linux and Apache.

Apache has a failover in their code for .local
http://hc.apache.org/httpcomponents-client-ga/httpclient/clover/org/apache/http/impl/cookie/RFC2965DomainAttributeHandler.html

.local is often a Linux installer's "Hello World" of TLDs, and many LAMP installations (quite popular) depend upon this.

Just putting this in here to document these.  I don't disagree with pulling .local, but it might have crept in with some good logic.

Comment 2

[Jothan Frakes]

Revised Apache.org Link:
http://hc.apache.org/httpcomponents-client-ga/httpclient/clover/org/apache/http/impl/cookie/RFC2965DomainAttributeHandler.html?line=131#src-131

Comment 3

[Gervase Markham [:gerv]]

In the normal use of the PSL, having .local listed is a no-op, because the fallback behaviour is to treat any unknown domain as if it's listed just as itself. If people are using the PSL for other things than e.g. cookie setting, it might make a difference to them - but there's at least one use, which was the source of this bug report, where having .local messes things up.

Gerv

Comment 4

[Jothan Frakes]

Attachment: Patch to remove .local

Comment 5

[Gervase Markham [:gerv]]

Comment on attachment 536070 [details] [diff] [review]
Patch to remove .local

Jothan: when attaching patches, the right thing to do is "request review", by setting the "review" flag on the attachment to "?", with a requestee of whoever you want to do the review.

I'll review this one, but in future you could ask e.g. pkasting.

Gerv

Comment 6

[Jothan Frakes]

OK, cool.  

Will do on future items.   I am learning the process on these, so thanks for the patience while I am learning the force.

Comment 7

[Gervase Markham [:gerv]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8a56b449f8bc

Gerv

Comment 8

[Peter Kasting]

Should this be ->FIXED then?

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8a56b449f8bc

Comment 10

[Ed Morley [:emorley]]

(In reply to Peter Kasting from comment #8)
> Should this be ->FIXED then?

At least for now, I have to mark bugs manually after merging inbound to m-c, which is somewhat tedious so tends to get saved until a few hours after the merge.

Comment 11

[Gervase Markham [:gerv]]

edmorley: you have come across Bugzilla's "mass change" feature, haven't you? :-)

Gerv

Comment 12

[Ed Morley [:emorley]]

Unfortunately each bug needs it's own changeset pasted, a scan of the whiteboard to see if the bug needs to be kept open any longer & setting the assignee if it's been left blank - so sadly can't be set using mass change. My current brainstorming ideas for automating this are at https://etherpad.mozilla.org/automating-merge-bug-marking , but it's just a case of finding the time as a volunteer to do it :-)

Comment 13

[Gervase Markham [:gerv]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/84c358b65105
https://hg.mozilla.org/releases/mozilla-beta/rev/006ca0def8bf

Gerv

Comment 14

[u279076]

Is there something QA can do to verify this fix?