The MultiMedia Subscription Protocol (MMSP)

Internet-Draft: draft-mmsp-00
Date:           June 2026
Author:         MMSP Community
Status:         Community Specification
License:        Apache-2.0

Status note. MMSP is an independent, open community specification. The draft-NN versioning borrows IETF Internet-Draft naming as a familiar convention only: MMSP has not been submitted to the IETF, is not an IETF work product and is not affiliated with or endorsed by the IETF, the IESG or ISOC. “Pre-IETF” describes an intention to potentially pursue that track in future, not current standing.

Abstract

This document specifies the MultiMedia Subscription Protocol (MMSP), a JSON-based protocol for subscribing to and consuming multimedia content feeds. MMSP is a semantic superset of RSS 2.0 and Atom, extending feed syndication to cover rich multimedia content including video, audio, articles, images, short-form content, documents, galleries, events, software releases, newsletters, courses, and livestreams.

MMSP is designed around a “calm consumption” model. At the wire level it guarantees this through two enforceable properties: it is pull-only, with no server-push mechanism, and it mandates a minimum poll interval. Presentation behaviour, such as whether a client raises notifications, is out of scope for the base protocol; clients that wish to commit to calm behaviour MAY conform to the optional Calm Consumption Profile (Section 4.1). Subscribers consume feeds when they choose to, not when publishers demand attention.

1. Introduction

RSS and Atom have served as the foundation of web content syndication since the early 2000s. However, both protocols were designed primarily for text-based content and have accumulated multimedia support only through informal extensions and namespace overlays.

MMSP addresses three gaps:

1. Multimedia-first schema: item types, media attachments, chapters, transcripts, captions, and quality variants are first-class fields, not extension namespaces.

2. Cross-platform normalization: content from any declared source type (RSS, Atom, podcast feeds) normalizes into a single item schema, allowing unified consumption regardless of origin format.

3. Calm consumption: at the wire level the protocol guarantees pull-only behaviour and a minimum poll interval, and defines no server-push mechanism. How a client surfaces new items to a subscriber, including whether it notifies, is a client-presentation concern outside the base protocol; clients MAY additionally conform to the optional Calm Consumption Profile (Section 4.1).

1.1 Motivation

The proliferation of multimedia content platforms, combined with the notification fatigue caused by push-heavy consumption models, creates a need for a protocol that:

• Treats video, audio, and other media as first-class content types
• Enables subscription to content from any source with a declared feed
• Returns control of consumption timing to the subscriber

1.2 Design Principles

• Pull-only: MMSP servers MUST NOT push content to clients. Clients poll at their discretion, subject to poll interval constraints.
• Declared sources only: MMSP supports only sources that explicitly declare themselves consumable via a supported source type.
• Credential-free spec: authentication and platform API credentials are implementation concerns, not protocol concerns.
• Privacy by default: the protocol minimises information disclosed to publishers during polling.
• Backwards compatible: any RSS 2.0 or Atom feed is consumable as an MMSP source via normalization.

2. Conventions and Definitions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

Feed: A machine-readable document conforming to this specification that describes a collection of items published by a source.

Feed Manifest: The top-level MMSP document served at a feed URL, containing feed metadata and an array of items.

Item: A single piece of content within a feed, with a defined type and associated metadata.

Source: A content origin from which an MMSP client derives a feed, declared via a source type and configuration.

Client: A conforming implementation that polls feeds, normalizes source types, and presents content to a subscriber.

Publisher: An entity that serves a feed manifest at a stable URL.

Subscriber: A human or system that consumes content via an MMSP client.

Poll: An HTTP GET request issued by a client to retrieve the current state of a feed.

Normalization: The process of converting a non-native source type (RSS, Atom) into an MMSP item representation.

Calm consumption: The pattern of consuming feed content at subscriber-chosen times, with no server-push or notification mechanism.

4. Protocol Overview

MMSP is a stateless HTTP-based protocol. A publisher serves a feed manifest as a JSON document. A client polls the manifest URL periodically, respecting the declared poll interval, and presents new items to the subscriber when the subscriber chooses to view them.

