RFC 8030

Generic Event Delivery Using HTTP Push

📅 published December 2016, from ietf

1. Introduction ✨

Okay so, bestie, we're starting with the title block and let me tell you, it's giving main character energy 🦋. This is RFC 8030: Generic Event Delivery Using HTTP Push 💖. It's a Standards Track document from the IETF, dated December 2016, and it was written by M. Thomson (Mozilla), E. Damaggio, and B. Raymor, Ed. (Microsoft). It's ISSN 2070-1721 🎀. Nothing in the title block says it obsoletes or updates another RFC, so there's nothing to replace or patch 💅.

Read this first, then keep going 🫶. The section below is the intro, and it's a whole vibe.

Many applications on mobile and embedded devices need to stay connected all the time so that real-time events, like incoming calls or messages, can be delivered (or "pushed") quickly 🌸. These devices usually have limited power, so finding more efficient ways to serve app needs is a huge win for the whole ecosystem 🔋.

Radio is a big power hog 😭. Radio communications eat a major chunk of a wireless device's energy budget, so it's not a small thing.

Here's the tea 🍵: when multiple apps each keep their own persistent connections or sessions going, they can waste the device radio, because every single session brings its own overhead 💀. Keep-alive traffic, which is used so middleboxes don't time out sessions too early, can add up to a lot of waste 🙈. Maintenance traffic ends up dominating over the long run, since the events themselves are relatively rare ✨.

So the move is to consolidate all real-time events into one session 👑. A single service gathers all the events and hands them off to applications as they arrive. That means just one session, so you avoid all those duplicated overhead costs 💅. Iconic, honestly.

The W3C Push API [API] describes an API that lets web applications use a consolidated push service 🧚. This document builds on that work by describing a protocol that can be used to:

  • request the delivery of a push message to a user agent,
  • create new push message delivery subscriptions, and
  • monitor for new push messages.

A standardized way to deliver events matters a lot for the W3C Push API 🍓, especially since application servers might need to use multiple push services. Right now, the subscription, management, and monitoring jobs are handled by proprietary protocols 🙄. Those work fine, but they don't get the perks that standardization brings 💜.

This document intentionally does not describe how a push service is discovered 🔍. Discovery is left for future efforts, if it turns out to be needed at all. For now, user agents are expected to be configured with a URL for a push service 🎀.

1.1. Conventions and Terminology 📚

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]. 🫶

This document defines the following terms, so let's get everyone on the same page 🤓:

  • application: Both the sender and the ultimate consumer of push messages. Lots of applications have parts that run on a user agent and other parts that run on servers 📱🖥️.
  • application server: The part of an application that usually runs on a server and asks for a push message to be delivered 🖥️.
  • push message subscription: A message delivery context set up between the user agent and the push service, and shared with the application server. Every push message is tied to a push message subscription 🔗.
  • push message subscription set: A message delivery context set up between the user agent and the push service that groups multiple push message subscriptions into a set 🗂️.
  • push message: A message sent from an application server to a user agent through a push service 💌.
  • push message receipt: A 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 receives push messages 📲.

Examples in this document use the HTTP/1.1 message format [RFC7230] 🌈. Lots of the exchanges can be done with HTTP/1.1:

  • Subscribing for Push Messages (Section 4)
  • Requesting Push Message Delivery (Section 5)
  • Replacing Push Messages (Section 5.4)
  • Acknowledging Push Messages (Section 6.2)

When an example depends on HTTP/2 server push, the more verbose frame format from [RFC7540] is used 🎬:

  • Receiving Push Messages for a Subscription (Section 6)
  • Receiving Push Messages for a Subscription Set (Section 6.1)
  • Receiving Push Message Receipts (Section 6.3)

All examples use HTTPS over the default port (443) rather than the registered port (1001) 🔐. A push service deployment might prefer this setup to give user agents the best shot at reaching the service 🎯. A push service might also use HTTP alternative services to redirect a user agent to the registered port (1001), which gets the perks of the standardized HTTPS port without losing reachability (see Section 3) 🦋. This would only show up in the examples through the Alt-Used header field [RFC7838] in requests from the user agent to the push service 👀.

