[2] プッシュメッセージ受領証 (push message receipt) は、 プッシュサービスからアプリケーションサーバーへ送信されるメッセージ配送確認です (message delivery confirmation) 。 >>1 1.1.

[15] 仕様書ではほかに receipt、 delivery receipt, push receipt, receipt of the message receipt of the push message と呼んだり、 機能として delivery confirmation と呼んだりしています。 利用者エージェントがこれを送信することを acknowledge と呼んでいます。

[3] 受領証購読資源 (receipt subscription resource) (リンク関係型 urn:ietf:params:push:receipt) は、 アプリケーションサーバーがプッシュメッセージの配送確認を受信するものです。 >>1 2.1.

[4] アプリケーションサーバーは、 プッシュ資源への要求 (プッシュメッセージの送信) で、 配送確認を要求できます。 アプリケーションサーバーは受領証購読資源を作成し、 応答で通知します。 プッシュメッセージの送信

[5] プッシュサービスは、 配送確認 (delivery confirmation) に対応しなければなりません >>1 5.1.。 アプリケーションはプッシュメッセージ資源に DELETE 要求を送信し、受領を肯定します。 それを踏まえてプッシュサービスはアプリケーションサーバーに適切に応答します。

[13] プッシュサービスは、 受領証購読を終了 (満期) できます。 >>1 7.3.

[10] アプリケーションサーバーは、 受領証購読資源に対し、 GET 要求を送信して受領証の配送を要求します。 >>1 6.3.

[12] プッシュサービスは、 受領証購読資源が満期の場合、 404 応答を返さなければなりません。 >>1 7.3.

[31] プッシュサービスは、 要求に対して応答しません。 HTTP/2 server push によって受領証を送信します。 >>1 6.3.

[40] プッシュサービスは、受領証ごとに、 PUSH_PROMISE で GET 要求を利用者エージェントに送信します。 この GET 要求は、 プッシュメッセージ資源を取得するものです。 >>1 6.3.

[11] それに対する応答は、 プッシュメッセージ配送の結果を表します。データは含みません。 >>1 6.3.

[6] 配送確認を受け取れるかどうかは TTL: の影響を受けます。

[7] Topic: の重複により置き換えられた古いプッシュメッセージについては、 利用者エージェントから遅れて配送肯定が届いても、 受領証は抑制するべきです。 >>1 5.4.

[8] プッシュサービスは、 プッシュメッセージ応答が DELETE された場合、 アプリケーションサーバーに 204 応答を返さなければなりません。 >>1 6.2., 6.3.

[9] プッシュサービスは、 TTL: 到来前にプッシュメッセージの配送を断念した場合、 アプリケーションサーバーに 410 応答を返さなければなりません。 >>1 6.2., 6.3.

[14] アプリケーションサーバーは、 受領証購読資源に DELETE 要求を送信して、 削除できます。 >>1 7.3.