The Mercure Protocol
|The information below is for an old version of the document
Active Internet-Draft (individual)
||Intended RFC status
||(No stream defined)
||RFC Editor Note
||Send notices to
Network Working Group K. Dunglas
Intended status: Informational 22 October 2018
Expires: 25 April 2019
The Mercure Protocol
Mercure is a protocol allowing to push data updates to web browsers
and other HTTP clients in a fast, reliable and battery-efficient way.
It is especially useful to publish real-time updates of resources
served through web APIs, to reactive web and mobile apps.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 April 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
6. Re-Connection and State Reconciliation
8. Security Considerations
9.1. Normative References
9.2. Informative References
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
* Topic: An HTTP [RFC7230] or HTTPS [RFC2818] topic URL. The unit
to which one can subscribe to changes.
* Publisher: An owner of a topic. Notifies the hub when the topic
feed has been updated. As in almost all pubsub systems, the
publisher is unaware of the subscribers, if any. Other pubsub
systems might call the publisher the "source". Typically a
website or a web API, but can also be a web browser.
* Subscriber: A client application that subscribes to real-time
updates of topics. Typically a Progressive Web App or a Mobile
App, but can also be a server.
* Target: A subscriber, or a group of subscribers. A publisher is
able to securely dispatch updates to specific targets. Using an
HTTP [RFC7230] or HTTPS [RFC2818] URL to identify targets is
* Hub: A server that handles subscription requests and distributes
the content to subscribers when the corresponding topics have been
updated (a Hub implementation is provided in this repository).
Any hub MAY implement its own policies on who can use it.
If the publisher is a server, it SHOULD advertise the URL of one or
more hubs to the subscriber, allowing it to receive live updates when
topics are updated. If more than one hub URL is specified, it is
expected that the publisher notifies each hub, so the subscriber MAY
subscribe to one or more of them.
The publisher SHOULD include at least one Link Header [RFC5988] with
"rel=mercure" (a hub link header). The target URL of these links
MUST be a hub implementing the Mercure protocol.
Note: this relation type has not been registered yet [RFC5988].
During the meantime, the relation type "https://git.io/mercure" can
be used instead.
The publisher MAY provide the following target attributes in the Link
* "last-event-id": the globally unique identifier of the last event
dispatched by the publisher at the time of the generation of this
resource. If provided, it MUST be passed to the hub through a
query parameter called "Last-Event-ID" and will be used to ensure
that possible updates having been made during between the resource
generation time and the connection to the hub are not lost. See
section #Re-Connection-and-State-Reconciliation. If this
Show full document text