]>

Melbourne Australia mnot@mnot.net https://mnot.net/

Internet-Draft This specification defines Feed Menus, a simplified means of discovering the feeds (e.g., RSS or Atom) offered by a Web site. About This Document Status information for this document may be found at . information can be found at . Source for this draft and an issue tracker can be found at .

Introduction Automatic discovery of Web feeds (in formats such as RSS and Atom ) using link relations in HTML is widely supported both by consuming software (e.g., feed readers) and Web sites (including in many content management systems). Deployment of autodiscovery has uncovered significant issues with this approach. Because feed links are specific to a page, they are only apparent to software that can take advantage of them (for example, to show a 'subscribe' button) when that page is being viewed. This means that sites need to repeat the relevant feeds in the headmatter of all pages on a site to assure that they are viewable, creating overhead both in effort (to organise the pages) and bandwidth (to serve them). Practically, this means that it is often necessary to hunt around the pages of a site to find all of the relevant feeds, since sites are unwilling to repeat them on every page. Furthermore, because many content management systems automatically create this metadata, in practice many feeds that are advertised using autodiscovery are not actually functional -- site owners do not realise that the feeds are being advertised and do not check the feeds for quality and relevance. Finally, there are no existant best practices for naming or assigning metadata to feeds (for example, their format), leading to confusing user experiences. For example, because many sites make both RSS and Atom feeds available, there are often duplicate entries in the autodiscovery metadata. This specification documents a different mechanism for discovering the feeds relevant to a Web site. By defining a single, well-known location that describes a site's feeds, it encourages a more curated, usable directory of the site's feeds for easy discovery and consumption by clients. describes this format; recommends practices for publishers that wish to use it, and provides guidance to clients for processing it.

Notational Conventions 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 when, and only when, they appear in all capitals, as shown here.

Feed Menu Documents A feed menu document is a JSON format whose root is an menu object (). For example, a minimal feed menu document:

Menu Objects A menu object is a JSON object with a "feed-menu" member. Its potential members are:

• "feed-menu": A short human readable title for the menu (REQUIRED)
• "items": An array of menu objects and feed items.
• "lang": The natural language of the intended audience of the menu, expressed as a Language-Tag The natural language of the intended audience of the feed item, expressed as a Language-Tag

Menu objects MAY contain other members, to be defined by updates to this specification. Likewise, the items array MAY contain other types of objects, to be defined by updates to this specification. Menu objects can contain other menu objects to represent a nested structure. For example:

Feed Items A feed item is a JSON object with a "feed-title" member. Its potential members are:

• "feed-title": A short human readable title for the feed item (REQUIRED)
• "description": A potentially longer human readable description of the feed item's purpose or content; can further explain or augment the title (OPTIONAL)
• "rss": A URL to retrieve a RSS representation of the feed item (see below)
• "atom": A URL to retrieve an Atom representation of the feed item (see below)
• "lang": The natural language of the intended audience of the feed item, expressed as a Language-Tag

One of "rss" or "atom" is REQUIRED; both MAY be present. URLs in "rss" and "atom" values MAY be relative, and MUST be resolved relative to the feed document's URL without a path. For example, if a feed document is located at "https://example.net/.well-known/feed-menu.json" and the "rss" member contains "feed.xml", the resulting RSS feed URL would be "https://example.net/feed.xml". Feed items MAY contain other members, to be defined by updates to this specification. For example, a feed menu document with a more elaborate feed item:

Publishing Feed Menus Feed menu documents are published at the "feed-menu.json" well-known URI for a given Web site. For example: If the Web site supports multiple languages, its publisher can:

1. Use HTTP proactive negotiation to server different feed menu documents to clients depending upon the Accept-Language request header field, and/or
2. Publish a feed menu document with menu objects and/or feed items that declare their language.

For example, the latter might look like: It is RECOMMENDED that feed-titles be no longer than 50 characters, and that descriptions be no longer than 140 characters. However, processors SHOULD NOT strictly enforce these limits, although they may take measures to deal with long values. Publishing software (for example, content management systems) SHOULD NOT automatically create feed menu documents, unless they have a high degree of certainty that the publisher is aware and that doing so is intentional.

Processing Feed Menus Processors MUST only request feed menu documents from the "feed-menu.json" well-known URI. When requesting feed menu documents, processors SHOULD negotiate for content language using proactive negotiation; see . If the languages understood by the user is known to the processor, it SHOULD suppress any menu objects and feed items that declare a "lang" member that does not match. Processors SHOULD follow redirects when requesting feed menu documents, subject to limits on loop, abuse, and similar error handling. Processors MUST ignore unrecognised members of menu and feed items. Likewise, they MUST ignore unrecognised objects in the menu object's items array. Processors SHOULD make menu object items available to users in the order they appear in the array. For example, a visual interface might make them available as a list. In some cases, however, they may be made available in another ordering (for example, a search interface). Processors SHOULD NOT display feed items that do not have a link that they are able to follow -- for example, those using unsupported URI schemes. In some cases, this may be difficult for implementations to conform to; for example, if feed links are dispatched to separate software.

IANA Considerations IANA should register the following Well-Known URI:

• URI Suffix: feed-menu.json
• Change Controller: IETF
• Specification document(s): [this document]

Security Considerations A malicious actor who gains write access to the well-known location can effectively hijack the subscription list for an entire site's audience. Clients that automatically fetch the feed menu document leak the fact that the user is interested in subscribing to feeds. In some views this might be a feature; it creates evidence that providing feeds would be beneficial to a publisher's audience. However, it is also a privacy risk.

References Normative References This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Informative References WHATWG

JSON Schema

Implementation Status A Web browser extension for presenting feed menus is available for Safari, Firefox, and Chrome here: https://github.com/mnot/feedmenu-extension The following Web site(s) have a demonstration feed menu:

• https://mnot.net/

(other implementations can be listed as the appear; please contact me)