<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/11/2014 1:16 PM, Yoshiro YONEYA
wrote:<br>
</div>
<blockquote
cite="mid:20141112061605.d06742b7fa15ba26ced190b5@jprs.co.jp"
type="cite">
<pre wrap="">Asmus-san,
</pre>
<blockquote type="cite">
<pre wrap="">Just out of interest, can you give me an example of a label
where jpan+latn needs to be mixed?
</pre>
</blockquote>
<pre wrap="">
Followings are existing Japanese JP domain names including Alphabets.
JR東日本.jp
日本IBM.jp
株式会社NTTドコモ.jp
Some companies are using such mixed script name. I'm not sure if
they want to register such name on TLD, but I don't have reason
to prohibit it.
I'll reply to your answer to my 2nd question separately.
Regards,
</pre>
</blockquote>
<font face="Candara"> Yoneya-san,<br>
<br>
The text in B.3.2 of the Procedure anticipates only two cases
where<br>
script-mixing is allowed. They are: a) mixing of
Common/Inherited<br>
with certain scripts, and b) the mixture of East Asian scripts
such as t<br>
the Hiragana+Katakana+Kanji trio for "und-Jpan". Beyond that, <br>
including the common "usage" of mixing ASCII in various
cultures, <br>
no mixing is anticipated. This describes the default position.<br>
<br>
The Integration Panel is aware of the Japanese practices using<br>
Romaji, but is not taking an action towards making an exception
for<br>
this. The bar for the IP panel to make any exception to the
status quo<br>
on script mixing suggested in the procedure would be very high.<br>
<br>
The absence of such an exception does make the root more
restrictive<br>
than second level domains; it also affects other cultures' more<br>
occasional use of ASCII letters. However, the restriction of not<br>
allowing digits in the roots affects some writing systems
already more<br>
severely than the absence of ASCII mixing (disallowing plurals,
for<br>
example). Overall, this restrictiveness is built firmly into the<br>
suggested course of action by the Procedure and and in turn
aligned with the<br>
provision in RFC 6912 that zones higher in the DNS tree tend to
have<br>
more restrictive rules.<br>
<br>
That is the best I can do at this point to give you more
background<br>
on my short reply during the ICANN51 meeting.<br>
<br>
Perhaps you get further understanding of this by discussing it
with<br>
Marc Blanchet, who, I believe is at the same IETF meeting with
you.<br>
<br>
Cheers,<br>
<br>
A./<br>
</font><br>
</body>
</html>