RFC 3492: Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page] PROPOSED STANDARD Updated by: 5891 Errata ExistNetwork Working Group A. Costello Request for Comments: 3492 Univ. of California, Berkeley Category: Standards Track March 2003 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) Status of this Memo This document specifies an Internet stan
もう絶対迷わないエラーレスポンスの作り方【RFC7807】 - Qiita
この記事は「ゆめみ その2 Advent Calendar 2019」の5日目の記事です。 ある日のこと… 「いきなりそんなこと言われても…」 上司「ついでにいろんなところで使いまわせるように普遍的なのにしてね」 「えぇ…」 「こういう時にエラーレスポンスが標準化されてRFCでまとめられてたらいいのになぁ…」 ありました RFC7807 : Problem Details for HTTP APIs RFC7807では開発においてHTTP APIのために新しくエラーレスポンスを定義するのを避けるために、プログラムが読み取れるような問題詳細（Problem Details）をapplication/problem+jsonまたはapplication/problem+xmlで定義しています。 問題詳細（Problem Details）ってなんぞや？ type, title, status,
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
RFC 5424 - The Syslog Protocol 日本語訳
RFC 5424 - The Syslog Protocol 日本語訳 原文URL : https://datatracker.ietf.org/doc/html/rfc5424 タイトル : RFC 5424 - Syslogプロトコル 翻訳編集 : 自動生成 [要約] RFC 5424は、シスログプロトコルに関する標準仕様であり、ログメッセージの受け渡しと管理を目的としています。このRFCは、システム管理者や開発者にとって重要な情報源となることが期待されています。 Network Working Group R. Gerhards Request for Comments: 5424 Adiscon GmbH Obsoletes: 3164 March 2009 Category: Standards Track
IETF-syslog(RFC 5424)メッセージフォーマット
現在、syslogメッセージのフォーマットは以下の2つの標準があります。 BSD-syslogメッセージ(または、legacy-syslogメッセージとも呼ばれています。) IETF-syslogメッセージ BSD-syslogメッセージフォーマットについては、過去記事「BSD-syslogメッセージフォーマット」で紹介しています。合わせてご覧ください。 今回は、IETF-syslogメッセージフォーマットについてご紹介します。 IETF-syslogメッセージフォーマット(RFC 5424)IETF-syslogメッセージフォーマットはRFC 5424※で提唱されており、以下の3つの要素で構成されます。 HEADER STRUCTURED-DATA MSG ※参考: https://tools.ietf.org/html/rfc5424 HEADERHEADER要素は、さらに以下の要素で
JavaScript の MIME タイプが `text/javascript` に統一されようとしている
現在、 JavaScript の MIME タイプは2006年4月に公開された RFC 4329(www.rfc-editor.org) にて text/javascript (OBSOLETE) application/javascript (COMMON) text/ecmascript (OBSOLETE) application/ecmascript (COMMON) の4つが定義されています。 この RFC 4329 では text/* の2つは OBSOLETE 扱いな一方で、 JavaScript を呼び出す HTML の仕様では HTML5 以降、 <script> 要素の type 属性を省略することが推奨 されたうえで、省略時の値は text/javascript である とされました。 このように RFC 側と HTML 側で矛盾が生じる事態が長い間続いています。 実
OAuth 2.0 におけるアクセストークン実装方法の検討 - 理系学生日記
OAuth 2.0 のプロバイダにおいて、アクセストークンをどのようにシステムで保持するのかっていうところを考えたり調べたりしていました。 前提として、OAuth のトークンには以下の 2 種類の表現方法があります (RFC 6819 3.1. Tokens) Handle "opaque" トークンとも呼ばれるトークンの表現方法です。 認可サーバー内部のデータ実体に対する単なる参照として表現され、トークンの文字列自体に意味はありません。トークンから参照を得るためには、トークンをキーにデータ実体を探して、必要な情報 (DB 上とかにある有効期限とか) を手に入れるという形になります。 Assertion トークン自体に意味を持たせるトークンの表現方法です。 トークンから直接、必要な情報 (有効期限とか) を取得できます。 アクセストークンに焦点を合わせると、トークンを発行するのは認可サーバ
HTTPメソッドのPUT・DELETEは、本当に冪等（べきとう）なのか？ – knowledge capsule
GET・HEAD GET・HEADが冪等というのは、納得がいく。 確かに、同じリソースファイルのURLに何度GET・HEADリクエストしようとも、リソースの状態は変わらないだろう。 少し引っかかるのは、クライアントに返却されるレスポンスコードは変わるということだ。 GETのレスポンスは、リソースファイルがクライアントでキャッシュされているかによって、200（200）か304（Not Modified）になるだろう。 PUT、DELETEについては疑問が残る。 PUTは、対象のリソースを更新するが、リソースがなければ作成する。 DELETEは、対象のリソースがあれば削除するが、リソースがなければ何もしない。 サーバーのリソースの状態を見ると、PUTの場合、1度目のリクエストでリソースが作成され、2度目のリクエストでリソースが更新される。 DELETEの場合、1度目のリクエストでリソースが削除
MACアドレスの再利用は、みんなが思っているよりもはるかに一般的:Geekなぺーじ
MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF
TCPの再送時間について - はろぐ
1. TCPの再送制御 TCPの機能にはフロー制御、順序保証、再送制御などがあります。 再送制御では、システムの障害時やパケットの消失時などにパケットの再送を制御しています。再送は一般的には複数回実施され、回数を重ねる毎に再送間隔が広がっていきます。 ネットワークの設計では迂回時間60秒以内などとしているところもありますが、具体的に障害が発生してから何秒後のタイミングで救われるのか計算してみます。 2. TCPの再送時間の計算式と取り得る時間 TCPの再送時間の計算式はOS毎に設定されています。今回はLinux/HP-UXで確認します。 利用システムのバージョンに寄っても変更される可能性がありますが、確認したシステムのHP-UXではRFC2988、LinuxではRFC6298に準拠していました。 RFC6298を確認すると、TCPの再送時間は以下の式により計算され、最小値が1秒、最大値60
ABNF - Wikipedia
ABNF（Augmented Backus–Naur form）は、バッカス・ナウア記法 (BNF) の拡張の一種。構文規則や生成規則はBNFとは異なる。通信プロトコルなどの言語の形式体系を記述するメタ言語として開発された。RFC 5234 で文書化されており、IETF が通信プロトコルを定義する際によく使っている。拡張バッカス・ナウア記法とも呼ばれるが、EBNF（Extended Backus-Naur Form）も同じ訳語となるため、区別するためあえて ABNF としている。 RFC 5234 は、RFC 4234およびRFC 2234 に存在した問題を修正し置換したものである。 概要[編集] ABNFの記述は以下のような生成規則群からなる。 ここで、rule は大文字小文字が区別される非終端記号、definition はその rule を定義する記号列、comment は文書化のため
RFC1215 ＳＮＭＰで使用するトラップを定義することに対する取り決め
この文書はRFC1215の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。 Network Working Group M. Rose, Editor Request for Comments: 1215 Performance Systems International March 1991 A Convention for Defining Traps for use with the SNMP ＳＮＭＰで使用するトラップを 定義することに対する取り決め Status of this Memo この文書の状態 This m
文書や資料に使って良いIPアドレス - Disce gaudere. 楽しむ事を学べ。
資料等で例として使うIPアドレス用に、 文書作成用IPアドレス(Address Blocks Reserved for Documentation)がRFCで定められている。 IPv4アドレス： RFC5737に"IPv4 Address Blocks Reserved for Documentation"として、 "TEST-NET-1/2/3"の3つのブロックが記されている。 192.0.2.0/24 (192.0.2.0 〜 192.0.2.255) 198.51.100.0/24 (198.51.100.0 〜 198.51.100.255) 203.0.113.0/24 (203.0.113.0 〜 203.0.113.255) IPv6アドレス： RFC3849に、"IPv6 Address Prefix Reserved for Documentation"として記されている
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
PHPでダウンロードさせるファイル名がIEで文字化けする件 - Qiita
問題はどんな言語で書いても起こることですが、たまたま仕事でPHPつかってたときにぶつかったのでメモしておきます。 結論 HTTPのレスポンスヘッダで Content-Disposition: attachment; filename*=UTF-8''URLエンコードされたファイル名を送ってあげる。 追記 2017/11/02: Edgeでも通用するようです。https://github.com/netcommons/NetCommons2/issues/126 ファイル名が化ける PHPでファイルアップローダをつくっていました。 動作確認はUbuntu 14.04のFirefox30をつかっていましたが、社内ではIE11がデフォ。「一応やっとくか」とIE11で動かしたら、日本語のファイル名が見事に化けました。 またお前か、IE！チキショー Slim Frameworkをつかっているので、こ
Windowsネットワーク 第16...＠IT：連載 基礎から学ぶ
第16回 信頼性のある通信を実現するTCPプロトコル（3）：基礎から学ぶWindowsネットワーク（3/4 ページ） TCP技術を習得するうえで非常に重要な項目として、「TCPの状態遷移図」というものがある。これはTCPプロトコルの規格書であるRFC793（STD0007）に掲載されている、TCPプロトコルの内部ステートを表現した図である。すでに解説したように、TCPでは接続ごとに、それぞれシーケンス番号やACK番号、オープン／クローズなどの処理状態といった「ステート（状態）」を持っている。このようなプロトコルを「ステートフルな（stateful、状態を持つ）」プロトコルという。TCP接続のオープンやクローズ、確立などに伴う、状態の変化を表現した図を「状態遷移図」という。 以下は、RFC793に記載されているTCPの状態遷移図を簡略化したものである（完全な状態遷移図についてはRFC793を
RFC 6455 - The WebSocket Protocol（日本語訳）
RFC6455 - The WebSocket Protocol 日本語訳 この文書は、 IETF による, 2011 年 12 月付け発行 PROPOSED STANDARD RFC 6455 "The WebSocket Protocol" （HTML 版） を日本語に翻訳したものです。 この翻訳には翻訳上の誤りがあるかもしれませんし、正確性は保証されません。 この仕様の公式な文書は英語版であり、この日本語版は公式のものではありません。 最終更新日時点のこのページの URL ： http://www.hcn.zaq.ne.jp/___/WEB/RFC6455-ja.html CSS や DOM の対応が古いブラウザでは、閲覧に不具合が生じたり, 一部の切替機能（ウィンドウ左下隅：原文表示＝アクセスキー Z, 原語表示＝アクセスキー X ）が働かないかもしれません（ HTML5 から導入
RFC1321(The MD5 Message-Digest Algorithm)
トップページ - 翻訳ドキュメント - RFC 1321 原文：ftp://ftp.rfc-editor.org/in-notes/rfc1321.txt 原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。 .original { color: blue; display: none; } → .original { color: blue; display: block; } サイト内関連リンク：RFC 1810 MD5のパフォーマンスに関する報告 The MD5 Message-Digest Algorithm MD5 メッセージダイジェストアルゴリズム Status of this Memo この文書の位置付け This memo provides
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC 3339の日付形式
SMTP手順