Publisher                         Client                    Subscriber
    |                               |                            |
    |  GET /.well-known/mmsp.json   |                            |
    |  or feed URL                  |                            |
    |<------------------------------|                            |
    |  200 OK + Feed Manifest JSON  |                            |
    |------------------------------>|                            |
    |                               |  (stores new items)        |
    |                               |                            |
    |                               |  subscriber opens reader   |
    |                               |<---------------------------|
    |                               |  presents new items        |
    |                               |--------------------------->|

The base protocol defines no notification mechanism and places no normative requirement on how a client surfaces newly polled items to a subscriber; this is a client-presentation concern. Clients that wish to make an explicit commitment to calm behaviour MAY conform to the optional Calm Consumption Profile defined below.

4.1 Calm Consumption Profile (Optional)

The Calm Consumption Profile is an optional conformance profile that a client MAY claim. It exists so that “calm consumption” can be a concrete, self-certified commitment without placing unobservable requirements on the wire protocol.

A client claiming conformance to the Calm Consumption Profile:

• MUST NOT raise interruptive notifications (system push notifications, sounds, vibration, or badge counts) as a result of polling a feed.
• MUST surface newly polled items only in response to an explicit subscriber action, such as opening or refreshing the reader interface.
• MAY display a passive, non-interruptive unread indicator within its own interface.

Because notification behaviour is not observable on the wire, conformance to this profile cannot be verified by a publisher or by an on-the-wire conformance test; it is a commitment a client makes to its subscribers, not a property a publisher can test. This separation is deliberate: the base protocol carries only requirements that are observable and enforceable on the wire, and the calm-presentation contract lives here, as a profile, rather than as an untestable MUST in the core.

5. Feed Manifest

A feed manifest is a JSON object served over HTTPS. The media type is application/mmsp+json.

5.1 Required Fields

5.2 Optional Fields

5.3 Author Object

5.4 Capabilities

The capabilities field declares optional protocol features supported by this feed. Defined capability strings:

5.5 Pagination Object

A feed manifest returns the newest items inline. Older items are retrieved by walking pages backwards in time. A publisher that offers historical items beyond the first page SHOULD include a pagination object and a next_url.

5.5.1 Walking Pages

• When has_more is true, the manifest MUST include next_url. The client retrieves the next (older) page by issuing a poll to next_url.
• When has_more is false, the client has reached the end of the available history and MUST NOT request further pages.
• A client performing a backfill walk MUST follow next_url values only; it MUST NOT synthesise page URLs or numeric offsets of its own.

5.5.2 Consistency Under Mutation

Feeds change between page fetches as new items are published. To prevent items being skipped or duplicated during a backfill walk, the cursor MUST anchor a page to a stable ordering position, defined as descending published with item id as a tie-breaker, rather than to a numeric offset. Items published at the head of the feed after a walk begins MUST NOT alter the set of items reachable from an already-issued cursor. A publisher MUST keep a cursor resolvable for at least the feed’s ttl_seconds (Section 8.1) and SHOULD keep it resolvable for substantially longer. A client that receives an error or an unresolvable cursor MUST restart the walk from the feed manifest rather than guessing a position.

5.5.3 Termination and Loop Safety

A client MUST bound a backfill walk. It MUST stop when has_more is false, when next_url is absent, or when it observes a cursor value it has already seen during the current walk. A client SHOULD additionally impose an implementation-defined maximum page count per walk so that a misbehaving or hostile publisher cannot drive an unbounded fetch loop.

5.6 Feed Validation and Error Handling

A client MUST validate a feed manifest before use and MUST fail safely when validation does not pass. A failed poll MUST NOT discard previously stored, valid items for that feed.

