The Mercure Protocol
draft-dunglas-mercure-03
|
Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2019-01-09
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
xml
pdf
html
bibtex
|
Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group K. Dunglas
Internet-Draft Les-Tilleuls.coop
Intended status: Informational 9 January 2019
Expires: 13 July 2019
The Mercure Protocol
draft-dunglas-mercure-03
Abstract
Mercure is a protocol enabling the pushing of data updates to web
browsers and other HTTP clients in a fast, reliable and battery-
efficient way. It is especially useful for publishing 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 13 July 2019.
Copyright Notice
Copyright (c) 2019 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
1. Terminology
2. Discovery
3. Subscriptions
4. Publication
5. Authorization
5.1. Publishers
5.2. Subscribers
6. Reconnection and State Reconciliation
7. Encryption
8. Security Considerations
9.1. Normative References
9.2. Informative References
Author's Address
1. Terminology
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
RECOMMENDED.
* 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.
2. Discovery
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
RECOMMENDED 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]. In
the meantime, the relation type "https://git.io/mercure" MAY be used
instead.
The publisher MAY provide the following target attributes in the Link
Headers:
* "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