Browser IDN display policy: opinions sought

Gervase Markham gerv at
Mon Dec 12 18:33:57 CET 2011

On 12/12/11 17:24, Paul Hoffman wrote:
> Not speaking for Andrew, just myself:
> On Dec 12, 2011, at 8:54 AM, Gervase Markham wrote:
>> If I am to do such a check (and presumably to fail if the domain
>> doesn't meet it), what about when a policy changes to be more
>> strict? How do you deal with grandfathering?
> The zone owner deals with grandfathering. They publish a policy that
> reflects all of the zones they control.

So published policies can only ever been loosened, not tightened?

(If they were tightened, existing domains might fail the new policy,
which would result in them being blocked. This is what I mean by the
grandfathering problem.)

> If you are asking "how does a browser deal with grandfathering when a
> policy changes?", I would say the same thing: assume that the zone
> owner has reasons for publishing that policy.

So just block the domains, then?

>> What about performance? I would need to look up the rules for the
>> zone "" every time I accessed, for lots of
>> values of foo. This doesn't sound like it would improve
>> performance.
> A sane browser would look up policies based on the browser's own
> policy update strategy, and would risk missing a policy update.
> Further, given that the policies would have TTLs on them, you don't
> even need to think about looking up a policy until the TTL expires.
> Further, the browser will know whether or not the zone had a policy
> before and base its lookup strategy on that.

Except if it's the first time the user has visited the site, or the user
has cleared their browsing history, or is using private browsing, or
their cache has been cleared due to memory pressure on their mobile
device, or...

> Or was that meant to be another strawman objection?

Oh, no.

Historically, the idea that a browser will burden the Internet and its
own speed characteristics with millions or billions of additional
requests per day, (and making them blocking - so don't render the site
until it returns) for a purpose such as this has been met with
incredulity and barely-suppressed laughter from our performance and
networking teams.

>> If there are going to be rules, by far the best place to enforce
>> them is once at domain registration time, not in real time in
>> performance critical code millions of times a day at access time.
> Fully disagree. That restricts TLDs to never changing their policies.

Surely the opposite? If a TLD enforces a policy at registration time, it
can change that policy and start accepting registrations under the new
one, without consulting anyone.

> Noted. So, if other browser vendors adopt a different approach, are
> you saying Mozilla won't? I thought the purpose of this thread was to
> revisit the question of what would be best for the users.

I'm not saying that. But no other browser vendor has adopted an approach
which requires extra network requests for each new site visited, and
periodically thereafter. And I don't expect them to.


More information about the Idna-update mailing list