「メールアドレスのルール」なんて使ってはいけない3つの理由 - めもおきば
定期的に繰り返される話題ですがまた盛り上がっているのできちんと書いておきます。 「通るべきメールアドレスが弾かれると激おこ」という前提で話を進めます。 問題点1. メールアドレスに関して、RFCなんてそもそも守られていない 2009年以前に登録されたDoCoMo携帯のメールアドレスなど、quoted-stringじゃないのにピリオド連続するものが実在している以上、彼らを許容するべきです。 今そこにある実装 >>(越えられない壁)>> RFC です。 問題点2. メールアドレスの国際化 @の左側(addr-spec)でUTF-8を利用できるようにするRFC5335が発行されています。これにより、通すべき文字が一気に増えます。 RFC5335 Internationalized Email Headers JPRSが国際化電子メールアドレスの標準化活動に貢献 / 株式会社日本レジストリサービス
RFC7540 (HTTP/2) 日本語訳
May 17, 2015 先日の5月15日に、ようやく HTTP/2 の最終的な仕様が RFC7540 として発行されました。仕様がほぼ固まったところからなんだかんだで半年近くかかりましたが、やっと一安心というところです。いつものように今回も日本語訳を用意しましたので、RFC7540 日本語訳として公開します。「RFC になったし、HTTP/2 勉強するか」と思っている方のお役に立てれば幸いです。 仕様としては Draft 14 以降バイナリレベルの変更は入っていません。最後のドラフトとなった Draft 17 からも大きく変更はなく、h2c トークンの明記と編集上の細かい変更にとどまっていますので、今ある実装に手を加える必要もなさそうです。 さて、英語の勉強がてら始めた HTTP/2 の仕様の翻訳ですが、Draft 04 の時にスタートして気がつけば2年弱ほど続けてきたことになります。D
RFC 6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
Internet Engineering Task Force (IETF) P. Hoffman Request for Comments: 6698 VPN Consortium Category: Standards Track J. Schlyter ISSN: 2070-1721 Kirei AB August 2012 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA Abstract Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify
RFC 6394: Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
Internet Engineering Task Force (IETF) R. Barnes Request for Comments: 6394 BBN Technologies Category: Informational October 2011 ISSN: 2070-1721 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) Abstract Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server pro
例として推奨されているドメイン名とIPアドレス - あどけない話
解説記事や発表資料で、ドメインの例を出す場合、example.jp等を使うことが推奨されているのを知っている人は多いでしょう。しかし、IPアドレスの方は知らない人もいるみたいです。ここでは両方について出典を示しながらまとめます。 知っていて別の例を使うのはいいのですが、知らないで別の例を使うのはよくないです。 gTLDのドメイン名の例 RFC2606で以下のように定められています。 3. Reserved Example Second Level Domain Names The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples. example.com exa
ソフトウェア分野の研究開発 / RFC 5023 Atom Publishing Protocol 日本語訳 | Ricoh Japan
この文書は RFC 5023 The Atom Publishing Protocol を, BCP78によって付託された権利に基づいて日本語に翻訳したものです。 翻訳には誤りがある可能性があります。この翻訳の正確性は保証しません。 翻訳についてのお問合せ先：（SSL対応フォーム） （非SSL対応フォーム） 翻訳者一覧 株式会社リコー 山本陽平 日野原寛 高桑寿一 中川勝樹 沖田邦夫 井上浩一 兵清弘 リコーソフトウエア株式会社 福田朋紀 更新履歴 2008-01-07 日外アソシエーツ株式会社 久我様の指摘を受け 9.7 の訳文をわかりやすく、11.2 の抜けを修正 2007-12-06 9.6、9.7.1、9.7.2、10 の誤記、表記ぶれを修正 2007-11-08 エヌ・ティ・ティ・コミュニケーションズ株式会社 朝倉様の指摘を受け 9.3/9.4 の誤訳を修正 2007-11-0
国際化ドメイン名(IDN)のフィッシング詐欺脆弱性について - 日本語.jp
ホーム ＞ 対応環境について ＞国際化ドメイン名(IDN)のフィッシング詐欺脆弱性について - 既に対策は存在し、.JPはサービス開始当初より対策済み - 2005年2月7日から8日にかけて、国際化ドメイン名(IDN)に起因するフィッシング詐欺脆弱性が発見されたとの報道がありました。しかしながら、その本質的な内容はブラウザなどのアプリケーションの問題ではなく、そのドメイン名を運用・管理するレジストリの側がどれだけきちんとした対応を行うかという問題であると言うことができます。ここでは、その内容を 問題の本質 報道されている問題に対する解決策は既に存在し、多くのレジストリでは適用されていること JPドメイン名ではサービス開始当初から適切に対策をしていること という流れでご説明します。 なお、現実には、フィッシングでは誘導先のURIを偽装したり隠蔽したりするなど、もっと巧妙な手段が使われているこ
セキュリティ関連 RFC：IPA 独立行政法人 情報処理推進機構
IPA/ISEC（独立行政法人 情報処理推進機構 セキュリティセンター）は、インターネットセキュリティに関する重要な RFC（Request for Comments）を日本語に翻訳して提供しています。 RFC は、IETF (Internet Engineering Task Force) におけるインターネットコミュニティの標準等の検討が公表される一連の文書であり、1969年に発行され始めました。それらの内容としては、インターネット標準の仕様のみならず、現時点における最善の実践（BCP）、FYI（For Your Information）を含む情報提供、実験的なもの、および、歴史的なものがあり、広範にわたります。原文は、英語で記述されています。 この目的は、 「ベンダーによるインターネットセキュリティ機能の実装を促進すること」および「ユーザのインターネットセキュリティについての認識を向
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Errors in RFC 1912
RFC 1912: Common DNS Operational and Configuration Errors
技術解説 : 迷惑メール対策委員会
dkim.jp
fam.cx
RFC3225 リゾルバのDNSSECサポートの表示
IETF | Internet Engineering Task Force
RFC2396 "Uniform Resource Identifiers (URI): Generic Syntax" 邦訳