ＭＡＰ(Mail Address Portability)が始まる……のだろうか？
メンテナンス中なので要点のみ。
(開始時はめちゃくちゃでしたけど)なんとなくごり押しで通ってしまったＭＮＰ(Mobile Number Portability)に味をしめたのか、今度はＭＡＰ(Mail Address Portability)を始める計画があるとか。
……市場をめちゃくちゃにかき回すのはまぁどうでも(?)いいとして、ＭＡＰはＭＮＰとは違って「エーテルが同じ(＝声)」というわけではないのだから、メール関連の「違い」をきちんと吸収するための仕掛けを考えた上で行動して欲しいところで。
まずはドメイン名。
普通に考えたら「よそのキャリアに移った後でも、同じドメイン名を使う……というのは無理」というところについて、まっとうな解決法はあるのだろうかという疑問があります。
移った先のキャリアにメールボックスを持って、そこに対して元のキャリアからのメールを転送する……というのは一見まともに見えるものの、転送をする時点で「移った先のメールアドレス」が必要になってしまいます。
また、移った先のメールボックスに「もとの(＝ドメイン名からして異なる)メールアドレスを割り当てる」というのは、ドメイン名がもつ「階層表現」を壊してしまうため、ルーティングミスを起こす原因になるかもしれません(なるのかどうかという詳しいところは解らないのですが……)。
そうすると、現実的な方法はこんな感じになるのかな……と。
- 元のキャリアにメールボックスをおいたままにして、移った先のキャリアの端末からそのメールボックスにアクセスする。
- ＭＡＰを利用したままメールアドレスを変更するために、元のキャリアは移った先のキャリアに対して「メールアドレスを変更するためのサービス」を提供し、これを移った先のキャリアにある文字コンテンツサービスから利用できるようにする。
次に絵文字。
今の状態は「各社各様にテキトーな文字を割り当てて、それを相互変換表でやりとりしている」という状況……将来的にはこれを何とかできるような方向に持って行く必要があると思う。
- ＭＡＰに対応した端末は、ＭＡＰに参加する全キャリアの絵文字を入力できるインターフェースを持つ。
- ただし、実際に使うことができる絵文字は、ケータイに登録した「メールアドレス」からうち決めとし、利用するキャリアには関係なく決定される仕掛けとする。
- ＭＡＰに対応する端末は、絵文字を扱うための内部コードを自由に決めることができる。ただし、送出する絵文字のコードは各キャリアのものに変換してから送出する。
- 開発効率の鈍化防止＆将来的なユニーク絵文字コードを策定するため、内部コードには可能な限り「中間絵文字コード」を作成して用いるべき。
- 中間絵文字コードについては、将来的にUnicodeに対してマッピングできるように、可能な限り重複文字を整理して、かつ無計画な拡張を必要としない程度に「体系だった拡張」を行った上で、利用を開始できるようにする。
- これは、速攻で始めないと間に合わないかも。安岡先生が前に論文を書いていらしたけれど、この点を解消できる企業なり団体なりというのは存在するのだろうか……。
- とはいえ、「重複の整理」というのはかなりややこしくて……同じ絵文字のはずなのに「どう考えも受ける印象が違う！」とかいうのがありそう。実際には
(極端な手抜き絵文字は除去した上で)単純に全部並べてしまうのが一番安全という気も。
- 中間絵文字コードについては、将来的にUnicodeに対してマッピングできるように、可能な限り重複文字を整理して、かつ無計画な拡張を必要としない程度に「体系だった拡張」を行った上で、利用を開始できるようにする。
とりあえず、「絵文字交換問題を根本的に解決することを前提に」ＭＡＰの計画を立てて欲しいですね……これをきっかけにして「他社ケータイとの溝」や「ケータイと他の情報端末との溝」が埋まってくれればよいのですが。