• Malformed JSON. If the response body does not parse as JSON, the client MUST treat the poll as failed, MUST retain the last known-good state of the feed, and SHOULD surface a fetch error for that feed to the subscriber. The client MUST apply back-off (Section 8.3) rather than immediately re-polling.
• Wrong media type. If the response is not application/mmsp+json, and is not a recognised RSS/Atom/podcast source being normalized, the client SHOULD treat the poll as failed.
• Missing or mistyped required fields. If any field REQUIRED by Section 5.1 is absent, or is present with the wrong JSON type, the manifest is invalid; the client MUST reject the manifest as a whole and retain the last known-good state.
• Unknown manifest members. A client MUST ignore any feed-level member it does not recognise, rather than rejecting the manifest. This is the manifest-level counterpart of the item rule in Section 6.15, and is what lets a later minor version (Section 5.7) add feed-level fields safely.
• Unsupported version. Version handling is defined in Section 5.7.
• Invalid individual items. A client MUST NOT discard an entire, otherwise-valid feed solely because individual items are invalid. Item-level handling is defined in Section 6.15.

5.7 Protocol Versioning

The mmsp field carries a MAJOR.MINOR version string.

• Minor versions are additive and backward-compatible. A new MINOR version within the same MAJOR version MUST only add optional fields, item types, or capabilities. It MUST NOT remove a field, change the type or meaning of an existing field, or make an existing optional field required.
• Clients accept any minor version of a major version they implement. A client that implements major version N MUST accept any feed whose version is N.x, regardless of the value of x, and MUST ignore members it does not recognise (Sections 5.6 and 6.15). This is what makes adding fields in a later minor version safe.
• Major versions may break compatibility. A change to MAJOR signals a break. A client that does not implement a feed’s MAJOR version MUST NOT process the manifest as if it understood it; it MUST reject the feed and SHOULD inform the subscriber that the feed requires a newer client.
• Publishers MUST NOT introduce breaking changes within a major version. Any change that would break a conforming N.x client requires incrementing MAJOR.

6. Item Schema

Each entry in the items array is an item object.

6.1 Required Fields

6.2 Optional Fields

6.3 Item Types

The type field MUST contain one of the following values:

Clients MUST treat unrecognized type values as "article" for display purposes and MUST NOT reject items with unrecognized types.

6.4 Media Object

Multiple media entries with different mime_type or quality_label values represent quality variants of the same content.

6.5 Thumbnail Object

6.6 Chapter Object

6.7 Transcript Object

6.8 Caption Object

6.9 Series Object

6.10 ContentRating Object

6.11 GeoRestriction Object

6.12 Paywall Object

6.13 Source Object (Normalization Metadata)

Populated by clients during normalization of non-native source types.

6.14 Canonical URL and Deduplication

When the same content appears in multiple sources (e.g., a video available on both a primary platform and a mirror), canonical_url SHOULD be set to the authoritative URL for the content.

Clients that aggregate multiple sources SHOULD use canonical_url to deduplicate items. Two items with identical canonical_url values SHOULD be treated as the same piece of content.

6.15 Item Validation and Partial-Feed Tolerance

Real feeds contain occasional malformed items. A client MUST be tolerant of bad items without discarding the whole feed.

• Skip, do not reject. If an item is missing a field REQUIRED by Section 6.1, or carries a REQUIRED field of the wrong JSON type, the client MUST skip that single item and MUST continue processing the remaining items in the feed.
• Unknown members MUST be ignored. A client MUST ignore any object member it does not recognise, at every level of the item schema, rather than rejecting the item. This is the forward-compatibility rule that lets later minor versions (Section 5.7) and future extensions add fields without breaking existing clients.
• Unknown item types degrade. As defined in Section 6.3, an unrecognised type value MUST be treated as article for display and MUST NOT cause the item to be rejected.
• Invalid optional fields degrade. If an OPTIONAL field is present but malformed, the client SHOULD ignore that field and render the item without it, rather than skipping the item.
• Observability. A client SHOULD record how many items it skipped in a given poll so the condition is diagnosable, and SHOULD NOT silently hide a feed that yielded zero valid items from an otherwise successful fetch.

7. Source Types

MMSP defines five source types. A source type determines how a client acquires and normalizes a feed.

7.1 mfeed (Native MMSP)

A native MMSP feed manifest. No normalization required.

{
  "source": {
    "type": "mfeed",
    "url": "https://example.com/.well-known/mmsp.json"
  }
}

7.2 rss (RSS 2.0)

An RSS 2.0 feed. Clients MUST normalize RSS items to MMSP item schema per Appendix B.