Examples don't include specific methods for push message encryption or application server authentication, because the protocol doesn't define a mandatory system 🙅‍♀️. If you want to see how the W3C Push API [API] handles its requirements, check out the examples in Voluntary Application Server Identification [VAPID] and Message Encryption for WebPush [ENCRYPT] 💖.

2. Overview ✨

okay so push services have a cast of three 🎭: the user agent, the push service, and the application server. let's get into the vibe 💅

    +-------+           +--------------+       +-------------+
    |  UA   |           | Push Service |       | Application |
    +-------+           +--------------+       |   Server    |
        |                      |               +-------------+
        |      Subscribe       |                      |
        |--------------------->|                      |
        |       Monitor        |                      |
        |<====================>|                      |
        |                      |                      |
        |          Distribute Push Resource           |
        |-------------------------------------------->|
        |                      |                      |
        :                      :                      :
        |                      |     Push Message     |
        |    Push Message      |<---------------------|
        |<---------------------|                      |
        |                      |                      |

                      Figure 1: WebPush Architecture

so at the very start 🎀, the user agent creates a new message subscription and then hands it off to its application server. this subscription is the root of every interaction after that, literally the foundation of the whole thing 🧚. the application server uses it to send messages to the push service for delivery to the user agent, and the user agent uses it to keep an eye on the push service for any incoming message 👀.

to give you more control over who gets to do what 🔐, a message subscription is split into two resources, each with different powers:

  • A subscription resource is used to receive messages from a subscription and to delete a subscription. It is private to the user agent 🤫.
  • A push resource is used to send messages to a subscription. It is public and shared by the user agent with its application server 📣.

it's expected that each application gets its own unique subscription 💜. but the protocol has no hard rules about how many there can be. you can make multiple subscriptions for the same application, or several applications can share one subscription. just know that sharing subscriptions has security and privacy implications, so think before you share 🙈.

subscriptions have a limited lifetime ⏳. either the push service or the user agent can also end one at any time, so user agents and application servers have to be ready to handle changes in the subscription state. no surprises allowed, bestie 💅.

2.1. HTTP Resources

this protocol uses HTTP resources [RFC7230] and link relations [RFC5988]. here are the resources it defines 🌸:

  • push service: This resource is used to create push message subscriptions (Section 4). A URL for the push service is configured into user agents.
  • 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.
  • 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.
  • 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 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. 🧾
  • 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. 🦋

3. Connecting to the Push Service

okay the connection part is so important 🔒. the push service MUST use HTTP over Transport Layer Security (TLS) [RFC2818] following the recommendations in [RFC7525]. it shares the same default port number (443/TCP) with HTTPS, but it MAY also advertise the IANA-allocated TCP System Port (1001) using HTTP alternative services [RFC7838] ✨.

here's the tea 🍵: the default port (443) has really broad reachability, but it's mostly used for web browsing, and it usually comes with a shorter idle timeout than other ports configured in middleboxes. for WebPush, that would cause unnecessary radio activity just to keep the connection alive on battery-powered devices 🔋. not ideal, no cap.

advertising the alternate port (1001) lets middleboxes tune their idle timeouts for connections that are specifically for push, where data is expected to show up pretty rarely 🌈.

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" 🕰️.

4. Subscribing for Push Messages

to make a new subscription, the user agent sends a POST request to its configured push service resource 📮.

POST /subscribe HTTP/1.1
Host: push.example.net

a 201 (Created) response means the push subscription was created 🎉. the URI for the push message subscription resource that was created in response to the request MUST be returned in the Location header field 📍.

the push service MUST provide a URI for the push resource that goes with the push message subscription, in a link relation of type "urn:ietf:params:push" 🔗.

distributing the push URI to the application server is an application-specific thing 🤷‍♀️. but confidentiality protection and application server authentication MUST be used so this URI is not disclosed to unauthorized recipients (Section 8.3). it's giving security, periodt 🔐.

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

4.1. Collecting Subscriptions into Sets

