インターネット技術タスクフォース（IETF） M. Thomson
Request for Comments: 8030 Mozilla
カテゴリ: 標準化過程 E. Damaggio
ISSN: 2070-1721 B. Raymor, Ed.
Microsoft
2016年12月
HTTP Pushを用いた汎用イベント配信
概要
この文書は、ユーザーエージェントにリアルタイムイベントを配信するための
簡単なプロトコルを記述する。この仕組みはHTTP/2サーバープッシュを使用する。
このメモの位置付け
これはインターネット標準化過程の文書である。
この文書はインターネット技術タスクフォース（IETF）の成果物である。
これはIETFコミュニティの合意を表すものである。公開レビューを受けており、
インターネット技術運営グループ（IESG）によって公開が承認されている。
インターネット標準に関する詳細情報は、RFC 7841の第 2節で
入手できる。
この文書の現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、
http://www.rfc-editor.org/info/rfc8030で入手できる。
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Thomson, et al. 標準化過程 [Page 1]
RFC 8030 HTTP Web Push 2016年12月
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 規約と用語 . . . . . . . . . . . . . . . . . . . . . . 4
2. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. HTTPリソース . . . . . . . . . . . . . . . . . . . . . 7
3. プッシュサービスへの接続 . . . . . . . . . . . . . . . . 8
4. プッシュメッセージの購読 . . . . . . . . . . . . . . . . 8
4.1. 購読を集合へまとめる . . . . . . . . . . . . . . . . 9
5. プッシュメッセージ配信の要求 . . . . . . . . . . . . . 10
5.1. プッシュメッセージ受領確認の要求 . . . . . . . . . 10
5.2. プッシュメッセージのTime-To-Live . . . . . . . . . 11
5.3. プッシュメッセージの緊急度 . . . . . . . . . . . . 13
5.4. プッシュメッセージの置換 . . . . . . . . . . . . . 14
6. 購読に対するプッシュメッセージの受信 . . . . . . . . 15
6.1. 購読集合に対するプッシュメッセージの受信 . . . . 17
6.2. プッシュメッセージの確認応答 . . . . . . . . . . 18
6.3. プッシュメッセージ受領確認の受信 . . . . . . . . 19
7. 運用上の考慮事項 . . . . . . . . . . . . . . . . . . . 20
7.1. 負荷管理 . . . . . . . . . . . . . . . . . . . . . . 20
7.2. プッシュメッセージの失効 . . . . . . . . . . . . . 20
7.3. 購読の失効 . . . . . . . . . . . . . . . . . . . . . 21
7.3.1. 購読集合の失効 . . . . . . . . . . . . . . . . . 21
7.4. アプリケーションの信頼性への影響 . . . . . . . . 22
7.5. 購読集合と並行HTTP/2ストリーム . . . . . . . . . 22
8. セキュリティ上の考慮事項 . . . . . . . . . . . . . . 22
8.1. プッシュサービスアクセスからの機密性 . . . . . . 23
8.2. プライバシー上の考慮事項 . . . . . . . . . . . . 23
8.3. 認可 . . . . . . . . . . . . . . . . . . . . . . . . 24
8.4. サービス拒否に関する考慮事項 . . . . . . . . . . 25
8.5. ログ記録のリスク . . . . . . . . . . . . . . . . . 25
9. IANAに関する考慮事項 . . . . . . . . . . . . . . . . . 26
9.1. ヘッダーフィールド登録 . . . . . . . . . . . . . 26
9.2. リンク関係URN . . . . . . . . . . . . . . . . . . 26
9.3. サービス名およびポート番号登録 . . . . . . . . . 28
10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. 規範的参考文献 . . . . . . . . . . . . . . . . . 28
10.2. 参考情報 . . . . . . . . . . . . . . . . . . . . 30
謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . 31
Thomson, et al. 標準化過程 [Page 2]
RFC 8030 HTTP Web Push 2016年12月
1. はじめに
モバイル機器や組み込み機器上の多くのアプリケーションでは、着信や
メッセージなどのリアルタイムイベントを適時に配信（または
「プッシュ」）できるよう、ネットワーク通信への継続的なアクセスを
必要とする。これらの機器は通常、利用可能な電力が限られているため、
アプリケーション要件を満たすより効率的な方法を見つけることは、
アプリケーションエコシステムに大きな利益をもたらす。
電力使用量への大きな寄与要因の1つは無線である。無線通信は、
無線機器のエネルギー予算の大きな部分を消費する。
複数のアプリケーションからの永続的な接続またはセッションを
調整せずに使用すると、各独立したセッションがそれぞれ独自の
オーバーヘッドを生じ得るため、機器の無線の不必要な使用につながる。
特に、ミドルボックスがセッションを早期にタイムアウトしないように
するためのkeep-aliveトラフィックは、大きな浪費をもたらし得る。
イベントは比較的まれであるため、長期的には保守用トラフィックが
支配的になりがちである。
すべてのリアルタイムイベントを単一のセッションに統合することで、
ネットワークおよび無線リソースをより効率的に使用できる。単一の
サービスがすべてのイベントを統合し、それらのイベントが到着すると
アプリケーションへ配信する。これには1つのセッションだけが必要で、
重複するオーバーヘッドコストを回避できる。
W3C Push API [API]は、Webアプリケーションから
統合されたプッシュサービスを使用できるようにするAPIを記述している。
この文書は、その作業を拡張し、次のことに使用できるプロトコルを
記述する。
o ユーザーエージェントへのプッシュメッセージ配信を要求すること、
o 新しいプッシュメッセージ配信購読を作成すること、および
o 新しいプッシュメッセージを監視すること。
標準化されたイベント配信方法は、アプリケーションサーバーが
複数のプッシュサービスを使用する必要がある場合があるW3C Push APIに
とって特に重要である。購読、管理、および監視機能は現在、独自
プロトコルによって実現されている。これらは十分ではあるが、
標準化がもたらす利点はいずれも提供しない。
この文書は、プッシュサービスがどのように発見されるかを意図的に
記述しない。プッシュサービスの発見は、そもそも必要であることが
判明した場合、将来の取り組みに委ねられる。ユーザーエージェントは、
プッシュサービスのURLで構成されることが期待される。
Thomson, et al. 標準化過程 [Page 3]
RFC 8030 HTTP Web Push 2016年12月
1.1. 規約と用語
この文書におけるキーワード"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、
"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、
および"OPTIONAL"は、[RFC2119]で記述されているように解釈される。
この文書は、次の用語を定義する。
application: プッシュメッセージの送信者と最終的な利用者の両方。
多くのアプリケーションは、ユーザーエージェント上で動作する
コンポーネントと、サーバー上で動作する他のコンポーネントを持つ。
application server: 通常サーバー上で動作し、プッシュメッセージの
配信を要求するアプリケーションのコンポーネント。
push message subscription: ユーザーエージェントとプッシュサービスの
間で確立され、アプリケーションサーバーと共有されるメッセージ
配信コンテキスト。すべてのプッシュメッセージは、プッシュ
メッセージ購読に関連付けられる。
push message subscription set: 複数のプッシュメッセージ購読を集合に
まとめる、ユーザーエージェントとプッシュサービスの間で確立
されるメッセージ配信コンテキスト。
push message: アプリケーションサーバーからプッシュサービスを介して
ユーザーエージェントへ送信されるメッセージ。
push message receipt: プッシュサービスからアプリケーションサーバーへ
送信されるメッセージ配信確認。
push service: ユーザーエージェントへプッシュメッセージを配信する
サービス。
user agent: プッシュメッセージの受信者である機器およびソフトウェア。
この文書の例では、HTTP/1.1メッセージ形式[RFC7230]を使用する。
多くの交換はHTTP/1.1を使用して完了できる。
o プッシュメッセージの購読（Section 4）
o プッシュメッセージ配信の要求（Section 5）
o プッシュメッセージの置換（Section 5.4）
o プッシュメッセージの確認応答（Section 6.2）
Thomson, et al. 標準化過程 [Page 4]
RFC 8030 HTTP Web Push 2016年12月
例がHTTP/2サーバープッシュに依存する場合は、[RFC7540]のより詳細な
フレーム形式が使用される。
o 購読に対するプッシュメッセージの受信（Section 6）
o 購読集合に対するプッシュメッセージの受信（Section 6.1）
o プッシュメッセージ受領確認の受信（Section 6.3）
すべての例では、登録済みポート（1001）ではなく、デフォルトポート
（443）上のHTTPSを使用する。プッシュサービスの展開では、ユーザー
エージェントがサービスに到達できる可能性を最大化するために、この
構成を好む場合がある。プッシュサービスは、到達性を犠牲にすることなく
標準化されたHTTPSポートの利点を得るため、HTTP代替サービスを使用して
ユーザーエージェントを登録済みポート（1001）へリダイレクトしてもよい
（Section 3参照）。これは、ユーザーエージェントからプッシュサービス
への要求にAlt-Usedヘッダーフィールド[RFC7838]が含まれることを通じて
例に現れるだけである。
このプロトコルは必須のシステムを定義しないため、例にはプッシュ
メッセージの暗号化やアプリケーションサーバー認証の具体的な方法は
含まれない。Voluntary Application Server Identification [VAPID]および
Message Encryption for WebPush [ENCRYPT]の例は、W3C Push API [API]が
その要件のために採用したアプローチを示している。
Thomson, et al. 標準化過程 [Page 5]
RFC 8030 HTTP Web Push 2016年12月
2. 概要
プッシュサービスの一般的なモデルには、3つの基本的なアクターが
含まれる。ユーザーエージェント、プッシュサービス、および
アプリケーション（サーバー）である。
+-------+ +--------------+ +-------------+
| UA | | Push Service | | Application |
+-------+ +--------------+ | Server |
| | +-------------+
| Subscribe | |
|--------------------->| |
| Monitor | |
|<====================>| |
| | |
| Distribute Push Resource |
|-------------------------------------------->|
| | |
: : :
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
図1: WebPushアーキテクチャ
プロセスの最初に、新しいメッセージ購読がユーザーエージェントに
よって作成され、その後そのアプリケーションサーバーへ配布される。
この購読は、アクター間の将来のすべての相互作用の基礎である。
購読は、アプリケーションサーバーがプッシュサービスへメッセージを
送信し、ユーザーエージェントへ配信させるために使用される。
ユーザーエージェントは、その購読を使用して、受信メッセージが
ないかプッシュサービスを監視する。
認可に対するより多くの制御を提供するため、メッセージ購読は
異なる能力を持つ2つのリソースとしてモデル化される。
o 購読リソースは、購読からメッセージを受信し、購読を削除するために
使用される。これはユーザーエージェントに対して非公開である。
o プッシュリソースは、購読へメッセージを送信するために使用される。
これは公開され、ユーザーエージェントからそのアプリケーション
サーバーと共有される。
各アプリケーションに一意の購読が配布されることが期待されるが、
このプロトコルには本質的な濃度制約はない。複数の購読が同じ
Thomson, et al. 標準化過程 [Page 6]
RFC 8030 HTTP Web Push 2016年12月
アプリケーションのために作成されることも、複数のアプリケーションが
同じ購読を使用することもできる。ただし、購読の共有にはセキュリティ
およびプライバシー上の影響があることに注意する。
購読には限られた存続期間がある。また、プッシュサービスまたは
ユーザーエージェントのいずれかによって、いつでも終了され得る。
ユーザーエージェントおよびアプリケーションサーバーは、購読状態の
変更を管理する準備をしておかなければならない。
2.1. HTTPリソース
このプロトコルは、HTTPリソース[RFC7230]およびリンク関係
[RFC5988]を使用する。次のリソースが定義される。
push service: このリソースは、プッシュメッセージ購読（Section 4）を
作成するために使用される。プッシュサービスのURLはユーザー
エージェントに構成される。
push message subscription: このリソースは、メッセージ購読に対する
読み取りおよび削除アクセスを提供する。ユーザーエージェントは、
プッシュメッセージ購読を使用してプッシュメッセージ（Section 6）を
受信する。すべてのプッシュメッセージ購読には、厳密に1つの
関連するプッシュリソースがある。
push message subscription set: このリソースは、プッシュメッセージ
購読の集合に対する読み取りおよび削除アクセスを提供する。
ユーザーエージェントは、集合内のすべてのプッシュメッセージ
購読についてプッシュメッセージ（Section 6.1）を受信する。
型"urn:ietf:params:push:set"のリンク関係は、プッシュメッセージ
購読集合を識別する。
push: アプリケーションサーバーは、プッシュリソースを使用して
プッシュメッセージの配信（Section 5）を要求する。
型"urn:ietf:params:push"のリンク関係は、プッシュリソースを識別する。
push message: プッシュサービスは、配信のために受け入れられた
プッシュメッセージ（Section 5）を識別するためにプッシュ
メッセージリソースを作成する。プッシュメッセージリソースは、
ユーザーエージェントがプッシュメッセージの受信（Section 6.2）を
確認応答するためにも削除される。
receipt subscription: アプリケーションサーバーは、受領確認購読を
使用してプッシュメッセージの配信確認（Section 5.1）を受信する。
型"urn:ietf:params:push:receipt"のリンク関係は、受領確認購読を
識別する。
Thomson, et al. 標準化過程 [Page 7]
RFC 8030 HTTP Web Push 2016年12月
3. プッシュサービスへの接続
プッシュサービスは、[RFC7525]の推奨事項に従い、Transport Layer Security
（TLS）[RFC2818]上のHTTPを使用しなければならない（MUST）。
プッシュサービスはHTTPSと同じデフォルトポート番号（443/TCP）を
共有するが、HTTP代替サービス[RFC7838]を使用してIANA割り当て済み
TCPシステムポート（1001）を広告してもよい（MAY）。
デフォルトポート（443）は広い到達性特性を提供する一方で、最も多くは
Webブラウジングのシナリオで使用され、ミドルボックスで構成された他の
ポートよりも短いアイドルタイムアウトを持つ。WebPushシナリオでは、
これはバッテリー駆動機器で接続を維持するための不必要な無線通信に
つながる。
代替ポート（1001）を広告することで、ミドルボックスは、データ交換が
まれであるという期待のもと、プッシュシナリオに固有の接続の
アイドルタイムアウトを最適化できる。
ミドルボックスは[RFC5382]のREQ-5に従うべきであり（SHOULD）、そこでは
「'established connection idle-timeout'の値は2時間4分未満であっては
ならない（MUST NOT）」と述べられている。
4. プッシュメッセージの購読
ユーザーエージェントは、新しい購読を作成するために、構成された
プッシュサービスリソースへPOST要求を送信する。
POST /subscribe HTTP/1.1
Host: push.example.net
201（Created）応答は、プッシュ購読が作成されたことを示す。
要求への応答として作成されたプッシュメッセージ購読リソースのURIは、
Locationヘッダーフィールドで返されなければならない（MUST）。
プッシュサービスは、プッシュメッセージ購読に対応するプッシュ
リソースのURIを、型"urn:ietf:params:push"のリンク関係で提供
しなければならない（MUST）。
プッシュURIをアプリケーションサーバーへ配布するためには、
アプリケーション固有の方法が使用される。このURIが認可されていない
受信者に開示されないことを確実にするため、機密性保護および
アプリケーションサーバー認証が使用されなければならない（MUST）
（Section 8.3）。
Thomson, et al. 標準化過程 [Page 8]
RFC 8030 HTTP Web Push 2016年12月
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
rel="urn:ietf:params:push"
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
Location: https://push.example.net/subscription/LBhhw0OohO-Wl4Oi971UG
4.1. 購読を集合へまとめる
複数のプッシュメッセージ購読を購読集合へまとめることは、プッシュ
サービスおよびユーザーエージェントにとって大きな効率改善を表し得る。
プッシュサービスは、型"urn:ietf:params:push:set"のリンク関係で、
購読集合リソースのURIを提供してもよい（MAY）。
購読集合がプッシュメッセージ購読応答で返された場合、ユーザー
エージェントは、新しいプッシュメッセージ購読を作成する後続の要求に、
型"urn:ietf:params:push:set"のリンク関係でこの購読集合を含める
べきである（SHOULD）。
ユーザーエージェントは、購読の存続期間にわたって集約された方法で
プッシュメッセージを受信できない場合、その購読集合を省略してもよい
（MAY）。これは、ユーザーエージェントが他のプッシュメッセージ受信者を
代理して購読を監視している場合に必要となることがある。
POST /subscribe HTTP/1.1
Host: push.example.net
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
プッシュサービスは、その応答で同じ購読集合を返すべきである
（SHOULD）が、ユーザーエージェントが提供したものを再利用できない場合は
新しい購読集合を返してもよい（MAY）。
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </push/YBJNBIMwwA_Ag8EtD47J4A>;
rel="urn:ietf:params:push"
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
Location: https://push.example.net/subscription/i-nQ3A9Zm4kgSWg8_ZijV
プッシュサービスは、無効な購読集合を含む要求に対して400
（Bad Request）状態コードを返さなければならない（MUST）。プッシュ
サービスは、購読集合を省略した要求を拒否するために429
（Too Many Requests）状態コード[RFC6585]を返してもよい（MAY）。
Thomson, et al. 標準化過程 [Page 9]
RFC 8030 HTTP Web Push 2016年12月
プッシュサービスが要求が同じユーザーエージェントに由来することを
検出する方法は実装固有であるが、TLS接続、送信元IPアドレス、および
ポートなどの周辺情報を考慮に入れることができる。実装者は、一部の
ヒューリスティックが誤検出を生じ、その結果、要求が誤って拒否される
可能性があることに留意する。
5. プッシュメッセージ配信の要求
アプリケーションサーバーは、ユーザーエージェントによって
アプリケーションサーバーへ配布されたプッシュリソースへHTTP POST要求を
送信することで、プッシュメッセージの配信を要求する。プッシュ
メッセージの内容は要求の本文に含まれる。
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
201（Created）応答は、プッシュメッセージが受け入れられたことを示す。
要求への応答として作成されたプッシュメッセージリソースのURIは、
Locationヘッダーフィールドで返されなければならない（MUST）。
これは、メッセージがユーザーエージェントへ配信されたことを示す
ものではない。
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:55 GMT
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
5.1. プッシュメッセージ受領確認の要求
アプリケーションサーバーは、プッシュメッセージが配信され、
その後ユーザーエージェントによって確認応答されたときにプッシュ
サービスから確認を要求するために、"respond-async"設定を持つ
Preferヘッダーフィールド[RFC7240]を含めることができる。プッシュ
サービスは、配信確認をサポートしなければならない（MUST）。
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
Prefer: respond-async
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
Thomson, et al. 標準化過程 [Page 10]
RFC 8030 HTTP Web Push 2016年12月
プッシュサービスが確認付き配信のためにメッセージを受け入れる場合、
202（Accepted）応答を返さなければならない（MUST）。要求への応答として
作成されたプッシュメッセージリソースのURIは、Locationヘッダー
フィールドで返されなければならない（MUST）。プッシュサービスはまた、
型"urn:ietf:params:push:receipt"のリンク関係で、受領確認購読
リソースのURIを提供しなければならない（MUST）。
HTTP/1.1 202 Accepted
Date: Thu, 11 Dec 2014 23:56:55 GMT
Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
rel="urn:ietf:params:push:receipt"
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
同じオリジン[RFC6454]への後続の受領確認要求では、アプリケーション
サーバーは、返された受領確認購読を型"urn:ietf:params:push:receipt"の
リンク関係に含めるべきである（SHOULD）。これにより、プッシュサービスに
受領確認を集約する選択肢が与えられる。プッシュサービスは、その応答で
同じ受領確認購読を返すべきである（SHOULD）が、アプリケーション
サーバーが提供したものを再利用できない場合は、新しい受領確認購読を
返してもよい（MAY）。
アプリケーションサーバーは、受領確認購読の存続期間にわたって集約された
方法で受領確認を受信できない場合、その受領確認購読を省略してもよい
（MAY）。これは、アプリケーションサーバーが他のプッシュメッセージ
送信者を代理して受領確認購読を監視している場合に必要となることがある。
プッシュサービスは、無効な受領確認購読を含む要求に対して400
（Bad Request）状態コードを返さなければならない（MUST）。プッシュ
サービスが、維持する受領確認購読の数を制限したい場合、受領確認購読を
省略した受領確認要求を拒否するために429（Too Many Requests）状態
コード[RFC6585]を返してもよい（MAY）。
5.2. プッシュメッセージのTime-To-Live
プッシュサービスは、一定期間プッシュメッセージを保存することで、
プッシュメッセージ配信の信頼性を大幅に向上させることができる。
ユーザーエージェントは多くの場合断続的にしか接続されないため、
プッシュサービスに短期メッセージ保存があることから利益を得る。
配信の遅延は、ユーザーエージェントとの通信をまとめるためにも
使用でき、それにより無線リソースを節約できる。
一部のプッシュメッセージは、一定の時間が経過すると有用でなくなる。
関連性を失った後にメッセージを配信することは無駄である。たとえば、
プッシュメッセージに通話通知が含まれる場合、発信者が通話を断念した後に
Thomson, et al. 標準化過程 [Page 11]
RFC 8030 HTTP Web Push 2016年12月
メッセージを受信しても価値はない。ユーザーエージェント上の
アプリケーションは、無用な警告を生成しないよう、そのメッセージを
抑制せざるを得ない。
アプリケーションサーバーは、プッシュメッセージ配信の要求にTTL
（Time-To-Live）ヘッダーフィールドを含めなければならない（MUST）。
TTLヘッダーフィールドは、プッシュメッセージがプッシュサービスに
よって保持される期間を秒単位で示唆する値を含む。
TTL規則は、秒単位の時間を表す非負整数を指定する。TTL値を解析し
バイナリ形式へ変換する受信者は、少なくとも31ビットの非負整数範囲を
持つ算術型を使用すべきである（SHOULD）。受信者が表現可能な最大整数を
超えるTTL値を受信した場合、または後続の計算でオーバーフローが
発生した場合、その値を2147483648（2^31）とみなさなければならない
（MUST）。
TTL = 1*DIGIT
プッシュサービスは、TTLヘッダーフィールドを省略した要求への応答として
400（Bad Request）状態コードを返さなければならない（MUST）。
プッシュサービスは、要求された期間より短い期間だけプッシュメッセージを
保持してもよい（MAY）。これは、実際のTTLを示すTTLヘッダーフィールドを
応答で返すことによって示される。このTTL値は、アプリケーション
サーバーが提供した値以下でなければならない（MUST）。
TTL期間が経過すると、プッシュサービスは、プッシュメッセージを
ユーザーエージェントへ配信しようとしてはならない（MUST NOT）。
プッシュサービスは、処理における時間計算の誤差を考慮してTTL値を
調整することがある。たとえば、サーバークラスター内でプッシュ
メッセージを配布すると、クロックスキューや伝播遅延により誤差が
生じることがある。
プッシュサービスは、アプリケーションサーバーがプッシュサービスへ
プッシュメッセージを送信する際に費やした時間、またはユーザー
エージェントへプッシュメッセージを送信する際に発生した遅延を
考慮する義務はない。アプリケーションサーバーは、TTLヘッダー
フィールド値を選択する際に、転送遅延を考慮する必要がある。
TTLがゼロのプッシュメッセージは、ユーザーエージェントがメッセージを
受信可能である場合、直ちに配信される。配信後、プッシュサービスは、
TTLがゼロのプッシュメッセージを直ちに削除することを許可される。
これは、ユーザーエージェントがプッシュメッセージリソースに対して
HTTP DELETEを実行してメッセージの受信を確認応答する前に発生し得る。
したがって、アプリケーションサーバーは、TTLがゼロのプッシュ
メッセージについて確認応答受領確認を受信することに依存できない。
Thomson, et al. 標準化過程 [Page 12]
RFC 8030 HTTP Web Push 2016年12月
ユーザーエージェントが利用できない場合、TTLがゼロのプッシュ
メッセージは失効し、決して配信されない。
5.3. プッシュメッセージの緊急度
バッテリー駆動の機器では、長時間休止状態を維持することがしばしば
重要である。特に無線通信は大きな電力を消費し、機器が動作できる
時間の長さを制限する。
些細なメッセージを受信するためにリソースを消費することを避けるには、
アプリケーションサーバーがメッセージの緊急度を伝達でき、またユーザー
エージェントが、特定の緊急度のメッセージだけをプッシュサーバーが
転送するよう要求できると有用である。
アプリケーションサーバーは、プッシュメッセージ配信の要求にUrgency
ヘッダーフィールドを含めてもよい（MAY）。このヘッダーフィールドは
メッセージの緊急度を示す。プッシュサービスは、Urgencyヘッダー
フィールドをユーザーエージェントへ転送してはならない（MUST NOT）。
Urgencyヘッダーフィールドのないプッシュメッセージは、値"normal"を
既定値とする。
ユーザーエージェントは、プッシュメッセージを監視する際に、
受信を希望するプッシュメッセージの最低緊急度を示すため、Urgency
ヘッダーフィールドを含めてもよい（MAY）。プッシュサービスは、
ユーザーエージェントが監視要求で示した値より低い緊急度のプッシュ
メッセージを配信してはならない（MUST NOT）。メッセージを監視する際に
Urgencyヘッダーフィールドを含めないユーザーエージェントには、
あらゆる緊急度のプッシュメッセージが配信される。
Urgencyヘッダーフィールドの文法は次のとおりである。
Urgency = urgency-option
urgency-option = ("very-low" / "low" / "normal" / "high")
緊急度の低い順に示す。
+----------+-----------------------------+--------------------------+
| Urgency | 機器の状態 | アプリケーション例 |
| | | シナリオ |
+----------+-----------------------------+--------------------------+
| very-low | 電源接続中かつWi-Fi接続中 | 広告 |
| low | 電源接続中またはWi-Fi接続中 | トピック更新 |
| normal | 電源接続中でもWi-Fiでもない | チャットまたはカレンダー |
| | | メッセージ |
| high | バッテリー残量低下 | 着信電話または |
| | | 時間依存の警告 |
+----------+-----------------------------+--------------------------+
表1: 例示的なUrgency値
Thomson, et al. 標準化過程 [Page 13]
RFC 8030 HTTP Web Push 2016年12月
要求には、Urgencyヘッダーフィールドの複数の値を含めてはならない
（MUST NOT）。そうでない場合、プッシュサービスは400（Bad Request）
状態コードを返さなければならない（MUST）。
5.4. プッシュメッセージの置換
プッシュサービスによって保存されたプッシュメッセージは、新しい内容で
置き換えることができる。プッシュメッセージが送信されている間に
ユーザーエージェントがオフラインである場合、プッシュメッセージを
更新することで、古くなったメッセージや冗長なメッセージがユーザー
エージェントへ送信される状況を避けられる。
トピックが割り当てられたプッシュメッセージだけが置き換えられる。
トピックを持つプッシュメッセージは、同一トピックを持つ未処理の
プッシュメッセージを置き換える。
プッシュメッセージトピックは、Topicヘッダーフィールドで運ばれる
文字列である。トピックは、同じ購読へ送信されたプッシュメッセージを
関連付けるために使用され、それ以外の意味を伝えない。
Topicヘッダーフィールドの文法は、[RFC7230]で定義された"token"規則を
使用する。
Topic = token
このプロトコルで使用する場合、Topicヘッダーフィールドは、URLおよび
ファイル名に安全なBase64アルファベット[RFC4648]から最大32文字に
制限されなければならない（MUST）。これらの制約を満たさないTopic
ヘッダーフィールドを持つ要求を受信したプッシュサービスは、
アプリケーションサーバーに対して400（Bad Request）状態コードを
返さなければならない（MUST）。
プッシュメッセージ置換要求は、新しいプッシュメッセージリソースを
作成すると同時に、一致するトピックを持つ既存のメッセージリソースを
削除する。削除されたプッシュメッセージの配信が試みられていた場合、
プッシュメッセージが置き換えられた後に確認応答がプッシュサービスへ
到着することがある。そのような削除済みメッセージに対する配信受領確認は
抑制されるべきである（SHOULD）。
置換要求はまた、一致するトピックの前のメッセージに関連付けられた
保存済みTTL、Urgency、および任意の受領確認購読も置き換える。
同じ購読への未処理メッセージと共有されていないトピックを持つプッシュ
メッセージは、通常どおり保存または配信される。
Thomson, et al. 標準化過程 [Page 14]
RFC 8030 HTTP Web Push 2016年12月
たとえば、次のメッセージは既存のメッセージを置き換える原因となり得る。
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 600
Topic: upd
Content-Type: text/plain;charset=utf8
Content-Length: 36
ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF
プッシュサービスが"upd"というトピックを持つ未処理のプッシュ
メッセージを識別した場合、そのメッセージリソースは削除される。
201（Created）応答は、プッシュメッセージ置換が受け入れられたことを
示す。要求への応答として作成された新しいプッシュメッセージ
リソースのURIは、Locationヘッダーフィールドに含まれる。
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:57:02 GMT
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
Topicヘッダーフィールドの値は、ユーザーエージェントへ転送しては
ならない（MUST NOT）。その値は暗号化も認証もされない。
6. 購読に対するプッシュメッセージの受信
ユーザーエージェントは、プッシュメッセージ購読リソースへGET要求を
行うことで、新しいプッシュメッセージの配信を要求する。プッシュ
サービスはこの要求に応答しない。代わりに、アプリケーションサーバーから
送信されたプッシュメッセージの内容をHTTP/2サーバープッシュ[RFC7540]を
使用して送信する。
ユーザーエージェントは、その要求にUrgencyヘッダーフィールドを含めても
よい（MAY）。プッシュサービスは、表1（例示的なUrgency値）で定義
されるように、そのヘッダーフィールドの値より低い緊急度のメッセージを
配信してはならない（MUST NOT）。
各プッシュメッセージは、PUSH_PROMISEで送信される合成GET要求への応答
としてプッシュされる。このGET要求は、アプリケーションサーバーが
メッセージ配信を要求したときにプッシュサービスによって作成された
プッシュメッセージリソースに対して行われる。応答ヘッダーは、
型"urn:ietf:params:push"のリンク関係で、プッシュメッセージ購読に
対応するプッシュリソースのURIを提供すべきである（SHOULD）。応答本文は、
アプリケーションサーバーがプッシュリソースへ送信した最新の要求の
エンティティ本文である。
Thomson, et al. 標準化過程 [Page 15]
RFC 8030 HTTP Web Push 2016年12月
次の例の要求はHTTP/2上で行われる。
HEADERS [stream 7] +END_STREAM +END_HEADERS
:method = GET
:path = /subscription/LBhhw0OohO-Wl4Oi971UG
:authority = push.example.net
プッシュサービスは、要求が未完了のまま残ることを許可する。アプリケーション
サーバーからプッシュメッセージが送信されると、初期要求に関連付けて
サーバープッシュが生成される。サーバープッシュの応答にはプッシュ
メッセージが含まれる。
PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS
:method = GET
:path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
:authority = push.example.net
HEADERS [stream 4] +END_HEADERS
:status = 200
date = Thu, 11 Dec 2014 23:56:56 GMT
last-modified = Thu, 11 Dec 2014 23:56:55 GMT
cache-control = private
link = </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
rel="urn:ietf:params:push"
content-type = text/plain;charset=utf8
content-length = 36
DATA [stream 4] +END_STREAM
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
HEADERS [stream 7] +END_STREAM +END_HEADERS
:status = 200
ユーザーエージェントは、"wait"設定を"0"に設定したPreferヘッダー
フィールド[RFC7240]を含めることで、プッシュメッセージ購読リソースの
内容を直ちに要求することもできる。この要求への応答として、プッシュ
サービスは、まだ配信されていないすべてのプッシュメッセージに対して
サーバープッシュを生成しなければならない（MUST）。
関連するサーバープッシュを伴わない204（No Content）状態コードは、
現在利用可能なメッセージがないことを示す。これは、プッシュメッセージが
失効したためである可能性がある。
Thomson, et al. 標準化過程 [Page 16]
RFC 8030 HTTP Web Push 2016年12月
6.1. 購読集合に対するプッシュメッセージの受信
購読に対するプッシュメッセージの受信と、購読集合に対する受信との間には
小さな違いがある。購読集合が利用可能である場合、ユーザーエージェントは、
個々のプッシュメッセージ購読ではなく、購読集合を使用してプッシュ
メッセージを監視すべきである（SHOULD）。
ユーザーエージェントは、プッシュメッセージ購読集合リソースへGET要求を
行うことで、プッシュメッセージ購読の集合に対する新しいプッシュ
メッセージの配信を要求する。プッシュサービスはこの要求に応答しない。
代わりに、アプリケーションサーバーから送信されたプッシュメッセージの
内容をHTTP/2サーバープッシュ[RFC7540]を使用して送信する。
ユーザーエージェントは、その要求にUrgencyヘッダーフィールドを含めても
よい（MAY）。プッシュサービスは、表1（例示的なUrgency値）で定義
されるように、そのヘッダーフィールドの値より低い緊急度のメッセージを
配信してはならない（MUST NOT）。
各プッシュメッセージは、PUSH_PROMISEで送信される合成GET要求への応答
としてプッシュされる。このGET要求は、アプリケーションサーバーが
メッセージ配信を要求したときにプッシュサービスによって作成された
プッシュメッセージリソースに対して行われる。合成要求は、
型"urn:ietf:params:push"のリンク関係で、プッシュメッセージ購読に
対応するプッシュリソースのURIを提供しなければならない（MUST）。
これにより、ユーザーエージェントはメッセージの発信元を区別できる。
応答本文は、アプリケーションサーバーによってプッシュリソースへ送信された
最新の要求のエンティティ本文である。
次の例の要求はHTTP/2上で行われる。
HEADERS [stream 7] +END_STREAM +END_HEADERS
:method = GET
:path = /subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy
:authority = push.example.net
プッシュサービスは、要求が未完了のまま残ることを許可する。アプリケーション
サーバーからプッシュメッセージが送信されると、初期要求に関連付けて
サーバープッシュが生成される。サーバープッシュの応答にはプッシュ
メッセージが含まれる。
PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS
:method = GET
:path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
:authority = push.example.net
Thomson, et al. 標準化過程 [Page 17]
RFC 8030 HTTP Web Push 2016年12月
HEADERS [stream 4] +END_HEADERS
:status = 200
date = Thu, 11 Dec 2014 23:56:56 GMT
last-modified = Thu, 11 Dec 2014 23:56:55 GMT
link = </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
rel="urn:ietf:params:push"
cache-control = private
content-type = text/plain;charset=utf8
content-length = 36
DATA [stream 4] +END_STREAM
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
HEADERS [stream 7] +END_STREAM +END_HEADERS
:status = 200
ユーザーエージェントは、"wait"設定を"0"に設定したPreferヘッダー
フィールド[RFC7240]を含めることで、プッシュメッセージ購読集合
リソースの内容を直ちに要求できる。この要求への応答として、プッシュ
サービスは、まだ配信されていないすべてのプッシュメッセージに対して
サーバープッシュを生成しなければならない（MUST）。
関連するサーバープッシュを伴わない204（No Content）状態コードは、
現在利用可能なメッセージがないことを示す。これは、プッシュメッセージが
失効したためである可能性がある。
6.2. プッシュメッセージの確認応答
プッシュメッセージが少なくとも1回はユーザーエージェントへ適切に
配信されることを確実にするため、ユーザーエージェントは、プッシュ
メッセージリソースに対してHTTP DELETEを実行して、メッセージの受信を
確認応答しなければならない（MUST）。
DELETE /message/qDIYHNcfAIPP_5ITvURr-d6BGt HTTP/1.1
Host: push.example.net
プッシュサービスが確認応答を受信し、アプリケーションが配信受領確認を
要求していた場合、プッシュサービスは受領確認購読を監視している
アプリケーションサーバーへ204（No Content）応答を返さなければ
ならない（MUST）。
プッシュサービスが合理的な時間内に確認応答を受信しない場合、その
メッセージはまだ配信されていないとみなされる。プッシュサービスは、
広告された失効までメッセージの配信を再試行し続けるべきである
（SHOULD）。
プッシュサービスは、応答しないユーザーエージェントや運用上の制約
などのシナリオにより、広告された失効の前にメッセージの配信再試行を
停止してもよい（MAY）。アプリケーションが
Thomson, et al. 標準化過程 [Page 18]
RFC 8030 HTTP Web Push 2016年12月
配信受領確認を要求していた場合、プッシュサービスは受領確認購読を
監視しているアプリケーションサーバーへ410（Gone）応答を返さなければ
ならない（MUST）。
6.3. プッシュメッセージ受領確認の受信
アプリケーションサーバーは、受領確認購読リソースへHTTP GET要求を
行うことで、プッシュサービスから受領確認の配信を要求する。プッシュ
サービスはこの要求に応答しない。代わりに、ユーザーエージェントにより
メッセージが確認応答されたとき（Section 6.2）に、HTTP/2サーバー
プッシュ[RFC7540]を使用してプッシュ受領確認を送信する。
各受領確認は、PUSH_PROMISEで送信される合成GET要求への応答として
プッシュされる。このGET要求は、アプリケーションサーバーがメッセージ
配信を要求したときにプッシュサービスによって作成された同じプッシュ
メッセージリソースに対して行われる。応答には、メッセージ配信の結果を
示す状態コードが含まれ、データは運ばない。
次の例の要求はHTTP/2上で行われる。
HEADERS [stream 13] +END_STREAM +END_HEADERS
:method = GET
:path = /receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM
:authority = push.example.net
プッシュサービスは、要求が未完了のまま残ることを許可する。ユーザー
エージェントがメッセージを確認応答すると、プッシュサービスは配信
受領確認をアプリケーションサーバーへプッシュする。204（No Content）
状態コードは、メッセージが配信され、確認応答されたことを確認する。
PUSH_PROMISE [stream 13; promised stream 82] +END_HEADERS
:method = GET
:path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
:authority = push.example.net
HEADERS [stream 82] +END_STREAM
+END_HEADERS
:status = 204
date = Thu, 11 Dec 2014 23:56:56 GMT
ユーザーエージェントがプッシュメッセージの受信を確認応答せず、
プッシュサービスが広告された失効の前にメッセージの配信再試行を
停止した場合、プッシュサービスは410（Gone）状態コードを持つ失敗応答を
プッシュしなければならない（MUST）。
Thomson, et al. 標準化過程 [Page 19]
RFC 8030 HTTP Web Push 2016年12月
7. 運用上の考慮事項
7.1. 負荷管理
プッシュサービスは、非常に多数の開いたTCP接続を維持しなければ
ならない可能性が高い。これらの接続を効果的に管理するには、接続を
サーバーインスタンス間で移動できることに依存する場合がある。
ユーザーエージェントは、307（Temporary Redirect）状態コード[RFC7231]を
サポートしなければならない（MUST）。これは、新しい購読が要求された
時点で、プッシュサービスが負荷を再分配するために使用できる。
負荷を再分配したいサーバーは、HTTP代替サービス[RFC7838]を使用して
これを行うことができる。HTTP代替サービスは、各種リソースの同じURIを
維持しながら負荷を再分配できるようにする。ユーザーエージェントは、
代替接続を確立した後にGOAWAYフレームを使用することで、円滑な移行を
確保できる。
7.2. プッシュメッセージの失効
TTLヘッダーフィールドに基づくプッシュメッセージの保存は、プッシュ
サービスにとって潜在的に大きな量のストレージを構成する。プッシュ
サービスは、メッセージを無期限に保存する義務はない。プッシュサービスは、
TTLヘッダーフィールド（Section 5.2）を使用して、メッセージをどのくらい
保持するつもりかをアプリケーションサーバーに示すことができる。
プッシュメッセージを能動的に監視していないユーザーエージェントは、
その期間中に失効したメッセージを受信しない。
保存され、まだユーザーエージェントへ配信されていないプッシュ
メッセージは、ユーザーエージェントが監視を再開すると配信される。
保存されたプッシュメッセージには、アプリケーションサーバーによって
配信が要求された時刻を示すLast-Modifiedヘッダーフィールド
（[RFC7232]のSection 2.2）を含めるべきである（SHOULD）。
失効したメッセージだけを持つプッシュメッセージ購読リソースへのGET要求は、
プッシュメッセージが一度も送信されなかったかのような応答をもたらす。
プッシュサービスは、過負荷を避けるために保存されるプッシュメッセージの
サイズおよび数を制限する必要がある場合がある。メッセージのサイズを
制限するため、プッシュサービスは、大きすぎるエンティティ本文を含む
要求に応答して413（Payload Too Large）状態コード[RFC7231]を返しても
よい（MAY）。プッシュサービスは、4096バイト以下のサイズのエンティティ
本文に対する応答で413状態コードを返してはならない（MUST NOT）。
Thomson, et al. 標準化過程 [Page 20]
RFC 8030 HTTP Web Push 2016年12月
保存されるプッシュメッセージの数を制限するため、プッシュサービスは、
アプリケーションサーバーがプッシュメッセージ配信要求で提案したものより
短いTime-To-Liveで応答してもよい（MAY）（Section 5.2）。メッセージが
受け入れられた後、プッシュサービスは、広告されたTime-To-Liveの前に
後からメッセージを失効させてもよい（MAY）。アプリケーションサーバーが
配信受領確認を要求していた場合、プッシュサービスは失敗応答
（Section 6.2）を返さなければならない（MUST）。
7.3. 購読の失効
場合によっては、購読を更新できるように終了する必要がある。これは、
プッシュメッセージ購読と受領確認購読の両方に適用される。
プッシュサービスは、いつでも購読を失効させてもよい（MAY）。
ユーザーエージェントから失効したプッシュメッセージ購読リソース
（Section 6）への未処理要求、またはアプリケーションサーバーから
失効した受領確認購読リソース（Section 6.3）への未処理要求がある場合、
これは404（Not Found）状態コードを返すことで通知されなければならない
（MUST）。
アプリケーションサーバーが失効したプッシュメッセージ購読へプッシュ
メッセージを送信しようとした場合、プッシュサービスは404（Not Found）
状態コードを返さなければならない（MUST）。
ユーザーエージェントは、対応するURIへDELETE要求を送信することで、
そのプッシュメッセージ購読を削除できる。アプリケーションサーバーは、
対応するURIへDELETE要求を送信することで、その受領確認購読を削除できる。
7.3.1. 購読集合の失効
プッシュサービスは、いつでも購読集合を失効させてもよく（MAY）、
またその集合内のすべてのプッシュメッセージ購読も失効させなければ
ならない（MUST）。ユーザーエージェントがプッシュ購読集合
（Section 6.1）に対する未処理要求を持つ場合、これは404（Not Found）
状態コードを返すことで通知されなければならない（MUST）。
ユーザーエージェントは、購読集合URIへDELETE要求を送信することで、
購読集合の削除を要求できる。これにより、集合内のすべてのプッシュ
メッセージ購読も削除されなければならない（MUST）。
購読集合のメンバーである特定のプッシュメッセージ購読が失効または
削除された場合、それはその購読集合からも削除されなければならない
（MUST）。
Thomson, et al. 標準化過程 [Page 21]
RFC 8030 HTTP Web Push 2016年12月
7.4. アプリケーションの信頼性への影響
断続的なネットワーク接続や機器上で失敗するアプリケーションに対する
信頼性のある配信をサポートしないプッシュサービスは、機器に対して
アプリケーションサーバーへ直接受信を確認応答することを強制し、
個々のアプリケーションサーバーへの（通常はセキュアな）接続を確立し
維持するために、追加の電力消費を生じさせる。
プッシュメッセージにアプリケーション状態に不可欠な情報が含まれる場合、
プッシュメッセージの信頼性は重要になり得る。状態の修復は、特に通信能力が
限られた機器では高コストになり得る。プッシュメッセージが正しく受信された
ことを知ることで、再送、ポーリング、および状態の再同期を避けられる。
プッシュメッセージ配信受領確認が利用できることにより、プッシュサービスが
重要なメッセージを配信できない場合に備えて、アプリケーション開発者が
代替のメッセージ配信機構を作成しようとする誘惑を防ぐことができる。
これらの欠点を補うためにポーリング機構やバックアップメッセージング
チャネルを設定すると、プッシュサービスが提供する利点のほぼすべてが
打ち消される。
ただし、一過性のメッセージ（例: 着信通話）や、すぐに置き換えられる
メッセージ（例: 現在の未読メール数）については、信頼性は必要でない
場合がある。
7.5. 購読集合と並行HTTP/2ストリーム
プッシュサービスがユーザーエージェントにプッシュメッセージ購読集合の
使用を要求する場合、HTTP/2 SETTINGSフレーム[RFC7540]内の
SETTINGS_MAX_CONCURRENT_STREAMSパラメーターによって、並行してアクティブな
ストリームの数を制限してもよい（MAY）。ユーザーエージェントは、
プッシュメッセージ購読を管理するための1つの並行ストリームと、
プッシュサービスによって返される各購読集合につき1つの並行ストリームに
制限されてもよい（MAY）。これにより、ユーザーエージェントはプッシュ
サービスへの購読要求を直列化することを強制される可能性がある。
8. セキュリティ上の考慮事項
このプロトコルは、[RFC7525]の推奨事項に従い、Transport Layer Security
（TLS）[RFC2818]上のHTTPを使用しなければならない（MUST）。これには、
ユーザーエージェントとプッシュサービスの間の通信、および
アプリケーションサーバーとプッシュサービスの間の通信が含まれる。
したがって、すべてのURIは"https"スキームを使用する。これにより、
外部の当事者から購読およびプッシュメッセージを保護するための
機密性と完全性保護が提供される。
Thomson, et al. 標準化過程 [Page 22]
RFC 8030 HTTP Web Push 2016年12月
8.1. プッシュサービスアクセスからの機密性
TLSによって提供される保護は、プッシュサービスから内容を保護しない。
追加の保護策がない場合、プッシュサービスはメッセージ内容を検査し、
変更できる。
このプロトコルを使用するアプリケーションは、エンドツーエンドの
機密性、完全性、およびデータ発信元認証を提供する機構を使用しなければ
ならない（MUST）。プッシュメッセージを送信するアプリケーションサーバーと、
それを受信するユーザーエージェント上のアプリケーションは、しばしば
同じアプリケーションの異なるインスタンスにすぎないため、適切な
セキュリティコンテキストを確立するための標準化されたプロトコルは
必要ない。ユーザーエージェントからそのアプリケーションサーバーへの
購読情報の配布も、鍵合意のための便利な媒体を提供する。
この要件のため、W3C Push API [API]は、プッシュサービスから
メッセージ内容を保護するために、Message Encryption for WebPush
[ENCRYPT]を採用している。他のシナリオは、同様のポリシーによって
対処できる。
Topicヘッダーフィールドは、同じ主題のプッシュメッセージについて
より細かな相関を可能にする情報を公開する。これは、プッシュサービスに
よるプッシュメッセージのトラフィック分析を支援するために使用される
可能性がある。
8.2. プライバシー上の考慮事項
プッシュメッセージの機密性は、誰が通信しているか、またいつ通信しているかの
身元が保護されることを保証しない。ただし、公開される情報量は制限できる。
プッシュリソースに提供されるURIは、特定のユーザーエージェントに関する
通信を相関させる根拠を一切提供してはならない（MUST NOT）。任意の2つの
プッシュリソースURIを、その内容だけに基づいて相関させることが可能で
あってはならない（MUST NOT）。これにより、ユーザーエージェントは、
異なるアプリケーション間または時間をまたいだ相関を制御できる。
もちろん、これはユーザーエージェントが公開する可能性のある他の情報を
使用した相関を防ぐものではない。
同様に、プッシュメッセージを識別するためにプッシュサービスが提供するURIは、
購読間の相関を可能にする情報を一切提供してはならない（MUST NOT）。
同じ購読に対するプッシュメッセージURIは、関連付けられた購読または
その購読に対する他のプッシュメッセージとの相関を可能にする情報を
含んでもよい（MAY）。
ユーザー情報および機器情報は、プッシュURIまたはプッシュメッセージURIを
通じて公開されてはならない（MUST NOT）。
Thomson, et al. 標準化過程 [Page 23]
RFC 8030 HTTP Web Push 2016年12月
加えて、同じユーザーエージェントによって確立されたプッシュURIまたは
同じ購読に対するプッシュメッセージURIは、それらをユーザーエージェントと
相関させることを可能にする情報を一切含んではならない（MUST NOT）。
注: これは、結果として得られる匿名性集合（[RFC6973], Section 6.1.1）が
十分に大きい限り、完全である必要はない。プッシュURIは必然的に
プッシュサービスまたは単一のサーバーインスタンスを識別する。
トラフィック分析を使用して購読を相関させることも可能である。
ユーザーエージェントは、いつでも新しい識別子を持つ新しい購読を
作成できなければならない（MUST）。
8.3. 認可
このプロトコルは、ユーザーエージェントが購読を作成することを許可されて
いるかどうか、またはプッシュメッセージをユーザーエージェントへ配信
できるかどうかを、プッシュサービスがどのように確立するかを定義しない。
プッシュサービスは、利用可能な任意のHTTP互換認可方法に基づいて要求を
認可することを選択してもよく（MAY）、これにはセキュリティレベルが異なる
複数の選択肢（実験的な選択肢を含む）がある。認可プロセスおよび関連する
任意の資格情報は、プッシュサービスのURIとともにユーザーエージェントに
構成されることが期待される。
認可は、プッシュメッセージ購読、プッシュ、および受領確認購読リソースの
capability URLを使用して管理される（[CAP-URI]）。
capability URLは、URLの知識だけに基づいてリソースへのアクセスを付与する。
capability URLは、その「容易な onward sharing」および「容易なクライアント
API」という特性のために使用される。これらの特性により、プッシュサービスと
アプリケーションサーバーの間で、事前に取り決められた関係や追加の
プロトコルに依存することを避けられる。
capability URLはベアラートークンとして機能する。プッシュメッセージ購読URIを
知っていることは、プッシュメッセージを受信する、または購読を削除する
いずれかの認可を意味する。プッシュURIを知っていることは、プッシュ
メッセージを送信する認可を意味する。プッシュメッセージURIを知っている
ことは、その特定のメッセージを読み取り、確認応答することを可能にする。
受領確認購読URIを知っていることは、プッシュ受領確認を受信する認可を
意味する。
パスコンポーネントに大量のランダムエントロピー（少なくとも120ビット）を
符号化することで、有効なcapability URLを推測して成功することが困難になる。
Thomson, et al. 標準化過程 [Page 24]
RFC 8030 HTTP Web Push 2016年12月
8.4. サービス拒否に関する考慮事項
ユーザーエージェントは、有効なプッシュメッセージの発信元を、
プッシュURIの配布を認可されたアプリケーションサーバーに制限することで
制御できる。プッシュURIを推測困難にすることで、プッシュURIを受け取った
アプリケーションサーバーだけがそれを使用できることが確保される。
ユーザーエージェントによって正常に認証されないプッシュメッセージは
配信されないが、これはサービス拒否リスクを生じ得る。比較的少量の
プッシュメッセージであっても、バッテリー駆動機器の電力を使い果たす
原因となり得る。
この場合に対処するため、W3C Push API [API]はVoluntary
Application Server Identification [VAPID]を採用している。これは、
ユーザーエージェントが購読を特定のアプリケーションサーバーに制限できる
ようにする。これにより、プッシュサービスはユーザーエージェントへ接触せずに
不要なメッセージを識別して拒否できる。
有効なプッシュURIを持つ悪意のあるアプリケーションは、プッシュサービスの
より大きなリソースを使用して、ユーザーエージェントに対するサービス拒否
攻撃を行う可能性がある。プッシュサービスは、個々のユーザーエージェントへ
プッシュメッセージが送信される速度を制限すべきである（SHOULD）。
プッシュサービスは、アプリケーションサーバーがプッシュリソースへの
プッシュメッセージ配信に関するレート制限を超えた場合、429
（Too Many Requests）状態コード[RFC6585]を返してもよい（MAY）。
プッシュサービスはまた、アプリケーションサーバーがプッシュリソースへ
別の要求を行う前に待機するよう求められる時間を示すため、Retry-After
ヘッダー[RFC7231]を含めるべきである（SHOULD）。
プッシュサービスまたはユーザーエージェントは、あまりにも多くの
プッシュメッセージを受信する購読（Section 7.3）を終了してもよい
（MAY）。
プッシュサービスは、ユーザーエージェントに対してサービスを拒否することも
できる。意図的なメッセージ配信失敗は、一時的なネットワークエラー、
ユーザーエージェントの利用可能性の中断、または実際のサービス停止に
起因し得る障害と区別することが困難である。
8.5. ログ記録のリスク
サーバー要求ログは、購読関連URIまたは同じユーザーエージェントに対する
購読関連URI間の関係を明らかにする可能性がある。ログ保持の制限および
強力なアクセス制御機構により、URIが認可されていない実体へ明らかに
されないことを確保できる。
Thomson, et al. 標準化過程 [Page 25]
RFC 8030 HTTP Web Push 2016年12月
9. IANAに関する考慮事項
このプロトコルは、Section 9.1で新しいHTTPヘッダーフィールドを定義する。
新しいリンク関係型は、Section 9.2で定義されるURNを使用して識別される。
ポート登録はSection 9.3で定義される。
9.1. ヘッダーフィールド登録
HTTPヘッダーフィールドは、<https://www.iana.org/assignments/message-
headers/>で維持されている"Message Headers"レジストリ内に登録される。
この文書は次のHTTPヘッダーフィールドを定義し、次のエントリーが
"Permanent Message Header Field Names"レジストリ（[RFC3864]）に
追加された。
+-------------------+----------+----------+--------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+--------------+
| TTL | http | standard | Section 5.2 |
| Urgency | http | standard | Section 5.3 |
| Topic | http | standard | Section 5.4 |
+-------------------+----------+----------+--------------+
変更管理者は次のとおりである。"IETF (iesg@ietf.org) - Internet
Engineering Task Force"。
9.2. リンク関係URN
この文書は、リンク関係型を識別するために使用するURNを登録する。
これらは、[RFC3553]のSection 4の手順に従って新しい"Web Push
Identifiers"レジストリへ追加された。対応する"push"サブ名前空間は、
"IETF URN Sub-namespace for Registered Protocol Parameter Identifiers"
レジストリへ登録された。
"Web Push Identifiers"レジストリは、IETF Reviewポリシー[RFC5226]の下で
運用される。
レジストリ名: Web Push Identifiers
URN Prefix: urn:ietf:params:push
仕様: RFC 8030（この文書）
リポジトリ: http://www.iana.org/assignments/webpush-parameters/
Thomson, et al. 標準化過程 [Page 26]
RFC 8030 HTTP Web Push 2016年12月
Index Value: このレジストリ内の値は、接頭辞"urn:ietf:params:push"で
始まるURNまたはURN接頭辞である。各値は独立して登録される。
"Web Push Identifiers"レジストリへの登録には、次の情報が含まれる。
URN: 完全なURNまたはURN接頭辞。
Description: 概要説明。
Contact: 登録を行う人物またはグループのメール。
Index Value: [RFC3553]で記述されているとおり。
Reference: URNまたはURN接頭辞の意味を記述する仕様への参照。
登録されるURN接頭辞には、URNがどのように構築されるかの説明が
含まれる。これは特定のURNには適用されない。
これらの値は、"Web Push Identifiers"レジストリの初期内容として
登録される。
URN: urn:ietf:params:push
Description: このリンク関係型は、プッシュメッセージを送信するための
リソースを識別するために使用される。
Contact: IETFのWEBPUSH WG（webpush@ietf.org）
Reference: RFC 8030（この文書）
URN: urn:ietf:params:push:set
Description: このリンク関係型は、プッシュメッセージ購読の集合を
識別するために使用される。
Contact: IETFのWEBPUSH WG（webpush@ietf.org）
Reference: RFC 8030（この文書）
URN: urn:ietf:params:push:receipt
Description: このリンク関係型は、プッシュメッセージの配信確認を
受信するためのリソースを識別するために使用される。
Contact: IETFのWEBPUSH WG（webpush@ietf.org）
Thomson, et al. 標準化過程 [Page 27]
RFC 8030 HTTP Web Push 2016年12月
Reference: RFC 8030（この文書）
9.3. サービス名およびポート番号登録
サービス名およびポート番号は、<https://www.iana.org/assignments/service-names-port-numbers/>で
維持されている"Service Name and Transport Protocol Port Number Registry"内に
登録される。
[RFC6335]に従い、IANAはシステムポート番号1001およびサービス名
"webpush"を割り当てた。
Service Name:
webpush
Port Number:
1001
Transport Protocol:
tcp
Description:
HTTP Web Push
Assignee:
The IESG (iesg@ietf.org)
Contact:
The IETF Chair (chair@ietf.org)
Reference:
RFC 8030（この文書）
10. 参考文献
10.1. 規範的参考文献
[CAP-URI] Tennison, J., "Good Practices for Capability URLs", W3C
First Public Working Draft capability-urls, February 2014,
<http://www.w3.org/TR/capability-urls/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
Thomson, et al. 標準化過程 [Page 28]
RFC 8030 HTTP Web Push 2016年12月
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008,
<http://www.rfc-editor.org/info/rfc5382>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<http://www.rfc-editor.org/info/rfc6585>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
Thomson, et al. 標準化過程 [Page 29]
RFC 8030 HTTP Web Push 2016年12月
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<http://www.rfc-editor.org/info/rfc7232>.
[RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
DOI 10.17487/RFC7240, June 2014,
<http://www.rfc-editor.org/info/rfc7240>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <http://www.rfc-editor.org/info/rfc7838>.
10.2. 参考情報
[API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
B., and E. Fullea, "Push API", W3C Editor's Draft push-
api, November 2016, <https://w3c.github.io/push-api/>.
[ENCRYPT] Thomson, M., "Message Encryption for Web Push", Work in
Progress, draft-ietf-webpush-encryption-06, October 2016.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[VAPID] Thomson, M. and P. Beverloo, "Voluntary Application Server
Identification for Web Push", Work in Progress,
draft-ietf-webpush-vapid-01, June 2016.
Thomson, et al. 標準化過程 [Page 30]
RFC 8030 HTTP Web Push 2016年12月
謝辞
この文書への重要な技術的入力は、Ben Bangert、Peter Beverloo、
Kit Cambridge、JR Conlin、Lucas Jenss、Matthew Kaufman、
Costin Manolache、Mark Nottingham、Idel Pivnitskiy、Robert Sparks、
Darshak Thakore、および多くの他の人々によって提供された。
著者の連絡先
Martin Thomson
Mozilla
331 E Evelyn Street
Mountain View, CA 94041
United States of America
Email: martin.thomson@gmail.com
Elio Damaggio
Microsoft
One Microsoft Way
Redmond, WA 98052
United States of America
Email: elioda@microsoft.com
Brian Raymor (editor)
Microsoft
One Microsoft Way
Redmond, WA 98052
United States of America
Email: brian.raymor@microsoft.com
Thomson, et al. 標準化過程 [Page 31]