822238 - PSL .PY exception rules without global rule

Status: RESOLVED FIXED

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

Description

[Simone Carletti]

Posted on behalf of Bryan McQuade.

Hi,

I notice that in http://hg.mozilla.org/mozilla-central/rev/355a2ac5f897 the following rules were added:

com.py
coop.py
edu.py
gov.py
mil.py
net.py
org.py
!nic.py
!una.py

Note the two exception rules at the end "!nic.py" and "!una.py" and also note that there is no *.py rule.

The public suffix list documentation reads "An exclamation mark (!) at the start of a rule marks an exception to a previous wildcard rule. An exception rule takes priority over any other matching rule."

In this case, there is no previous wildcard rule to except so it's not clear what these exceptions mean.

How should these ! rules be interpreted in the absence of a *.py rule?

Comment 1

[Simone Carletti]

Follow ups.

Simone:

> As you can see from the diff, the rule *.py was there but it was since removed because we received confirmation from the registry that no registration is available for .PY at the > second level and the only second levels available are those listed in the patch.
> 
> I honestly didn't remember the rule in the PSL documentation where the exception is expected to amend a wildcard rule. In this case, the intention was "no registration is allowed at > second level, except for nic.py and una.py".
> 
> I don't think there is a way to express this with a wildcard rule, in this case. I'd like to know Gerv feedback on this topic.
> 
> Bryan, is this rule causing any parsing issue to you?


Gervase:

> There are two ways this can legitimately be encoded:
> 
> *.py
> !nic.py
> !una.py
> 
> (All registrations in .py are at the third level except for nic.py and una.py. Of course, in practice, 3rd level registrations only occur below a small set of defined second levels.)
> 
> or
> 
> py
> 
> com.py
> coop.py
> edu.py
> gov.py
> mil.py
> net.py
> org.py
> 
> (Registrations in .py may either be at the second level, or at the third level below one of these listed 2nd levels. Of course, in practice, there are only two examples of second > level registration.)
> 
> Which one we pick is not too important; they have different "forward compatibility" properties. One question is what helps Chrome most, given that it uses the PSL for the Omnibox.


Bryan:

> My parser did not handle this case correctly which is why I raised the issue here.
> 
> I think it's ok to expand the meaning of ! in the absence of a wildcard rule if it allows the public suffix grammar to be more expressive in a way that's useful for the py domains. > You'd want to reach out to all of the major consumers to make sure they handle it correctly.
> 
> Otherwise, if it's really never intended to use ! without a wildcard, it would be great to have some sort of test that validates the public suffix file each time it's checked in (or > as part of a submission process) to make sure these kinds of rules are not able to sneak in.
>

Comment 2

[Gervase Markham [:gerv]]

Here's a more readable version of what I said :-)

"There are two ways this can legitimately be encoded:

*.py
!nic.py
!una.py

(All registrations in .py are at the third level except for nic.py and una.py. Of course, in practice, 3rd level registrations only occur below a small set of defined second levels.)

or

py
com.py
coop.py
edu.py
gov.py
mil.py
net.py
org.py

(Registrations in .py may either be at the second level, or at the third level below one of these listed 2nd levels. Of course, in practice, there are only two examples of second level registration.)

Which one we pick is not too important; they have different "forward compatibility" properties. One question is what helps Chrome most, given that it uses the PSL for the Omnibox."

CCing pkasting to see if he has a preference.
Gerv

Comment 3

[Peter Kasting]

My preference would be for the second form.

Neither one is future-proof: it's possible for the registry to allow more hosts in .py or to add more 2LDs.  But the second one seems clearer to me, and if we have to pick one of the aforementioned conditions to handle correctly, I'd rather have the system automatically be accommodating of new hostnames in .py rather than have it be accommodating of new 2LDs, since the former doesn't seem like as much of a "registrar policy change" (in the sense that we monitor such policies) as the latter.

Comment 4

[Gervase Markham [:gerv]]

OK. weppos: can you prepare a patch which makes the .py list look like the second form?

Gerv

Comment 5

[Simone Carletti]

I agree with the second form as well. As far as I remember, is the one original proposed when I first had to deal with .PY exceptions.

Preparing the patch right now.

Comment 6

[Simone Carletti]

Attachment: Patch for .PY exception rules

Comment 7

[Gervase Markham [:gerv]]

Comment on attachment 694280 [details] [diff] [review]
Patch for .PY exception rules

r=gerv.

Gerv

Comment 8

[Gervase Markham [:gerv]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3b9ab5404a25

Gerv

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/3b9ab5404a25