仕様書

呼称

[10] RFC 8030 の題名はプロトコル名ではなく、 本文中もプロトコル名称を明確に述べていないので、 正式名称はよくわかりません。

[12] RFC 8030 各ページヘッダーには HTTP Web Push とあります。 >>1 ポート番号 1001 の IANA登録簿雛形の説明にも HTTP Web Push と記入されています。 >>1 9.3.

[13] ポート番号 1001 の IANA登録簿雛形のサービス名は、 webpush とされています。 >>1 9.3.

[14] URN は urn:ietf:params:push と省略形の push になっています。 その IANA登録簿は Web Push Identifiers なる名称で、すると Web Push がプロトコル名に当たる部分です。 >>1 9.2.

[15] 開発した IETF の WG は「WEBPUSH WG」 ですが、これはプロトコル名とは即断できません。

[16] RFC 8291 や RFC 8292 は、題名に 「Web Push」と入っています。 RFC 8030 のプロトコルを The Web Push protocol と呼ぶ他、文中に何度か「Web Push」 と出てきます。 構文内で WebPush や application/webpush-options+json と使われる部分もあります。

[18] Push API は web push protocol と呼んでいます。

用途

[3] モバイル端末・埋め込み機器の応用で実時間イベントをネットワークから受け取りたい (「プッシュ」されたい) 要求がある一方で、 電力制約があって通信を抑制したいです。 応用ごとに別個に通信するのではなく、 1つのサービスに集約するのが良いと考えられます。 そのような前提の元、 Push API では従来独占的プロトコルが用いられてきましたが、 本手法は標準化されたプロトコルとして開発されたものです。 >>1 1.

[5] と仕様書では説明されていますが、電力の制約を持ち出すまでもなく、 無数の Webアプリケーションを常時稼働させておくのは現実的とはいえません。 Webブラウザーで当該 Webアプリケーションを開いていないときでもプッシュメッセージを受け取れるために (そうでなければとても実用的とはいえません)、 ワーカーを常時動作させておくとか、 最低でも1つHTTP接続を維持させておかなければならないとしたら、 計算機資源を無駄に消費し続けることになります。 賢いアーキテクチャーとはいえないでしょう。 Webプラットフォームという分散システムな全体設計と矛盾するようですが、 特定少数個に集約したプロトコルになるのは必然といえます。

[4] 理論上 Push API と併用せず独自の方法と組み合わせることも可能ですが、 実例があるかは不明です。

プロトコル

[6] 次の用語が定義されています。 この用語は他の関連仕様でも使われています。

[11] プッシュメッセージの送受信など多くの操作は、 プッシュメッセージ購読を使って行います。

API

Push API

歴史

[2] 2016年12月に IETF の提案標準 RFC 8030 として出版されました。 >>1

[9] Web Push Parameters, 2017-12-27 01:57:03 +09:00 https://www.iana.org/assignments/webpush-parameters/webpush-parameters.xhtml