{
  "source": {
    "type": "rss",
    "url": "https://example.com/feed.xml"
  }
}

7.3 atom (Atom 1.0)

An Atom 1.0 feed. Clients MUST normalize Atom entries to MMSP item schema per Appendix C.

{
  "source": {
    "type": "atom",
    "url": "https://example.com/atom.xml"
  }
}

7.4 podcast (RSS + Podcast Namespace)

An RSS feed using the iTunes or Podcast Index namespace for podcast metadata. Clients MUST normalize per Appendix B and SHOULD additionally map podcast-specific fields per Appendix D.

{
  "source": {
    "type": "podcast",
    "url": "https://example.com/podcast.xml"
  }
}

7.5 platform (Platform Adapter)

A platform-specific feed source. The platform_id identifies the platform adapter. Platform adapters are defined outside this specification. Clients that do not support a given platform_id SHOULD fall back to rss if an rss_fallback_url is provided.

{
  "source": {
    "type": "platform",
    "platform_id": "example-platform",
    "config": {},
    "rss_fallback_url": "https://example.com/feed.xml"
  }
}

8. Poll Semantics

8.1 Minimum Poll Interval

MMSP enforces a calm consumption model through mandatory poll interval constraints.

The poll object within a feed manifest declares polling parameters:

Normative constraints:

• Clients MUST NOT poll a feed more frequently than the declared min_interval_seconds. If not declared, the default minimum is 300 seconds (5 minutes).
• The min_interval_seconds value MUST NOT be set below 300 by publishers. Clients MUST enforce a floor of 300 seconds regardless of the declared value.
• Notification and presentation behaviour is not governed by this section. Clients that commit to suppressing interruptive notifications do so under the optional Calm Consumption Profile (Section 4.1).

8.2 Conditional GET

Clients SHOULD use HTTP conditional GET to avoid unnecessary data transfer:

• Clients SHOULD store the ETag response header value from each successful poll and send it as If-None-Match on subsequent polls.
• Clients SHOULD store the Last-Modified response header value and send it as If-Modified-Since on subsequent polls.
• When a server responds with 304 Not Modified, clients MUST treat this as a successful poll with no new items and MUST update their last-poll timestamp.

8.3 Rate Limiting

• When a server responds with 429 Too Many Requests, clients MUST cease polling for at least the duration specified in the Retry-After response header.
• If no Retry-After header is present, clients MUST apply an exponential back-off starting from the current min_interval_seconds.
• Clients MUST NOT retry a 429-responding feed more frequently than the calculated back-off interval.

8.4 Feed Relocation

When a feed permanently moves to a new URL, the publisher SHOULD serve the old URL with a 301 Moved Permanently HTTP response pointing to the new URL. Additionally, the publisher MAY set moved_to in the feed manifest:

{
  "moved_to": "https://new-location.example.com/.well-known/mmsp.json"
}

Clients that encounter moved_to MUST update stored subscription URLs to the new location and MUST NOT continue polling the old URL.

8.5 Feed Deprecation

A publisher announcing feed shutdown SHOULD set the deprecated field:

{
  "deprecated": {
    "reason": "This feed is shutting down.",
    "sunset_date": "2027-01-01T00:00:00Z"
  }
}

Clients SHOULD surface deprecation notices to subscribers.

9. Discovery

9.1 Well-Known URI

Publishers SHOULD serve the MMSP feed manifest at:

https://{host}/.well-known/mmsp.json

This path is registered per [RFC8615].

9.2 HTML Link Discovery

Publishers SHOULD include a link element in the HTML <head> of their website:

<link rel="alternate"
      type="application/mmsp+json"
      title="Feed Title"
      href="https://example.com/.well-known/mmsp.json">

9.3 Discovery Priority

Clients performing autodiscovery for a given URL SHOULD attempt discovery in the following order:

1. /.well-known/mmsp.json on the same host
2. HTML <link rel="alternate" type="application/mmsp+json"> element
3. HTML <link rel="alternate" type="application/rss+xml"> element (RSS fallback)
4. HTML <link rel="alternate" type="application/atom+xml"> element (Atom fallback)

