Draft: draft-thomson-webpush-protocol

Commentary: Only one comment . Do you think you can look at that before I merge it ?
Paragraph (version A):
A link relation of type
"urn:ietf:params:push:message:subscription" refers to a resource
with read and delete access to a message subscription.  A user
agent monitor using this resource.
Paragraph (version B):
This resource provides read and delete access for a message
subscription.  A user agent monitor using a message subscription.
Paragraph (version A):
A link relation of type
"urn:ietf:params:push:receipt:subscription" refers to a resource
with read access to a receipt subscription.  An application server
request_receipt for push messages using this resource.
Paragraph (version A):
A user agent sends a POST request to its configured push service
resource to create a new subscription.  If successful, the push
service MUST return new "subscription", "push", and "receipt
subscribe" resources in response to this request.  URIs for these
resources are included in Link header fields in the response.
Paragraph (version A):
The user agent should securely distribute both the "push" and
"receipt subscribe" resources to its application server.  Details are
outside the scope of this document.
Paragraph (version A):
A response with a 201 (Created) status code includes a URI for the
"subscription" resource in the Location header field.
Paragraph (version A):
An application server creates a new subscription for push message
receipts by sending a HTTP POST request to the "receipt subscribe"
resource distributed by its user agent.  If successful, the push
service MUST return a new "receipt subscription" resource in response
to this request.  The URI for this resource is included in a Link
header field in the response.
Paragraph (version A):
A response with a 201 (Created) status code includes a URI for the
"receipt subscription" resource in the Location header field.
Paragraph (version B):
This resource provides read access for a receipt subscription.  An
application server request_receipt for push messages using a
receipt subscription.
Paragraph (version B):
A user agent sends a POST request to its configured push service
resource to create a new subscription.
Paragraph (version B):
A response with a 201 (Created) status code MUST include a URI for
the new "subscription" resource in the Location header field.
Paragraph (version B):
The push server MUST provide a URI for a new push resource that
corresponds to this subscription in a link relation of type
"urn:ietf:params:push:message".
Paragraph (version B):
The push server MUST provide a URI for a new receipt subscribe
resource that corresponds to this subscription in a link relation of
type "urn:ietf:params:push:receipt:subscribe".
Paragraph (version B):
The user agent SHOULD securely distribute both the "push" and
"receipt subscribe" URIs to its application server.  Details are
outside the scope of this document.
Paragraph (version B):
An application server creates a new subscription for push message
receipts by sending a HTTP POST request to the "receipt subscribe"
resource distributed by its user agent.
Paragraph (version B):
A successful response with a 201 (Created) status code MUST include a
URI for the "receipt subscription" resource in the Location header
field.
Paragraph (version A):
This link relation type is used to identify a resource for
subscribing to push messages.
Paragraph (version A):
This link relation type is used to identify a resource for
subscribing for delivery confirmations for push messages.