Information on RFC 8259 » RFC Editor
The JavaScript Object Notation (JSON) Data Interchange Format, December 2017 File formats: Status:INTERNET STANDARD Obsoletes:RFC 7159 Author:T. Bray, Ed. Stream:IETF Source:jsonbis (art) Cite this RFC: TXT | XML | BibTeX DOI: https://doi.org/10.17487/RFC8259 Discuss this RFC: Send questions or comments to the mailing list json@ietf.org Other actions: View Errata | Submit Errata | Find IPR Di
HTTPSレコードがRFCになりました | IIJ Engineers Blog
RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお
RFCの読み方
こんにちは。技術開発室の伊藤です。 ハートビーツではメールサーバを自社で運用しています。そのメールサーバの移設を実施するにあたり、移設を対応するチームでさまざまなメールの仕様を理解しておく必要がありました。 メールプロトコルの仕様についてはRFC（Request For Comments）が発行されているため、メールに関するRFCを読んでまとめる勉強会を行いました。 その際にRFCを読むにあたって知っておくとよいことがいくつかあったので紹介します。 RFCとは RFCとはIETF（Internet Engineering Task Force）というインターネット技術の標準化を推進する団体やその他の団体が発行している、インターネット標準や技術提供の文書です。もともとは非公式な文書であることを明確にするため、Request For Comments（コメント募集）という名前にしていたようです
A New Definition of HTTP
Hi, I’m Mark Nottingham. I usually write here about the Web, protocol design, HTTP, and Internet governance. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social other HTTP posts Yet More New HTTP Specs Wednesday, 8 June 2022 How Multiplexing Changes Your HTTP APIs Sunday, 13 October 2019 Designing Headers for HTTP Compression Tuesday, 27 November 2018 How to Think About HTTP S
RFC 7519: JSON Web Token (JWT)
Internet Engineering Task Force (IETF) M. Jones Request for Comments: 7519 Microsoft Category: Standards Track J. Bradley ISSN: 2070-1721 Ping Identity N. Sakimura NRI May 2015 JSON Web Token (JWT) Abstract JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a
40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が
HTTP/2の改定版仕様(RFC9113)の変更点について - ASnoKaze blog
2015年に標準化された、RFC7540 HTTP/2 の改定作業が進められています。 作業中のドキュメントは「http2bis」として公開されている。 現時点で含まれている変更点を見ていきます。なお、今後も変更が入る可能性はあります。 HTTPセマンティクス仕様を参照 もともとのHTTP/2の仕様では、HTTPメッセージのセマンティクスについて既存のHTTP/1.1の仕様を参照していました。しかし、HTTP/1.1の仕様はHTTPセマンティクス仕様に分離整理されました。 それにあわせて、改訂版ではその新しいHTTPセマンティクス仕様を参照しています。ヘッダやボディといった用語について変更された部分があるので、HTTP/2の改訂版仕様でも用語の使い方をあわせています。 セマンティクス側の変更点について以前書いた記事を参照ください。 asnokaze.hatenablog.com TLS 1
QUICをゆっくり解説(1)：QUICが標準化されました | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを
タイムゾーンを含むタイムスタンプ文字列表現の標準化 - ASnoKaze blog
「Date and Time on the Internet: Timestamps with additional information」という提案仕様がIETFで提出されているので簡単に紹介する。 この仕様では、下記のようなタイムスタンプの文字列フォーマットの定義を行う 1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew] 背景 TC39 Temporal Temporalという時間を扱う新しいAPIが、TC39でStage 3となっている。 tc39.es このAPIでは、タイムゾーンを含む文字列を生成できる。 const zonedDateTime = Temporal.ZonedDateTime.from({ timeZone: 'America/Los_Angeles', year: 1995, month:
QUIC is now RFC 9000
Why FastlyProductsServicesSolutionsDevelopersPartnersResourcesPricing QUIC is now RFC 9000QUIC is a new latency-reducing, reliable, and secure internet transport protocol that is slated to replace TCP, the most commonly used transport today. We’ve talked before about how we love QUIC and are deeply invested in making it a success because it aligns with our mission to build a faster, more resilient
RFC 8996でTLS1.0とTLS1.1が廃止に - ASnoKaze blog
IETFで、TLS1.0とTLS1.1を正式に非推奨にする「RFC 8996 Deprecating TLS 1.0 and TLS 1.1」が公開されました。 新しいプロトコルへの移行期間は十分であるとし、TLS1.0, TLS1.1, DTLS1.0は廃止となり、TLS 1.2, TLS1.3, DTLS 1.2のみが使用できます。表現としても、MUST NOTで利用を禁止しています。 TLS 1.0 MUST NOT be used TLS 1.1 MUST NOT be used 2015年に公開された、TLS利用時の推奨事項を定めたRFC7525がありますが、今回の禁止内容も含めて改定作業が開始されています。詳細については以前書いたとおり asnokaze.hatenablog.com 更新されるRFC RFC 8996では、既存のRFCについても言及しており TLS1.2以上で
HTTPのバージョンについて、現在のまとめ - Qiita
はじめに HTTPのバージョンと仕様について、個々最近の動きについて整理しておこうかと思います。 HTTPには幾つかのバージョンが有り、現在HTTP/1.1とHTTP/2が広く利用されており、HTTP/3も徐々に使われだしています。 バージョンが異なっていても、クライアントからHTTPリクエストを送り、サーバがHTTPレスポンスを返すのは変わりません。HTTPメッセージをどのようなフォーマットで送るかはバージョンによって異なりますが、HTTPメッセージが持つ意味は変わりません。 意味(セマンティクス)とは、GETリクエストやPOSTリクエスト、ステータスコード、ヘッダがどういった意味を持つかということです。 バージョンと、セマンティクスの歴史的遷移は下記のとおりです。 HTTP/1.1とセマンティクス HTTPは最初0.9から始まり、HTTP/1.0、HTTP/1.1と進んできました。 H
"HTTPヘッダ"が指すものとは - Qiita
普段"HTTPヘッダ"と呼んでるものについて、仕様上は "header fields" と呼ぶらしかったり、自分でも整理できていなかった。 今後もHTTP関連の仕様を読んでいく上でも理解しておきたかったので、この記事では、下記の用語について整理していく HTTP field header/trailer field field line HTTP セマンティクス まず、参照するドキュメントについて簡単に補足します。今回触れる用語は、HTTPセマンティクスの仕様である「HTTP Semantics(ドラフト版)」で定義されています。 HTTPセマンティクスとは、HTTPメッセージ(HTTPメソッドや、レスポンスコード、フィールド)の意味の定義です。 各HTTP/1.1~HTTP/3の仕様ではこのHTTPメッセージをどのように送るか(例えば、HTTP/2ではストリーム上のフレームで送信する)を
RFC7938 - 大規模データセンター内でのルーティングのためのBGPの利用方法 - show log @yuyarin
はじめに この文書は RFC7938 - Use of BGP for Routing in Large-Scale Data Centers の日本語訳です。 翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。 免責 いつものやつ 目次 はじめに 免責 目次 概要 1. 導入 2. ネットワーク設計の要件 2.1 帯域とトラフィックのパターン 2.2 CAPEXの最小化 2.3 OPEXの最小化 2.4 トラフィックエンジニアリング 2.5 要件の要約 3. データセンタートポロジーの概要 3.1 従来のDCトポロジー 3.2 Closネットワークトポロジー
『HTTP/2についての概要をまとめる』
注意この記事は、HTTP/2を勉強する過程での学びのメモを残したものです。 できるだけ、論文や仕様書、信頼できるソースを元に学習しているが、HTTP/2を（意識して）実務で使用したことはないレベルの人が書いた記事ですので間違った知識などもあるかもしれないので注意。 HTTP/2とはHTTP/2は、ウェブにおけるアプリケーション層のプロトコルとして最も使用されているHTTPのうち、2015年に新しく公開されたものである。 現在広く普及しているHTTP/1.1における後述の課題を解決するために作成された。 HTTP/2が作成された理由などについて説明するために、HTTPの歴史を軽く振り返る。 HTTPの歴史HTTP/0.9初代。GETメソッドのみ存在し、ヘッダもステータスコードもない。 HTTP/1.0がでてから初めて、0.9と呼ばれるようになったらしい。 HTTP/1.0HTTP/1.0は、
HTTP/2の仕様、改定作業が始まる - ASnoKaze blog
[追記] 2021年10月時点の変更点について新しく記事を書きました asnokaze.hatenablog.com == もくじ HTTP/2の改定作業 修正点 優先度制御について TLS1.3および0-RTT GREASEのコードポイントの予約 疑似ヘッダの扱い h2cの削除 セマンティクス仕様への参照 そのた参照の更新 security considerations の追記 HTTP/2の改定作業 HTTP/2の仕様は2015年に「RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2)」として標準化されています。 RFCは公開されたあとに、エラッタが見つかることがあります。このようなエラッタを修正するために、新しくRFCを出し直すということが行われます。 HTTP/2においてもいくつかのエラッタが公開されています (参考リンク)。
DNSプロトコルのここ数年のトピック紹介
こんにちは、滝澤です。 筆者の趣味として調べているDNSのプロトコルのここ数年のトピックについて紹介してみます。 ほぼ毎年、DNSに関連する新しいRFC（インターネットに関する技術仕様）が公開され、仕様が更新されたり、新しい仕様が追加されたりしています。 ここ数年のトピックについてまとめてみたいと思い立ち、この記事を書きました。 なお、この記事は2020年8月時点での情報となります。すべてを網羅しているわけではありません。 ちなみに、筆者は次のサイトを公開している人でもあります。 DNS RFCs ANYクエリーに対してRRsetをすべて返すわけではない 2019年1月に「RFC 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」が公開されました。 このRFCでは、DNSレスポンダー（DNSレ
IPv6セキュリティ ～問題点と対策～ - JPNIC
今回のインターネット10分講座では、IPv6環境におけるセキュリティ問題について、代表的な問題点を挙げ、その対策や緩和策を解説します。 1. はじめに 現在、IPv6に対応したネットワーク機器やサービスの普及が進みつつありますが、このIPv6環境におけるセキュリティ問題およびその対策・緩和策については広く理解されているとは言えません。本稿では、その理解の一助となるよう、IPv6環境のセキュリティについての誤解を取り上げた後、IPv6環境における代表的なセキュリティ問題であるFirst Hop SecurityおよびIPv6移行・共存技術に関わるトンネルの問題について、その対策や緩和策を解説します。 2. IPv6セキュリティについての誤解 まず、IPv6に関するセキュリティ上の誤解について、取り上げておきます。 よくある誤解として「IPv6環境ではIPsec(Security Archit
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Signature HTTP Authentication Scheme
日本語 | http2 explained
