[17] Web Push protocol は、プッシュメッセージの配送に関する利用者エージェント、 プッシュサービス、 アプリケーションサーバー3者間のプロトコルです。 HTTP を下位層とするプロトコルです。
[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
と使われる部分もあります。
[3] モバイル端末・埋め込み機器の応用で実時間イベントをネットワークから受け取りたい (「プッシュ」されたい) 要求がある一方で、 電力制約があって通信を抑制したいです。 応用ごとに別個に通信するのではなく、 1つのサービスに集約するのが良いと考えられます。 そのような前提の元、 Push API では従来独占的プロトコルが用いられてきましたが、 本手法は標準化されたプロトコルとして開発されたものです。 >>1 1.
[5] と仕様書では説明されていますが、電力の制約を持ち出すまでもなく、 無数の Webアプリケーションを常時稼働させておくのは現実的とはいえません。 Webブラウザーで当該 Webアプリケーションを開いていないときでもプッシュメッセージを受け取れるために (そうでなければとても実用的とはいえません)、 ワーカーを常時動作させておくとか、 最低でも1つHTTP接続を維持させておかなければならないとしたら、 計算機資源を無駄に消費し続けることになります。 賢いアーキテクチャーとはいえないでしょう。 Webプラットフォームという分散システムな全体設計と矛盾するようですが、 特定少数個に集約したプロトコルになるのは必然といえます。
[6] 次の用語が定義されています。 この用語は他の関連仕様でも使われています。
[11] プッシュメッセージの送受信など多くの操作は、 プッシュメッセージ購読を使って行います。
[2] に IETF の提案標準 RFC 8030 として出版されました。 >>1
[9] Web Push Parameters, https://www.iana.org/assignments/webpush-parameters/webpush-parameters.xhtml