URIのスキーム一覧 - こせきの技術日記
tag URIをもっとあちこちで使いたい。例えばXML名前空間名には、httpよりもtagの方が適切に思える。しかし、RFCのステータスがINFORMATIONALなのが気になった。使う上でどのくらい問題なんだろう。 とりあえず全スキームのRFCステータスを調べてみた。IANAの一覧を使って生成。 IANA | URI Schemes http://www.ietf.org/download/rfc-index.txt 生成に使ったスクリプト。 http://gist.github.com/426852 RFCのステータスについては、以下の記事がわかりやすかった。 RFC 822 と RFC 2822 - あどけない話 Internet StandardsとRFC − ＠IT RFCの分類 JPNIC RFC-JP(IETFにおける標準化プロセス) スキームの登録方法はRFC4395で定め
ABNF - Wikipedia
ここで、rule は大文字小文字が区別される非終端記号、definition はその rule を定義する記号列、comment は文書化のためのコメントである。最後尾には必ず CR と LF による改行コードが付属する。 規則名は大文字小文字を区別しない。<rulename> も <RULENAME> も <rUlENamE> も同じ規則を参照している。規則名はいわゆるアルファベット文字で始まり、その後にアルファベット、数字、ハイフンが続く。 山括弧（<と>）は規則名を囲むのに必要とはされていない。しかし、規則名を識別しやすいように山括弧で囲むことが多い。 ABNF は 7ビットASCIIで符号化され、最上位の8ビット目はゼロに設定される。 終端記号は1つ以上の文字コードで表される。 文字コードは、パーセント記号“%”とそれに続く基数を表す文字（b = 2進、d = 10進、x = 16
CSVファイルの一般的書式 (RFC4180 日本語訳) - アルプス登山の玄関口・笠井家
2005年10月に公開された、RFC4180「Common Format and MIME Type for Comma-Separated Values (CSV) Files (CSVファイルの一般的書式、およびMIMEタイプ) 」の日本語訳です。謝辞と文献の箇所は原文のままです。 データ交換において頻繁に使われるCSV形式ですが、ベンダの独自仕様が乱立しているのが実情です。 本RFCは、遅まきながら出てきた、最初にして唯一の、「公式(?)」な仕様です。もっとも、区分 (Category) がInformationalのRFCなので、「標準」ではありませんが… 原文は、http://www.ietf.org/rfc/rfc4180.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。 なお、可読性向上のため、ページのヘッダ・フ
RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files
Network Working Group Y. Shafranovich Request for Comments: 4180 SolidMatrix Technologies, Inc. Category: Informational October 2005 Common Format and MIME Type for Comma-Separated Values (CSV) Files Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright
ドコモもauはとりあえず"da..me."@を受け取れるようにしとくべし : 404 Blog Not Found
2007年11月20日12:00 カテゴリiTech ドコモもauはとりあえず"da..me."@を受け取れるようにしとくべし けだし同感なのだけど、これでもメアドを再設定しない人をどうするかという問題は残る。 ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。 とりあえずドコモの携帯で確認したが、2007年11月現在のいまも、***.@docomo.ne.jpとか**....***@docomo.ne.jpといったメールアドレスの設定/取得は可能なままである。 というわけで、解決策を考えてみた。 実はRFC2822の規定では、da.me..@docomo.ne.jpというメールアドレスはNGだが、意外なことに"da.me.."@docomo.ne.jpであればOKなのだ。@の前の部分が""でくくられている場合、RFC2822はそれを特別扱いすることになっているので、こんなトリック
L'eclat des jours(2006-11-26) IE6が標準にしたがっている点
_ IE6が標準にしたがっている点 XMLHttpRequestを使うページのテストをしている。 1つのページでイベント受信用と送信用で2つ使う。受信用で使うってことはつまり、Cometというわけだが。 問題は、Cometのパフォーマンスを見たくて、「新規ウィンドウ」を開くところから始まった。イベントは受信できるのに送信できない。タイミングによっては送信できるけど受信はできない。なにがなにやら。あるいは完全にハングしてプロセスを殺すしか手段がなくなったりもする。 で、いろいろ試行錯誤してるうちに、どうもインスタンスが同時に2つしか作れないんじゃないかと気づいた。 で検索すると Ajax-Development-Gotchasなんてページが見つかった。 IEは長年に渡る標準を無視する伝統を打破してRFC2616に従ったので2インスタンスしか同時に実行しないと書いている。しかもそれ以上の作成要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ietf.org/rfc/rfc2183.txt
https://www.ietf.org/rfc/rfc2231.txt
RFC 2445 - Internet Calendaring and Scheduling Core Object Specification (iCalendar)