10. RSS and Atom Normalization

When consuming rss, atom, or podcast source types, clients MUST normalize source items into MMSP item objects.

10.1 General Normalization Rules

• Fields present in the source MUST be mapped per Appendix B or C.
• Fields absent in the source MUST be omitted from the normalized item (not set to null).
• The normalized item’s source field MUST be populated with the source feed’s type and URL.
• The original source fields SHOULD be preserved in the original field.

10.2 Type Inference

When normalizing from RSS or Atom (which have no item type field), clients SHOULD infer type as follows:

1. If an enclosure or media attachment has a video MIME type: video
2. If an enclosure or media attachment has an audio MIME type: audio
3. If an enclosure or media attachment has an image MIME type: image
4. Otherwise: article

For podcast source type, all items SHOULD be inferred as audio unless overridden by media metadata.

11. HTTP Requirements

• All MMSP feed URLs MUST use HTTPS (TLS 1.2 or later). Clients MUST reject non-HTTPS feed URLs.
• Source URLs of type rss, atom, and podcast MUST use HTTPS. Clients SHOULD warn and MAY reject non-HTTPS source URLs.
• Clients MUST send a User-Agent header on all polls whose first token identifies the protocol and version: MMSP/<version> (for this revision, MMSP/1.0).
• Clients SHOULD append a single product token identifying the client software and its version, separated by a space, for example: User-Agent: MMSP/1.0 Meridian/2.3. This lets a publisher’s operator distinguish, rate-limit, and contact the author of a specific implementation that is behaving badly, which a uniform User-Agent makes impossible.
• To preserve subscriber privacy, the User-Agent MUST NOT carry any information that identifies the subscriber or the individual installation: no operating-system build string, no device identifier, no per-install or per-user token, and nothing derived from subscriber data. Permitted identification is limited to the coarse {software name, software version} pair, which is shared by every user of that client and therefore adds negligible per-subscriber entropy.
• Clients MUST NOT vary the User-Agent per feed, per poll, or per subscriber.

12. Security Considerations

12.1 HTTPS Enforcement

All feed URLs and media URLs in a conforming MMSP implementation MUST use HTTPS. This prevents content injection via man-in-the-middle attacks on unencrypted channels.

12.2 Content Sanitization

Item description fields may contain HTML. Clients MUST sanitize HTML content before rendering to prevent cross-site scripting (XSS) attacks. Clients MUST NOT execute JavaScript from feed content.

12.3 URL Validation

Clients MUST validate all URLs received in feed manifests before fetching. Clients MUST reject URLs with non-HTTPS schemes. Clients implementing server-side feed fetching MUST apply SSRF (Server-Side Request Forgery) mitigations including blocking private IP ranges and loopback addresses.

12.4 XML Parsing (RSS/Atom Normalization)

When parsing RSS or Atom XML for normalization, clients MUST disable external entity expansion to prevent XML External Entity (XXE) attacks. Clients MUST enforce a maximum document size limit to prevent denial-of-service via large XML documents (billion laughs attack).

12.5 Feed Authenticity (Known Limitation)

This revision of MMSP defines no mechanism for verifying that a feed served at a given URL is authoritative. This is a known limitation, to be addressed in a future revision, rather than a settled position.

HTTPS authenticates the transport to a host; it does not establish that the host is the legitimate publisher of a feed. An attacker who takes over a domain, a hosting account, or a network path (for example via DNS or BGP hijacking, or a lapsed and re-registered domain) can serve a feed under a previously trusted URL with a fully valid certificate. Well-known URI registration and certificate validation raise the bar but do not close this gap: a subscriber cannot today distinguish a genuine publisher from an attacker who has acquired control of the publisher’s URL.

Clients and subscribers MUST NOT treat the mere presence of a feed at an HTTPS URL as proof of publisher authenticity.

A future revision is expected to define an OPTIONAL content-authenticity mechanism: a detached signature over a canonical serialisation of the feed or item, verified against a publisher key, most likely building on HTTP Message Signatures [RFC9421]. To keep that path open without a breaking change, the member name signature is reserved at both feed and item level by this document; clients MUST ignore it where present (Section 6.15) until a future revision assigns it meaning, and publishers MUST NOT use signature for any other purpose.