okay this one's a total efficiency glow-up ⚡. grouping push message subscriptions into a subscription set can be a huge win for both 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" 💜.

when a subscription set comes back in a push message subscription response, the user agent SHOULD include that set in a link relation of type "urn:ietf:params:push:set" in later requests to create new push message subscriptions 🫶.

a user agent MAY skip the subscription set if it can't receive push messages in an aggregated way for the whole lifetime of the subscription 🙃. this could happen if the user agent is monitoring subscriptions on behalf of other push message receivers.

POST /subscribe HTTP/1.1
Host: push.example.net
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
        rel="urn:ietf:params:push:set"

the push service SHOULD send back the same subscription set in its response 🔁. it MAY return a new subscription set instead, but only if it can't reuse the one the user agent gave it 🫠.

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 🚫. it MAY return a 429 (Too Many Requests) status code [RFC6585] to turn down requests that leave out a subscription set 🛑.

how a push service figures out that requests come from the same user agent is up to the implementation 🕵️. it could look at ambient info like the TLS connection, source IP address, and port. implementers, a gentle reminder: some heuristics can produce false positives, which means legit requests might get rejected by accident 🥺.

5. Requesting Push Message Delivery

an application server asks for a push message to be delivered by sending an HTTP POST request to a push resource that a user agent handed to it 📬. the content of the push message goes in the body of the request ✉️.

POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36

iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB

a 201 (Created) response means the push message was accepted 🥳. the URI for the push message resource that was created in response to the request MUST be returned in the Location header field. but heads up ⚠️: this does NOT mean the message reached the user agent yet. accepted is not the same as delivered, bestie 💀.

HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:55 GMT
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt

5.1. Requesting Push Message Receipts ✨

okay bestie, so an application server can slap the Prefer header field [RFC7240] on its request with the "respond-async" preference 💅. That's how it asks the push service to confirm when a push message is delivered and then acknowledged by the user agent 🫶. The push service MUST support delivery confirmations 🔥.

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" 🎀.

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, which is so smart 🧠✨. The push service SHOULD return the same receipt subscription in its response. It MAY return a new receipt subscription if it's unable to reuse the one the application server provided 🦋.

An application server MAY omit the receipt subscription if it's 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 👀.

A push service MUST return a 400 (Bad Request) status code for requests that contain an invalid receipt subscription 🙅‍♀️. If a push service wants 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 🚦.

5.2. Push Message Time-To-Live ⏰

okay so a push service can seriously boost delivery reliability by storing push messages for a while 💖. User agents are often only intermittently connected, so short-term storage at the push service is a total lifesaver 🛟.

Delaying delivery might also be used to batch communication with the user agent, which conserves radio resources 🔋✨.

Some push messages stop being useful once a certain amount of time passes 🙈. Delivering them after they've stopped being relevant is wasteful 🗑️. For example, if the push message is a call notification, getting it after the caller already hung up is of zero value 📞💀. The app at the user agent then has to suppress the message so it doesn't pop up 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 holds a value in seconds that suggests how long a push message is retained by the push service 🕰️.

The TTL rule specifies a non-negative integer, representing time in seconds. A recipient that parses and converts a TTL value to binary form SHOULD use an arithmetic type with 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 = 1*DIGIT

A push service MUST return a 400 (Bad Request) status code in response to requests that omit the TTL header field 🚫.

A push service MAY retain a push message for a shorter duration than requested 🏃‍♀️. It shows 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 the application server provided 💅.

Once the TTL period elapses, the push service MUST NOT attempt to deliver the push message to the user agent 🛑. A push service might tweak the TTL value to account for time accounting errors in processing. For instance, distributing a push message within a server cluster might rack up errors from clock skew or propagation delays 🌐.

A push service isn't obligated to account for time the application server spent sending a push message to the push service, or for delays while sending a push message to the user agent 🤷‍♀️. So the application server needs to account for transit delays when it picks a TTL header field value 🧠.

