Internet Engineering Task Force (IETF) JM. Valin Request for Comments: 6716 Mozilla Corporation Category: Standards Track K. Vos ISSN: 2070-1721 Skype Technologies S.A. T. Terriberry Mozilla Corporation September 2012 Definition of the Opus Audio Codec Abstract This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applicatio
RFC-2119 内田訳 Uploaded: 1998/1/22. Network Working Group Request for Comments: 2119 BCP: 14 Category: Best Current Practice S. Bradner Harvard University March 1997 RFC文書中で要求レベルを表現するために用いられるキーワードの使用法について（Key words for use in RFCs to Indicate Requirement Levels） この文書の状態（Status of this Memo） この文書は、インターネット社会のために、現時点での最上の慣習を同定しておき、進化させるべく、議論や示唆を期待するものです。文書の配布に関しては制限を設けません。 This document specifies an In
Internet Engineering Task Force (IETF) L. Dusseault Request for Comments: 5789 Linden Lab Category: Standards Track J. Snell ISSN: 2070-1721 March 2010 PATCH Method for HTTP Abstract Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal
2007/06/21 Evilビット(RFC 3514)の使い道 RFC 3514というエープリフール(4/1)に公開されたジョークRFCがある。このRFC、Steven Bellovin氏が執筆した "The Security Flag in the IPv4 Header" で、IPv4の未使用フラグを使って "evil bit" を定義したもの。ジョークRFCなのでどこにも実装されていないものと思いきや(FreeBSDでの実装がある)、BreakingPoint Systems社がBPS-1000というネットワークテストシステムで利用されている。BPS-1000というのは、色々なトラフィックパターンや攻撃パターンを作ることができるシステムでネットワーク製品やセキュリティ製品の開発に使われるものらしい。RFC 3514をサポートすることで悪意のあるトラフィックを簡単に識別できるようにし
http://www.rfc-editor.org/rfc/rfc6265.txt is out! Back when I was a HTTP rookie in the late 90s, I once expected that there was this fine RFC document somewhere describing how to do HTTP cookies. I was wrong. A lot of others have missed that document too, both before and after my initial search. I was wrong in the sense that sure there were RFCs for cookies. There were even two of them (RFC2109 an
S. Bradner Harvard University March 1997 Network Working Group Request for Comments: 2119 BCP: 14 Category: Best Current Practice (要求レベル指示のための RFC 用キーワード) このメモの位置づけ この文書は、インターネット・コミュニティーのために Internet Best Current Practices (インターネットの現時点での最良の慣行) を定め、かつ改善のための議論と提案とを求めるものである。 このメモの配布に制限はない。 要旨 標準路線の文書の多くには仕様の要求レベルを示すのに用いられている語がいくつかある。 それらの語はしばしば大文字で書かれる。 この文書では、それらの語を IETF 文書の中で解釈されるべきとおりに定義する。 このガイドラ
リンク上の問題や追加情報があるようでしたらどしどし連絡してください。 インターネットに散らばるＲＦＣの 日本語訳（和訳）のリンクリストを作りました。 多分、同じ翻訳で、コピーが複数あると思えるのはまとめて１行にしています。 （高橋邦夫さんが訳したＲＦＣ１８５５はあまりにもコピーが多いので一部のリンクのみ掲載しています） 同じＲＦＣを、多分別の人が翻訳したと思えるのは別の行にしています。 時代の流れでなくなったページもあります（場所が変わって見つかっていないだけかもしれません）。 [日本語訳]が付いていない所はそんなページと思ってください。 ソースにはコメントとしてＵＲＬを残してあります。 いずれかのアーカイブを探せば見つかるかもしれません。 これらの日本語訳は完全なものとは限りません。 間違って翻訳していたり、 途中だけ翻訳されてたり、翻訳の途中で中断・中止してる事もあります。 翻訳の公開
Email Security Conference 2007 で、ある講演である人が、こんなことを言っていました。 メールのプロトコルである RFC 822 は Standard ですが、改訂版の RFC 2822 は Proposed Standard です。つまり、格下げされたんです。このころからも、メールよりも web の方がセキュアだということは明らかです。 僕はプログラム委員という立場なので、スポンサーの人のこういう間違った発言を正すと角が立つと思い、その場では黙っていました。技術を分っていないことは明らかだったので、放っておこうと思う気持ちもありました。 しかし、よく考えると IETF の標準化プロセスは、IETF 外の人にとって分りにくいのではないかと思い直しました。そこで、IETF に関わりのある人たちと議論して、どう伝えるべきか分ってきましたので、この記事を書いておきます
ここから署名です (ココカラショメイデス) セルフインフォ とは? このキーワードの内容に関わる方が 書いたキーワード（記事）です。 詳しくはヘルプをご覧ください。 署名とは、よくメールの最後に名前とか所属とかが書かれていたりしますが、それのことです。そのままですが、シグネチャともいいます。 署名に工夫を凝らしたりしているものもよく見かけます。特に、署名の上下につける飾り罫のようなものも、いろいろな種類があると思います。 --------- とか ********* とか ★★★★★ といった具合で。 この飾り罫が、いわば「ここから署名です」という合図にもなっているといえます。しかしこの合図には、事実上標準とされるものがあったりします。 その事実上標準とされる「ここから署名です」の合図とは、これです。 -- 実際、こういうのを合図にしている人も結構いますね。しかし実は
IPA/ISEC（独立行政法人 情報処理推進機構 セキュリティセンター）は、インターネットセキュリティに関する重要な RFC（Request for Comments）を日本語に翻訳して提供しています。 RFC は、IETF (Internet Engineering Task Force) におけるインターネットコミュニティの標準等の検討が公表される一連の文書であり、1969年に発行され始めました。それらの内容としては、インターネット標準の仕様のみならず、現時点における最善の実践（BCP）、FYI（For Your Information）を含む情報提供、実験的なもの、および、歴史的なものがあり、広範にわたります。原文は、英語で記述されています。 この目的は、 「ベンダーによるインターネットセキュリティ機能の実装を促進すること」および「ユーザのインターネットセキュリティについての認識を向
Internet-Draft、RFC Internet-Draftは、各個人が自由に投稿することができ、6か月間、 IETFのFTPサーバおよびWebサーバに置かれる。 Internet-Draftは、 6ヶ月でArchive から消えていくWorking-in-Progressのドキュメントである。 各個人および各Working Groupは、Internet-Draftが、 広くインターネット業界に有用な情報を含んでいると判断すると、 これを、RFC(あるいはBCP, Best Current Practice)にするようIESGに申請する。 申請が承認されると、 ドキュメントにはRFC番号(あるいはBCP番号)が割り当てられ、 公式にIETFのFTPおよび Webサーバを通じて恒常的に参照可能なドキュメントとなる。 なお、RFCには、4種類のドキュメント種別が存在していおり、 情報の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く