Bundling

Eric Brunner-Williams ebw at abenaki.wabanaki.net
Wed Dec 2 21:23:07 CET 2009


Lisa Dusseault wrote:
> I don't see where that principle begins and ends.  If it were entirely 
> true, zone operators would be entirely free to register xn--garbage as a 
> domain, entirely free to register DISALLOWED characters.


First and foremost, my opening question, mostly to John, though it was 
broad enough to cover all of the co-authors, was where, other than 
from ICANN's DNS IDN requirement, did the IDNAbis WG find its 
requirements?

Now there wasn't a lot of answer, and what there was was that there 
were other sources of requirement, for which one is free to imagine 
that SMTP and HTTP implementors, not merely DNS implementors, might be 
requirement authors.

Clearly outside of the requirements authors was any zone operator 
anywhere, who might be using any subset of, and supersets of, the 
usual suspect RFCs.

So yes, there's a zone in which "heart", some printer turd in the 
UTC's work product styled as a character, is valid. i-heart-nyc is the 
obvious (really obvious) example, and there are others.

In part we are here because some or all of {UTC, IETF, ICANN} have 
made life difficult for implementors of i18n/l10n systems, including 
resource to name mapping applications, so the "stupid hack" in the 
para above should be read tolerantly. That hack was stupid, but the 
need to work around {UTC, IETF, ICANN} damage is real.

It is certainly the case that zone file managers operating under 
contract with ICANN _will_not_ register xn--garbage.

It is certainly also the case that zone file managers operating under 
agreements to be technically consistent with zone files manged under 
contract with ICANN -- and this set includes at least most of the zone 
file managers presently working around prior damage -- also _will_not_ 
register xn--garbage.

So your question is reasonable, so long as you know what the scope of 
actors for whom xn--garbage registrations are possible, or even 
likely, and if you appreciate that a scopeless (in protocol) mechanism 
to prevent xn--garbage assumes a condition known not to be true -- 
that there are no widespread "stupid browser tricks" (the reference is 
to Vixie's famous dicta), and both Israel and Korea IDN are defined by 
sbt, or that if the mechanism to prevent xn--garbage is universal 
across top level zones, or top and 2nd level zones, or top and 2nd and 
3rd level zones, or ... that somewhere at the bottom there are turtles 
who may play by other rules. [Yertle the Turtle reference for others.]




> Since it is in the purview of IDNA designers to make a character valid 
> or disallowed,  wouldn't also be in the purview of IDNA designers to say 
> something like "This character becomes valid on date 01/01/2020", 
> right?  So why wouldn't it be in the purview of IDNA designers to also 
> say something like "This character becomes fully valid on date 
> 01/01/2020, but until then, may be registered if it is bundled with 
> another sequence"?



Andrew already hit this nail. We manage zones. The rational for 
bundling arises elsewhere than the protocol.



> Doncha love slippery slopes :)


The slope problem has always been present, and we're trying to solve a 
bounded problem, modulo some requirement authors are still more
guessed at than declared.

Eric


> Lisa
> 
> On Wed, Dec 2, 2009 at 11:26 AM, Andrew Sullivan <ajs at shinkuro.com 
> <mailto:ajs at shinkuro.com>> wrote:
> 
>     On Wed, Dec 02, 2009 at 07:17:41PM +0000, Shawn Steele wrote:
> 
>      > So if that's how the problem will be solved, is there a better way
>      > to state it?  Or should bundling in these cases just be a BCP?
> 
>     We couldn't offer anything other than BCP or even Informational,
>     because zone operators are quite correct in asserting that the
>     contents of their zone are entirely within the purview of local
>     policy: this is not something one can require as a matter of protocol.
> 
>     A
> 
>     --
>     Andrew Sullivan
>     ajs at shinkuro.com <mailto:ajs at shinkuro.com>
>     Shinkuro, Inc.
>     _______________________________________________
>     Idna-update mailing list
>     Idna-update at alvestrand.no <mailto:Idna-update at alvestrand.no>
>     http://www.alvestrand.no/mailman/listinfo/idna-update
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update



More information about the Idna-update mailing list