サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
NTTドコモは、国際標準「RFC」に準拠していないアドレスのドコモメール（@docomo.ne.jp）が、iOS14以降のメールアプリで送信できなくなる事象を確認していると発表した。対象のユーザーには、メールアドレスを変更するか、プロファイル更新するよう案内している。 iOS14以降で、アドレス内に2連続のドット（..）が含まれていたり、アットマーク前にドット（.@）が含まれているアドレスを利用している場合に、メールが送信できなくなることを確認したという。 RFCは、インターネットの標準化団体IETF（The Internet Engineering Task Force）が発行している、技術仕様をまとめた文書。2009年ごろまでに作られた日本のキャリアメールのアドレスの一部は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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? (2025/05/04追記2022年6月公開された『RFC 9110 HTTP Semantics』にて、418は Unusedになりました) 418 I’m a tea potとは ステータスコード 418 I’m a tea potは、エイプリルフールに発行されたジョークRFCであるRFC2324「HyperText Coffee Pot Control Protocol」 で定義されているステータスコードです。Googleでも 418 を返すURLがあります。Error 418 (I’m a teapot)!? https
インターネットに関連するプロトコルなどを規定する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 7992HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995PDF Format for RFCs RFC 7996SVG Drawings for R
インターネットで使われる各種仕様の多くは、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
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 の
ここ数日、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
IETFに対して中国からと思われる標準化提案が行われています。 その内容は、インターネットを分断することによって自律した運営が行えるようにDNSを変更するというものです。 IETFの議題になっているわけではなく、単にinternet draftとして提出されただけなので、恐らくほとんど相手にされずにRFCになることはないと予想されますが、こういった提案が行われたことそのものが、ニュースになっています。PCWorld : Chinese Operators Hope to Standardize a Segmented InternetPCWorldの記事は6月19日でしたが、ICANN44がその記事が出た直後の24日だったこともあり、ICANNでも話題になったようです。 ICANN 44: Examining TheAIP Internet Draft Proposal | Dyn
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ページを開く
