TCP ヘッダに「死亡フラグ」を追加するジョーク RFC | スラド IT
2023 年 4 月 1 日に発行されたジョーク RFC は 3 件あったが、そのうちの 1 件 RFC9401 は TCP ヘッダに死亡フラグ (DTH) を追加するものだった。著者は Satoshi Toyosawa 氏 (参考訳)。 RFC9401 では DTH を「TCP セッションがすぐに終了する可能性がある場合に、DTH セグメントを送信する必要がある」と説明しており、中国語の「四」と「死」の発音の類似から、TCP ヘッダーのコントロールビットフィールド第 4 ビットを選択している。 死亡フラグのネーミングはアニメやマンガ、ライトノベルからとったといい、死亡フラグがセットされる具体的な場面として以下のようなものを挙げている。 悪の科学者が、完璧な発明に過度の自信を示したとき (多くは自分の発明によって殺される) 塹壕の兵士が婚約者の写真を見せ、帰国後の結婚について語ったとき カ
MACアドレスの再利用は、みんなが思っているよりもはるかに一般的:Geekなぺーじ
MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF
Jリーグチケットは正当なメールアドレスを受け付けない - ただのにっき(2019-09-06)
■ Jリーグチケットは正当なメールアドレスを受け付けない (この日記を書いているのはなんと10月1日という……日記ビハインドが一ヶ月近いなんてひさびさだ) わが川崎フロンターレも後期からついにシーズンチケットがデジタル化されて、ICカード1枚が郵送されてくるだけになった。めでたい。いっそアプリ化してくれてもいいんだけど。 で、その余波として行けない試合のチケットを譲渡ないし転売できるようになった。リーグ2連覇していまや毎試合チケット完売しているありさまなので、無駄な空席が出ないのは助かりますな。チケット譲渡・転売の手続きをするにはJリーグチケットのアカウントが必要なので、さっそく登録……しようとしたらエラーになった: おれは訓練されたインターネットユーザなので、この時点でピンときてはいるんだけど、いちおう念の為サポートに連絡してみる。翌日届いた返信がこう: Jリーグチケットでは、@前の1文
IPv6基本仕様のRFC 2460が廃止:Geekなぺーじ
IPv6の基本仕様を規定したRFC 2460が廃止されました。RFC 2460が発行されたのは1998年なので、IPv6の基本仕様を規定したRFCが廃止されるのは約19年間ぶり、2回目の廃止です。今後は、RFC 2460を廃止するRFC 8200がIPv6の基本仕様を規定したRFCになります。 Internet Protocol, Version 6 (IPv6) Specification 今後、IPv6の基本仕様に関して勉強、参照、紹介などをする場合には、今回廃止されたRFC 2460ではなく、RFC 8200を利用する必要があります。 RFC 8200が発行されるまでに行われてた議論や、6月時点におけるIETFでの議論に関しては、先月、NTTコミュニケーションズ株式会社の西塚要さんが書かれた記事が素晴らしいので、是非そちらをごらんください。 Internet Watch: 20歳を超
なぜIPv6とIPv4の名前解決は別々に行なわれるのか？:Geekなぺーじ
www.example.comなどの「名前」に対応するIPアドレスをDNSサーバに問い合わせるとき、IPv4とIPv6に関する名前解決を単一の問い合わせで行うことはできません。そのため、DNSサーバに対して、IPv4に関する問い合わせと、IPv6に関する問い合わせを、別々に2度行う必要があります。 これは、DNSサーバに対しての問い合わせが単一のレコードに対してしか行えないためです。 Aレコード（IPv4アドレス）の問い合わせと、AAAAレコード（IPv6アドレス）の問い合わせは、それぞれ別々のレコードに対する問い合わせなので、両方を同時には行えないのです。 ただし、「IPv4とIPv6に関するDNSサーバへの問い合わせは別々に行わなければならない」というのは、事実上の話であって、「仕様上そうなっている」と言い切れるのかどうかは微妙かも知れません。 DNSに関するRFCは、悪名高いRFC
RFCの正規文書がXMLに:Geekなぺーじ
インターネットに関連するプロトコルなどを規定するRFC(Request For Comments)の正規文書のフォーマットが、これまでのplain-text ASCIIからXMLへと変わります。そのためのRFCが、RFC 7990 - RFC 7998として策定されました。 RFC 7990 RFC Format Framework RFC 7991 The "xml2rfc" Version 3 Vocabulary RFC 7992 HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995 PDF Format for RFCs RFC 7996 SVG Drawings for R
HTTP/1.1、公開から15年の時を経て改訂 | スラド IT
「1つだったRFCは6つに分割され」とあったのは、2616をUpdateした https://tools.ietf.org/html/rfc7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing https://tools.ietf.org/html/rfc7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content https://tools.ietf.org/html/rfc7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests https://tools.ietf.org/html/rfc7233 Hypertext Transfer Protocol
前代未聞？RFC 7158が一瞬で廃止されてRFC 7159に！:Geekなぺーじ
3月2日より、ロンドンにてIETF 89が開催中ですが、IETFでRFC 7158が一瞬で廃止されるという珍事が発生しました。 どうも、2014年3月と記載すべきところを2013年3月としてしまったので、それを修正するためにRFC 7159が発行され、RFC 7158は即座に廃止されています。 RFC 7158とRFC 7159のdiffを見ると、見事に2013と2014の違いしかありません。 しかし、「本当にこれだけの違いで大丈夫なの？」と思える部分もあります。 たとえば、「Status of This Memo」Errataを記載する部分がRFC 7159において、Errataを「http://www.rfc-editor.org/info/rfc7158」としているのですが、正しくは「http://www.rfc-editor.org/info/rfc7159」だと思われます。 また
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC違反のメールアドレス の許容 · Issue #1325 · EC-CUBE/ec-cube
RFC標準を調べるための知識やツール - Qiita