「RFC違反」アドレスのドコモメール、iOS14で送信不可に
NTTドコモは、国際標準「RFC」に準拠していないアドレスのドコモメール（@docomo.ne.jp）が、iOS14以降のメールアプリで送信できなくなる事象を確認していると発表した。対象のユーザーには、メールアドレスを変更するか、プロファイル更新するよう案内している。 iOS14以降で、アドレス内に2連続のドット（..）が含まれていたり、アットマーク前にドット（.@）が含まれているアドレスを利用している場合に、メールが送信できなくなることを確認したという。 RFCは、インターネットの標準化団体IETF（The Internet Engineering Task Force）が発行している、技術仕様をまとめた文書。2009年ごろまでに作られた日本のキャリアメールのアドレスの一部はRFCに準拠していないと以前から指摘されており、トラブルの元になると批判されていた。
RFCに則ったメールアドレスでダブルドットを使う方法 - 泥府湾日誌
そういえば前に書いたとき*1「RFCに従えばピリオドが二連続するアドレスは作れない」みたいな書き方をしてしまったので、補足しておかないと。 RFC2822、3.4.1. Addr-spec specificationを参照してもらえば分かるとおり、メールアドレスのlocal-part（@の前の部分）を規定する方法は二つある。*2 このうち、dot-atomという記述ではダブルドットは記述できない。しかし、quoted-string形式では恐るべき自由度*3でメールアドレスを記述することが出来る。従って携帯電話の「あり得ないメールアドレス」でもこの形式だと考えれば許されるかもしれないのだが・・・この場合、local-partは"mailaddress"の形で記述されている必要があります。*4 あと、MTAがちゃんと対応しているのか不安があったりします。RFC3696 3. Restricti
HTTPで「418 I’m a tea pot」を実装してはいけない(2018/10/18追記) - Qiita
418 I’m a tea potとは ステータスコード 418 I’m a tea potは、エイプリルフールに発行されたジョークRFCであるRFC2324「Hyper Text Coffee Pot Control Protocol」 で定義されているステータスコードです。 Googleでも 418 を返すURLがあります。 Error 418 (I’m a teapot)!? https://www.google.com/teapot 昨日、golangとnodejsにおいて、418 I’m a tea pot の実装を削除するIssue が投げられています。 golang: net/http: remove support for status code 418 I'm a Teapot nodejs: 418 I'm A Teapot #14644 Issue中でも書かれている通
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
RFCは、なぜ「意見募集」という名前だったのか？:Geekなぺーじ
インターネットで使われる各種仕様の多くは、RFCと呼ばれる文書として発行されています。 RFCは、「意見募集」や「意見を求む」といった意味を持つRequest For Commentsの略ですが、インターネットに関連する通信仕様の標準を示す文書の名称が、なぜ意見を募集するとなっているのでしょうか？ それには、初期のRFCが発行された時代背景があるのです。 RFCの文書番号は新しい文書とともに増加していくので、基本的に文書番号が小さいほど昔のものになります。 最初のRFCである、RFC 1は、1969年4月7日に発行されています。 多少余談になりますが、RFC 1は、「インターネット」という単語が生まれる前に発行されています。 「インターネット（internet）」という単語が初めて登場するRFCは、1974年に発行されたRFC 675です。 1973年に発行されたRFC 604とRFC 6
Ruby 2.1 と 2.2 における、URI#parseの挙動の違い - Qiita
症状 Ruby 2.1では、URIに使用できない文字（アンダースコア、アンダーバー）を含んだ文字列( http://abc_def.com/foobar/ ※1)をURI#parseに与えた際にURI::InvalidURIErrorの例外が発生する。 2015/08/15追記： ※1…この文字列はURIとしては RFC違反 です。ホスト名にアンダースコア、アンダーバーを含むことはできません。@key-amb様、ご指摘頂きありがとうございます。 なお、この記事では 「RFC違反の文字列に対して、同じURI#parseを使っているが、Rubyのマイナーバージョンに依って挙動が違う」 という点にのみ焦点を当てて、実際にどのように異なっているのか、Ruby2.2で2.1の挙動が欲しい場合にどうすれば良いのかについて論じます。 [1] pry(main)> require 'uri' => tru
HTTP2 の RFC7540 が公開されました - Block Rockin’ Codes
Intro 今朝、ついにずっと策定作業が行われていた HTTP/1.1 の後継仕様である HTTP2 と、 関連仕様である HPACK が、 RFC として公開されました。 ついに HTTP2 RFC 7540 出た！！ #http2study / “rfc7540.txt” http://t.co/CuaVul98l3— Jxck (@Jxck_) 2015, 5月 14 それぞれ番号は 7540 と 7541 になります。 RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) RFC7541 - HPACK: Header Compression for HTTP/2 ちなみに HTTP/2.0 ではなく HTTP/2 が正式名称です。(マイナーバージョンアップでの HTTP/2.1 などはありません) 二年半 HTTP2 の
Geekなぺーじ:MessagePackがIETF標準化に巻き込まれてる件について
ここ数日、MessagePackがIETFにおける標準化に巻き込まれてザワザワしています。 何が起きているかというと、MessagePackプロジェクトとは関係が無い第三者がIETFで派生物の標準化を進めようとしています(binarypack、Informational RFCとして)。 binarypackは、自らをMessagePackの派生であるとしながらも、MessagePackとの後方互換性が無いものです。 MessagePack is in danger! binarypackのInternet-Draftを提出しているのは、coreと6lowpanのchairです。 Chairであるかどうかが議論そのものに与える影響はそこまで大きくないとも言えますが、少なくともIETFでの話の進め方に精通した人物であることは確かです。 ただ、今回のInternet-Draftは、その人物がC
中国からネットを分断統治の標準化提案？:Geekなぺーじ
IETFに対して中国からと思われる標準化提案が行われています。 その内容は、インターネットを分断することによって自律した運営が行えるようにDNSを変更するというものです。 IETFの議題になっているわけではなく、単にinternet draftとして提出されただけなので、恐らくほとんど相手にされずにRFCになることはないと予想されますが、こういった提案が行われたことそのものが、ニュースになっています。 PCWorld : Chinese Operators Hope to Standardize a Segmented Internet PCWorldの記事は6月19日でしたが、ICANN44がその記事が出た直後の24日だったこともあり、ICANNでも話題になったようです。 ICANN 44: Examining The AIP Internet Draft Proposal | Dyn
HTTPの新ステータスコード「451 Unavailable for Legal Reasons」を、グーグルのTim Bray氏がIETFに提案
HTTPの新ステータスコード「451 Unavailable for Legal Reasons」を、グーグルのTim Bray氏がIETFに提案 WebブラウザとWebサーバのあいだでやりとりされる通信プロトコルのHTTPには、リクエストに対するレスポンスを表すためのさまざまなステータスコードがあります。例えば、「200 OK」「404 Not Found」などはその代表的な例です。 ここに新しいステータスを追加しようという提案がIETFに対して行われました。提案したのはXML仕様の策定に関わった主要な人物であり、現在グーグルでAndroidのデベロッパーアドボケイトをしているTim Bray氏。 提案されたステータスコードは「451 Unavailable for Legal Reasons」（451 法的な理由によって利用不可）です。 ISPとサーチエンジンに影響するようだ 提案では
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
