サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
インターネット技術を推進する団体IETFは、中国が提案したインターネットの中核を置き換える新技術New IP（IP: internet protocol）に全面的な「ノー」を突きつけた。 中国HuaweiがITUに"New IP"提案、IETFは連絡を受け検討 経緯は次のようになる。2019年9月、中国企業Huaweiの専門家らが、国連機関ITU（国際電気通信連合）に対して新たなインターネットの基本技術"New IP"を提案した。この提案は、ITUからインターネット技術を推進するIETF（The Internet Engineering Task Force）にも伝えられた。2020年3月28日、Financial Timesはこの新技術New IPへの懸念を伝える長文記事を掲載した（Inside China’s controversial mission to reinvent the
HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として 現在標準化が進められている新たなHTTPである「HTTP/3」のトランスポート層プロトコルとなる予定の新しい通信プロトコル「QUIC」が、インターネットで用いられる通信プロトコルなどの標準化を行う団体のIETF（Internete Engineering Task Force）により「RFC 9000」として策定を完了、新たなインターネット標準になったことが明らかになりました。 QUIC is now RFC 9000 | Fastly QUIC is RFC 9000 | daniel.haxx.se QUICはもともとHTTPをより高速化するためにGoogleが開発し、その後IETFで標準化が進められてきました。 QUICはまずは次世代のHTTPであるHTTP/3のトランスポート
IETFのQUICワーキンググループはHTTP/3の標準化プロセスを完了し、「RFC 9114」として発表しました。 HTTP/3 has been published as an RFC. https://t.co/jdsUHy9FKD — IETF QUIC WG (@quicwg) June 6, 2022 HTTPはWorld Wide Webを開発したティム・バーナーズ＝リーによって1990年に最初のバージョンが作られました。 その後、1996年にHTTP/1.0がIETFによってRFC化され、1999年にHTTP/1.1へアップデート。2015年2月には初めてのメジャーバージョンアップとなるHTTP/2がRFCとなりました。HTTP/3は7年ぶりのメジャーアップデートと言えます。 HTTP/3では高速な通信を実現するために、HTTPのトランスポート層を従来のTCPからQUICに
IETFのQUICワーキンググループで標準化作業が進められてきたQUICとHTTP/3が、6月のQUICワーキンググループにおけるラストコールを経て、IETFのステアリンググループであるIESGのラストコールとして10月21日に受諾されました。 ラストコールとしてIESGが受諾したドキュメントは、QUICとHTTP/3の標準化に関わる以下の6つのドキュメントです。 QUIC: A UDP-Based Multiplexed and Secure Transport QUIC Loss Detection and Congestion Control Using TLS to Secure QUIC Version-Independent Properties of QUIC Hypertext Transfer Protocol Version 3 (HTTP/3) QPACK: Head
W3CとIETFは、WebRTCが正式な標準仕様に到達したことを発表しました。 The @W3C and the @ietf are pleased to announce that Web Real-Time Communications (WebRTC) is now an official standard, bringing audio and video communications anywhere on the Web.https://t.co/GCHkDK7BHH pic.twitter.com/gBwdap47sO — W3C (@w3c) January 26, 2021 The @ietf and @w3c are pleased to announce that Web Real-Time Communications (WebRTC) is now an offi
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
The process of defining a web standard is a lengthy process that ensures usefulness, consistency and compatibility across browsers. Today the W3C and IETF mark the completion of perhaps one of the most important standards during the pandemic: WebRTC. History WebRTC is a platform giving browsers, mobile apps, and desktop apps real-time communication capabilities, typically used for video calling. T
グローバルネットワークの多くの標準を定めているインターネット技術タスクフォース（IETF）は先週、コンピューター間でデータを送信するためのプロトコルであるQUICを標準として発表した。ウェブブラウザーやオンラインサービスは何年も前からQUICを試用してきたが、IETFによる承認は、本格採用するのに十分なほど同プロトコルが成熟していることを示している。 QUICは、インターネットの速度とセキュリティを向上させ、インターネット黎明期の1974年にまでさかのぼる標準プロトコルTCPに取って代わる可能性がある。 データ転送という基本的なレベルでインターネットを改善することは困難を極める。数え切れないほどの機器、プログラム、サービスが、何十年も続いてきた初期のインフラを利用するよう構築されているからだ。 インターネットの基盤をアップグレードすることは、世界に広がる通信と商業のバックボーンを維持するた
この記事は、 NTT Communications Advent Calendar 2024 10日目の記事です。 先日、自前のMedia over QUICの実装をIETF 121のハッカソンへ持ち込んで相互接続試験に参加してきました。 その結果、他の参加者の実装との相互接続に成功し、Working Groupのリストに名前を記載いただけました。 本記事では、Media over QUICの概要や動向を紹介し、ハッカソンでの体験について報告します。 はじめに Media over QUICとは？ 概要 プロトコルの構成 通信の参加者 何が嬉しいの？ メディアのフリーズを防げる 映像や音声以外も扱える オンデマンドとリアルタイムを統合できる サードパーティのネットワークと連携しやすくなる 現在の動向と未来予想 仕様安定化に向けた議論の継続 WebRTCの拡張機能との競合 ハッカソンの参加報
先月行われたIETF 115において、eBPFの一部ドキュメントをIETFからRFCとして出すか？という議論が行われました。 まだ議論の段階で結論は出ていないが、簡単にメモとして残しておく。 なお、僕自身はKernel, eBPF方面に明るいわけではない... eBPF サイドミーティング IETFでは会期中に特定トピックについて議論するサイドミーティングが行われます。IETF 115において「eBPF standardization side meeting」が開催されました。 eBPF Foundationのほうからは、Dave Thaler氏らを中心にeBPF Steering Committeeから数名と、IETF参加者がサイドミーティングに出席したようです。 概要 eBPF Foundation は、eBPF クロスプラットフォーム ドキュメントをどこで公開するかについて検討して
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? IETFで議論されている、HTTP/3やWeb関連の応用トピックについて、次回ミーティングセッションに合わせ紹介していく。 IETF 107について QUICやHTTP/3は現在IETFで標準化が進められています。 そんなIETFの107回目のミーティングが今週(3/23~27)から開催されます。元々はバンクーバーで開催予定でしたが、急遽リモートでの開催となりました。 それに合わせ、開催セッションも少なくなっています(Agenda参照)。開催されるセッションは、今後の作業の進め方を決める必要がある初開催のWGや、BoF（同じ課題に興味を
Intro HTTPBis では、RFC 8941: Structured Field Values (以下 SFV) の更新作業が行われている。 RFC 8941: Structured Field Values for HTTP https://www.rfc-editor.org/rfc/rfc8941.html 機能面では Date 型が追加されるという点が大きいが、個人的にはその裏で行われるもっと興味深い議論に注目したい。 それは、「RFC における ABNF の立ち位置」に関するものだ。 ABNF と Parsing Algorithm SFV は、簡単に言えば HTTP Field Value のための構造化フォーマットで、JSON がそのまま使えなかったことに対する代替仕様だ。よって、基本的には目的となる構造体と文字列フォーマット間の Encode / Decode が定義
s2n-quic is a Rust implementation of the IETF QUIC protocol, featuring: a simple, easy-to-use API. See an example of an s2n-quic echo server built with just a few API calls high configurability using providers for granular control of functionality extensive automated testing, including fuzz testing, integration testing, unit testing, snapshot testing, efficiency testing, performance benchmarking,
IETF 115 London 現地参加記 備忘録を込めてわかりやすさより、一週間をできるだけ文章にすることをメインにする。 金曜日 11/4 (移動) 土曜日 11/5 (観光) 日曜日 11/6 11:00- ハッカソンを覗きに 16:00 - 17:00 New Participants' Quick Connections 17:00 - 19:00 Welcome Reception 月曜日 11/7 (会議初日) 08:00 - 09:00 Systers Networking Event 09:30 - 11:30 Monday Session I Dispatch 13:00 - 15:00 Monday Session II QUIC 15:00 - 15:30 おやつ飲み物休憩タイム 15:30 - 17:30 Monday Session III H
イノベーションセンターの三島と深川です。 普段の業務では、Segment Routing を始めとする経路制御技術や、IPFIX や Streaming Telemetry などの監視技術の検証・運用、高速ソフトウェアルーター「Kamuee」の開発をしています。 我々は 2023/11/04-10 に行われた IETF 118 Prague へ参加しました。 この記事では、IETF 118 の参加報告として、主に Hackathon での成果と各 WG の動向などをご紹介します。 (出典: https://www.ietf.org/) IETF の概要や IETF 117 についてはIETF117 参加報告とおもしろワーキンググループ紹介をご覧ください。 IETF 118 参加報告 以下では、我々が現地で参加した IETF meeting の内容をご紹介します。 IETF 118 の全スケ
WebRTC enables rich, interactive, live voice and video communications anywhere on the Web, boosting global interconnection Read testimonials from W3C Members. https://www.w3.org/ and https://www.ietf.org/ — 26 January 2021 — The World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) announced today that Web Real-Time Communications (WebRTC), which powers myriad services, is
IETF、IETF Meetingとは ※ IETF 116などの定期的に開催されるin-personな会合をこのブログでは “IETF Meeting” と呼びますが、正式名称ではない可能性があります。正式名称があったら教えてください。ちょっと探したけど総称っぽいものが見付かりませんでした。 IETFは、"Internet Engineering Task Force" の略で、インターネットの標準を決める団体です。ざっくばらんに言えば、RFCを出しているところです。 IETFが何なのかについては、既に良い説明があるのでそちらを参考にするのがいいでしょう。以下にリンクを貼っておきます。 インターネット用語1分解説～IETFとは～ - JPNIC IETFとは～はじめに～ - JPNIC IETFとRFC - JPNIC JPRS トピックス＆コラム No.22 | インターネット標準の作
標準化団体大手のWorld Wide Web Consortium(W3C)とInternet Engineering Task Force(IETF)が、ブラウザやアプリケーションにシンプルなAPI経由でリアルタイム通信を提供するオープンソーステクノロジー「WebRTC」が標準規格になったと発表しました。 Web Real-Time Communications (WebRTC) transforms the communications landscape as it becomes a World Wide Web Consortium (W3C) Recommendation and Internet Engineering Task Force (IETF) standards https://www.w3.org/2021/01/pressrelease-webrtc-rec.
イノベーションセンターの三島と深川です。 普段の業務では、Segment Routing を始めとする経路制御技術や、IPFIX や Streaming Telemetry などの監視技術の検証・運用、高速ソフトウェアルーター「Kamuee」の開発をしています。 今回、我々は 2023/07/22-28 に行われた、IETF 117 に参加しました。 この記事では、IETF 117 の参加を通じて得た経験や現地の様子、各 WG の動向などをご紹介します。 IETF (Internet Engineering Task Force) とは IETF は、インターネット技術の標準化を推進する団体です。 標準化の議論は Working Group (WG) 単位で推進され、主にメーリングリストを通じて議論が行われます。 メーリングリストは誰でも閲覧・参加が可能です。 また、標準化された技術は I
IETF には rough consensus and running code というモットーがあるらしい。 rough consensus and running code IETF | Running Code We reject: kings, presidents and voting. We believe in: rough consensus and running code. https://www.ietf.org/proceedings/24.pdf きっかけは、仕事で技術的な判断のファシリテーションがうまくいかず困っていて、標準策定をする組織のベストプラクティスが参考になるかもと思ったこと。彼らは構造上トップダウンで方針決定をできないはずだし、加入時の選考がないのでメンバーの多様性もより大きいはず。そんな環境での合意形成は普通の企業よりも難しそうなので、参考になるの
OpenMetricsという提案仕様が、11月25日にIETFに提出されました。仕様は「OpenMetrics, a cloud-native, highly scalable metrics protocol」こちらから閲覧できます。 これはIETFでの標準化の一歩目であり最終的にRFCとなるかはまだまだわかりません。 ただ標準化の観点で興味深いと思っています。ですので今回は、仕様の中身には触れずラフに書いていこうかと思います。 はじめに 自分自身は、監視やモニタリングについて専門ではないものの、多くのインフラ/クラウド環境のモニタリングでPrometheusが使用されているのは知っています。 そのPrometheusが使っている、メトリクス収集のプロトコル/フォーマットであるOpenMetricsがIETFに持ち込まれたという点は、標準化側の視点で興味深く見ております。 もちろん、SP
IETF 116 Yokohama25 Mar 2023 - 31 Mar 2023 IETF 116 starts Saturday 25 March and runs through Friday afternoon, 31 March. The IETF Hackathon and IETF Codesprint take place on the weekend. Newcomers' training and technical tutorials take place on Sunday afternoon. Participants should plan their travel accordingly. The schedule may be updated very close to the start to the meeting.
Google Chromeチームは10月7日(米国時間)、「Chromium Blog: Chrome is deploying HTTP/3 and IETF QUIC」において、Google Chromeが「Google QUIC」に加えて「IETF QUIC」を積極的にサポートしていく方針と伝えた。 QUIC（Quick UDP Internet Connections）は、Googleが開発したUDP（User Datagram Protocol）やTLS（Transport Layer Security）をベースとした新しい通信プロトコルである。 現在は、標準化団体のIETF（Internet Engineering Task Force）により標準化が進められており、次期HTTPとなる「HTTP/3」ではベースとなるトランスポートプロトコルとしてQUICが採用されることになって
draft-momoka-httpbis-settings-enable-websockets IETFのhttpbis-wgに提出したあとにメーリスで議論したことのめも。 こちらのブログの続きです。 momoka0122y.hatenablog.com まず前回のブログの時点では大枠を書いただけでinternet-draftとして提出していなかったので提出しました。やり方は internet draft の書き方。テンプレートを使ってマークダウンで で書いた通り。 datatracker.ietf.org そしてIETF http-wgに提出してhttp-wg にメールを送った。（このときメールを送るのに承認が必要とのことで少し待った。少し待った後承認メールが送られると思ったが来なかったので10日後ぐらいに再度メールを送ったらメーリスに無事送れていた） lists.w3.org Hell
The IETF works on a broad range of networking technologies that provide the foundation for the Internet's growth and evolution.
IETFではインターネットで使用されているプロトコルの標準化を行っています。TCPやHTTPの仕様がRFCという文書として公開されているのをご存知の方も多いでしょう。 そのIETFは、年3回オフラインのミーティングを実施しており、次回(2023年3月25日~) の開催地は横浜(Yokohama)となっております。 前回日本で開催されたのは2015年ですので、8年ぶりということになります。プロトコルの標準化の会議を実際に見る貴重な機会になるかとおもいますので、これを機会に参加しようと思われる方もいるでしょう。 そんな方のために、よりIETFを楽しむための幾つか記事を書いていこうかと思います。 1.「参加申し込み」 2.「予習/事前の議論のキャッチアップ」 3.「WG紹介, ホットトピック紹介」 4.「当日の流れ/会議の流れ」 特にIETFのミーティングは、メーリングリストや前回の会議の続きで
ついに、IETF 116 Yokohamaが始まりましたね！！横浜で僕と握手！！ WGのミーティングは月曜日からですので、ちょうど直前ということになります。 パシフィコ横浜ノース 3Fで受付を済ませたあとは、アジェンダ(URL)のページを参考に会議室に行くだけです。 WGのミーティングでは、前回議論した提案仕様のIssueが議論されます。できれば、WGミーティングのAgendaは抑えて予習はしておいた方が良いかと思います。とはいえ、会議中にちんぷんかんぷんでも情報を追うコツを幾つか書いておこうと思います。 心得 英語は分からない、、、みんな分からない大丈夫！！ せっかくなので色々な人に話しかけよう (議論とかは詳しい人に聞こう！) 無理して全部のミーティングに出る必要はない！ WG ミーティング materials 各WGのアジェンダ及び発表資料は マテリアルページ(URL)に記載されます
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