A Push message with a zero TTL is immediately delivered if the user agent is available to receive it ⚡. After delivery, the push service is allowed to remove a push message with a zero TTL right away 💨. That might happen before the user agent acknowledges receipt by performing an HTTP DELETE on the push message resource. So an application server can't count on getting acknowledgement receipts for zero TTL push messages 😭.

If the user agent is unavailable, a push message with a zero TTL expires and is never delivered 🪦.

5.3. Push Message Urgency 🔋

For a battery-powered device, it's often critical that it stays dormant for long stretches 😴. Radio communication in particular eats up power and limits how long the device can keep running 🪫.

To avoid burning resources on trivial messages, it's super helpful if an application server can communicate the urgency of a message, and if the user agent can ask the push server to only forward 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" 🫶.

A user agent MAY include the Urgency header field when monitoring for push messages, to indicate the lowest urgency of push messages it's willing to receive 🔔. A push service MUST NOT deliver push messages with lower urgency than the value the user agent indicated in its monitoring request 🚷. Push messages of any urgency are delivered to a user agent that doesn't include an Urgency header field when monitoring for messages 🌈.

The grammar for the Urgency header field is as follows:

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

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 🙅‍♀️.

5.4. Replacing Push Messages 🔄

A push message the push service has stored can be replaced with new content 💫. If the user agent is offline while the push messages are being sent, updating a push message avoids the situation where outdated or redundant messages get 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 it doesn't convey any other semantics 🫧.

The grammar for the Topic header field uses the "token" rule defined in [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 filename-safe Base 64 alphabet [RFC4648] 🔤. A push service that receives a request with a Topic header field that doesn't meet these constraints MUST return a 400 (Bad Request) status code to the application server 🚫.

A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource with 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 already 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 🔁.

A push message with a topic that isn't 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 created in response to the request is included in the Location header field 📍.

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 🔓⚠️.

6. Receiving Push Messages for a Subscription 📬

okay so this is where the user agent actually gets to hear the messages 🦋 It asks for new push messages by sending a GET request to a push message subscription resource 💖 The push service doesn't reply to that request right away. Instead, it uses HTTP/2 server push [RFC7540] to send the contents of each push message as soon as an application server sends it 🔥

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) ✨

Each push message gets pushed as the response to a synthesized GET request that shows up in a PUSH_PROMISE 🧚 That GET is aimed at the push message resource the push service made when the application server asked for 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 the application server sent to the push resource. Literally the freshest copy 💅

Here's an example request made over 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

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. No waiting around, bestie 💜

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 🙈

6.1. Receiving Push Messages for a Subscription Set

okay so receiving messages for a subscription set is basically the same as for a single subscription, with a few small differences 🍓 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. Way less overhead, iykyk 🫶

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 doesn't 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 🦋

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) ✨

Each push message gets pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. That GET is aimed at the push message resource the push service created 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 lets the user agent tell where each message came from 🧚 The response body is the entity body from the most recent request an application server sent to the push resource.

Here's the example request, made over 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

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, the push service MUST generate a server push for all push messages that have not yet been delivered. Instant gratification 🔥

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 💀

6.2. Acknowledging Push Messages

okay this part is so important 😭 To make sure a push message reaches 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 🫶

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 🎀

If the push service doesn't get the acknowledgement within a reasonable amount of time, the message is considered not yet delivered. The push service SHOULD keep retrying delivery of the message until its advertised expiration ⏳

The push service MAY stop retrying delivery of the message before its advertised expiration, for reasons like 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. Rip receipt 💀

6.3. Receiving Push Message Receipts

the application server asks the push service for receipts by sending an HTTP GET request to the receipt subscription resource 📬 The push service doesn't reply to that request right away. Instead, it uses HTTP/2 server push [RFC7540] to send push receipts whenever the user agent acknowledges a message (Section 6.2) ✨

Each receipt gets pushed as the response to a synthesized GET request sent in a PUSH_PROMISE. That GET is aimed at the same push message resource the push service created when the application server requested message delivery. The response includes a status code showing the result of the message delivery, and it carries no data 🧚

Here's the example request, made over 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 🌟

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 push message, and the push service stops retrying delivery before the message's advertised expiration, then the push service MUST push a failure response with a status code of 410 (Gone) 💔

