Draft: draft-ietf-webpush-protocol

Commentary: 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 .
Paragraph (version A):
A push resource is used by the application server to request the
delivery of a push message (see send).  A link relation of type
"urn:ietf:params:push" is used to identify a push resource.
Paragraph (version B):
A push resource is used by the application server to request the
delivery of a push message (see send).  A link relation of type
"urn:ietf:params:push" identifies a push resource.
Paragraph (version A):
A receipt subscribe resource is used by an application server to
create a receipt subscription (see receipt_subscription).  A link
relation of type "urn:ietf:params:push:receipt" is used to
identity a receipt subscribe resource.
Paragraph (version A):
An application server request_receipt for push messages using a
receipt subscription.
Paragraph (version B):
A receipt subscribe resource is used by an application server to
create a receipt subscription (see receipt_subscription).  A link
relation of type "urn:ietf:params:push:receipts" identifies a
receipt subscribe resource.
Paragraph (version B):
An application server request_receipt for push messages using a
receipt subscription.  A link relation of type
"urn:ietf:params:push:receipt" is identifies a receipt
subscription.
Paragraph (version A):
The push service MUST provide a URI for a receipt subscribe resource
in a link relation of type "urn:ietf:params:push:receipt".
Paragraph (version B):
The push service MUST provide a URI for a receipt subscribe resource
in a link relation of type "urn:ietf:params:push:receipts".
Paragraph (version A):
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.
Paragraph (version A):
The application sets the Push-Receipt header field value to a receipt
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).
Paragraph (version B):
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.
Paragraph (version B):
The application sets the link relation value to a receipt
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).
Paragraph (version A):
This link relation type is used to identify a resource for
creating new push message receipt subscriptions.
Paragraph (version B):
This link relation type is used to identify a resource for
receiving delivery confirmations for push messages.
Paragraph (version B):
This link relation type is used to identify a resource for
subscribing to delivery confirmations for push messages.