Change:
Is there any value in using a link relation type for the receipt subscription rather than a new header field? We already have to define the link relation type, so maybe it can save on a bit of protocol machinery.
While considering this, I noticed an editorial error in Section 10.2 where the link relation is referenced as urn:ietf:push:receipts instead of urn:ietf:push:receipt which is used throughout the rest of the draft. Using a link relation might be more consistent - not sure that it saves on protocol machinery? Are you proposing to replace the Push-Receipt header with a new link relation - potentially there would be: push:receipts - to create new receipt subscriptions push:receipt - a specific receipt subscription
Yes, there are the same number of moving parts. My mistake. Just remembered the actual reason for opening the issue. The HTTP working group often state that header fields need to have wide applicability for them to be defined, otherwise the data they carry is best carried in payload bodies. The same restriction does not apply to link relations.

Discussion:
A push resource is used by the application server to request the delivery of a push message (see send).  A link relation of type <del> "urn:ietf:params:push" is used to identify a push resource. </del> <ins> "urn:ietf:params:push" identifies a push resource. </ins> A push message resource is created to identify push messages that have been accepted by the push service.  The push message resource

A receipt subscribe resource is used by an application server to create a receipt subscription (see receipt_subscription).  A link <del> relation of type "urn:ietf:params:push:receipt" is used to identity a receipt subscribe resource. </del> <ins> relation of type "urn:ietf:params:push:receipts" identifies a receipt subscribe resource. </ins> An application server request_receipt for push messages using a <del> receipt subscription. </del> <ins> receipt subscription.  A link relation of type "urn:ietf:params:push:receipt" is identifies a receipt subscription. </ins> 3.

of type "urn:ietf:params:push". The push service MUST provide a URI for a receipt subscribe resource <del> in a link relation of type "urn:ietf:params:push:receipt". </del> <ins> in a link relation of type "urn:ietf:params:push:receipts". </ins> An application-specific method is used to distribute the push and receipt subscribe URIs to the application server.  Confidentiality

6.1. <del> An application server can use the Push-Receipt header field to request a confirmation from the push service when a push message is delivered and acknowledged by the user agent.  The Push-Receipt header field is a URI-Reference as defined in Section 2.7 of RFC7230. </del> <ins> An application server can use the "urn:ietf:params:push:receipt" link relation type to request a confirmation from the push service when a push message is delivered and acknowledged by the user agent. </ins> <del> The application sets the Push-Receipt header field value to a receipt </del> <ins> The application sets the link relation value to a receipt </ins> subscription URI.  This receipt subscription resource MUST be created from the same receipt subscribe resource which was returned with the push message subscription response (see message_subscription).

urn:ietf:params:push:receipt This link relation type is used to identify a resource for <del> creating new push message receipt subscriptions. </del> <ins> receiving delivery confirmations for push messages. (this document) The Web Push WG (webpush@ietf.org) urn:ietf:params:push:receipts This link relation type is used to identify a resource for subscribing to delivery confirmations for push messages. </ins> (this document)