The Mercure Protocol
draft-dunglas-mercure-04
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2019-08-27
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
xml
pdf
htmlized
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 27 August 2019
Expires: 28 February 2020
The Mercure Protocol
draft-dunglas-mercure-04
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 28 February 2020.
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 (https://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.
Dunglas Expires 28 February 2020 [Page 1]
Internet-Draft The Mercure Protocol August 2019
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Publishers . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Subscribers . . . . . . . . . . . . . . . . . . . . . . . 8
6. Reconnection and State Reconciliation . . . . . . . . . . . . 8
7. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . 10
10. Informative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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: The unit to which one can subscribe to changes. The topic
MUST be identified by an IRI [!@RFC3987] or by a string. Using an
HTTPS [RFC7230] or HTTP [RFC7230] URI [RFC3986] is RECOMMENDED.
* 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. The target
MUST be identified by an IRI [!@RFC3987] or by a string. Using an
HTTPS [RFC7230] or HTTP [RFC7230] URI is RECOMMENDED.
* Hub: A server that handles subscription requests and distributes
the content to subscribers when the corresponding topics have been
updated. Any hub MAY implement its own policies on who can use
it.
Dunglas Expires 28 February 2020 [Page 2]
Internet-Draft The Mercure Protocol August 2019
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
Show full document text