7. Operational Considerations 🛠️

7.1. Load Management

a push service is likely to be juggling a very large number of open TCP connections 🌊 Managing those connections well can depend on being able to move them between server instances.

A user agent MUST support the 307 (Temporary Redirect) status code [RFC7231]. A push service can use it to spread load around when a new subscription is requested 🦋

A server that wants to spread out load can do it with HTTP alternative services [RFC7838]. Alternative services let you redistribute load while keeping the same URIs for various resources, which is lowkey genius 🧠 A user agent can make a smooth transition by using the GOAWAY frame once it has set up a replacement connection 🫶

7.2. Push Message Expiration

storing push messages based on the TTL header field can take up a potentially huge amount of space on a push service 😭 A push service isn't obligated to store messages forever. It can tell an application server how long it plans to keep a message by using the TTL header field (Section 5.2) ⏳

A user agent that isn't actively monitoring for push messages won't receive messages that expire during that gap 🙈

Push messages that are stored and haven't been delivered to a user agent get delivered once the user agent starts monitoring again 💌 Stored push messages SHOULD include a Last-Modified header field (Section 2.2 of [RFC7232]) showing when an application server requested delivery 🕰️

A GET request to a push message subscription resource with only expired messages gets a response as though no push message was ever sent. Zero drama 💅

Push services might need to limit the size and number of stored push messages so they don't get overloaded 🌸 To limit message size, 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 response to an entity body that is 4096 bytes or less in size. Small messages are always welcome, periodt 🎀

To limit the number of stored push messages, the push service MAY respond with a shorter Time-To-Live than the one the application server proposed in its request for push message delivery (Section 5.2) ⏱️ Once a message has been accepted, the push service MAY later expire the message before its advertised Time-To-Live. If the application server requested a delivery receipt, the push service MUST return a failure response (Section 6.2) 🥀

7.3. Subscription Expiration ⏳

okay so sometimes a subscription has to get terminated so it can be refreshed 🔄 and this applies to BOTH push message subscriptions AND receipt subscriptions. bestie, it's giving clean lifecycle energy ✨

A push service MAY expire a subscription at any time 💅 and 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, that MUST be signaled by returning a 404 (Not Found) status code. no cap, the 404 is non-negotiable 🙅‍♀️

A push service MUST return a 404 (Not Found) status code if an application server tries to send a push message to an expired push message subscription. the sender gets told it's gone, periodt 💀

A user agent can remove its push message subscription by sending a DELETE request to the corresponding URI 🗑️ and an application server can remove its receipt subscription by sending a DELETE request to the corresponding URI too. same energy, different lane 🦋

7.3.1. Subscription Set Expiration 🧺

A push service MAY expire a subscription set at any time, and it MUST also expire all push message subscriptions in the set 👑 that's the whole squad going down together, lowkey dramatic but iconic. If a user agent has an outstanding request to a push subscription set (Section 6.1), that MUST be signaled by returning a 404 (Not Found) status code 🌸

A user agent can request that a subscription set be removed by sending a DELETE request to the subscription set URI 🎀 and this MUST also remove all push message subscriptions in the set. the set goes, the members go, no exceptions 🫶

If a specific push message subscription that's a member of a subscription set gets expired or removed, then it MUST also be removed from its subscription set 🧚 no ghost members allowed!

7.4. Implications for Application Reliability 🍓

okay real talk, a push service that doesn't support reliable delivery over flaky network connections or failing applications on devices forces the device to acknowledge receipt directly to the application server 😭 which means extra power drain just to set up and keep (usually secure) connections going to each individual app server. the battery is SCREAMING 🔋💀

Push message reliability can be super important if messages carry info that's critical to the state of an application. repairing state can be expensive, especially for devices with limited communications capacity 🥲 and knowing a push message was correctly received saves you from retransmissions, polling, and state resynchronization. it's like a little receipt that says "we're good bestie" 🧾💖

