 
|
はてなキーワード: RFCとは
そんな風潮自体が、一般市民がインターネットに流れ込んできた結果なんだよ。
WAREZとかCRACKとかPTHCとか細々とやって所を、ネタになるからといって煽りまくったのはそっちだろうが。
マジコンなんて、バッ活の最後のページで本当にこれ売れてんの？って代物だった。
むしろ、X-TerminatorとかPCにメモリダンプできる奴の方が売れてたし。
パソファミとか、自分で基盤作って吸い出したりとかだったしな。
勝手に入り込んできて拡散して、この風潮にそろそろ嫌気がさしてきたので法的規制します？
勝手にやってろ。
すでに、海外に開発・製造拠点が移っている以上、国内のサイト規制した所で何もかわんねーよ。
[追記]
当たり前だ。
そこから生じる被害があるなら、各国の法律がインターネットの外で対処するべきだったんだよ。
おいすー。クソコテ起きてきたよ。
* インターネットには、そういうアクセス方法を規定したルールは無いのですか？
インターネットに関する技術の標準を定める団体であるIETFが正式に発行するRFCと呼ばれる文書があります。
ただし、これには罰則規定があるわけでもなく、守らなければならないというものでもありません。
これそのまんま採用で。さんきう。
* Librahack氏のクローラーは、そのRFCというルールは守っていたのですか？
ソース公開されてないけど分析結果は教えてもらったのでその内容で書くよ！
ルール違反はなかった，ってことでした。もっと突っ込めば「トラブったのはサーバ側が原因と考えるのが妥当」みたいな結果でした。昨日貼った http://www26.atwiki.jp/librahack/pages/24.html#id_632dd0a1 あたり見てもらえれば衝撃の新事実って感じです。
つことで情報さんきうです。
でも，いつもココ見てるとは限らないのでできたらメールかなんかで頼むｗｗ
俺の友人（Aと呼ぶことにする）のブログにちょっとした愚痴が書いてあったんで、それに気軽な気持ちでコメントしたのだが、
「分かってないやつが何を言っているのか」という趣旨のレスをメールにて受けてしまった。
そのメール、あまりにオブラートに包んでいない文面のため「えええーー？？」と我が家の杉山のような状況。
こっちにしてみれば
・ブログの読み手が書き手の感情を理解してると思われても困っちゃう
・あまりにも感情的なメールはちょっと。。。（RFCのネチケットガイドラン読んでよ）
なのです。
深く考えずにコメントした俺も確かに悪いけど、もうちょい「ネチケット」を知って下さい。お願いします。
ほかの場面でAはトラブルを起こしてしまうんじゃないか？と余計な心配をしてしまう。
追記：2009-09-25 22:48
ブくまが付いてびびっております。みなさんありがとうございます。
俺は深く考えもせずにコメントをつけるところがあり、
今までトラブルになったことは記憶の限りではなかったけど今回のことで
これは氷山の一角なのか？と、オンラインコミュニケーションに対してかなり臆病になりました。
なんかスゲー話題になってるみたいなので、一応サポートで飯を食ってる人間として（上の例で言えば、オペレーターが相談してる上司か社員にあたる立場になる）一枚噛んでみる。
未熟なサポートと困ったユーザーはどうしたって無くならない訳で。サポート屋としては、実は元記事のような客はそんなに困らない。
対応の巧拙はあっても結局は同じ結果になったはずだし、後日素直にリセット処理にも応じてる。「気が動転してました」と自分の非についてもある程度反省しているようだし。（ただ、散々ごねた上に「法務を出せ」とまで言い、ブログでdisった挙句に勘違いでした…･･･って逆に訴えられても仕方ないレベルじゃないか？）
一番厄介なのが、ブコメに見られる中途半端に知識をかじったワナビーども。
コイツラは何かと言うとゴチャゴチャ話をややこしくする。初期化すれば済むだけの話を「そもそもIMAPとは（キリッ）」なんて言い出すから始末に終えない。いいから初期化しろよ！そうすりゃ直るんだから！
さて、まずは元記事の症状からざっくりと問題を判別してみよう。
8/31 22:00過ぎから、i.softbank.jpへの接続ができなくなりました。エラーメッセージは「ユーザ名またはパスワードが正しくありません」なのですが、IMAPアクセスしているiPhone側もPC側もユーザ名もパスワードも変更していないので、急にこの挙動になってしまったのが理解できませんでした。
アカウント情報を削除して登録しなおしてみたり、MySoftbankでメールアドレスやパスワードを変更してみても症状は全く変わりませんでした。その後、自分のi.softbank.jpにメールを送ってみると、
550 Invalid recipient:
でメールが戻ってきていることが判明しました。受取先が無効ですエラーってことは、アドレスが存在していない扱いになってしまっています。しかし、MySoftbankにはログインできていることから、
iPhoneの端末側の問題ではなく、IMAPサーバ側の問題である
という見解に至りました。
じぶんの経験で言えば、ユーザー側でここまで切り分けてくれた時点で御の字であるｗ有償サポートでも、いや、だからこそか、ここまでやってくれる人はいない。
"MySoftbank"のアカウントとメールのアカウントが同一であるかは分からないが、IMAPサーバ「側」の問題（iPhone本体ではない、という意味）であることは確かだ。
ところで、"550 Invalid recipient:"のエラーはIMAPではなくSMTPのエラーである。
これが、例えばSMTPは問題ない、つまり「送信できるけど受信できない」状態であればIMAPサーバーが悪いと言える。
しかし「送信できない」となると、IMAPは全く関係がない。
理由については「IMAP」でぐぐると最初のページに出てくる記事だがこのページ辺りを参考にして欲しい。
あと、設定方法をぐぐってみると、
IMAPサーバーとSMTPサーバーは別になってるようなので、「IMAPサーバー」の問題ではないことも容易に分かる。
つまりどういうことかというと、メールアカウント自体が消えてしまっているか、ロックされているか、見えなくなっているかということ。
加えて言えばSMTPサーバーも被害者の可能性があり、アカウントを管理しているLDAPサーバーのようなものが原因だった可能性のほうが高い。
したがって
iPhoneの設定確認やリセット処理など一通り試てもらった後、iPhoneを復元してみますとのこと。復元後メール設定をしてみると、なぜかメール受信ができるようになってました。
とアカウントをリセットするのはマニュアルどおりのテキトーな処置ではなく、むしろ論理的な問題判別に基づいたアクションといえる。「なぜか」じゃねーよｗ
関連記事を見ると、同じ症状の方もいるようだ。
あと「IMAPならPCでもiPhoneでもできるはず」っていう意見に対する反論はこの辺の記事が参考になる。
ここまで分かれば、ブコメのIMAP厨（笑）がいかに見当違いなことを言ってるかが分かると思う。
「IMAP」という言葉に過剰反応して問題が見えなくなってる。
覚えたての言葉を使いたがる子供ですか？IMAP言いたいだけちゃうんかと。
最後にブクマのバカなコメントに突っ込んでおこう。こういう輩を放っておくと、第二第三の被害者が出かねないからな！サポート的な意味で！
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/iwa/20090904/1252016930
「良く分からん」のに「鯖側ちょいと直せば済む」と言い切るエスパーぶり！具体的にどこをどう「直せば」いいんですか？
「メールプロトコルの話」ではないでしょ、プロトコル以前のサーバー側の問題なんだからｗ知ったか乙ｗｗｗ
b:id:mnemo プロトコルの問題なのに PC という語に過剰反応する、このサポートレベルのぶこめが多くてびっくり。
プロトコル以前の問題なのに IMAP という語に過剰反応する、このサポートレベル以下のぶこめにびっくりｗｗｗ
b:id:noraora サポート外もなにも、IMAPなんだから今まで正常だった機能が使えないってことはPC、iPhone関係なしにIMAPサーバ側の問題だろ
IMAP（キリッ）だっておｗｗｗ
b:id:sy0ta PCでアクセスするのはおかしいとかコメントしてる人は頭おかしいの？PCからIMAPでアクセスしておかしくなるってことは、それはIMAPじゃないってことだろ。できて当たり前のことをサポート外と言い切る姿勢がおかしい。
日本語でおｋ。どこにIMAPをフルスペックでサポートする、なんて書いてあるんですかｗｗｗそもそもIMAPが悪いなんて誰も言ってねーしｗｗｗ
b:id:hirok73 わかんないので詳しい人教えてください：iPhoneでしか読めない（特定のMUAでしか読めない）状態でIMAP対応と名乗るのはありなの？
どこの公式情報に「IMAP対応」なんて書いてある？あとRFCをフルスペックでサポートしてないMUA、MTAなんていくらでもあるよｗ代表的なのがoutlook様だｗ
もちろんブコメもバカな意見ばっかりじゃなくて、まともな意見もある。
b:id:maakunh iPhoneのアカウント設定が壊れていたのかな？壊れた状態で何度もアクセスすることで、サーバ側で不正アクセスと判断され、アカウントロックされたとか・・・
b:id:z0rac ん？それIMAPの問題じゃなくメールボックスがアクセス不能になってる。/つうかアカウント消えてね？
サポートの立場としては、「こういうことが起こってる可能性が高い」と説明し、コンセンサスを取った後初期化処理を行うべきだった。その点では、お互い不幸な事件ではあったのだ。
うん。「Expires」は日付。百歩譲って、RFCに「0の場合は特別扱いしろ」とかいてあるので0はありだと思うが、「-1」は論外。
つぎに「JSESSIONID」のSet-Cookie。ルートディレクトリのコンテンツに対する要求なのに「Path=/cs」がついてる。ありえん。っていうか他のページも行くたんびに同じSet-Cookieがでてる。ぱっと探してみたところ「/cs」のパスを持つコンテンツはないので、なんかの設定ミスだろうな。
「SS_X_JSESSIONID」のSet-Cookieは見ての通り。
あとはcharsetのWindows-31J。IANA的には全く問題ないんだが、MSIEがこれを認識できないバグを持っているので、Shift_JISを使うのが常道。一部のサーバーソフトがShift_JISだと問題を起こすんでWindows-31Jにしてるんだろうけど、この問題を回避する方法は有名。知らないのはモグリ。
あと、「サーバーが超混雑しててつながりにくくてしょうがない」という状況で、KeepaliveのTimeoutがデフォルトの15秒のままってのもなー。3～5秒でいいよ。
こんなところかな。異論は認める。
追記
確かに、写真部Flickrたんは忘れていたけど、キャラ付けが思いつかないね。six apartとwordpressは迷ったけど、どっちでもいいかな、と。EITFものど元まででかかったけど、思い出せなくてRFCにした。それ以上は、きつくなるだけなので、ここまでで。
それにしても、マジでみんな列挙型ネタ、好き過ぎ。こういうネタやったらウケるだろうなぁ、と思ったらほぼそのまんまはてブに反映されててワロタ。「○○するための××をN個」なんてすぐにはてブホットエントリ入りするし。例えば、ネタ系列でも、同じような事をプログラミング言語とかでやってみたら、またすぐにエントリ入りするだろうね。戦国時代な数の多いジャンルでやると、すぐにウケると思うよ。
私立T女子学園は、正にその通り(個人的にあずまんがよりもT女だったので)。ああいうギャグ群像劇がモデル。
Google信者なので、世界征服ネタは思いつかなかったけど、普段は良い顔しているけど、自分に批判的な言動には「な・ん・だ・っ・て?」みたいに目を光らせてみるというのも良いかも。あとは、Googleモテネタとか。
とか、そんな感じ。
ちなみに、この手のマンガを考えるときに、超大金持ちを混ぜておくというのは、話を膨らませるための一種の王道。こち亀の中川とか、うる星やつらの面堂終太郎とか、そういうの。御坊っ茶魔くんとか、有閑倶楽部なんて、それだけをネタにしたような作品だし。ここで言えば、microsoftがT女の田中小夏みたいな立場。例えば、
とか、そんな感じ。富豪刑事とか、デスノートのL絡みも似たようなもんでしょう。同じようなシチュエーションは、発明家でも使えるので、そちらで考えてみても面白いです。上記で言えば、
とか、そんな感じ。ネタ振りがYouTubeで、たしなめるのがGoogleかな。話の切っ掛けは、性格の幼いキャラにして、その後、やや大人なキャラが突っ込み入れて、その後、別の展開と言うのがセオリー。Twitterとか、YouTubeがそういう先陣を切るキャラでしょう。
あとは、三段論法を壊すというオチもこの手のギャグでありがち。ここで言えば、TechCrunchが、矛盾する情報に悩んであさっての方向で結論を出したりとか、Wikipediaが、あまりの情報の多さに、却ってとんちんかんなことを言い出したり。ちょっとひねらないと面白くないけどね。
というわけで、皆さん、楽しんでいただけだでしょうか。ネタが当たって、僕は楽しかったです。
長くて……読む気にならん。
それはどうかと思うよ。長いのは丁寧に書いているからだし、これまでの経緯をまとめているからだし、複雑な問題だし、そういう単純化が問題を複雑にしているし。
とかいいつつ、単純化しちゃう。
立法による強いネット規制をかわすため、悪質なIDをアク禁できるようにすることは、たとえプライバシー上の問題が生ずるとしても、やむを得ない選択だった。
IDを使用してサイト閲覧履歴を分析した広告が始まった。ヤミ金融業者や、悪質リフォーム業者、架空請求詐欺団なども、カモIDリストを活用するだろう。注意が必要である。
この調子で進むと、「PCもケータイ同様にIDの送信を義務づける」という法案が浮上するかもしれない。
RFC 3041、DoubleClick社の集団訴訟、WMPスーパーcookie脆弱性、Intel PSN不買運動など、ID送信の何が問題か、いつでもすぐに30秒で説明できるよう、構えておかないと、日本だけインターネットの世界を変えられてしまうかもしれない。
私たちは、ちゃんとくい止めることができるだろうか。
au以外は、公式サイト以外には送信されない様に対策を講じていた。
それが、ナンバーポータビリティの延長として、IDもポータブルにする（携帯電話会社を変更しても、IDがそのまま使えるようにする）ということを総務省が提言し、その時点では、IDの統一化は長期的な話であり、それまでに公式サイト以外には送信されない様に対策をしてもらえばいいと思っていた。
それが、突如、NTTドコモがIDを全サイトに送信すると決定した。
イー・モバイル「EMnet」もIDを送信するようになっていた。どうやら、IDの全サイトへの送信というのが、「日本のケータイWeb」の「標準仕様」となったようだ。
なぜこのような展開になったのか。強制されそうな未成年者向けの携帯フィルタリングの対象から明示的に外してもらえるように、「健全コミュニティサイト」というものを認定して、監視制度などを判断するISOやプライバシーマークと似た仕組み、悪質ユーザーのブラックリストの導入などの計画のためだ。
青少年に限って、匿名性のないコミュニティサイトにしかアクセスできないようにするというのは、良い落しどころではないかと思う。
最近になってIDの送信を始めた各事業者は変更するハードルを高くしている。
国会議員らによって性急にもたらされた極めて強い青少年ネット規制をかわすため、悪質ユーザを排斥するために今すぐにでも実現できる、IDを全サイトに送信することは、はたとえプライバシー上の問題が生ずるとしても、やむを得ない選択だった。
NTTドコモでは広告各社がサイト閲覧履歴を分析し利用者の特性に応じた広告提供を始めた。ヤミ金融業者や、悪質リフォーム業者、架空請求詐欺団なども、弱者を求めてカモリストを欲しがっており、そうした業者にも活用されるだろう。
この調子で進むと、最悪のシナリオが訪れるおそれがある。国会で審議された青少年ネット規制法案では、パソコンメーカーには、フィルタリングソフトの組み込みを義務づけていた。この調子で、何年か後には、「PCもケータイWeb同様にIDの送信を義務づける」という法案が浮上するかもしれない。
「PCもケータイ同様に!」という勢力に対して、ID送信の何が問題で、どうしてインターネットではそれをやってはいけないのか、いつでもすぐに30秒で説明できるよう、構えておかないといけない。
「銀行の口座だって名寄せされているんですよ。複数の口座を持っていても住所氏名で名寄せして1人の情報として役所に報告しているんです。」重要なのは、IDがどのように使われ得るかの個別の検討であって、IDが付くことではない。WebのID送信の話をしているのに、銀行口座の名寄せの話など何の関係もない。
「IPv6だって、MACアドレスを含むIPアドレスが一人一人に付き、アクセス先に通知されるようになるんです」1999年に批判が巻き起こり、RFC 3041という解決策が作られて、そうはなっていない。
「cookieと同じでしょ」その認識も技術的に明らかな誤りである。DoubleClick社の集団訴訟、WMPスーパーcookie脆弱性。
アーキテクチャ設計を今のうちにやっておかないと、問題が顕在化してからでは遅い。青少年ネット規制の機運が再び性急に浮上し、「これから設計して構築します」などという意見が通らない情勢になってしまうかもしれない。
90年代末にインターネットを舞台に言われていたような構想が、再び語られている。Intel社がPentium IIIにプロセッサシリアル番号（PSN）を搭載して「電子商取引に活用してください」と提案したのが、消費者団体の反対運動を招き、Pentiumの不買運動にまで発展したのは1999年のことだった。日本のケータイWebが今やっていることは、まさにIntelがPCの世界でやろうとして猛反発を食らったことである。
日本の消費者は欧米と違って反対運動をしない。嫌なことは嫌だとちゃんと普段から声をあげるようにしていないと、ある日突然、議員立法で日本だけインターネットの世界を変えられてしまうかもしれない。
私たちは、ちゃんとくい止めることができるだろうか。
具体的なことは http://takagi-hiromitsu.jp/diary/20080710.html#p01 で。
学生 「はい。人生のクオリティです。例えばアカウント名を悩まずに付けることが出来ます」
面接官「…で、そのライフハックは当社において働くうえで何のメリットがあるとお考えですか？」
学生 「はい。USBメモリを安心して取り出せます」
面接官「いや、当社にUSBメモリは持ち込み禁止ですから。あなたにではなく、当社にどういうメリットがあるのかと…」
学生 「ヒザの上でノートPCを快適に使いながら、メール送信サーバを設置出来ます」
学生 「Internet Explorerの同時ダウンロード数も増やせます」
面接官「ふざけないでください。RFC違反ですよ。だいたい…」
学生 「『接続するサーバ側の負荷にも配慮し、問題ない場合に限って使うのがよいだろう』」
学生 「あれあれ？怒らせていいんですか？使いますよ。ライフハック」
面接官「いいですよ。使って下さい。ライフハックとやらを。それで満足したら帰って下さい」
面接官「帰れよ」
Internet Explorer 7の同時ダウンロード数を増やす ?? ITmedia ＋D
http://plusd.itmedia.co.jp/pcuser/articles/0711/07/news072.html
接続数の制限は低速ネット時代のもの、という意見は否めない。だけど現在はニコ動、YouTube、その他画像サイトなど大容量ファイルを普通にやりとりする。一昔前ならぶち切れられてもおかしくないメガバイト単位のファイルをメールに添付してくるやつも増えた。そういう時代に接続数を増やすというのはどう考えても賢明ではない、やめるべきだと思う。
と、これだけならRFC遵守派と何も変わらない意見だと思うが、仕事で使うPCで、上記のような大容量ファイルをやりとりしないという前提であれば、接続数を増やすのはかまわないと思う。しかしながらそういう点ははっきりしっかり明記すべき。
http://anond.hatelabo.jp/20071017174143
何を以って原理とするかといえば、日本国憲法やRFCの文書群などであるわけで。それらは生半可な議論や支持だけで成立しているわけじゃないし。ただもちろんこれらに異議を唱える自由だってあるが、やはり無断リンク禁止派の主張は社会的にまずいというのが私の現在の結論だ。
というかURLって現実で無理やり比喩させるなら電話番号じゃなくて出版物の出版コードだし。
雑誌が無理やり紹介するだけでは、少なくとも刑事には問われないはずでは。民事には問われるかもしれないけど、よっぽどの場合でなければ賠償とかならんと思うんだが。というかすぐさま言及自体が罪に問われかねないなんて社会、恐ろしすぎる。
っていうかちょっと時間がないので他にもあるけど略
ごめん。馬鹿の思いつきだけど。
なんでもそうだけど、ルールはある程度シンプルじゃないとわけがわからなくなる。
形態の料金プランとかそうだし、マージャンのへんなルールとか、あとRFCとか。
新しいルールがどんどん作られてばっかり。法案法案って法律つくってばかりで減らないでしょ。めったに減らない。
立法府のほかに消法府もつくって、無駄な法律が統廃合していく必要があるんじゃない？
ルールが複雑すぎるから法の抜け道が出来て、不公平冠がつのるじゃない。
あとさ、不公平はみんな嫌いなくせに、特別扱いされるのはみんな好きでしょ、基本的に。
だから、自分に有利な法律を作っちゃう。この場合はこれを免除、あの場合はあれを免除、みたいなお得な割引プランみたいな法律があるから、一方で不公平感を感じる人がいるんだよ。
そして、法律をしらべまくってズルしようと頭をこらした人が、特典をうけとりまくる。つまり法の抜け抜け穴をついてボロモウケ。
日本の法律を全部把握できてる人なんて、もう居ないでしょう。弁護士だって守備範囲から漏れてる部分いっぱいあるんでしょ。
みんなが守れるシンプルでわかりやすいルールにしないとダメだ。
ちょっと、無駄でいらない法律をみんなで洗い出せるシステムが必要だな。現状有効な日本の法律全部が一覧できるサイトってないの？
まずは RFC 1738 - Uniform Resource Locators (URL) （日本語訳）を参考にして、記号文字のURLエンコードがどのようにあるべきかを確認します。
いくらなんでもRFC 1738はないでしょ。RFC 2396 Uniform Resource Identifiers (URI): Generic Syntaxが出たのが1998年の8月だよ。最新のRFC 3986 Uniform Resource Identifier (URI): Generic Syntaxですら2005年1月、つまり2年以上前に出てるんだよ。
・・・といちゃもんつけようかと思ったけど、ECMAScript 3が1999年12月だからRFC 3986は参照できないね。さらにECMAScript 1にいたっては1997年6月だから、どうあがいてもRFC 1738しか参照できないわけだ。そのへんECMAScriptの仕様書にもちらっと書いてあるね。そこらをみんな考慮に入れて誰か改良版を作ってくれないかな、というだけいってみるテスト。
で、結局resはどんな意味なのだろう。
ジのトピックを識別する短い文字列を持つ。返信で使われると、そのフィール
ドボディは「Re:」（ラテン語の「res」、「??について」から）で始まるかも
しれない(MAY)。もしこれがなされるなら、他の文字列や１つより多くの使用
は好ましくない結果をもたらすので、文字列「Re:」はたった１つだけ、使わ
れるべきである。
responseの時に何のメールだかわからなくなるから、Reつけて示せと？
Re:I Love you!
が、
ということか。
response aboutが省略されて、Reになってるんだから、
re-ply ,re-sponseのreでもいいとおもっちゃうゆるゆる派。
日本語の場合は
Subject:先輩好きです!
の返信には
Subject:件:先輩好きです!
みたいに書けってことでしょ？
Subject:件:件:件:先輩好きです!
とか連続でつけるんじゃねぇ！ってことでしょ？(つけるメーラーあるよね・・・)
Subject:件[3]：先輩好きです!
でもRFC的には[3]これについても記述はないっぽ。使っていいのはRe :だけとかさみしすよ。
ところてん、Keywords:って使われてる？にゅるーん。
見たことないきがする。初めて知ったよ。にゅるーん。
あと、CRLFって守られてる？LFで吐くヤツ多くない？にゅるーん。
とりあえず、からしすみそさんばいずでいただきます。ちゅるん。
メールの件名の頭に付く「Re:」は Response の略じゃないよ！
わかりやすい説明の例
http://www.wdic.org/w/WDIC/re（re - 通信用語の基礎知識）
ラテン語の名詞res(レース)「こと・もの」の奪格re(レー)から英語の前置詞に転じた。なお、ラテン語では名詞の一変化であって前置詞ではない。
例えば、メールの返答の件名(Re:〜)や、掲示板のレスポンスタイトル等に使われる。しかしそもそも省略形ではないので、このRe:はreplyの略でもresponseの略でもない。
RFC ってのは、簡単に言うと「インターネットで使う技術の細かい作りについてちゃんと決めて、みんなでその決まりに従おうね！」というもの。じゃあ RFC 2822 について見てみよう。
http://www.puni.net/~mimori/rfc/rfc2822.txt（Internet Message Format）
The "Subject:" field is the most common and contains a short string identifying the topic of the message. When used in a reply, the field body MAY start with the string "Re: " (from the Latin "res", in the matter of) followed by the contents of the "Subject:" field body of the original message.
「Subject:」フィールドはもっとも一般的で、メッセージのトピックを識別する短い文字列を持つ。返信で使われると、そのフィールドボディは「Re:」（ラテン語の「res」、「??について」から）で始まるかもしれない(MAY)。
きちんとメールに関する標準規格文書に明記されているんだよ！
これら二つの記事をまとめると、「Subject: フィールド（件名欄）にはラテン語の res （レース）が変化した re （レー）を使う場合もある」ってことになる。繰り返すけど reply や response は関係ないから注意してね！
さて、それじゃあ次に他の辞書ではどうなってるか見てみようね！
http://dictionary.goo.ne.jp/search.php?MT=re&kind=ej&mode=0&base=1&row=4（Re: - goo 辞書）
Re:
goo 辞書さんが出す情報（EXCEED 英和辞典の内容）まちがってるよ！ これってどこにメール送ったらいいのかな。三省堂に電話しなきゃだめ？
訂正しないと RFC 2822 でちゃんと明記したひとがかわいそうだよ。だって「メールの頭についてる Re: はラテン語からきてるんだからね！」って言ってるのに「英語の reply だよーんあばばばば」なんて言われたら、「最初にラテン語だっていったのに……」って悲しくなっちゃうよ。ひどいよ。
辞書は言葉に対する一般的な認識を列挙するものだってことはわかってるよ。言葉が変化するものだということもわかってる。俗説を書くなとも言わない。でもね、Re: の場合は最初にきちんとした定義があったんだよ。俗説は俗説なのであって、定義を超えることはできない。
たとえば円周率は 3.14 って学校で習うけど、これは小学生に記号を使った計算は難しいので、円周率に関する計算では記号を使わずに 3.14 ということにするってだけの話で、別に円周率が 3.14 になったわけじゃない。円周率はπなんだよ。同じように、Re: が reply や response の略称であるという誤った俗説がいくら広まったところで、Re: は ラテン語からきてて、その事実は全く変わらない！
俗説を書くなとは言わない。だけど俗説は俗説だと明記しないとだめだよ。本来の意味とは全く無関係なんだから。この三省堂 EXCEED 英和辞典の内容は、俗説が本来の意味であるかのようにしか読めないよ。
勘違いすることはわるいことだと思わない。科学技術者だって誤用ぐらい平気でやる。でも科学技術における、言葉に対する一般認識と正しい意味の差が理解できない人は、科学技術の用語について述べるべきではないよね！ 少なくとも指摘を受けたら訂正するべきだよ。
というわけなんだけど、三省堂 EXCEED 英和辞典の件はどこに連絡すればいいのかな。
http://dictionary.sanseido-publ.co.jp/support/question.html（辞典に関するお問い合わせ - 三省堂書店）
ここでいいのかな。ちょっとメール送ってくるね！
次はアルクだよ！
RE
正しかったので問題ないです！ でも、〈ラテン語〉って書いてあるせいで、なんかラテン語の前置詞みたいに見えるね。最初の「re - 通信用語の基礎知識」にも書いてあったように、ラテン語の前置詞じゃなくて英語の前置詞だよ。まあこれはアルクの表記スタイルを把握できていない僕がわるいんだけどね！
サービス提供元に「RFC違反だ糞 直せ糞」ってゴネたところで
誰一人特をしない問題だと思うんですが
なんで誰一人得をしないの？
論理が繋がっていないじゃん。
http://anond.hatelabo.jp/20070413135718
RFC的には正しくないけど
サービス提供元に「RFC違反だ糞 直せ糞」ってゴネたところで
誰一人特をしない問題だと思うんですが
ここの住人の皆様は静観 or モヒカン？
そうこうしてるうちに今週のぶんが届いちゃった
ISO-2022-JP を名乗っているならRFC的にアウト。
ISO-2022-JP にいわゆる半角カタカナは定義されていないから。