More detail: a sketchy idea for expressing zone policy

Andrew Sullivan ajs at shinkuro.com
Wed Dec 9 19:00:38 CET 2009


On Wed, Dec 09, 2009 at 05:20:23PM +0000, Shawn Steele wrote:

> One problem with the per-zone rules is complexity and whether or not people would adopt it.

Yes.

> Another problem is that it doesn't help when processing disconnected
> strings.  If I wanted to validate a URL in an address book, I'd have
> to look it up.

Hrm.  Isn't that true today?  If I give you a URL, don't you have to
check in the DNS to see whether you get NXDOMAIN?

> What happens when the zone changes the policy?  (Or adds a policy
> when it suddenly becomes aware of the option?)

It seems to me that things which did archiving of links (like, say,
spiders) would have to archive the policy document under which the
archive was accessed, too.  But since the policies have a begin and
end timestamp, that should work.

 > If we were going to provide rules that effectively cause bundling
 > per-zone for certain characters, then I'd think about extending it
 > to some of the other sequences discussed on the list.  Eg: If I
 > want to bundle ß and ss, then maybe I also want to bundle ö and oe.
 > Or maybe neither of those, but ı and I.

Right.  That's actually one of the features I think this mechanism
delivers.  You can use it for those kinds of policies.  (You can also
use it for other interesting policies unrelated to IDNA.  For
instance, this mechanism could also be recycled to indicate "these DNS
labels are equivalent to me for cookie purposes", which would be a
much nicer way than the current array of filthy hacks to solve the
mistakes in the cookie specification.  That's off topic for this
list, however.)

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.


More information about the Idna-update mailing list