It sounds promising. I also like the idea that someone floated of having something like TRANSITIONAL_2016. A combination of these approaches may allow us to transition to these characters while avoiding 99% of the problems.<div>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Thu, Dec 3, 2009 at 09:48, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@shinkuro.com" target="_blank">ajs@shinkuro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I've been thinking more about the TRANSITIONAL approach, and the sort<br>
of registry-bundle + sunset clause discussion, and I'm wondering if<br>
the two approaches can't be combined to solve the harms that people<br>
seem to feel are present especially from ß. This is a drafty outline<br>
of how a combined approach could result in the ß being PVALID. I'm<br>
concentrating on its case right now because (1) it's a slightly<br>
simpler problem and (2) it seems to be the case that many think has<br>
the greatest potential for harm. If what I am suggesting satisfies<br>
those who think ß is too dangerous, I think the same strategy more or<br>
less can be adopted for other problematic cases. This is extremely<br>
hand-wavy right now (as it has been in the past when I've described it<br>
casually to people). I haven't really worked through the details,<br>
but if anyone thinks this is a not-insane way out of the current bind,<br>
then I'll work on it some more.<br>
<br>
I should say to begin with that I view our current problem as<br>
basically a co-ordinated update problem. It's impossible to declar a<br>
flag day. Those arguing for mapping are basically arging from the<br>
danger of backward _ambiguous_ compatibility (thanks to Mark for<br>
putting it so clearly). I regard that objection as a reasonable one,<br>
but I am not totally convinced that the solution ("never ever use<br>
this") is the right answer. If we had a way to co-operatively<br>
introduce the characters in a predictable way, then clients could know<br>
what to do.<br>
<br>
First, the characters we're worried about go into a TRANSITIONAL or<br>
MAYBE category. If we call it TRANSITIONAL, then I suggest we set<br>
some sunset date by which the TRANSITIONAL characters are just<br>
automatically PVALID, as was already suggested, but I don't feel<br>
strongly about this. If we use MAYBE, then this feature is permanent.<br>
I prefer TRANSITIONAL because it makes this go away (what I'm<br>
proposing is a kludge). This would be required immediately, so that<br>
we could go ahead with the rest of the changes in IDNA2008.<br>
<br>
We write another document about lookups (or just add a restriction to<br>
protocol) that says how clients looking up these characters might deal<br>
with them. The default is refuse, so that the danger that some<br>
participants see is minimized: there's no ambiguity, but there is a<br>
failure. The alternative is to use a mechanism provided by the<br>
registry in order to decide what to do. Specifying this is also<br>
required immediately in order that we proceed.<br>
<br>
Finally, we write a document that outlines how a registry (== zone<br>
operator) might deal with these characters. The document outlines<br>
what bundling, if any, can be done for various characters. It also<br>
specifies a format by which a registry can publish its policy on what<br>
mapping happens. The location of the policy is places in an SRV or<br>
NAPTR or some such record. That allows a client (any client) to find<br>
the policy as published by the zone operator. Then the client can<br>
look up the policy document, find the character in question and see<br>
how it is mapped.<br>
<br>
Clients can, in this way, be tuned appropriately if desired by local<br>
users, but they can ship by default with a policy that is tightly<br>
closed. As registries come up with mappings, they can publish them<br>
and the clients that understand this mechanism can react<br>
appropriately. Over time, the reaction might even be different (as<br>
users' expectations come to be different) without us needing to<br>
re-open the protocol.<br>
<br>
This document does not have to come with the rest of IDNA2008, because<br>
the default "closed" policy on these TRANSITIONAL characters means<br>
that they just don't work to begin with.<br>
<br>
The mechanism suffers from some obvious flaws. First, we're adding<br>
another lookup plus the obtaining of some policy document to a<br>
resolution context. I think this is partly solvable by putting<br>
expirations on documents and by using longish TTLs on the records.<br>
We're also adding the potential for a lot of never-to-be-satisfied<br>
NAPTR or whatever lookups against authority servers, and that's not<br>
nothing. It's another pile of stuff to specify, and so these<br>
characters become delayed while we hammer out this specification. It<br>
requires the invention of a way to specify mappings in an<br>
easy-to-publish and machine-readable format. It requires more<br>
infrastructure by sites that want to use the mechanism.<br>
<br>
Nevertheless, it does offer the possibility that both ends of the<br>
communication can establish (securely, if this is done with DNSSEC for<br>
the lookup and TLS for obtaining the policy) what the situation is<br>
with respect to characters in the zone. This would allow, I think,<br>
more sophisticated client-side mapping that is desirable to some<br>
communities where that sophisticaed mapping could be co-ordinated,<br>
while yet providing a stable and predictable default as some are<br>
arguing is necessary. (Once we had the mechanism, we might use it for<br>
other purposes too -- I originally thought of something like this in<br>
an effort to attack the "cookie problem", but nobody seemed interested<br>
so I haven't pursued it.)<br>
<br>
Again, I am aware this is a very sketchy suggestion right now. That<br>
stipulated, does it sound remotely sane?<br>
<br>
A<br>
<font color="#888888"><br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@shinkuro.com" target="_blank">ajs@shinkuro.com</a><br>
Shinkuro, Inc.<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</font></blockquote></div><br></div>