13. Privacy Considerations

13.1 Information Disclosed During Polling

When a client polls a feed, the publisher observes:

• The client’s IP address
• The poll timestamp and frequency
• The User-Agent string (MMSP/1.0)
• Conditional GET headers (ETag, If-Modified-Since)

This information may allow publishers to infer subscription patterns. Clients SHOULD document this behaviour to subscribers.

13.2 IP Address Correlation

A subscriber who polls multiple feeds from the same IP address may be identified across unrelated publishers through IP correlation. Clients SHOULD support operation through a proxy or VPN for subscribers who require stronger privacy guarantees. This is an implementation concern, not a protocol requirement.

13.3 Subscription List Privacy

A subscriber’s subscription list constitutes a record of their interests. Clients SHOULD store subscription lists locally and MUST NOT transmit subscription lists to remote services without explicit subscriber consent.

14. IANA Considerations

14.1 Media Type Registration

This document registers the following media type:

• Type name: application
• Subtype name: mmsp+json
• Required parameters: none
• Optional parameters: version (version string, e.g., “1.0”)
• Encoding considerations: UTF-8
• Security considerations: See Section 12
• Published specification: This document
• Author: MMSP Community

14.2 Well-Known URI Registration

This document registers the following Well-Known URI per [RFC8615]:

• URI suffix: mmsp.json
• Change controller: IETF
• Specification document: This document

References

Normative References

• [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
• [RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017.
• [RFC8615] Nottingham, M., “Well-Known Uniform Resource Identifiers (URIs)”, RFC 8615, May 2019.
• [RFC9110] Fielding, R. et al., “HTTP Semantics”, RFC 9110, June 2022.

Informative References

• RSS 2.0 Specification, Harvard Berkman Center, 2003.
• Atom Syndication Format, RFC 4287, December 2005.
• JSON Feed Version 1.1, Brent Simmons and Manton Reece, 2020.
• [RFC9421] Backman, A., Richer, J., Sporny, M., “HTTP Message Signatures”, RFC 9421, February 2024.

Appendix A: Filter Grammar

Clients supporting subscription-level filtering SHOULD implement the following filter grammar. Filters are evaluated client-side against normalized item objects.

A.1 Grammar (ABNF)

filter       = expr
expr         = term *(SP bool-op SP term)
bool-op      = "AND" / "OR"
term         = ["NOT" SP] atom / "(" expr ")"
atom         = type-filter / tag-filter / author-filter /
               lang-filter / duration-filter / date-filter /
               keyword-filter / rating-filter
type-filter  = "type:" item-type
tag-filter   = "tag:" string-val
author-filter = "author:" string-val
lang-filter  = "lang:" language-code
duration-filter = "duration:" range-expr
date-filter  = "published:" date-range-expr
keyword-filter = "keyword:" string-val
rating-filter = "rating:" rating-val
range-expr   = ">=" number / "<=" number /
               "[" number "," number "]"
date-range-expr = ">=" iso8601 / "<=" iso8601 /
                  "[" iso8601 "," iso8601 "]"
string-val   = DQUOTE *(%x20-21 / %x23-7E) DQUOTE
item-type    = "video" / "audio" / "article" / "image" /
               "short" / "document" / "gallery" / "event" /
               "release" / "newsletter" / "course" / "livestream"
rating-val   = "general" / "teen" / "mature" / "explicit"
language-code = 2*8ALPHA *("-" 2*8(ALPHA / DIGIT))

A.2 Examples

type:video AND duration:>=300

Match video items 5 minutes or longer.

NOT tag:"sponsored" AND (type:article OR type:newsletter)

Match articles and newsletters without the “sponsored” tag.

keyword:"climate" AND lang:en AND published:>=2026-01-01T00:00:00Z

Match English items containing “climate” published in 2026 or later.

Appendix B: RSS 2.0 Field Mapping

Appendix C: Atom Field Mapping

Appendix D: Podcast Namespace Mapping