The availability of push message delivery receipts means the application developer isn't tempted to build alternative mechanisms for message delivery in case the push service fails to deliver a critical message 🙈 because setting up a polling mechanism or a backup messaging channel to make up for these shortcomings negates almost all of the advantages a push service provides. don't do it, it's not worth it 💅

However, reliability might not be necessary for messages that are transient (e.g., an incoming call) 📞 or messages that get quickly superseded (e.g., the current number of unread emails) 📬 those can be a little more chaotic and that's fine ✨

7.5. Subscription Sets and Concurrent HTTP/2 Streams 🌈

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 line up its subscription requests one at a time, so no multitasking for this one 🙃

8. Security Considerations 🔐

okay this part is SERIOUS bestie, so pay attention 🚨 This protocol MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525]. this covers 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 🔒 and that gives confidentiality and integrity protection for subscriptions and push messages from external parties. lock it down 💜

8.1. Confidentiality from Push Service Access 👀

The protection TLS gives you does NOT protect content from the push service 😳 without extra safeguards, a push service can inspect and modify the message content. yikes 💀

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 set up a proper security context. the subscription info that goes from the user agent to its application server is also a convenient medium for key agreement, which is honestly so clever 🧠✨

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, so mix and match as needed 🫶

The Topic header field exposes information that allows more granular correlation of push messages on the same subject 👀 and that might be used to aid traffic analysis of push messages by the push service. so be careful with what you put in Topic 🙈

8.2. Privacy Considerations 🕵️‍♀️

Push message confidentiality does NOT ensure that the identity of who is communicating, and when they are communicating, is protected 😭 however, the amount of info that's exposed can be limited, so that's the goal 💖

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 lets a user agent control correlation across different applications or over time. of course, this doesn't prevent correlation using other info a user agent might expose, so it's not a magic shield 🙃

Similarly, the URIs the push service gives out 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 🎀

User and device information MUST NOT be exposed through a push or push message URI 🚫 no leaking your deets, bestie 💅

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 🌸

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. 👀 the vibe is "close enough, but stay aware" 🫶

A user agent MUST be able to create new subscriptions with new identifiers at any time 🦋 fresh start whenever you want, iconic.

8.3. Authorization 🔑

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, and there are multiple options (including experimental ones) 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 📋

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. so if you have the link, you're in 💅

Capability URLs are used for their "easy onward sharing" and "easy client API" properties ✨ and these properties make it possible to avoid relying on prearranged relationships or additional protocols between push services and application servers. no extra handshake drama needed 🙌

Capability URLs act as bearer tokens 🎟️ knowing a push message subscription URI implies authorization to either receive push messages or delete the subscription. knowing a push URI implies authorization to send push messages. knowing a push message URI allows for reading and acknowledging that specific message. knowing a receipt subscription URI implies authorization to receive push receipts. every URI is basically a key 🔑

Encoding a large amount of random entropy (at least 120 bits) in the path component ensures that it's difficult to successfully guess a valid capability URL 🧠💪 so make those paths super random, no "/my-cute-url" allowed 🙅‍♀️

8.4. Denial-of-Service Considerations 🚧

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 means only application servers that have actually received a push URI can use it 🫶

Push messages that aren't successfully authenticated by the user agent won't be delivered, but this can still present a denial-of-service risk 😰 Even a relatively small volume of push messages can cause battery-powered devices to exhaust their power reserves 🔋💀

To address this case, the W3C Push API [API] has adopted Voluntary Application Server Identification [VAPID], which lets a user agent restrict a subscription to a specific application server 🛡️ the push service can then identify and reject unwanted messages without contacting the user agent. bye bye spam 👋

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 😈 so Push services SHOULD limit the rate at which push messages are sent to individual user agents 🚦

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 making another request to the push resource ⏰

A push service or user agent MAY also terminate subscriptions (Section 7.3) that receive too many push messages 🛑

A push service is also able to deny service to user agents 😬 Intentional failure to deliver messages is difficult to tell apart from faults, which might happen due to transient network errors, interruptions in user agent availability, or genuine service outages. it's a whole mess to untangle 🌀

8.5. Logging Risks 📜

