Katakana Middle Dot again (Was: tables-06b.txt: A.5, A.6, A.9)

John C Klensin klensin at jck.com
Sat Jul 25 10:52:45 CEST 2009



--On Saturday, July 25, 2009 18:30 +1000 Wil Tan
<wil at cloudregistry.net> wrote:

> John,
> 
> I share your views that this character (and the other middle
> dot for that matter) is similar enough to an important
> protocol character that it warrants extra care. If we are to
> go down that road, I'd like to see:
> 
> 1. That the contextual rule be validated at lookup time as
> well. Since it is easy and attractive (to phishers) to mint
> DNS labels at lower level of the tree, not requiring the
> lookup check does nothing to mitigate the concerns. This was
> also raised by Chris (and in a similar vein, Shawn);

That would work for me.  The question from my point of view is
whether the extra test and lookup-time code would be worth it,
especially for a moderately-complex rule.  I'm perfectly
prepared to believe the answer is "yes".   This is also a
new-ish question: we assumed 18 months or so ago that the only
members of ContextJ were ZWJ and ZWNJ and that everything else
went into ContextO, but have not reexamined that one as our
understanding has  evolved.

> 2. That at least one (Han|Hiragana|Katakana) character should
> come before the katakana middle dot; and
> 
> 3. That the label contains only (Han|Hiragana|Katakana|LDH) +
> middle dot.

Makes sense to me but, again, the boundaries of appropriate
usage of this character is outside my competence.
 
> However, it makes the rule considerably more complex and
> because of this I was thinking more of leaving this to the
> application, which may have more contextual information (such
> as user's locale, the TLD, etc.) to take appropriate steps to
> protect the user.

It is a question, again, of how to draw the line.  In some
sense, the way that IDNA works makes "in the IDNA protocol" and
"in the application" different versions of the same thing -- all
of IDNA occurs "in the application" although API design, etc.,
may change perceptions of that.   The argument about  how
normative mapping should be has its mirror image here.
Personally, I can live with "general prohibition on
registration; recommend that lookup-side applications be
extra-careful with this stuff".  That is more or less what
CONTEXTO is about and would be consistent with what I think you
are suggesting above (the text in Protocol may need tuning;
suggested text welcome).     Somewhat more would also work for
me if we can fairly clearly justify it.

If applications start drawing lines differently on what should
have been registered, we get the most inconsistent behavior
possible.  That is why Protocol contains language requiring that
anything that is Lookup-Valid must be looked up, even if one
decides to warn the user first.

Be careful, however, about any assumptions of actions based  on
TLDs.   The presence of DNAME and the lack of any "give me back
the canonical/primary tree" function in the DNS makes that one
very fragile even if there were no other issues.

best,
     john



More information about the Idna-update mailing list