日本レジストリサービス (JPRS) は、日本語ドメイン名を普及させたいと思っているなら、「日本語ドメイン名」と連呼するだけでなく、ウェブサイト運営者やユーザーや開発者に「日本語ドメイン名を使いたい」と思わせるような宣伝活動をするべきです。そのためには、広報と技術者とが連携するべきです。その点、「電子メール本文中の日本語ドメイン名 URL をクリックできるようにするには」は要するに「日本語ドメイン名を使ってください」と言っているだけで開発者が求める情報を提供しておらず、しかも日本語ドメイン名 URL への対応は簡単であるかのように謳っていますが実際には難しいところについて言及していないだけになってしまっており、開発者の役に立つ文書になっているとは思えません。
今の多くの電子メールソフト (メーラー) では、本文中に次のように URL らしき文字列が現れると、
> 七草粥も食べずに正月が終わっていった…… orz せめて写真だけでもどうぞ。 http://www.ajinomoto.co.jp/recipe/condition/menu/701147.asp
次のようにその部分がハイパーリンクになるように作られています。
> 七草粥も食べずに正月が終わっていった…… orz せめて写真だけでもどうぞ。 http://www.ajinomoto.co.jp/recipe/condition/menu/701147.asp
一方、日本語ドメイン名を同じように認識するメーラーはわずかです。例えば、 Outlook Express 6 では下の URL はハイパーリンクになりません。
> 七草粥も食べずに正月が終わっていった…… orz せめて写真だけでもどうぞ。 http://味の素.jp/recipe/condition/menu/701147.asp
これでは日本語ドメイン名を使ってもらえそうにありません。ということで、 2006 年 12 月 27 日、 JP ドメインを管理し日本語ドメイン名の普及に努めている日本レジストリサービス (JPRS) は、電子メール本文中の日本語ドメイン名 URL をクリックできるようにするにはという一連の文書を発表しました。
なんですけど……これ、技術者を馬鹿にしているんですか? こんな簡単なことはメーラーを作る人なら絶対にわかっています。それだけでは済まないから対応していないんです。 JPRS に技術者がいないわけがないのですが、広報活動に技術者が関わらないと、いつまでたっても日本語ドメイン名は広まらないと思います。
なお、言い訳を先に書きますが、僕はメーラーの開発をしたことはありませんし、残念ながらメーラーに限らずいかなる開発コミュニティーにも属していません。単にプログラミングとソフトウェア開発に興味がある素人です。でも、技術文書はそれなりに読んできていると思うので、僕が JPRS が今回発表した文書に対して感じた不満を書こうと思います。
JPRS の発表した文書は、ユーザー向けの電子メール本文での日本語ドメイン名 URL 記述ガイド (以下「ユーザーガイド」) と、メーラー開発者向けの日本語ドメイン名 URL クリック対応アプリケーション開発者ガイド 〜メーラー編〜 (以下「開発者ガイド」)、それにメーラー開発者や JPRS がテストケースとして使うことを想定して書かれたと思われる日本語ドメイン名 URL クリック対応アプリケーションテスト仕様 (以下「テスト用ファイル」) から成ります。後日この仕様に準拠したメーラーの一覧を公開するそうです。
どれも短いので読んでもらえばいいのですが、さらに短くまとめると次のようになります。
JPRS 文書には、メーラー開発者が日本語ドメイン名をハイパーリンクにするために必要となる情報が書かれていません。少なくとも次の四つの点について、何らかの記述があってしかるべきだと思います。
1 はこのガイドの致命的な不備であり、これが議論されていないのでは相互運用できません。 2、 3、 4 は技術者がソフトを日本語ドメイン名 URL に対応させようと思ったら一緒に考えるに決まっている問題なので、技術者に配慮するなら何らかの記述があって当然なのに、 2 についてはテスト用ファイルの中に説明なく出てくるだけでガイドの中には出てこないし、 3 と 4 に至っては何も書いていません。
メールを書くユーザーはユーザーガイドに従って、
> 七草粥も食べずに正月が終わっていった…… orz お疲れ様です。大変そうですね。写真だけでもどうぞ (余計につらい?)。 <http://味の素.jp/recipe/condition/menu/701147.asp>
と書いたとします。これを普通に 1 行が適度な長さになるように切ると、
> 七草粥も食べずに正月が終わっていった…… orz お疲れ様です。大変そうですね。写真だけでもどうぞ (余計につらい?)。 <http://味 の素.jp/recipe/condition/menu/701147.asp>
のように URL の途中で改行されるかもしれません。改行はユーザーが入れるかもしれないし、メーラーが自動的に入れるかもしれません。もしも URL の途中で改行が入ることを避けるべきならば、ユーザーガイドと開発者ガイドの両方にその旨記述するべきですが、どちらにもそんな記述はありません。なので、送信側のユーザーもメーラーもガイドに準拠していれば、上のようなメールが作られる可能性はあります。
それなのに、受信側がこういうメールを受け取ったらどうするかも、開発者ガイドにはまったく書いていません。テスト用ファイルにも URL の途中で改行されている例は出てきません。改行の取り扱いについて何も書いていないので、これで「ガイドを作りました」などと言われても困ってしまいます。そんな簡単に対応できるなら苦労しませんよ。
途中で改行が入るような状況でも URL を認識できるようにすることが、 RFC 3986 付録 C で URI をアングルブラケットで囲もうと言っている理由の一つなのに、それに言及せずに「小規模の機能追加で可能と考えられる」って、何を言っているのでしょうか。本当にこのガイドを書いた人は RFC 3986 付録 C を読んだのでしょうか。
なお、 RFC 3986 付録 C には URI をアングルブラケット (または二重引用符) で囲むという提案と、そこで配慮してほしいことが書かれていますが、実際にどうやってテキストの中から URI を抜き出すかについては言及していません。なので、これだけでは実装できる仕様にはなっていません。実装するとしたらどう実装するかは開発者の腕にかかっています。それが悪いことだとは思わないのですが、「あとはうまいことやってください」という一言があるとないとでは気分が違います。その点、 RFC 3986 付録 C もいい加減だと思いますが、これは URI についていろいろ定めた文書の付録ですから、仕方ないかと思います。
それに対して、 JPRS 文書はまさにこの RFC 3986 付録 C で扱っている内容を日本語ドメイン名にも適用しようという提案です。その中で RFC 3986 付録 C を参照しておいて、そこで提示されている問題点に何の解決も示さず、ただ「使ってください / 対応してください」では、やっぱり……困ってしまいます。
具体例を挙げます。メーラー開発者が、「<http:」の後、改行を無視して URL らしき文字列が出てきて最後に「>」が出てきたらハイパーリンクにする、と決めたとしましょう。このとき、次のような事態が生じます。
> > 七草粥も食べずに正月が終わっていった…… orz > お疲れ様です。大変そうですね。写真だけでもどうぞ (余計につらい?)。 <http://味 見たら余計に悲しくなってきた。そもそも1月納品ってのが間違っていると思う > ……
「<http://味」の部分から始まって、改行を無視して読んでいくと、ずっと日本語ドメイン名に使える文字が並んでいます (句点は区切り文字として使えます)。それで「>」が出てきます。でも、これをハイパーリンクにしてほしいと思う人はいないでしょう。つまり、単純にやっていては駄目で、いろいろ考えることがあるのです。
開発者ガイドからは、このような問題への対処法はおろか、いろいろ考えなければならないことがあるという点すら書かれていません。これは非常に不誠実な態度だと思います。
開発者ガイドに一言も出てこない、 URL がアングルブラケットや二重引用符で囲まれていない場合が、テスト用ファイルに突然出てきて、じつはそちらの方がテスト用ファイルの大部分を占めています。どういう場合にどうするといいかについて、 informative でいいから提案するのがガイドの役割でしょうに。要求するのは JPRS の仕事で、頭を使うのは開発者の仕事ということでしょうか。それならそうでもよくて、ただガイドの中に「このガイドで定める形式に厳密には従っていない場合にも対応できるとよいと考えられる。しかし、このガイドではどのような場合にハイパーリンクとするかについて具体的には述べず、テスト用ファイルの中で例を示すにとどめる」のように「このガイドだけでは不十分なのは承知している」ということを表す文章がないのは、非常に不自然です。
開発者としては二度手間は嫌なので、ちゃんと国際化ドメイン名 (IDN) に一般に対応できて、それが日本語ドメイン名への対応も自動的に含んでいてくれると一番嬉しいのだと思います。そのような考察なく「日本語ドメイン名に対応しましょう」と言うのは自由ですが、愚かです。いまだに「国際化」ではなく「日本語対応」しか考えていない姿勢に落胆します。 JPRS の人に国際化なんて考えは毛頭なくて、メーラーには .JP だけサポートしてもらえればあとはどうでもいいのでしょうか。これも、「日本語以外を含む一般の国際化ドメイン名の統一的な扱いは俺たちには難しすぎて今すぐにはガイドを作れないのでこの文書では扱わないが、うまいこと扱える仕組みができるといいよねー」という意味の一言 (もう少し格調高く書いてくれた方がいいけど) があれば、こんなに怒らないのですが……自分たちがやっていることが技術的に不完全で不徹底なことだということを、わかっていないなら無能だし、わかっていて言わないなら不誠実です。
もう何をか言わんや。 JPRS は日本語ドメイン名にだけ興味があって、日本語のファイル名には興味はないのでしょうね。
JPRS はメーラーの開発者に対して、「日本語ドメイン名をサポートしてください。ほらこんなに簡単で便利です」と言いたいようです。本当は、難しい部分があって、その部分についてガイドは何の参考にもならないから、実現しようと思ったら技術者は難しい部分を自分で解決しなければならないのに、その労力に対する配慮も何も見せず、簡単な部分だけを見せて簡単であるかのように主張しています。でも、本当に簡単に実装できて便利で何も問題もないのだったら、「簡単だ」なんていちいち言われなくたって実装するに決まっています。技術者は馬鹿だから実装しないのではありません。実装するのはじつは簡単ではないから、さっと実装してしまって終わりというわけにいかないのです。なのに、 JPRS は自分たちが味方に付けたいはずの技術者をあえて貶めるようなことをしています。
上に挙げたような問題点は、「URL の line break には微妙な問題がある」とか「国際ドメイン名・IRI への対応は案外単純ではない」とかいう常識を知っている人ならガイドを読んで一瞬で気付くことです。メーラーを書くようなソフトウェア技術者なら当然のこと、ちゃんと勉強したことがない僕でも、雑談で得た次のような知識から、上のような問題点を見つけることはできました。
本当に日本語ドメイン名を普及させるつもりがあって、メーラーでの対応が重要だと思うなら、 JPRS はメーラー開発者が日本語ドメイン名 URL をハイパーリンクにしようとするとどのような困難があるかを考察して、それに対するある程度の解答を提案するべきです。「日本語ドメイン名をサポートしてください」と言っただけでみんなが従うほど、世の中甘くないと思います。
個人的には、国際化ドメイン名はうまくいけば世の中を少し便利にしてくれると思います。だから、国際化ドメイン名には期待しています。当サイトだって「http://フルーツチョコレートパフェ.jp/」で到達できたらわかりやすいかもしれないと思うことはあります。ただ、国際化ドメイン名をうまく運用するための議論が足りません。また、僕は JP ドメインの DNS の管理体制をよく理解していませんが、汎用 JP ドメイン名がうまく機能しているのはたぶん JPRS の技術力のおかげなのだろうと思っています。だとすれば、 JPRS の技術力についても不満はありません。ただ、 JPRS の広報と技術者が連携していないように見えるのが大変残念です。
本文中では Outlook Express 6 しかテストしませんでしたが、他のメーラーの状況も調べてみました。
残念ながら日本語ドメイン名 URL の途中で改行が入った場合にはどちらも正しく認識してくれなかったのですが、 1 行で書けば認識してくれるというのは意外でした。新しいメーラーでは、 1 行に日本語ドメイン名 URL が書かれているという最も単純な場合に関して言えば、対応状況は案外良いのかもしれません。 Outlook Express 6 は 2001 年 8 月リリースで (その後セキュリティ関連で機能向上を図った OE 6 SP2 は出ていますが)、 5 年以上も前のソフトですから対応していなくても仕方がないとして、他のローカルなメーラーやウェブメールサービスの状況も気になります。少なくとも JPRS のテスト用ファイルの必須扱いのテストケースが通るメーラーのリストは後日公開されるようなので、楽しみです。
「日本語ドメイン名の普及促進を目的とし、関連する包括的な活動を推進する組織」である日本語ドメイン名協会 (JDNA) なんてあったんですね。だとするとメーラーの日本語ドメイン名への対応を促すというのはまさに JDNA の領域だと思うのですが、この件では名前が出てきません。いったいどういう活動をしているのでしょう。日本語.jp を運営しているのも JPRS ですし。
2007 年 1 月 7 日公開、 2007 年 1 月 14 日付録 A・B を追加。著者: fcp / このサイトについて