Server request logs can reveal subscription-related URIs, or relationships between subscription-related URIs for the same user agent 👀 Limits on log retention and strong access control mechanisms can make sure URIs aren't revealed to unauthorized entities. lock your logs, bestie 🔐

9. IANA Considerations 🌸

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, and port registration is defined in Section 9.3

9.1. Header Field Registrations 📋

HTTP header fields are registered within the "Message Headers" registry maintained at 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]) ✨

+-------------------+----------+----------+--------------+
| 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" 🫶 and that's the registry glow-up, bestie 💖🌈

okay so IANA is getting three brand new link relation URNs, bestie 🎀 They're going into a fresh "Web Push Identifiers" registry, and that registration follows the procedures in Section 4 of [RFC3553] ✨. The matching "push" sub-namespace also got entered in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry 💅

The "Web Push Identifiers" registry runs under the IETF Review policy [RFC5226] 👑

Here's what the registry template looks like 🌸

Registry name:  Web Push Identifiers

URN Prefix:  urn:ietf:params:push

Specification:  RFC 8030 (this document)

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.

Every registration in this registry comes with a few details 🧚 Here they are, in their fields 💖

URN:  A complete URN or URN prefix.

Description:  A summary description.

Contact:  Email for the person or group making the registration.

Index Value:  As described in [RFC3553]

Reference:  A reference to a specification describing the semantics
   of the URN or URN prefix.

   URN prefixes that are registered include a description of how the
   URN is constructed.  This is not applicable for specific URNs.

And these three URNs are the starter pack, loaded in as the initial content of the "Web Push Identifiers" registry 🍓

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)

Reference:  RFC 8030 (this document)

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)

Reference:  RFC 8030 (this document)

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)

9.3. Service Name and Port Number Registration 🌈

Service names and port numbers live in the "Service Name and Transport Protocol Port Number Registry", which you can find at <https://www.iana.org/assignments/service-names-port-numbers/> 🦋

Following [RFC6335], IANA has given us System Port number 1001 and the service name "webpush" 💜 Here's the entry 💅

Service Name:
   webpush

Port Number:
   1001

Transport Protocol:
   tcp

Description:
   HTTP Web Push

Assignee:
   The IESG (iesg@ietf.org)

Contact:
   The IETF Chair (chair@ietf.org)

Reference:
   RFC 8030 (this document)

10. References 📚

10.1. Normative References 💖

These are the references the spec leans on hardest, so bookmark them 🔥

[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/>.

[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>.

[RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
           DOI 10.17487/RFC2818, May 2000,
           <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>.

[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>.

[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>.

[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>.

[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>.

[RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
           DOI 10.17487/RFC5988, October 2010,
           <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>.

[RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
           DOI 10.17487/RFC6454, December 2011,
           <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>.

[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>.

[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>.

[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>.

[RFC7240]  Snell, J., "Prefer Header for HTTP", RFC 7240,
           DOI 10.17487/RFC7240, June 2014,
           <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>.

[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>.

[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>.

10.2. Informative References 🫶

These ones are background reading, not required homework 🧚

[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/>.

[ENCRYPT]  Thomson, M., "Message Encryption for Web Push", Work in
           Progress, draft-ietf-webpush-encryption-06, October 2016.

[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>.

[VAPID]    Thomson, M. and P. Beverloo, "Voluntary Application Server
           Identification for Web Push", Work in Progress,
           draft-ietf-webpush-vapid-01, June 2016.

Acknowledgements 🌸

big thank you to everyone who gave serious technical input to this doc 🥹 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 💜

Authors' Addresses 🎀

Martin Thomson
Mozilla
331 E Evelyn Street
Mountain View, CA  94041
United States of America

Email: martin.thomson@gmail.com


Elio Damaggio
Microsoft
One Microsoft Way
Redmond, WA  98052
United States of America

Email: elioda@microsoft.com


Brian Raymor (editor)
Microsoft
One Microsoft Way
Redmond, WA  98052
United States of America

Email: brian.raymor@microsoft.com

that's the whole spec, bestie!! 🌈✨💅

📦 where this page comes from