[要約] RFC 8030は、HTTP Pushを使用した汎用イベント配信に関する仕様であり、イベントの非同期配信を可能にするためのプロトコルを提供します。目的は、イベントベースのアプリケーションやシステム間の効率的な通信を実現することです。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8030 Mozilla
Category: Standards Track E. Damaggio
ISSN: 2070-1721 B. Raymor, Ed.
Microsoft
December 2016
Generic Event Delivery Using HTTP Push
HTTPプッシュを使用した一般的なイベント配信
Abstract
概要
This document describes a simple protocol for the delivery of real-time events to user agents. This scheme uses HTTP/2 server push.
このドキュメントでは、ユーザーエージェントにリアルタイムイベントを配信するための簡単なプロトコルについて説明します。このスキームは、HTTP / 2サーバープッシュを使用します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8030.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. HTTP Resources . . . . . . . . . . . . . . . . . . . . . 7
3. Connecting to the Push Service . . . . . . . . . . . . . . . 8
4. Subscribing for Push Messages . . . . . . . . . . . . . . . . 8
4.1. Collecting Subscriptions into Sets . . . . . . . . . . . 9
5. Requesting Push Message Delivery . . . . . . . . . . . . . . 10
5.1. Requesting Push Message Receipts . . . . . . . . . . . . 10
5.2. Push Message Time-To-Live . . . . . . . . . . . . . . . . 11
5.3. Push Message Urgency . . . . . . . . . . . . . . . . . . 13
5.4. Replacing Push Messages . . . . . . . . . . . . . . . . . 14
6. Receiving Push Messages for a Subscription . . . . . . . . . 15
6.1. Receiving Push Messages for a Subscription Set . . . . . 17
6.2. Acknowledging Push Messages . . . . . . . . . . . . . . . 18
6.3. Receiving Push Message Receipts . . . . . . . . . . . . . 19
7. Operational Considerations . . . . . . . . . . . . . . . . . 20
7.1. Load Management . . . . . . . . . . . . . . . . . . . . . 20
7.2. Push Message Expiration . . . . . . . . . . . . . . . . . 20
7.3. Subscription Expiration . . . . . . . . . . . . . . . . . 21
7.3.1. Subscription Set Expiration . . . . . . . . . . . . . 21
7.4. Implications for Application Reliability . . . . . . . . 22
7.5. Subscription Sets and Concurrent HTTP/2 Streams . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Confidentiality from Push Service Access . . . . . . . . 23
8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 23
8.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 24
8.4. Denial-of-Service Considerations . . . . . . . . . . . . 25
8.5. Logging Risks . . . . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. Header Field Registrations . . . . . . . . . . . . . . . 26
9.2. Link Relation URNs . . . . . . . . . . . . . . . . . . . 26
9.3. Service Name and Port Number Registration . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 30
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Many applications on mobile and embedded devices require continuous access to network communications so that real-time events -- such as incoming calls or messages -- can be delivered (or "pushed") in a timely fashion. These devices typically have limited power reserves, so finding more efficient ways to serve application requirements greatly benefits the application ecosystem.
モバイルデバイスや組み込みデバイスの多くのアプリケーションは、ネットワーク通信への継続的なアクセスを必要とするため、着信やメッセージなどのリアルタイムのイベントをタイムリーに配信（または「プッシュ」）できます。これらのデバイスは通常、パワーリザーブが限られているため、アプリケーション要件に対応するためのより効率的な方法を見つけることで、アプリケーションエコシステムに大きなメリットがあります。
One significant contributor to power usage is the radio. Radio communications consume a significant portion of the energy budget on a wireless device.
電力使用量の重要な原因の1つは無線です。無線通信は、ワイヤレスデバイスのエネルギーバジェットのかなりの部分を消費します。
Uncoordinated use of persistent connections or sessions from multiple applications can contribute to unnecessary use of the device radio, since each independent session can incur its own overhead. In particular, keep-alive traffic used to ensure that middleboxes do not prematurely time out sessions can result in significant waste. Maintenance traffic tends to dominate over the long term, since events are relatively rare.
複数のアプリケーションからの永続的な接続またはセッションの調整されていない使用は、デバイスの無線の不必要な使用の一因となる可能性があります。独立したセッションごとに独自のオーバーヘッドが発生する可能性があるためです。特に、ミドルボックスが時期尚早にセッションをタイムアウトしないようにするために使用されるキープアライブトラフィックは、かなりの無駄になる可能性があります。イベントは比較的まれなので、メンテナンストラフィックは長期的に支配する傾向があります。
Consolidating all real-time events into a single session ensures more efficient use of network and radio resources. A single service consolidates all events, distributing those events to applications as they arrive. This requires just one session, avoiding duplicated overhead costs.
すべてのリアルタイムイベントを1つのセッションに統合することで、ネットワークリソースと無線リソースをより効率的に使用できます。単一のサービスがすべてのイベントを統合し、到着したイベントをアプリケーションに配信します。これにはセッションが1つだけ必要であり、オーバーヘッドの重複を回避できます。
The W3C Push API [API] describes an API that enables the use of a consolidated push service from web applications. This document expands on that work by describing a protocol that can be used to:
W3CプッシュAPI [API]は、Webアプリケーションからの統合プッシュサービスの使用を可能にするAPIについて説明しています。このドキュメントでは、次の目的で使用できるプロトコルについて説明することで、その作業をさらに詳しく説明します。
o request the delivery of a push message to a user agent,
o ユーザーエージェントへのプッシュメッセージの配信を要求し、
o create new push message delivery subscriptions, and
o 新しいプッシュメッセージ配信サブスクリプションを作成します。
o monitor for new push messages.
o 新しいプッシュメッセージを監視します。
A standardized method of event delivery is particularly important for the W3C Push API, where application servers might need to use multiple push services. The subscription, management, and monitoring functions are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.
イベント配信の標準化された方法は、アプリケーションサーバーが複数のプッシュサービスを使用する必要があるW3CプッシュAPIにとって特に重要です。サブスクリプション、管理、および監視機能は現在、独自のプロトコルによって実現されています。これらは十分ですが、標準化によってもたらされる利点はありません。
This document intentionally does not describe how a push service is discovered. Discovery of push services is left for future efforts, if it turns out to be necessary at all. User agents are expected to be configured with a URL for a push service.
このドキュメントでは、プッシュサービスの検出方法については意図的に説明していません。プッシュサービスの発見は、それがまったく必要であることが判明した場合、将来の取り組みに委ねられます。ユーザーエージェントは、プッシュサービスのURLを使用して構成する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document defines the following terms:
このドキュメントでは、次の用語を定義しています。
application: Both the sender and the ultimate consumer of push messages. Many applications have components that are run on a user agent and other components that run on servers.
アプリケーション：プッシュメッセージの送信者と最終消費者の両方。多くのアプリケーションには、ユーザーエージェントで実行されるコンポーネントと、サーバーで実行されるその他のコンポーネントがあります。
application server: The component of an application that usually runs on a server and requests the delivery of a push message.
アプリケーションサーバー：通常サーバー上で実行され、プッシュメッセージの配信を要求するアプリケーションのコンポーネント。
push message subscription: A message delivery context that is established between the user agent and the push service, and shared with the application server. All push messages are associated with a push message subscription.
プッシュメッセージサブスクリプション：ユーザーエージェントとプッシュサービスの間に確立され、アプリケーションサーバーと共有されるメッセージ配信コンテキスト。すべてのプッシュメッセージは、プッシュメッセージサブスクリプションに関連付けられています。
push message subscription set: A message delivery context that is established between the user agent and the push service that collects multiple push message subscriptions into a set.
プッシュメッセージサブスクリプションセット：複数のプッシュメッセージサブスクリプションを1つのセットに収集する、ユーザーエージェントとプッシュサービスの間に確立されるメッセージ配信コンテキスト。
push message: A message sent from an application server to a user agent via a push service.
プッシュメッセージ：プッシュサービスを介してアプリケーションサーバーからユーザーエージェントに送信されるメッセージ。
push message receipt: A message delivery confirmation sent from the push service to the application server.
プッシュメッセージの受信：プッシュサービスからアプリケーションサーバーに送信されるメッセージ配信確認。
push service: A service that delivers push messages to user agents.
プッシュサービス：ユーザーエージェントにプッシュメッセージを配信するサービス。
user agent: A device and software that is the recipient of push messages.
ユーザーエージェント：プッシュメッセージの受信者であるデバイスとソフトウェア。
Examples in this document use the HTTP/1.1 message format [RFC7230]. Many of the exchanges can be completed using HTTP/1.1:
このドキュメントの例では、HTTP / 1.1メッセージ形式[RFC7230]を使用しています。交換の多くは、HTTP / 1.1を使用して完了することができます。
o Subscribing for Push Messages (Section 4)
o プッシュメッセージのサブスクライブ（セクション4）
o Requesting Push Message Delivery (Section 5)
o プッシュメッセージ配信のリクエスト（セクション5）
o Replacing Push Messages (Section 5.4)
o プッシュメッセージの置き換え（セクション5.4）
o Acknowledging Push Messages (Section 6.2)
o プッシュメッセージの承認（セクション6.2）
When an example depends on HTTP/2 server push, the more verbose frame format from [RFC7540] is used:
例がHTTP / 2サーバープッシュに依存している場合、[RFC7540]のより詳細なフレーム形式が使用されます。
o Receiving Push Messages for a Subscription (Section 6)
o サブスクリプションのプッシュメッセージの受信（セクション6）
o Receiving Push Messages for a Subscription Set (Section 6.1)
o サブスクリプションセットのプッシュメッセージの受信（セクション6.1）
o Receiving Push Message Receipts (Section 6.3)
o プッシュメッセージの受信（セクション6.3）
All examples use HTTPS over the default port (443) rather than the registered port (1001). A push service deployment might prefer this configuration to maximize chances for user agents to reach the service. A push service might use HTTP alternative services to redirect a user agent to the registered port (1001) to gain the benefits of the standardized HTTPS port without sacrificing reachability (see Section 3). This would only be apparent in the examples through the inclusion of the Alt-Used header field [RFC7838] in requests from the user agent to the push service.
すべての例では、登録済みポート（1001）ではなく、デフォルトポート（443）でHTTPSを使用しています。プッシュサービスの展開では、ユーザーエージェントがサービスに到達する可能性を最大化するために、この構成が優先される場合があります。プッシュサービスは、HTTP代替サービスを使用してユーザーエージェントを登録済みポート（1001）にリダイレクトし、到達可能性を犠牲にすることなく標準化されたHTTPSポートの利点を得ることができます（セクション3を参照）。これは、ユーザーエージェントからプッシュサービスへのリクエストにAlt-Usedヘッダーフィールド[RFC7838]を含めることにより、例でのみ明らかになります。
Examples do not include specific methods for push message encryption or application server authentication because the protocol does not define a mandatory system. The examples in Voluntary Application Server Identification [VAPID] and Message Encryption for WebPush [ENCRYPT] demonstrate the approach adopted by the W3C Push API [API] for its requirements.
プロトコルには必須システムが定義されていないため、例にはプッシュメッセージの暗号化やアプリケーションサーバー認証の特定の方法は含まれていません。自主アプリケーションサーバー識別[VAPID]とWebPushのメッセージ暗号化[ENCRYPT]の例は、W3CプッシュAPI [API]がその要件に採用するアプローチを示しています。
A general model for push services includes three basic actors: a user agent, a push service, and an application (server).
プッシュサービスの一般的なモデルには、ユーザーエージェント、プッシュサービス、アプリケーション（サーバー）の3つの基本的なアクターが含まれます。
+-------+ +--------------+ +-------------+
| UA | | Push Service | | Application |
+-------+ +--------------+ | Server |
| | +-------------+
| Subscribe | |
|--------------------->| |
| Monitor | |
|<====================>| |
| | |
| Distribute Push Resource |
|-------------------------------------------->|
| | |
: : :
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
Figure 1: WebPush Architecture
図1：WebPushアーキテクチャ
At the very beginning of the process, a new message subscription is created by the user agent and then distributed to its application server. This subscription is the basis of all future interactions between the actors. A subscription is used by the application server to send messages to the push service for delivery to the user agent. The user agent uses the subscription to monitor the push service for any incoming message.
プロセスの最初に、新しいメッセージサブスクリプションがユーザーエージェントによって作成され、そのアプリケーションサーバーに配布されます。このサブスクリプションは、アクター間の将来のすべての対話の基礎となります。アプリケーションサーバーはサブスクリプションを使用して、ユーザーエージェントに配信するためにメッセージをプッシュサービスに送信します。ユーザーエージェントはサブスクリプションを使用して、受信メッセージのプッシュサービスを監視します。
To offer more control for authorization, a message subscription is modeled as two resources with different capabilities:
承認をより詳細に制御できるように、メッセージサブスクリプションは、機能が異なる2つのリソースとしてモデル化されています。
o A subscription resource is used to receive messages from a subscription and to delete a subscription. It is private to the user agent.
o サブスクリプションリソースは、サブスクリプションからメッセージを受信し、サブスクリプションを削除するために使用されます。これはユーザーエージェントにプライベートです。
o A push resource is used to send messages to a subscription. It is public and shared by the user agent with its application server.
o pushリソースは、サブスクリプションにメッセージを送信するために使用されます。これはパブリックであり、ユーザーエージェントとそのアプリケーションサーバーによって共有されます。
It is expected that a unique subscription will be distributed to each application; however, there are no inherent cardinality constraints in the protocol. Multiple subscriptions might be created for the same application, or multiple applications could use the same subscription. Note, however, that sharing subscriptions has security and privacy implications.
一意のサブスクリプションが各アプリケーションに配布されることが予想されます。ただし、プロトコルには固有のカーディナリティー制約はありません。同じアプリケーションに対して複数のサブスクリプションが作成される場合や、複数のアプリケーションが同じサブスクリプションを使用する場合があります。ただし、サブスクリプションを共有すると、セキュリティとプライバシーに影響することに注意してください。
Subscriptions have a limited lifetime. They can also be terminated by either the push service or the user agent at any time. User agents and application servers must be prepared to manage changes in the subscription state.
サブスクリプションには有効期限があります。また、プッシュサービスまたはユーザーエージェントによっていつでも終了できます。ユーザーエージェントとアプリケーションサーバーは、サブスクリプション状態の変更を管理できるように準備する必要があります。
This protocol uses HTTP resources [RFC7230] and link relations [RFC5988]. The following resources are defined:
このプロトコルは、HTTPリソース[RFC7230]およびリンク関係[RFC5988]を使用します。以下のリソースが定義されています。
push service: This resource is used to create push message subscriptions (Section 4). A URL for the push service is configured into user agents.
プッシュサービス：このリソースは、プッシュメッセージサブスクリプションの作成に使用されます（セクション4）。プッシュサービスのURLは、ユーザーエージェントに構成されます。
push message subscription: This resource provides read and delete access for a message subscription. A user agent receives push messages (Section 6) using a push message subscription. Every push message subscription has exactly one push resource associated with it.
プッシュメッセージサブスクリプション：このリソースは、メッセージサブスクリプションの読み取りおよび削除アクセスを提供します。ユーザーエージェントは、プッシュメッセージサブスクリプションを使用してプッシュメッセージを受信します（セクション6）。すべてのプッシュメッセージサブスクリプションには、1つのプッシュリソースが関連付けられています。
push message subscription set: This resource provides read and delete access for a collection of push message subscriptions. A user agent receives push messages (Section 6.1) for all the push message subscriptions in the set. A link relation of type "urn:ietf:params:push:set" identifies a push message subscription set.
プッシュメッセージサブスクリプションセット：このリソースは、プッシュメッセージサブスクリプションのコレクションに対する読み取りおよび削除アクセスを提供します。ユーザーエージェントは、セット内のすべてのプッシュメッセージサブスクリプションのプッシュメッセージ（セクション6.1）を受信します。タイプ「urn：ietf：params：push：set」のリンク関係は、プッシュメッセージサブスクリプションセットを識別します。
push: An application server requests the delivery (Section 5) of a push message using a push resource. A link relation of type "urn:ietf:params:push" identifies a push resource.
push：アプリケーションサーバーは、pushリソースを使用して、pushメッセージの配信（セクション5）を要求します。タイプ「urn：ietf：params：push」のリンク関係は、プッシュリソースを識別します。
push message: The push service creates a push message resource to identify push messages that have been accepted for delivery (Section 5). The push message resource is also deleted by the user agent to acknowledge receipt (Section 6.2) of a push message.
プッシュメッセージ：プッシュサービスは、プッシュメッセージリソースを作成して、配信が受け入れられたプッシュメッセージを識別します（セクション5）。プッシュメッセージリソースは、プッシュメッセージの受信（セクション6.2）を確認するために、ユーザーエージェントによっても削除されます。
receipt subscription: An application server receives delivery confirmations (Section 5.1) for push messages using a receipt subscription. A link relation of type "urn:ietf:params:push:receipt" identifies a receipt subscription.
受信サブスクリプション：アプリケーションサーバーは、受信サブスクリプションを使用してプッシュメッセージの配信確認（セクション5.1）を受信します。タイプ「urn：ietf：params：push：receipt」のリンク関係は、領収書のサブスクリプションを識別します。
The push service MUST use HTTP over Transport Layer Security (TLS) [RFC2818] following the recommendations in [RFC7525]. The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA-allocated TCP System Port (1001) using HTTP alternative services [RFC7838].
プッシュサービスは、[RFC7525]の推奨事項に従ってHTTP over Transport Layer Security（TLS）[RFC2818]を使用する必要があります。プッシュサービスはHTTPSと同じデフォルトのポート番号（443 / TCP）を共有しますが、HTTP代替サービス[RFC7838]を使用して、IANAが割り当てたTCPシステムポート（1001）も通知できます（MAY）。
While the default port (443) offers broad reachability characteristics, it is most often used for web-browsing scenarios with a lower idle timeout than other ports configured in middleboxes. For WebPush scenarios, this would contribute to unnecessary radio communications to maintain the connection on battery-powered devices.
デフォルトのポート（443）は幅広い到達可能性の特性を提供しますが、ミドルボックスで構成された他のポートよりもアイドルタイムアウトが低いWebブラウジングシナリオで最もよく使用されます。 WebPushシナリオの場合、これは不要な無線通信を引き起こし、電池式デバイスの接続を維持します。
Advertising the alternate port (1001) allows middleboxes to optimize idle timeouts for connections specific to push scenarios with the expectation that data exchange will be infrequent.
代替ポート（1001）をアドバタイズすると、ミドルボックスは、データ交換が頻繁に行われないことを想定して、プッシュシナリオに固有の接続のアイドルタイムアウトを最適化できます。
Middleboxes SHOULD comply with REQ-5 in [RFC5382], which states that "the value of the 'established connection idle-timeout' MUST NOT be less than 2 hours 4 minutes".
ミドルボックスは[RFC5382]のREQ-5に準拠する必要があります（SHOULD）は、「「確立された接続のアイドルタイムアウト」の値は2時間4分未満であってはならない」と述べています。
A user agent sends a POST request to its configured push service resource to create a new subscription.
ユーザーエージェントは、構成済みのプッシュサービスリソースにPOST要求を送信して、新しいサブスクリプションを作成します。
POST /subscribe HTTP/1.1 Host: push.example.net
POST / subscribe HTTP / 1.1ホスト：push.example.net
A 201 (Created) response indicates that the push subscription was created. A URI for the push message subscription resource that was created in response to the request MUST be returned in the Location header field.
201（Created）応答は、プッシュサブスクリプションが作成されたことを示します。リクエストへの応答として作成されたプッシュメッセージサブスクリプションリソースのURIは、Locationヘッダーフィールドに返される必要があります。
The push service MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".
プッシュサービスは、タイプ「urn：ietf：params：push」のリンク関係で、プッシュメッセージサブスクリプションに対応するプッシュリソースのURIを提供する必要があります。
An application-specific method is used to distribute the push URI to the application server. Confidentiality protection and application server authentication MUST be used to ensure that this URI is not disclosed to unauthorized recipients (Section 8.3).
アプリケーション固有のメソッドを使用して、プッシュURIをアプリケーションサーバーに配布します。機密保護とアプリケーションサーバー認証を使用して、このURIが不正な受信者に開示されないようにする必要があります（セクション8.3）。
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
Collecting multiple push message subscriptions into a subscription set can represent a significant efficiency improvement for push services and user agents. The push service MAY provide a URI for a subscription set resource in a link relation of type "urn:ietf:params:push:set".
複数のプッシュメッセージサブスクリプションをサブスクリプションセットに収集すると、プッシュサービスとユーザーエージェントの効率が大幅に向上する場合があります。プッシュサービスは、「urn：ietf：params：push：set」タイプのリンク関係でサブスクリプションセットリソースのURIを提供する場合があります。
When a subscription set is returned in a push message subscription response, the user agent SHOULD include this subscription set in a link relation of type "urn:ietf:params:push:set" in subsequent requests to create new push message subscriptions.
サブスクリプションセットがプッシュメッセージサブスクリプション応答で返される場合、ユーザーエージェントは、新しいプッシュメッセージサブスクリプションを作成する後続のリクエストで、このサブスクリプションセットを「urn：ietf：params：push：set」タイプのリンク関係に含める必要があります。
A user agent MAY omit the subscription set if it is unable to receive push messages in an aggregated way for the lifetime of the subscription. This might be necessary if the user agent is monitoring subscriptions on behalf of other push message receivers.
ユーザーエージェントは、サブスクリプションの有効期間中に集約された方法でプッシュメッセージを受信できない場合、サブスクリプションセットを省略してもよい（MAY）。これは、ユーザーエージェントが他のプッシュメッセージレシーバーに代わってサブスクリプションを監視している場合に必要になることがあります。
POST /subscribe HTTP/1.1
Host: push.example.net
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
The push service SHOULD return the same subscription set in its response, although it MAY return a new subscription set if it is unable to reuse the one provided by the user agent.
プッシュサービスは、応答で同じサブスクリプションセットを返す必要があります（SHOULD）。ただし、ユーザーエージェントによって提供されたサブスクリプションセットを再利用できない場合は、新しいサブスクリプションセットを返す場合があります。
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
A push service MUST return a 400 (Bad Request) status code for requests that contain an invalid subscription set. A push service MAY return a 429 (Too Many Requests) status code [RFC6585] to reject requests that omit a subscription set.
プッシュサービスは、無効なサブスクリプションセットを含むリクエストに対して、400（Bad Request）ステータスコードを返す必要があります。プッシュサービスは、サブスクリプションセットを省略したリクエストを拒否するために、429（Too Many Requests）ステータスコード[RFC6585]を返す場合があります。
How a push service detects that requests originate from the same user agent is implementation-specific but could take ambient information into consideration, such as the TLS connection, source IP address, and port. Implementers are reminded that some heuristics can produce false positives and hence, cause requests to be rejected incorrectly.
プッシュサービスが同じユーザーエージェントからのリクエストを検出する方法は実装固有ですが、TLS接続、送信元IPアドレス、ポートなどの環境情報を考慮することができます。実装者は、一部のヒューリスティックが誤検知を生成し、その結果、リクエストが誤って拒否される可能性があることに注意してください。
An application server requests the delivery of a push message by sending an HTTP POST request to a push resource distributed to the application server by a user agent. The content of the push message is included in the body of the request.
アプリケーションサーバーは、ユーザーエージェントによってアプリケーションサーバーに配布されたプッシュリソースに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
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
A 201 (Created) response indicates that the push message was accepted. A URI for the push message resource that was created in response to the request MUST be returned in the Location header field. This does not indicate that the message was delivered to the user agent.
201（Created）応答は、プッシュメッセージが受け入れられたことを示します。リクエストへの応答として作成されたプッシュメッセージリソースのURIは、Locationヘッダーフィールドに返される必要があります。これは、メッセージがユーザーエージェントに配信されたことを示すものではありません。
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:55 GMT
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
An application server can include the Prefer header field [RFC7240] with the "respond-async" preference to request confirmation from the push service when a push message is delivered and then acknowledged by the user agent. The push service MUST support delivery confirmations.
アプリケーションサーバーは、Preferヘッダーフィールド[RFC7240]に "respond-async"プリファレンスを含めて、プッシュメッセージが配信されてユーザーエージェントによって確認されたときにプッシュサービスからの確認を要求できます。プッシュサービスは、配信確認をサポートする必要があります。
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 When the push service accepts the message for delivery with confirmation, it MUST return a 202 (Accepted) response. A URI for the push message resource that was created in response to the request MUST be returned in the Location header field. The push service MUST also provide a URI for the receipt subscription resource in a link relation of type "urn:ietf:params:push:receipt".
iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iBプッシュサービスが、確認のための配信のためにメッセージを受け入れる場合、202（受け入れられた）応答を返さなければなりません（MUST）。リクエストへの応答として作成されたプッシュメッセージリソースのURIは、Locationヘッダーフィールドに返される必要があります。プッシュサービスは、「urn：ietf：params：push：receipt」タイプのリンク関係で、受信サブスクリプションリソースのURIも提供する必要があります。
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
For subsequent receipt requests to the same origin [RFC6454], the application server SHOULD include the returned receipt subscription in a link relation of type "urn:ietf:params:push:receipt". This gives the push service the option to aggregate the receipts. The push service SHOULD return the same receipt subscription in its response, although it MAY return a new receipt subscription if it is unable to reuse the one provided by the application server.
同じオリジン[RFC6454]への後続の受信要求の場合、アプリケーションサーバーは、返された受信サブスクリプションをタイプ "urn：ietf：params：push：receipt"のリンク関係に含める必要があります（SHOULD）。これにより、プッシュサービスに領収書を集計するオプションが提供されます。プッシュサービスは、その応答で同じ受信サブスクリプションを返す必要があります（SHOULD）。ただし、アプリケーションサーバーによって提供されたものを再利用できない場合は、新しい受信サブスクリプションを返す場合があります。
An application server MAY omit the receipt subscription if it is unable to receive receipts in an aggregated way for the lifetime of the receipt subscription. This might be necessary if the application server is monitoring receipt subscriptions on behalf of the other push message senders.
アプリケーションサーバーは、レシートサブスクリプションの有効期間中に集約された方法でレシートを受信できない場合、レシートサブスクリプションを省略してもよい（MAY）。これは、アプリケーションサーバーが他のプッシュメッセージ送信者に代わって受信サブスクリプションを監視している場合に必要になることがあります。
A push service MUST return a 400 (Bad Request) status code for requests that contain an invalid receipt subscription. If a push service wishes to limit the number of receipt subscriptions that it maintains, it MAY return a 429 (Too Many Requests) status code [RFC6585] to reject receipt requests that omit a receipt subscription.
プッシュサービスは、無効な受信サブスクリプションを含むリクエストに対して、400（Bad Request）ステータスコードを返さなければなりません（MUST）。プッシュサービスが維持するレシートサブスクリプションの数を制限したい場合は、429（Too Many Requests）ステータスコード[RFC6585]を返して、レシートサブスクリプションを省略したレシートリクエストを拒否する場合があります。
A push service can improve the reliability of push message delivery considerably by storing push messages for a period. User agents are often only intermittently connected, and so benefit from having short-term message storage at the push service.
プッシュサービスは、プッシュメッセージを一定期間保存することにより、プッシュメッセージ配信の信頼性を大幅に向上させることができます。多くの場合、ユーザーエージェントは断続的にしか接続されないため、pushサービスで短期間のメッセージストレージを使用するとメリットがあります。
Delaying delivery might also be used to batch communication with the user agent, thereby conserving radio resources.
配信の遅延は、ユーザーエージェントとのバッチ通信にも使用され、無線リソースを節約します。
Some push messages are not useful once a certain period of time elapses. Delivery of messages after they have ceased to be relevant is wasteful. For example, if the push message contains a call notification, receiving a message after the caller has abandoned the call is of no value; the application at the user agent is forced to suppress the message so that it does not generate a useless alert.
一部のプッシュメッセージは、一定の時間が経過すると役に立たなくなります。関連性がなくなった後のメッセージの配信は無駄です。たとえば、プッシュメッセージに通話通知が含まれている場合、発信者が通話を放棄した後にメッセージを受信しても意味がありません。ユーザーエージェントのアプリケーションは、メッセージを抑制して、無用のアラートを生成しないようにします。
An application server MUST include the TTL (Time-To-Live) header field in its request for push message delivery. The TTL header field contains a value in seconds that suggests how long a push message is retained by the push service.
アプリケーションサーバーは、プッシュメッセージ配信のリクエストにTTL（Time-To-Live）ヘッダーフィールドを含める必要があります。 TTLヘッダーフィールドには、プッシュメッセージがプッシュサービスによって保持される期間を示す秒単位の値が含まれています。
The TTL rule specifies a non-negative integer, representing time in seconds. A recipient parsing and converting a TTL value to binary form SHOULD use an arithmetic type of at least 31 bits of non-negative integer range. If a recipient receives a TTL value greater than the greatest integer it can represent, or if any of its subsequent calculations overflows, it MUST consider the value to be 2147483648 (2^31).
TTLルールは、秒数で時間を表す負でない整数を指定します。 TTL値を解析してバイナリ形式に変換する受信者は、少なくとも31ビットの非負整数範囲の算術型を使用する必要があります（SHOULD）。受信者が表すことができる最大の整数より大きいTTL値を受信した場合、またはその後の計算のいずれかがオーバーフローした場合、値を2147483648（2 ^ 31）と見なす必要があります。
TTL = 1*DIGIT
A push service MUST return a 400 (Bad Request) status code in response to requests that omit the TTL header field.
プッシュサービスは、TTLヘッダーフィールドを省略したリクエストに応答して、400（Bad Request）ステータスコードを返さなければなりません（MUST）。
A push service MAY retain a push message for a shorter duration than requested. It indicates this by returning a TTL header field in its response with the actual TTL. This TTL value MUST be less than or equal to the value provided by the application server.
プッシュサービスは、要求されたよりも短い期間、プッシュメッセージを保持する場合があります。これは、実際のTTLを含む応答でTTLヘッダーフィールドを返すことでこれを示します。このTTL値は、アプリケーションサーバーによって提供される値以下でなければなりません。
Once the TTL period elapses, the push service MUST NOT attempt to deliver the push message to the user agent. A push service might adjust the TTL value to account for time accounting errors in processing. For instance, distributing a push message within a server cluster might accrue errors due to clock skew or propagation delays.
TTL期間が経過すると、プッシュサービスはプッシュメッセージをユーザーエージェントに配信しようとしてはなりません。プッシュサービスは、処理中のタイムアカウンティングエラーを考慮してTTL値を調整する場合があります。たとえば、サーバークラスタ内にプッシュメッセージを配信すると、クロックスキューまたは伝播遅延が原因でエラーが発生する場合があります。
A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or delays incurred while sending a push message to the user agent. An application server needs to account for transit delays in selecting a TTL header field value.
プッシュサービスは、アプリケーションサーバーがプッシュサービスへのプッシュメッセージの送信に費やした時間、またはユーザーエージェントへのプッシュメッセージの送信中に発生した遅延を説明する義務はありません。アプリケーションサーバーは、TTLヘッダーフィールド値を選択する際の通過遅延を考慮する必要があります。
A Push message with a zero TTL is immediately delivered if the user agent is available to receive the message. After delivery, the push service is permitted to immediately remove a push message with a zero TTL. This might occur before the user agent acknowledges receipt of the message by performing an HTTP DELETE on the push message resource. Consequently, an application server cannot rely on receiving acknowledgement receipts for zero TTL push messages.
ユーザーエージェントがメッセージを受信できる場合は、TTLがゼロのPushメッセージがすぐに配信されます。配信後、プッシュサービスは、TTLがゼロのプッシュメッセージをすぐに削除できます。これは、ユーザーエージェントがプッシュメッセージリソースでHTTP DELETEを実行してメッセージの受信を確認する前に発生する可能性があります。その結果、アプリケーションサーバーは、ゼロTTLプッシュメッセージの確認応答の受信に依存できません。
If the user agent is unavailable, a push message with a zero TTL expires and is never delivered.
ユーザーエージェントが使用できない場合、TTLがゼロのプッシュメッセージは期限切れになり、配信されません。
For a device that is battery-powered, it is often critical that it remains dormant for extended periods. Radio communication in particular consumes significant power and limits the length of time that the device can operate.
バッテリ駆動のデバイスでは、多くの場合、長期間休止状態であることが重要です。特に無線通信はかなりの電力を消費し、デバイスが動作できる時間の長さを制限します。
To avoid consuming resources to receive trivial messages, it is helpful if an application server can communicate the urgency of a message and if the user agent can request that the push server only forwards messages of a specific urgency.
ささいなメッセージを受信するためにリソースを消費しないようにするには、アプリケーションサーバーがメッセージの緊急度を伝達できる場合、およびユーザーエージェントがプッシュサーバーが特定の緊急度のメッセージのみを転送するように要求できる場合に役立ちます。
An application server MAY include an Urgency header field in its request for push message delivery. This header field indicates the message urgency. The push service MUST NOT forward the Urgency header field to the user agent. A push message without the Urgency header field defaults to a value of "normal".
アプリケーションサーバーは、プッシュメッセージ配信のリクエストに緊急ヘッダーフィールドを含めることができます。このヘッダーフィールドは、メッセージの緊急度を示します。プッシュサービスは、緊急ヘッダーフィールドをユーザーエージェントに転送してはなりません（MUST NOT）。 Urgencyヘッダーフィールドのないプッシュメッセージは、デフォルトで「通常」の値になります。
A user agent MAY include the Urgency header field when monitoring for push messages to indicate the lowest urgency of push messages that it is willing to receive. A push service MUST NOT deliver push messages with lower urgency than the value indicated by the user agent in its monitoring request. Push messages of any urgency are delivered to a user agent that does not include an Urgency header field when monitoring for messages.
ユーザーエージェントは、プッシュメッセージを監視するときに緊急ヘッダーフィールドを含めて、受信したいプッシュメッセージの最低緊急度を示すことができます。プッシュサービスは、監視リクエストでユーザーエージェントが示す値よりも緊急度が低いプッシュメッセージを配信してはなりません（MUST NOT）。緊急度の高いプッシュメッセージは、メッセージの監視時に緊急度ヘッダーフィールドを含まないユーザーエージェントに配信されます。
The grammar for the Urgency header field is as follows:
Urgencyヘッダーフィールドの文法は次のとおりです。
Urgency = urgency-option
urgency-option = ("very-low" / "low" / "normal" / "high")
In order of increasing urgency:
緊急度が高い順に：
+----------+-----------------------------+--------------------------+
| Urgency | Device State | Example Application |
| | | Scenario |
+----------+-----------------------------+--------------------------+
| very-low | On power and Wi-Fi | Advertisements |
| low | On either power or Wi-Fi | Topic updates |
| normal | On neither power nor Wi-Fi | Chat or Calendar Message |
| high | Low battery | Incoming phone call or |
| | | time-sensitive alert |
+----------+-----------------------------+--------------------------+
Table 1: Illustrative Urgency Values
表1：緊急度の値の例
Multiple values for the Urgency header field MUST NOT be included in requests; otherwise, the push service MUST return a 400 (Bad Request) status code.
Urgencyヘッダーフィールドの複数の値をリクエストに含めることはできません。それ以外の場合、プッシュサービスは400（Bad Request）ステータスコードを返す必要があります。
A push message that has been stored by the push service can be replaced with new content. If the user agent is offline during the time that the push messages are sent, updating a push message avoids the situation where outdated or redundant messages are sent to the user agent.
プッシュサービスによって保存されたプッシュメッセージは、新しいコンテンツに置き換えることができます。プッシュメッセージの送信中にユーザーエージェントがオフラインの場合、プッシュメッセージを更新すると、古いメッセージや冗長メッセージがユーザーエージェントに送信される状況を回避できます。
Only push messages that have been assigned a topic can be replaced. A push message with a topic replaces any outstanding push message with an identical topic.
トピックを割り当てられたプッシュメッセージのみを置き換えることができます。トピックを含むプッシュメッセージは、未処理のプッシュメッセージを同じトピックに置き換えます。
A push message topic is a string carried in a Topic header field. A topic is used to correlate push messages sent to the same subscription and does not convey any other semantics.
プッシュメッセージトピックは、トピックヘッダーフィールドに含まれる文字列です。トピックは、同じサブスクリプションに送信されたプッシュメッセージを関連付けるために使用され、他のセマンティクスを伝えません。
The grammar for the Topic header field uses the "token" rule defined in [RFC7230].
トピックヘッダーフィールドの文法は、[RFC7230]で定義されている「トークン」ルールを使用します。
Topic = token
For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and a filename-safe Base 64 alphabet [RFC4648]. A push service that receives a request with a Topic header field that does not meet these constraints MUST return a 400 (Bad Request) status code to the application server.
このプロトコルで使用するために、トピックヘッダーフィールドは、URLおよびファイル名に対して安全なBase 64アルファベット[RFC4648]から32文字以内に制限する必要があります。これらの制約を満たさないトピックヘッダーフィールドを持つリクエストを受信するプッシュサービスは、400（不良リクエスト）ステータスコードをアプリケーションサーバーに返さなければなりません（MUST）。
A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource that has a matching topic. If an attempt was made to deliver the deleted push message, an acknowledgment could arrive at the push service after the push message has been replaced. Delivery receipts for such deleted messages SHOULD be suppressed.
プッシュメッセージ置換リクエストは、新しいプッシュメッセージリソースを作成し、同時に、一致するトピックを持つ既存のメッセージリソースを削除します。削除されたプッシュメッセージを配信しようとした場合、プッシュメッセージが置き換えられた後、確認がプッシュサービスに到着する可能性があります。そのような削除されたメッセージの配信確認は抑制されるべきです。
The replacement request also replaces the stored TTL, Urgency, and any receipt subscription associated with the previous message in the matching topic.
置換要求は、格納されているTTL、緊急度、および一致するトピックの前のメッセージに関連付けられているすべての受信サブスクリプションも置換します。
A push message with a topic that is not shared by an outstanding message to the same subscription is stored or delivered as normal.
同じサブスクリプションへの未解決のメッセージで共有されていないトピックを含むプッシュメッセージは、通常どおり保存または配信されます。
For example, the following message could cause an existing message to be replaced:
たとえば、次のメッセージは既存のメッセージを置き換える可能性があります。
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 600
Topic: upd
Content-Type: text/plain;charset=utf8
Content-Length: 36
ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF
If the push service identifies an outstanding push message with a topic of "upd", then that message resource is deleted. A 201 (Created) response indicates that the push message replacement was accepted. A URI for the new push message resource that was created in response to the request is included in the Location header field.
プッシュサービスがトピック "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
The value of the Topic header field MUST NOT be forwarded to user agents. Its value is neither encrypted nor authenticated.
トピックヘッダーフィールドの値をユーザーエージェントに転送してはなりません。その値は暗号化も認証もされていません。
A user agent requests the delivery of new push messages by making a GET request to a push message subscription resource. The push service does not respond to this request; instead, it uses HTTP/2 server push [RFC7540] to send the contents of push messages as they are sent by application servers.
ユーザーエージェントは、プッシュメッセージサブスクリプションリソースに対してGET要求を行うことにより、新しいプッシュメッセージの配信を要求します。プッシュサービスはこのリクエストに応答しません。代わりに、HTTP / 2サーバープッシュ[RFC7540]を使用して、アプリケーションサーバーから送信されたプッシュメッセージの内容を送信します。
A user agent MAY include an Urgency header field in its request. The push service MUST NOT deliver messages with lower urgency than the value of the header field as defined in Table 1 (Illustrative Urgency Values).
ユーザーエージェントは、そのリクエストに緊急ヘッダーフィールドを含めることができます。プッシュサービスは、表1（例示的な緊急値）で定義されているヘッダーフィールドの値よりも緊急度が低いメッセージを配信してはなりません（MUST NOT）。
Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. This GET request is made to the push message resource that was created by the push service when the application server requested message delivery. The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push". The response body is the entity body from the most recent request sent to the push resource by the application server.
各プッシュメッセージは、PUSH_PROMISEで送信された合成GETリクエストへの応答としてプッシュされます。このGET要求は、アプリケーションサーバーがメッセージ配信を要求したときに、プッシュサービスによって作成されたプッシュメッセージリソースに対して行われます。応答ヘッダーは、タイプ「urn：ietf：params：push」のリンク関係のプッシュメッセージサブスクリプションに対応するプッシュリソースのURIを提供する必要があります（SHOULD）。レスポンスボディは、アプリケーションサーバーによってプッシュリソースに送信された最新のリクエストのエンティティボディです。
The following example request is made over HTTP/2:
次のサンプルリクエストはHTTP / 2を介して行われます。
HEADERS [stream 7] +END_STREAM +END_HEADERS
:method = GET
:path = /subscription/LBhhw0OohO-Wl4Oi971UG
:authority = push.example.net
The push service permits the request to remain outstanding. When a push message is sent by an application server, a server push is generated in association with the initial request. The response for the server push includes the push message.
プッシュサービスでは、リクエストを未処理のままにすることができます。アプリケーションサーバーからプッシュメッセージが送信されると、最初のリクエストに関連してサーバープッシュが生成されます。サーバープッシュの応答には、プッシュメッセージが含まれます。
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
DATA [ストリーム4] + END_STREAM iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
HEADERS [stream 7] +END_STREAM +END_HEADERS
:status = 200
A user agent can also request the contents of the push message subscription resource immediately by including a Prefer header field [RFC7240] with a "wait" preference set to "0". In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered.
ユーザーエージェントは、「待機」設定が「0」に設定された優先ヘッダーフィールド[RFC7240]を含めることにより、プッシュメッセージサブスクリプションリソースのコンテンツをすぐに要求することもできます。このリクエストへの応答として、プッシュサービスは、まだ配信されていないすべてのプッシュメッセージに対してサーバープッシュを生成する必要があります。
A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available. This could be because push messages have expired.
サーバープッシュが関連付けられていないステータスコード204（コンテンツなし）は、現在利用可能なメッセージがないことを示します。これは、プッシュメッセージの有効期限が切れていることが原因である可能性があります。
There are minor differences between receiving push messages for a subscription and a subscription set. If a subscription set is available, the user agent SHOULD use the subscription set to monitor for push messages rather than individual push message subscriptions.
サブスクリプションとサブスクリプションセットのプッシュメッセージの受信には、わずかな違いがあります。サブスクリプションセットが利用可能な場合、ユーザーエージェントは、個々のプッシュメッセージサブスクリプションではなく、サブスクリプションセットを使用してプッシュメッセージを監視する必要があります（SHOULD）。
A user agent requests the delivery of new push messages for a collection of push message subscriptions by making a GET request to a push message subscription set resource. The push service does not respond to this request; instead, it uses HTTP/2 server push [RFC7540] to send the contents of push messages as they are sent by application servers.
ユーザーエージェントは、プッシュメッセージサブスクリプションセットリソースに対してGET要求を行うことにより、プッシュメッセージサブスクリプションのコレクションに対する新しいプッシュメッセージの配信を要求します。プッシュサービスはこのリクエストに応答しません。代わりに、HTTP / 2サーバープッシュ[RFC7540]を使用して、アプリケーションサーバーから送信されたプッシュメッセージの内容を送信します。
A user agent MAY include an Urgency header field in its request. The push service MUST NOT deliver messages with lower urgency than the value of the header field as defined in Table 1 (Illustrative Urgency Values).
ユーザーエージェントは、そのリクエストに緊急ヘッダーフィールドを含めることができます。プッシュサービスは、表1（例示的な緊急値）で定義されているヘッダーフィールドの値よりも緊急度が低いメッセージを配信してはなりません（MUST NOT）。
Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. This GET request is made to the push message resource that was created by the push service when the application server requested message delivery. The synthetic request MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push". This enables the user agent to differentiate the source of the message. The response body is the entity body from the most recent request sent to the push resource by an application server.
各プッシュメッセージは、PUSH_PROMISEで送信された合成GETリクエストへの応答としてプッシュされます。このGET要求は、アプリケーションサーバーがメッセージ配信を要求したときに、プッシュサービスによって作成されたプッシュメッセージリソースに対して行われます。合成リクエストは、「urn：ietf：params：push」タイプのリンク関係でプッシュメッセージサブスクリプションに対応するプッシュリソースのURIを提供する必要があります。これにより、ユーザーエージェントはメッセージのソースを区別できます。レスポンスボディは、アプリケーションサーバーによってプッシュリソースに送信された最新のリクエストのエンティティボディです。
The following example request is made over HTTP/2.
次のリクエストの例は、HTTP / 2を介して行われます。
HEADERS [stream 7] +END_STREAM +END_HEADERS
:method = GET
:path = /subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy
:authority = push.example.net
The push service permits the request to remain outstanding. When a push message is sent by an application server, a server push is generated in association with the initial request. The server push's response includes the push message.
プッシュサービスでは、リクエストを未処理のままにすることができます。アプリケーションサーバーからプッシュメッセージが送信されると、最初のリクエストに関連してサーバープッシュが生成されます。サーバープッシュの応答には、プッシュメッセージが含まれます。
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
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
DATA [ストリーム4] + END_STREAM iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
HEADERS [stream 7] +END_STREAM +END_HEADERS
:status = 200
A user agent can request the contents of the push message subscription set resource immediately by including a Prefer header field [RFC7240] with a "wait" preference set to "0". In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered.
ユーザーエージェントは、「待機」設定が「0」に設定されたPreferヘッダーフィールド[RFC7240]を含めることにより、プッシュメッセージサブスクリプションセットリソースのコンテンツをすぐに要求できます。このリクエストへの応答として、プッシュサービスは、まだ配信されていないすべてのプッシュメッセージに対してサーバープッシュを生成する必要があります。
A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available. This could be because push messages have expired.
サーバープッシュが関連付けられていないステータスコード204（コンテンツなし）は、現在利用可能なメッセージがないことを示します。これは、プッシュメッセージの有効期限が切れていることが原因である可能性があります。
To ensure that a push message is properly delivered to the user agent at least once, the user agent MUST acknowledge receipt of the message by performing an HTTP DELETE on the push message resource.
プッシュメッセージがユーザーエージェントに少なくとも1回適切に配信されるようにするには、ユーザーエージェントがプッシュメッセージリソースでHTTP DELETEを実行してメッセージの受信を確認する必要があります。
DELETE /message/qDIYHNcfAIPP_5ITvURr-d6BGt HTTP/1.1
Host: push.example.net
If the push service receives the acknowledgement and the application has requested a delivery receipt, the push service MUST return a 204 (No Content) response to the application server monitoring the receipt subscription.
プッシュサービスが確認を受信し、アプリケーションが配信確認を要求した場合、プッシュサービスは、受信サブスクリプションを監視しているアプリケーションサーバーに204（コンテンツなし）応答を返さなければなりません（MUST）。
If the push service does not receive the acknowledgement within a reasonable amount of time, then the message is considered to be not yet delivered. The push service SHOULD continue to retry delivery of the message until its advertised expiration.
プッシュサービスが妥当な時間内に確認応答を受信しない場合、メッセージはまだ配信されていないと見なされます。プッシュサービスは、アドバタイズされた有効期限までメッセージの配信を再試行し続ける必要があります。
The push service MAY cease to retry delivery of the message prior to its advertised expiration due to scenarios such as an unresponsive user agent or operational constraints. If the application has requested a delivery receipt, then the push service MUST return a 410 (Gone) response to the application server monitoring the receipt subscription.
プッシュサービスは、応答しないユーザーエージェントや操作上の制約などのシナリオにより、通知された有効期限が切れる前にメッセージの配信を再試行することを中止する場合があります。アプリケーションが配信確認を要求した場合、プッシュサービスは、受信サブスクリプションを監視しているアプリケーションサーバーに410（Gone）応答を返さなければなりません（MUST）。
The application server requests the delivery of receipts from the push service by making an HTTP GET request to the receipt subscription resource. The push service does not respond to this request; instead, it uses HTTP/2 server push [RFC7540] to send push receipts when messages are acknowledged (Section 6.2) by the user agent.
アプリケーションサーバーは、レシートサブスクリプションリソースに対してHTTP GETリクエストを行うことにより、プッシュサービスからのレシートの配信を要求します。プッシュサービスはこのリクエストに応答しません。代わりに、ユーザーエージェントによってメッセージが確認されたとき（セクション6.2）、HTTP / 2サーバープッシュ[RFC7540]を使用してプッシュ受信を送信します。
Each receipt is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. This GET request is made to the same push message resource that was created by the push service when the application server requested message delivery. The response includes a status code indicating the result of the message delivery and carries no data.
各レシートは、PUSH_PROMISEで送信された合成GET要求への応答としてプッシュされます。このGET要求は、アプリケーションサーバーがメッセージ配信を要求したときにプッシュサービスによって作成されたものと同じプッシュメッセージリソースに対して行われます。応答には、メッセージ配信の結果を示すステータスコードが含まれ、データは含まれません。
The following example request is made over HTTP/2.
次のリクエストの例は、HTTP / 2を介して行われます。
HEADERS [stream 13] +END_STREAM +END_HEADERS
:method = GET
:path = /receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM
:authority = push.example.net
The push service permits the request to remain outstanding. When the user agent acknowledges the message, the push service pushes a delivery receipt to the application server. A 204 (No Content) status code confirms that the message was delivered and acknowledged.
プッシュサービスでは、リクエストを未処理のままにすることができます。ユーザーエージェントがメッセージを確認すると、プッシュサービスは配信済みメッセージをアプリケーションサーバーにプッシュします。 204（コンテンツなし）ステータスコードは、メッセージが配信および確認されたことを確認します。
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
If the user agent fails to acknowledge the receipt of the push message and the push service ceases to retry delivery of the message prior to its advertised expiration, then the push service MUST push a failure response with a status code of 410 (Gone).
ユーザーエージェントがプッシュメッセージの受信の確認に失敗し、プッシュサービスがアドバタイズされた有効期限の前にメッセージの配信を再試行しなくなった場合、プッシュサービスはステータスコード410（Gone）で失敗応答をプッシュする必要があります。
A push service is likely to have to maintain a very large number of open TCP connections. Effective management of those connections can depend on being able to move connections between server instances.
プッシュサービスは、非常に多くのオープンTCP接続を維持する必要がある可能性があります。これらの接続の効果的な管理は、サーバーインスタンス間で接続を移動できるかどうかに依存します。
A user agent MUST support the 307 (Temporary Redirect) status code [RFC7231], which can be used by a push service to redistribute load at the time that a new subscription is requested.
ユーザーエージェントは、307（一時的なリダイレクト）ステータスコード[RFC7231]をサポートする必要があります。これは、新しいサブスクリプションが要求されたときに負荷を再配布するためにプッシュサービスで使用できます。
A server that wishes to redistribute load can do so using HTTP alternative services [RFC7838]. HTTP alternative services allows for redistribution of load while maintaining the same URIs for various resources. A user agent can ensure a graceful transition by using the GOAWAY frame once it has established a replacement connection.
負荷を再配分したいサーバーは、HTTP代替サービス[RFC7838]を使用してこれを行うことができます。 HTTP代替サービスは、さまざまなリソースに対して同じURIを維持しながら、負荷の再分配を可能にします。ユーザーエージェントは、置換接続を確立した後、GOAWAYフレームを使用して適切な移行を保証できます。
Storage of push messages based on the TTL header field comprises a potentially significant amount of storage for a push service. A push service is not obligated to store messages indefinitely. A push service is able to indicate how long it intends to retain a message to an application server using the TTL header field (Section 5.2).
TTLヘッダーフィールドに基づくプッシュメッセージのストレージは、プッシュサービスの潜在的にかなりの量のストレージで構成されます。プッシュサービスは、メッセージを無期限に保存する義務はありません。プッシュサービスは、TTLヘッダーフィールドを使用して、アプリケーションサーバーへのメッセージを保持する予定の期間を示すことができます（セクション5.2）。
A user agent that does not actively monitor for push messages will not receive messages that expire during that interval.
プッシュメッセージをアクティブに監視しないユーザーエージェントは、その間隔中に期限切れになるメッセージを受信しません。
Push messages that are stored and have not been delivered to a user agent are delivered when the user agent recommences monitoring. Stored push messages SHOULD include a Last-Modified header field (Section 2.2 of [RFC7232]) indicating when delivery was requested by an application server.
保存されていてユーザーエージェントに配信されていないプッシュメッセージは、ユーザーエージェントが監視を再開したときに配信されます。保存されたプッシュメッセージには、アプリケーションサーバーによって配信がリクエストされた日時を示すLast-Modifiedヘッダーフィールド（[RFC7232]のセクション2.2）を含める必要があります（SHOULD）。
A GET request to a push message subscription resource with only expired messages results in a response as though no push message was ever sent.
期限切れのメッセージのみを含むプッシュメッセージサブスクリプションリソースへのGETリクエストは、プッシュメッセージが送信されなかったかのように応答します。
Push services might need to limit the size and number of stored push messages to avoid overloading. To limit the size of messages, the push service MAY return a 413 (Payload Too Large) status code [RFC7231] in response to requests that include an entity body that is too large. Push services MUST NOT return a 413 status code in responses to an entity body that is 4096 bytes or less in size.
プッシュサービスは、過負荷を回避するために、保存されるプッシュメッセージのサイズと数を制限する必要がある場合があります。メッセージのサイズを制限するために、プッシュサービスは、エンティティボディが大きすぎるリクエストに応答して、413（ペイロードが大きすぎる）ステータスコード[RFC7231]を返す場合があります。プッシュサービスは、サイズが4096バイト以下のエンティティ本体への応答で413ステータスコードを返してはなりません（MUST NOT）。
To limit the number of stored push messages, the push service MAY respond with a shorter Time-To-Live than proposed by the application server in its request for push message delivery (Section 5.2). Once a message has been accepted, the push service MAY later expire the message prior to its advertised Time-To-Live. If the application server requested a delivery receipt, the push service MUST return a failure response (Section 6.2).
保存されたプッシュメッセージの数を制限するために、プッシュサービスは、アプリケーションサーバーがプッシュメッセージ配信のリクエストで提案した（セクション5.2）よりも短い有効期間で応答できます（MAY）。メッセージが受け入れられると、プッシュサービスは後で、アドバタイズされた存続可能時間の前にメッセージを期限切れにする場合があります。アプリケーションサーバーが配信確認を要求した場合、プッシュサービスは失敗応答を返す必要があります（セクション6.2）。
In some cases, it may be necessary to terminate subscriptions so that they can be refreshed. This applies to both push message subscriptions and receipt subscriptions.
場合によっては、サブスクリプションを更新できるようにサブスクリプションを終了する必要があります。これは、プッシュメッセージサブスクリプションと受信サブスクリプションの両方に適用されます。
A push service MAY expire a subscription at any time. If there are outstanding requests to an expired push message subscription resource (Section 6) from a user agent or to an expired receipt subscription resource (Section 6.3) from an application server, this MUST be signaled by returning a 404 (Not Found) status code.
プッシュサービスはいつでもサブスクリプションを期限切れにする場合があります。ユーザーエージェントからの期限切れのプッシュメッセージサブスクリプションリソース（セクション6）またはアプリケーションサーバーからの期限切れの受信サブスクリプションリソース（セクション6.3）への未処理の要求がある場合、404（見つかりません）ステータスコードを返すことによってこれを通知する必要があります。 。
A push service MUST return a 404 (Not Found) status code if an application server attempts to send a push message to an expired push message subscription.
アプリケーションサーバーが期限切れのプッシュメッセージサブスクリプションにプッシュメッセージを送信しようとする場合、プッシュサービスは404（見つかりません）ステータスコードを返さなければなりません（MUST）。
A user agent can remove its push message subscription by sending a DELETE request to the corresponding URI. An application server can remove its receipt subscription by sending a DELETE request to the corresponding URI.
ユーザーエージェントは、対応するURIにDELETEリクエストを送信することで、プッシュメッセージサブスクリプションを削除できます。アプリケーションサーバーは、対応するURIにDELETE要求を送信することにより、受信サブスクリプションを削除できます。
A push service MAY expire a subscription set at any time and MUST also expire all push message subscriptions in the set. If a user agent has an outstanding request to a push subscription set (Section 6.1), this MUST be signaled by returning a 404 (Not Found) status code.
プッシュサービスは、サブスクリプションセットをいつでも期限切れにすることができ、セット内のすべてのプッシュメッセージサブスクリプションも期限切れにする必要があります。ユーザーエージェントがプッシュサブスクリプションセット（セクション6.1）への未処理のリクエストを持っている場合、これは404（見つかりません）ステータスコードを返すことによって通知される必要があります。
A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI. This MUST also remove all push message subscriptions in the set.
ユーザーエージェントは、サブスクリプションセットのURIにDELETE要求を送信することで、サブスクリプションセットの削除を要求できます。これにより、セット内のすべてのプッシュメッセージサブスクリプションも削除する必要があります。
If a specific push message subscription that is a member of a subscription set is expired or removed, then it MUST also be removed from its subscription set.
サブスクリプションセットのメンバーである特定のプッシュメッセージサブスクリプションが期限切れまたは削除された場合は、サブスクリプションセットからも削除する必要があります。
A push service that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application server, incurring additional power drain in order to establish and maintain (usually secure) connections to the individual application servers.
断続的なネットワーク接続または障害のあるアプリケーションでの信頼性の高い配信をサポートしないプッシュサービスは、デバイスがアプリケーションサーバーに直接受信を確認するように強制し、個々のアプリケーションへの接続を確立および維持（通常は安全）するために追加の電力消費を発生させます。サーバー。
Push message reliability can be important if messages contain information critical to the state of an application. Repairing the state can be expensive, particularly for devices with limited communications capacity. Knowing that a push message has been correctly received avoids retransmissions, polling, and state resynchronization.
アプリケーションの状態にとって重要な情報がメッセージに含まれている場合、プッシュメッセージの信頼性は重要です。状態の修復は、特に通信容量が限られているデバイスの場合、費用がかかる可能性があります。プッシュメッセージが正しく受信されたことを知ることで、再送信、ポーリング、および状態の再同期を回避できます。
The availability of push message delivery receipts ensures that the application developer is not tempted to create alternative mechanisms for message delivery in case the push service fails to deliver a critical message. Setting up a polling mechanism or a backup messaging channel in order to compensate for these shortcomings negates almost all of the advantages a push service provides.
プッシュメッセージ配信レシートを利用できるため、アプリケーション開発者は、プッシュサービスが重要なメッセージの配信に失敗した場合に、メッセージ配信の代替メカニズムを作成する気になりません。これらの欠点を補うためにポーリングメカニズムまたはバックアップメッセージングチャネルを設定すると、プッシュサービスが提供する利点のほとんどすべてが無効になります。
However, reliability might not be necessary for messages that are transient (e.g., an incoming call) or messages that are quickly superseded (e.g., the current number of unread emails).
ただし、一時的なメッセージ（着信など）やすぐに置き換えられるメッセージ（現在の未読メールの数など）には、信頼性は必要ない場合があります。
If the push service requires that the user agent use push message subscription sets, then it MAY limit the number of concurrently active streams with the SETTINGS_MAX_CONCURRENT_STREAMS parameter within an HTTP/2 SETTINGS frame [RFC7540]. The user agent MAY be limited to one concurrent stream to manage push message subscriptions and one concurrent stream for each subscription set returned by the push service. This could force the user agent to serialize subscription requests to the push service.
プッシュサービスでユーザーエージェントがプッシュメッセージサブスクリプションセットを使用する必要がある場合は、HTTP / 2 SETTINGSフレーム[RFC7540]内のSETTINGS_MAX_CONCURRENT_STREAMSパラメーターを使用して、同時にアクティブなストリームの数を制限できます（MAY）。ユーザーエージェントは、プッシュメッセージサブスクリプションを管理するための1つの同時ストリームと、プッシュサービスによって返されるサブスクリプションセットごとに1つの同時ストリームに制限される場合があります。これにより、ユーザーエージェントはプッシュサービスへのサブスクリプション要求をシリアル化する必要があります。
This protocol MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525]. This includes any communications between the user agent and the push service, plus communications between the application server and the push service. All URIs therefore use the "https" scheme. This provides confidentiality and integrity protection for subscriptions and push messages from external parties.
このプロトコルは、[RFC7525]の推奨事項に従ってHTTP over TLS [RFC2818]を使用する必要があります。これには、ユーザーエージェントとプッシュサービス間の通信に加えて、アプリケーションサーバーとプッシュサービス間の通信が含まれます。したがって、すべてのURIは「https」スキームを使用します。これにより、サブスクリプションの機密性と整合性が保護され、外部の関係者からのメッセージがプッシュされます。
The protection afforded by TLS does not protect content from the push service. Without additional safeguards, a push service can inspect and modify the message content.
TLSによって提供される保護は、コンテンツをプッシュサービスから保護しません。追加の保護手段なしで、プッシュサービスはメッセージの内容を検査および変更できます。
Applications using this protocol MUST use mechanisms that provide end-to-end confidentiality, integrity, and data origin authentication. The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context. The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement.
このプロトコルを使用するアプリケーションは、エンドツーエンドの機密性、整合性、およびデータ発信元認証を提供するメカニズムを使用する必要があります。プッシュメッセージを送信するアプリケーションサーバーとそれを受信するユーザーエージェント上のアプリケーションは、同じアプリケーションの異なるインスタンスであることが多いため、適切なセキュリティコンテキストを確立するために標準化されたプロトコルは必要ありません。ユーザーエージェントからそのアプリケーションサーバーへのサブスクリプション情報の配布も、キー合意のための便利な媒体を提供します。
For this requirement, the W3C Push API [API] has adopted Message Encryption for WebPush [ENCRYPT] to secure the content of messages from the push service. Other scenarios can be addressed by similar policies.
この要件に対して、W3CプッシュAPI [API]はWebPushのメッセージ暗号化[ENCRYPT]を採用して、プッシュサービスからのメッセージのコンテンツを保護しています。他のシナリオも同様のポリシーで対処できます。
The Topic header field exposes information that allows more granular correlation of push messages on the same subject. This might be used to aid traffic analysis of push messages by the push service.
トピックヘッダーフィールドは、同じ件名のプッシュメッセージのより詳細な相関を可能にする情報を公開します。これは、プッシュサービスによるプッシュメッセージのトラフィック分析を支援するために使用できます。
Push message confidentiality does not ensure that the identity of who is communicating and when they are communicating is protected. However, the amount of information that is exposed can be limited.
プッシュメッセージの機密性は、誰が通信しているのか、いつ通信しているのかが識別されることを保証するものではありません。ただし、公開される情報量には制限があります。
The URIs provided for push resources MUST NOT provide any basis to correlate communications for a given user agent. It MUST NOT be possible to correlate any two push resource URIs based solely on their contents. This allows a user agent to control correlation across different applications or over time. Of course, this does not prevent correlation using other information that a user agent might expose.
プッシュリソースに提供されるURIは、特定のユーザーエージェントの通信を相互に関連付けるための基盤を提供してはなりません（MUST NOT）。内容にのみ基づいて2つのプッシュリソースURIを関連付けることはできません。これにより、ユーザーエージェントは、異なるアプリケーション間または時間の経過に伴う相関を制御できます。もちろん、これは、ユーザーエージェントが公開する可能性のある他の情報を使用した相関を妨げません。
Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation across subscriptions. Push message URIs for the same subscription MAY contain information that would allow correlation with the associated subscription or other push messages for that subscription.
同様に、プッシュメッセージを識別するためにプッシュサービスによって提供されるURIは、サブスクリプション間の相関を可能にする情報を提供してはなりません（MUST NOT）。同じサブスクリプションのプッシュメッセージURIには、関連するサブスクリプションまたはそのサブスクリプションの他のプッシュメッセージとの相関を可能にする情報が含まれている場合があります。
User and device information MUST NOT be exposed through a push or push message URI.
ユーザーおよびデバイス情報は、プッシュまたはプッシュメッセージURIを通じて公開してはなりません。
In addition, push URIs established by the same user agent or push message URIs for the same subscription MUST NOT include any information that allows them to be correlated with the user agent.
さらに、同じユーザーエージェントによって確立されたプッシュURIまたは同じサブスクリプションのプッシュメッセージURIには、それらをユーザーエージェントと関連付けることができる情報を含めてはなりません。
Note: This need not be perfect as long as the resulting anonymity set ([RFC6973], Section 6.1.1) is sufficiently large. A push URI necessarily identifies a push service or a single server instance. It is also possible that traffic analysis could be used to correlate subscriptions.
注：結果の匿名性セット（[RFC6973]、セクション6.1.1）が十分に大きければ、これは完全である必要はありません。プッシュURIは、必ずプッシュサービスまたは単一のサーバーインスタンスを識別します。トラフィック分析を使用してサブスクリプションを関連付けることもできます。
A user agent MUST be able to create new subscriptions with new identifiers at any time.
ユーザーエージェントは、いつでも新しい識別子で新しいサブスクリプションを作成できる必要があります。
This protocol does not define how a push service establishes whether a user agent is permitted to create a subscription, or whether push messages can be delivered to the user agent. A push service MAY choose to authorize requests based on any HTTP-compatible authorization method available, of which there are multiple options (including experimental options) with varying levels of security. The authorization process and any associated credentials are expected to be configured in the user agent along with the URI for the push service.
このプロトコルは、ユーザーエージェントがサブスクリプションの作成を許可されているかどうか、またはプッシュメッセージをユーザーエージェントに配信できるかどうかをプッシュサービスが確立する方法を定義していません。プッシュサービスは、利用可能なHTTP互換の認証方法に基づいてリクエストを認証することを選択できます。その認証方法には、さまざまなセキュリティレベルの複数のオプション（試験的なオプションを含む）があります。承認プロセスと関連する資格情報は、プッシュサービスのURIと共にユーザーエージェントで構成する必要があります。
Authorization is managed using capability URLs for the push message subscription, push, and receipt subscription resources ([CAP-URI]). A capability URL grants access to a resource based solely on knowledge of the URL.
承認は、プッシュメッセージサブスクリプション、プッシュ、および受信サブスクリプションリソース（[CAP-URI]）の機能URLを使用して管理されます。機能URLは、URLの知識だけに基づいてリソースへのアクセスを許可します。
Capability URLs are used for their "easy onward sharing" and "easy client API" properties. These properties make it possible to avoid relying on prearranged relationships or additional protocols between push services and application servers.
機能URLは、「簡単な共有」と「簡単なクライアントAPI」のプロパティに使用されます。これらのプロパティにより、プッシュサービスとアプリケーションサーバー間の事前に設定された関係や追加のプロトコルに依存することを回避できます。
Capability URLs act as bearer tokens. Knowledge of a push message subscription URI implies authorization to either receive push messages or delete the subscription. Knowledge of a push URI implies authorization to send push messages. Knowledge of a push message URI allows for reading and acknowledging that specific message. Knowledge of a receipt subscription URI implies authorization to receive push receipts.
機能URLは、ベアラートークンとして機能します。プッシュメッセージサブスクリプションURIの知識は、プッシュメッセージを受信するか、サブスクリプションを削除する承認を意味します。プッシュURIの知識は、プッシュメッセージを送信するための承認を意味します。プッシュメッセージURIの知識により、その特定のメッセージを読み取り、確認することができます。レシートサブスクリプションURIの知識は、プッシュレシートを受信するための承認を意味します。
Encoding a large amount of random entropy (at least 120 bits) in the path component ensures that it is difficult to successfully guess a valid capability URL.
パスコンポーネントに大量のランダムエントロピー（少なくとも120ビット）をエンコードすると、有効な機能URLを正しく推測することが困難になります。
A user agent can control where valid push messages originate by limiting the distribution of push URIs to authorized application servers. Ensuring that push URIs are hard to guess ensures that only application servers that have received a push URI can use it.
ユーザーエージェントは、承認されたアプリケーションサーバーへのプッシュURIの配布を制限することにより、有効なプッシュメッセージの発信元を制御できます。プッシュURIが推測されにくいようにすることで、プッシュURIを受け取ったアプリケーションサーバーだけがそれを使用できるようになります。
Push messages that are not successfully authenticated by the user agent will not be delivered, but this can present a denial-of-service risk. Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves.
ユーザーエージェントによって認証されなかったプッシュメッセージは配信されませんが、これによりサービス拒否のリスクが生じる可能性があります。比較的少量のプッシュメッセージでも、バッテリ駆動のデバイスが予備電力を使い果たす可能性があります。
To address this case, the W3C Push API [API] has adopted Voluntary Application Server Identification [VAPID], which allows a user agent to restrict a subscription to a specific application server. The push service can then identify and reject unwanted messages without contacting the user agent.
このケースに対処するために、W3CプッシュAPI [API]は自発的アプリケーションサーバー識別[VAPID]を採用しています。これにより、ユーザーエージェントはサブスクリプションを特定のアプリケーションサーバーに制限できます。プッシュサービスは、ユーザーエージェントに連絡せずに不要なメッセージを識別して拒否できます。
A malicious application with a valid push URI could use the greater resources of a push service to mount a denial-of-service attack on a user agent. Push services SHOULD limit the rate at which push messages are sent to individual user agents.
有効なプッシュURIを持つ悪意のあるアプリケーションは、プッシュサービスのより多くのリソースを使用して、ユーザーエージェントにサービス拒否攻撃を仕掛ける可能性があります。プッシュサービスは、プッシュメッセージが個々のユーザーエージェントに送信される速度を制限する必要があります（SHOULD）。
A push service MAY return a 429 (Too Many Requests) status code [RFC6585] when an application server has exceeded its rate limit for push message delivery to a push resource. The push service SHOULD also include a Retry-After header [RFC7231] to indicate how long the application server is requested to wait before it makes another request to the push resource.
アプリケーションサーバーがプッシュリソースへのプッシュメッセージ配信のレート制限を超えた場合、プッシュサービスは429（Too Many Requests）ステータスコード[RFC6585]を返す場合があります。プッシュサービスは、アプリケーションサーバーがプッシュリソースに対して別のリクエストを行う前に待機するように要求される時間を示すために、Retry-Afterヘッダー[RFC7231]も含める必要があります（SHOULD）。
A push service or user agent MAY also terminate subscriptions (Section 7.3) that receive too many push messages.
プッシュサービスまたはユーザーエージェントは、受信するプッシュメッセージが多すぎるサブスクリプション（7.3）も終了する場合があります。
A push service is also able to deny service to user agents. Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages.
プッシュサービスは、ユーザーエージェントへのサービスを拒否することもできます。意図的なメッセージ配信の失敗は、一時的なネットワークエラー、ユーザーエージェントの可用性の中断、または真のサービス停止が原因で発生する可能性のある障害と区別することが困難です。
Server request logs can reveal subscription-related URIs or relationships between subscription-related URIs for the same user agent. Limitations on log retention and strong access control mechanisms can ensure that URIs are not revealed to unauthorized entities.
サーバー要求ログは、同じユーザーエージェントのサブスクリプション関連のURIまたはサブスクリプション関連のURI間の関係を明らかにできます。ログの保持と強力なアクセス制御メカニズムの制限により、無許可のエンティティにURIが公開されないようにすることができます。
This protocol defines new HTTP header fields in Section 9.1. New link relation types are identified using the URNs defined in Section 9.2. Port registration is defined in Section 9.3
このプロトコルは、セクション9.1で新しいHTTPヘッダーフィールドを定義します。新しいリンク関係タイプは、セクション9.2で定義されたURNを使用して識別されます。ポートの登録はセクション9.3で定義されています
HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message-headers/>.
HTTPヘッダーフィールドは、<https://www.iana.org/assignments/message-headers/>で管理されている「メッセージヘッダー」レジストリ内に登録されます。
This document defines the following HTTP header fields, and the following entries have been added to the "Permanent Message Header Field Names" registry ([RFC3864]):
このドキュメントでは、次の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 |
+-------------------+----------+----------+--------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
変更管理者は、「IETF（iesg@ietf.org）-Internet Engineering Task Force」です。
This document registers URNs for use in identifying link relation types. These have been added to a new "Web Push Identifiers" registry according to the procedures in Section 4 of [RFC3553]; the corresponding "push" sub-namespace has been entered in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry.
このドキュメントでは、リンク関係タイプの識別に使用するURNを登録します。これらは、[RFC3553]のセクション4の手順に従って、新しい「Web Push Identifiers」レジストリに追加されました。対応する「push」サブ名前空間は、「IETF URN Sub-namespace for Registered Protocol Parameter Identifiers」レジストリに入力されています。
The "Web Push Identifiers" registry operates under the IETF Review policy [RFC5226].
「Web Push Identifiers」レジストリは、IETFレビューポリシー[RFC5226]の下で動作します。
Registry name: Web Push Identifiers
レジストリ名：Webプッシュ識別子
URN Prefix: urn:ietf:params:push
Specification: RFC 8030 (this document)
仕様：RFC 8030（このドキュメント）
Repository: http://www.iana.org/assignments/webpush-parameters/
Index Value: Values in this registry are URNs or URN prefixes that start with the prefix "urn:ietf:params:push". Each is registered independently.
インデックス値：このレジストリの値は、接頭辞「urn：ietf：params：push」で始まるURNまたはURN接頭辞です。それぞれが個別に登録されます。
Registrations in the "Web Push Identifiers" registry include the following information:
「Web Push Identifiers」レジストリの登録には、次の情報が含まれています。
URN: A complete URN or URN prefix.
URN：完全なURNまたはURNプレフィックス。
Description: A summary description.
説明：概要の説明。
Contact: Email for the person or group making the registration.
連絡先：登録を行う人またはグループのメール。
Index Value: As described in [RFC3553]
インデックス値：[RFC3553]で説明されているとおり
Reference: A reference to a specification describing the semantics of the URN or URN prefix.
参照：URNまたはURN接頭辞のセマンティクスを説明する仕様への参照。
URN prefixes that are registered include a description of how the URN is constructed. This is not applicable for specific URNs.
登録されているURNプレフィックスには、URNの構成方法の説明が含まれています。これは特定のURNには適用されません。
These values are entered as the initial content of the "Web Push Identifiers" registry.
これらの値は、「Web Push Identifiers」レジストリの初期コンテンツとして入力されます。
URN: urn:ietf:params:push
Description: This link relation type is used to identify a resource for sending push messages.
説明：このリンク関係タイプは、プッシュメッセージを送信するためのリソースを識別するために使用されます。
Contact: The WEBPUSH WG of the IETF (webpush@ietf.org)
連絡先：IETFのWEBPUSH WG（webpush@ietf.org）
Reference: RFC 8030 (this document)
参照：RFC 8030（このドキュメント）
URN: urn:ietf:params:push:set
Description: This link relation type is used to identify a collection of push message subscriptions.
説明：このリンク関係タイプは、プッシュメッセージサブスクリプションのコレクションを識別するために使用されます。
Contact: The WEBPUSH WG of the IETF (webpush@ietf.org)
連絡先：IETFのWEBPUSH WG（webpush@ietf.org）
Reference: RFC 8030 (this document)
参照：RFC 8030（このドキュメント）
URN: urn:ietf:params:push:receipt
Description: This link relation type is used to identify a resource for receiving delivery confirmations for push messages.
説明：このリンク関係タイプは、プッシュメッセージの配信確認を受信するためのリソースを識別するために使用されます。
Contact: The WEBPUSH WG of the IETF (webpush@ietf.org) Reference: RFC 8030 (this document)
連絡先：IETFのWEBPUSH WG（webpush@ietf.org）参照：RFC 8030（このドキュメント）
Service names and port numbers are registered within the "Service Name and Transport Protocol Port Number Registry" maintained at <https://www.iana.org/assignments/service-names-port-numbers/>.
サービス名とポート番号は、<https://www.iana.org/assignments/service-names-port-numbers/>にある「サービス名とトランスポートプロトコルのポート番号レジストリ」に登録されています。
In accordance with [RFC6335], IANA has assigned the System Port number 1001 and the service name "webpush".
[RFC6335]に従い、IANAはシステムポート番号1001とサービス名「webpush」を割り当てました。
Service Name: webpush
サービス名：webpush
Port Number: 1001
ポート番号：1001
Transport Protocol: tcp
トランスポートプロトコル：tcp
Description: HTTP Web Push
説明：HTTP Webプッシュ
Assignee: The IESG (iesg@ietf.org)
譲受人：IESG（iesg@ietf.org）
Contact: The IETF Chair (chair@ietf.org)
連絡先：IETF議長（chair@ietf.org）
Reference: RFC 8030 (this document)
参照：RFC 8030（このドキュメント）
[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/>.
[CAP-URI] Tennison、J.、「機能URLのグッドプラクティス」、W3C最初の公開草案ケーパビリティURL、2014年2月、<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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[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>.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、BCP 73、RFC 3553、DOI 10.17487 / RFC3553、2003年6月、 <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>.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、DOI 10.17487 / RFC3864、2004年9月、<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>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<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>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<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>.
[RFC5382] Guha、S。、編、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT動作要件」、BCP 142、RFC 5382、DOI 10.17487 / RFC5382、 2008年10月、<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>.
[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、DOI 10.17487 / RFC5988、2010年10月、<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>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<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>.
[RFC6454] Barth、A。、「The Web Origin Concept」、RFC 6454、DOI 10.17487 / RFC6454、2011年12月、<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>.
[RFC6585]ノッティンガム、M。およびR.フィールディング、「追加HTTPステータスコード」、RFC 6585、DOI 10.17487 / RFC6585、2012年4月、<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>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[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>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<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>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<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>.
[RFC7240] Snell、J。、「Prefer Header for HTTP」、RFC 7240、DOI 10.17487 / RFC7240、2014年6月、<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>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<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>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<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>.
[RFC7838]ノッティンガム、M。、マクマナス、P。、およびJ.レシュケ、「HTTP Alternative Services」、RFC 7838、DOI 10.17487 / RFC7838、2016年4月、<http://www.rfc-editor.org/info/ rfc7838>。
[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/>.
[API] Beverloo、P.、Thomson、M.、van Ouwerkerk、M.、Sullivan、B。、およびE. Fullea、「Push API」、W3C Editor's Draft push-api、2016年11月、<https：// w3c .github.io / push-api />。
[ENCRYPT] Thomson, M., "Message Encryption for Web Push", Work in Progress, draft-ietf-webpush-encryption-06, October 2016.
[暗号化] Thomson、M。、「Webプッシュのメッセージ暗号化」、進行中の作業、draft-ietf-webpush-encryption-06、2016年10月。
[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>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<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.
[VAPID] Thomson、M。、およびP. Beverloo、「Web Pushの自発的アプリケーションサーバー識別」、Work in Progress、draft-ietf-webpush-vapid-01、2016年6月。
Acknowledgements
謝辞
Significant technical input to this document has been provided by Ben Bangert, Peter Beverloo, Kit Cambridge, JR Conlin, Lucas Jenss, Matthew Kaufman, Costin Manolache, Mark Nottingham, Idel Pivnitskiy, Robert Sparks, Darshak Thakore, and many others.
このドキュメントに対する重要な技術情報は、ベンバンガート、ピーターベバールー、キットケンブリッジ、JRコンリン、ルーカスイェンス、マシューカウフマン、コスティンマノラッシュ、マークノッティンガム、アイデルピヴニツキー、ロバートスパークス、ダーシャクタコレ、その他多数から寄せられました。
Authors' Addresses
著者のアドレス
Martin Thomson Mozilla 331 E Evelyn Street Mountain View, CA 94041 United States of America
マーティントムソンMozilla 331 E Evelyn Street Mountain View、CA 94041アメリカ合衆国
Email: martin.thomson@gmail.com
Elio Damaggio Microsoft One Microsoft Way Redmond, WA 98052 United States of America
エリオダマッジオマイクロソフトワンマイクロソフトウェイレドモンド、ワシントン州98052アメリカ合衆国
Email: elioda@microsoft.com
Brian Raymor (editor) Microsoft One Microsoft Way Redmond, WA 98052 United States of America
ブライアンレイモア（編集者）マイクロソフトワンマイクロソフトウェイレドモンド、ワシントン州98052アメリカ合衆国
Email: brian.raymor@microsoft.com