Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、tools.ietf.org だった。 RFC 2616: Hy
メールシステム担当の人はもちろん、インフラ担当の人もDNSの設定とかで既に知ってはると思いますが、 10月にGoogleが発表した2024年2月から始まるGmailとYahoo!(米国)におけるスパム対策強化のあれです。 海外では数年前から"No Auth, No Entry"って「代表なくして課税なし」みたいな感じで言われているアレです。 識者の方々がいろんなところで記事にしてはりますので、他のところであんまり書かれていない気がするとこだけ記します。 まずは公式情報 Google Googleについては以下の二ヶ所を読んで理解して実践しておけば大丈夫そうです、たぶん。 パラメーターのhl=enをhl=jaに変えると日本語版になりますが、更新されるのが遅いので最初に英語版を見ておくのが良いです。 Email Sender Guidelines(81126) Email Sender Gui
[2024年1月10日、19日追記] GmailとYahoo!側のアップデートに合わせていくつか細かい説明を追加しています（大筋は変わっていません）。変更点だけ知りたい方は「追記」でページ内検索してください。 2023年10月3日、Googleはスパム対策強化のため、Gmailへ送るメールが満たすべき条件を2024年2月から厳しくすると発表しました。また米国Yahoo!も、2024年2月 第一四半期[1] から同様の対策を行うと発表しています。端的に言えば、この条件を満たさないと宛先にメールが届かなくなるという影響の大きな変更です。 この記事では、Gmailや米国Yahoo!の規制強化への対応方法を解説します。ただし米国Yahoo!にメールを送る人は多くないと思うので、フォーカスはGmail寄りです。また、メール配信サービス（海外だとSendGridやAmazon SES、国産だとblas
url.js `�� ���� /* href ┌────────────────────────────────────────┴──────────────────────────────────────────────┐ origin │ ┌────────────┴──────────────┐ │ │ authority │ │ ┌───────────────┴───────────────────────────┐ │ │ │ host resource │ │ ┌──────────┴─────────────────┐ ┌────────────┴───────────┬───────┐ │ │ hostname │ pathname │ │ │ │ ┌──────────────┴────────────┐ │ ┌──────┴───────┐ │ │ protocol
HTTPのGETといったメソッドやヘッダの意味を定義したHTTPセマンティクス仕様の改訂版である「HTTP Semantics」が標準化の大詰めを迎えている。(RFC9110となる予定) 既存の仕様から幾つか大事な変更が含まれているので簡単に紹介する。 目次 セマンティクス仕様の改訂作業 ざっくり変更点 用語整理 (Field) 用語整理 (body) 用語整理 (interim/final レスポンス) ステータスコードのレンジを明確化 ステータスコード418 unused Rangeを指定したPUTリクエスト GET, HEAD, DELETEでコンテンツを含めるのを非推奨 (SHOULD NOT) プロトコルのマイナーバージョンについて 更に詳しく知りたい場合 おわりに セマンティクス仕様の改訂作業 HTTPセマンティクス及び、HTTP/1.1の仕様の改定作業がIETFのHTTP W
Network Working Group T. Berners-Lee Request for Comments: 3986 W3C/MIT STD: 66 R. Fielding Updates: 1738 Day Software Obsoletes: 2732, 2396, 1808 L. Masinter Category: Standards Track Adobe Systems January 2005 Uniform Resource Identifier (URI): Generic Syntax Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and s
ネットワークワーキンググループ Request for Comments： 2119 BCP： 14 分類： ベストカレントプラクティス English RFC において要請の程度を示すために用いるキーワード （Key words for use in RFCs to Indicate Requirement Levels） このメモの位置付け このメモは、インターネット コミュニティのためにベストカレントプラクティス（現時点における最善の実践）について規定するものであり、改善のための議論や提案を求めております。 このメモの配布に制限はありません。 要旨 多くの標準化過程の文書において、いくつかの語句が、当該仕様の要請の程度を 示すために使われています。これらの語句は、よく大文字になっています。 この文書では、これらの語句が IETF の文書においてどのように解釈されるべきであるか、につい
Internet Engineering Task Force (IETF) M. Nottingham Request for Comments: 7807 Akamai Category: Standards Track E. Wilde ISSN: 2070-1721 March 2016 Problem Details for HTTP APIs Abstract This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. Status of This Memo This is
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く