トップ(最新)

nDiki : RFC

RFC

スポンサード リンク

Related term

2000年11月6日 (月)

計算機の名前を選ぶには…… このエントリーを含むはてなブックマーク

新しくコンピュータを手にいれて Linuxインストールする中で、時間がかかる作業は、

  • ハードディスクのフォーマット
  • ハードディスクのパーティション分割の計画
  • ホスト名の決定

だ。少なくとも私の場合。 結局一旦決めたら変えない事が多いので、やはり最初かなり悩む。 まあ、へなちょこな名前で落ちつく事の方が多いのだが。

そんなときには、ちょっと古いけど RFC1178。 先週他の RFC 調べていた時に日本語訳が目についたのでチェック。

読んでも名前は決められないけれど、少なくとも悪い名前は避けやすくなるだろう。

@ 追記

RFC2100 'The Naming of Hosts' というのもあり。

2001年7月2日追記。 中里 武志氏による邦訳の URLhttp://www.nn.iij4u.or.jp/... から、http://www.goto.info.kanagawa-u.ac.jp/... に変更。


[ 命名規則 ]

スポンサード リンク


[ 11月6日全て ]

2001年11月26日 (月)

14:00 FQDNFQHNRFC このエントリーを含むはてなブックマーク

FQDN (Fully Qualified Domain Name) は有名だよね。 RFC1594 かな(後継の RFC2664 には載っていない)。

FQHN (Fully Qualified Host Name) は? Cookie の話の RFC2109 で定義しているけど後継の RFC2965 では消えている。 後は RFC1153 でちょっと使っているぐらい。 FQHN はマイナーなり。

@ ドメイン名関連は

RFC1035, RFC1123 あたり。

@ FQDN……

短縮形で RFC検索するとあまりひっかからないけど、省略しない形だとそれなりに載っているようだ。


[ 11月26日全て ]

2004年1月25日 (日)

[ WiKicker ] 通知メールの Subject: フィールドのエンコーディング修正 このエントリーを含むはてなブックマーク

WiKicker には通知メールの Subject: フィールドがたまに壊れている問題があるのだが、ずっと放置しておいたままだった。 そろそろ次のバージョンをリリースしたいと思うので、今回修正しておく。

結果半日かかってしまった。

@ MIME::Words::encode_mimewords

まず現在エンコーディングに使っている MIME::Words::encode_mimewords (5.404)であるが、マニュアルを見ると charset によってはマズいエンコーディングを吐くらしい。 WiKicker で Subject: ヘッダが壊れるのも、この問題のせい。 文字境界を無視してぶったぎってエンコードされてしまう。 ということで、自前でエンコードする事にする。

@ 自前エンコーダ

まぁたいしたものではないが。 最初はエンコードする必要のある部分だけ encoded-word にする事も考えたのだが、面倒なのでやめ。 全部エンコードしてしまう事にする。 エンコーディングも最初は、"Q" encoding で実装しはじめたのだが(MIME::Words のデフォルトがそうなので、WiKicker でもそれを使っていた)ちょっと面倒なので、"B" encoding に変更。

@ タイトルの途中に空白が入ってしまう?

で、テスト。うーん。途中に余分な空白が入ってしまうな。 mew で受信したメールを見ると folding のところで余分な空白が入って表示される。 RFCとか見ても encoded-word に挟まれた CRLF SPACE は無視されるはずなんだけれどなぁ。

UTF-8 の代わりに ISO-2022-JPにしてみたりとか、エンコーディングを変えてみたり(Q or B)したのだが変わらず。 他から受けとっているメールは問題ないから、mew の問題でもなさそうだし。

ん? mew の inbox を確認してみると、他のソフトからのは \n, space でフォールディングされているな。 今書いているコードから送ったやつは \r\n, space でフォールディングされている。 RFC的には CRLF space では?

@ 問題は別のところに

WiKicker で \r\n, space でフォールディングしているところを \n, space でフォールディングするようにしたら直る。 けど、これでいいのかな?

って良く考えたら、他の部分はヘッダでも本文でも改行には \n を使っているんだった(Perl のヒアドキュメントを使っているので)。 ということは今まで、それを標準入力から受けとった sendmail が LFCRLF にしてくれていたのか。 あまり深い事考えてなかったな。 今回はフォールディングのところだけで CRLF にしたため 一個余分に CR がついてしまい、それがタイトルの文字列中の空白として表示されてしまったと。

結局疑うべきは自分のコード。


[ 1月25日全て ]

2005年1月27日 (木)

国際化識別子IRIのRFC このエントリーを含むはてなブックマーク

IRIRFC3987になった。

WiKicker を含めた WikiEngine など(非ASCII)キーワードからURIを生成するタイプのソフトウェア開発において今後要チェック。


[ 1月27日全て ]

Related web page

新しいSMTPのRFC | Okumura's Blog
http://oku.edu.mie-u.ac.jp/~okumura/blog/node/2277
【駄文】JSON における RFC 以前と以後。 - TokuLog 改めB日記
JSON の <strong>RFC</strong> は、JSON が普及してから出ています。 perl でいうと JSON::Syck は <strong>RFC</strong> より前にでている。 JSON::XS は <strong>RFC</strong> の後 準拠具合も出た時期に依存(maybe)。 なので、JSON feed みたいなのを出している Web API を利用するような場合、サーバ側が <strong>RFC</strong> 以前のライブラリをつかっている場合は JSON::Syck の方が parse error 起きにくかったりする場合があります。 とはいえ、option 指定すれば、JSON::XS
http://d.hatena.ne.jp/tokuhirom/20080808/1218154305
void GraphicWizardsLair( void ); // ドコモが今日からSender-ID/SPFでメールを受信拒否する設定を始めたけど、From:とenvelope-from:の解釈がRFCと違ってまぜこぜ?
http://www.otsune.com/diary/2007/11/01/1.html#200711011
ちょっとしたメモ - スクリプトのMIMEタイプがRFCとなって公式登録へ
UAがそれぞれのMIMEタイプを認識できるかどうか、簡単にテストしてみよう。次のボタンが呼び出す関数は、ラベルに示したMIMEタイプをtype属性として持つscript要素に記述してある。クリックしてダイアログが表示されれば、そのタイプとして記述したスクリプトが動作する、エラーになれば動かないと言えるはずだ。
http://www.kanzaki.com/memo/2005/06/28-2
IETF、国際化ドメイン名のRFCを発行
IETFは7日、国際化ドメイン名(Internationalized Domain Name:IDN)の技術仕様を規定した<strong>RFC</strong>を発行した。IDNのアーキテクチャーを示した「IDNA(Internationalizing Domain Names in Applications)」、文字の正規化処理を規定した「NAMEPREP」、エンコード方式「Punycode」の3本で、それぞれ<strong>RFC</strong> 3490、<strong>RFC</strong> 3491、<strong>RFC</strong> 3492となっている。 IDNについてはすでに、日本レジストリサービス(JPRS)や米VeriSign GRSによる登
http://internet.watch.impress.co.jp/www/article/2003/0310/idn.htm
RFC3548 ベース64とベース32とベース16コード化
この文書は<strong>RFC</strong>3548の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。 Network Working Group S
http://www5d.biglobe.ne.jp/~stssk/rfc3548j.html
Uniform Resource Identifier (URI): Generic Syntax
URI のRFC (RFC3986)
http://www.ietf.org/rfc/rfc3986.txt
RFC 3986 - Uniform Resource Identifier (URI): 一般的構文
Uniform Resource Identifiers (URI) は、リソースを識別するための単純かつ拡張性のある方法を提供する。 URI 構文とその意味論を扱うこの仕様書は、World-Wide Web グローバル情報利用の先進によって導入された概念に由来し、このような識別子の使用は 1990 年から始まり、これは &quot;Universal Resource Identifiers in WWW&quot; [<strong>RFC</strong>1630] に記述されている。 URI の構文は、&quot;Functional Recommendations for Inter
http://www.studyinghttp.net/cgi-bin/rfc.cgi?3986
W3CとIETF、日本語ファイル名などが利用できる国際化URIのRFCを発行
標準化団体のW3CとIETFは26日、URI(URL)の国際化方法を定めた<strong>RFC</strong> 3986と<strong>RFC</strong> 3987を公表した。すでにドメイン名の国際化方式については<strong>RFC</strong>として標準化されているが、さらにディレクトリ名やファイル名などの部分についても国際化の方式を定めた。これにより「http://日本語ドメイン名.jp/新着情報/」といったURLの利用が可能となる。 <strong>RFC</strong> 3986は、URIの仕様を定めたインターネット標準(
http://internet.watch.impress.co.jp/cda/news/2005/01/27/6242.html
ちょっとしたメモ - 時間軸を使うURIスキーム、tag:がRFCに
http://www.kanzaki.com/memo/2005/02/25-1

■よく検索されるキーワード

torrent(173) expressions(80) 竹内まりや(58) x31(25) ドラマ(23) linux(23) 手帳(21) 壁紙(21) perl(21) windows(20) 動画(19) wiki(17) porter(17) debian(16) 使い方(16) 画像(15) thinkpad(15) 作り方(15) gmail(14) usb(14) 秋葉原(13) ヨドバシ(13) ほぼ日手帳(13) 提案書(12) 活用(12) 竹内(12) 古川小百合(12) 修理(12) ノート(11) 無印(11) ヨドバシカメラ(11) nikon(11) 書き方(10) ダイソー(10) 万年筆(10) 生年月日(10) 大井町(10) ミニ6穴(9) ほぼ日(9) tc-1(9) 冷蔵庫(9) 設定(9) ニコン(9) java(9) mp3(8) 故障(8) 方眼(8) xp(8) 日誌(8) 感想(8) カメラ(8) allinanchor:*.torrent(8) バッグ(8) firefox(7) インストール(7) キーボード(7) mixi(7) 無料(7) リフィル(7) 小林麻耶(7) nikkor(7) ジョイントラック(7) madwifi(7) 原田夏希(7) skype(6) 変更(6) 三条まゆみ(6) ペンケース(6) web(6) emacs(6) home(6) ポーター(6) 2009(6) itunes(6) a6(6) 無印良品(6) デジカメ(6) finepix(6) 無線lan(6) 評判(6)

この日記のはてなブックマーク数 Add to Google RSS

Process Time: 0.828974s / load averages: 0.88, 1.20, 0.97
nDiki by WATANABE Yoshimasa (profile)
Powered by DiKicker
Base theme by Nana (for tDiary)