RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
Internet Engineering Task Force (IETF) S. Kitterman Request for Comments: 7208 Kitterman Technical Services Obsoletes: 4408 April 2014 Category: Standards Track ISSN: 2070-1721 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Abstract Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending hos
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
OAuth & OpenID Connect 関連仕様まとめ - Qiita
はじめに OAuth や OpenID Connect に関連する仕様を紹介していこうと思います。 仕様はたくさんあるものの、ほとんどオプショナルです。しかし、「認可サーバーを実装する際は、RFC 6749 だけではなく、認可コード横取り攻撃への対抗策である RFC 7636 も実装すべきである」* という点は強調しておきたいと思います。 * 「PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと」という記事もご参照ください。 1. OAuth 2.0 (RFC 6749) OAuth 2.0 の仕様の本体は RFC 6749 (The OAuth 2.0 Authorization Framework) です。RFC 6749 の解説記事は世の中にたくさんあるので、ここでは要点だけ手短に紹介します。 RFC 6749 は、アクセストークンを発行
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
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
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 をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。 なお、可読性向上のため、ページのヘッダ・フ
リダイレクトの警告
表示中のページから http://ya.maya.st/d/201110b.html にリダイレクトしようとしています。 このページにリダイレクトしないようにする場合は、前のページに戻ってください。
Emacsでrfcを読む - tototoshi の日記
ちょっと便利よ。 ;; rfc (defvar my-rfc-directory "~/Documents/rfc" "The directory rfc documents are saved") (defun rfc (n) "Open the rfc document. If the specified document doesn't exist, Download it from internet." (interactive "nNo.: ") (let* ((dir my-rfc-directory) (file (format "%s/rfc%d.txt" dir n))) (if (not (file-exists-p dir)) (mkdir dir)) (cond ((file-exists-p file) nil) (t (shell-command (format
Geekなぺーじ : IPアドレスにまつわるチョイネタ
IPv4アドレスの例としては、上記IPv4アドレスを使えばいいわけですが、世の中を見ると結構好き勝手なIPv4アドレスを例として利用している事例が多いというのが現状ではないかと思います。 私が初めてこれを知ったのは、kazuさんのブログの「あどけない話：例として推奨されているドメイン名とIPアドレス」を読んだときです。 それまでは、知らなかったので、適当なIPv4アドレスを使ったサンプルを書いてしまってました。 申し訳ありません。。。 余談ですが、kazuさんは、私が「技術的に一生追いつけそうにない」と思っている凄い人の一人です。 こういった凄い方々を色々と見ていると、私が自分のサイト名に「Geek」という在らぬ単語を入れてしまったことを悔いていたりします。 以前から書き続けていますが、私は「ギーク」なんかじゃないです。サイト名は気のせいです。すみません。。。 というか、そういう「凄い」と
RFCの分類 - JPNIC
いままで説明したようにRFCは様々な情報を伝達するという役割を担っている。 そこでそれぞれのRFCには内容や位置づけに応じていくつかの分類がある。 RFCの種類 まず大まかなところから考えていこう。 RFCが扱う内容は、少し乱暴だが、 インターネット標準に関するもの その他 の大きく2つにわけることができる。 前者は『インターネット標準化過程』というプロセスで処理されているRFC、 つまり『インターネット標準』を形成する文書群およびその候補となる文書群を指す。 標準化過程に関しては後で説明する。 これは標準化段階に応じて、 標準化への提唱(PS: Proposed Standard) 標準化への草稿(DS: Draft Standard) 標準(STD: Standard) の3つに分類される。 後者は、標準化過程として処理されていないRFC全般が含まれている。2000年現在は、 情報(I
RFC 822 と RFC 2822 - あどけない話
Email Security Conference 2007 で、ある講演である人が、こんなことを言っていました。 メールのプロトコルである RFC 822 は Standard ですが、改訂版の RFC 2822 は Proposed Standard です。つまり、格下げされたんです。このころからも、メールよりも web の方がセキュアだということは明らかです。 僕はプログラム委員という立場なので、スポンサーの人のこういう間違った発言を正すと角が立つと思い、その場では黙っていました。技術を分っていないことは明らかだったので、放っておこうと思う気持ちもありました。 しかし、よく考えると IETF の標準化プロセスは、IETF 外の人にとって分りにくいのではないかと思い直しました。そこで、IETF に関わりのある人たちと議論して、どう伝えるべきか分ってきましたので、この記事を書いておきます
Geolocation
Geolocation W3C Recommendation 15 August 2024 More details about this document This version: https://www.w3.org/TR/2024/REC-geolocation-20240815/ Latest published version: https://www.w3.org/TR/geolocation/ Latest editor's draft:https://w3c.github.io/geolocation/ History: https://www.w3.org/standards/history/geolocation/ Commit history Test suite:https://wpt.live/geolocation/ Implementation report
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DomainKeys Identified Mail (DKIM) Signatures
WebRTCの裏側
https://www.ietf.org/rfc/rfc3875
http://ftp.ics.uci.edu/pub/ietf/http/rfc2109.txt
RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON)