「電子メールアドレスで「@」を使用することを考案したレイ・トムリンソン氏、死去」記事へのコメント

アドレス表記いろいろ

[numa (4467)]

そういえば、昔は@の他にもいろいろありましたね。書き方が同じでも意味が違ったり。

• host1!host2!host3!user (UUCP方式)
• user at host (@の代わりにat)
• user%domain2@domain1 (転送ルート指定付ドメイン方式その1)
• @domain1,domain2:user@domain3 (転送ルート指定付ドメイン方式その2)
• [e-mail] (トップドメインがネットワーク名)

この間をメールアドレスを書き換えながらルーティングするので、途中で書き

Re:アドレス表記いろいろ

[numa (4467)]

メールの中身についても、いろいろ問題があって、

• 転送途中で各バイトの最上位ビットが落とされるので、わざわざ面倒くさいISO-2022-JPを使ったり。
• 送り先で文字エンコーディングが違って文字化けしたり。（これは、なんと今でもある！）
• 転送速度が遅くて中継ホストの負担も高いので、メールサイズを64KB程度に制限したり。
• テキストメールの一行の長さを制限したり。
• 添付ファイルが送れないのでいろいろ工夫したり。

楽しい世界でした。その頃の慣習が今でも一部に残っていて、わけもわからず続けていたりする。いい加減やめたらいいのにねえ。

Re:

[Anonymous Coward]

何をどうやめたらいいのか具体的な提案をどうぞ

Re:アドレス表記いろいろ

[numa (4467)]

具体的な提案ということなので…。

• いまどき8-bit cleanでない処理系を考慮する必要はない。バケツリレーの時代じゃないんだから、中間のどこかのサイトで最上位ビットが落ちたりしない。落としているとしたら、自分か相手のどちらか。
• MIMEサポートを前提とする。発信時にはMIMEに厳密に従ったデータを作り、受信時にはMIMEの指定に厳密に従って解釈する。中途半端にうまいことをしようとするから失敗する。たとえば、文字エンコーディング自動判別とか。
• 文字エンコーディングはUTF-8を必ずサポートする。表示できる必要はないが、解釈はできるようにする。UTF-8をサポートしていないクライアント（ガラケーとか）には、ゲートウェイが変換して渡せばよい。
• その他の文字エンコーディングとしてISO-2022-JP、Shift_JIS、Windows-31Jなどを使うときは、その解釈を厳密にする。ISO-2022-JPやShift_JISには丸付き数字を含めてはいけないし、Windows-31Jには顔文字を含めてはいけない（DoCoMoからSoftBankとかは例外でもいいけど）。CP932など、IANA登録外のエンコーディングは使わない。
• 「機種依存文字を使うな」というスローガンは、そもそも機種依存なのがなにか、一般人に判断できないから無意味である。どうせ、みんな絵文字や外国語文字を使った顔文字など、UTF-8でないと扱えない文字を使うのだから、全部UTF-8で送ればいい。（相手が表示できないといってきたら？　それは、フォントがないからですよ、たぶん。）
• ファイルサイズは、……どうせ、みんなMB単位のデータを添付して送ったりするんでしょ。情報交換当事者間の合意により適切なサイズを決定してください。

こんな感じでどうですか？　基本的に、現在の実装で対応できる範囲のはずです。対応していない実装が1つでもあるから……なんてことを言っていると、いつまでも前に進めません。対応が必要ならゲートウェイで頑張ってください。でなけりゃあきらめてください。