Suggest alternate media type.

[timbray]

Why shouldn't this thing have its own media type? If you're sticking it in your HTML header with

<link rel='alternate' type='application/json'

Then it's going to make it harder to discover the feed, because you might have multiple alternate JSON representations, things like Rails make it super easy to get either HTML or JSON from the same endpoint.

I look in my current blog header and see

<link rel='alternate' type='application/atom+xml'

So by analogy, I think application/feed+json would be better. It makes it dead easy for Feedly or whatever to figure out what to do, given the URL of my blog. If you want to do this, I'll even volunteer to register the media type, it's not rocket science.

[dret]

https://tools.ietf.org/html/rfc6839#section-3.1 encourages you to use +json as a suffix of a more expressive media type than just application/json.

[dret]

this seems to be related to #84.

[aaronpk]

any reason this hasn't been merged yet or discussed more? I just got tripped up on this building a reader.

[martymcguire]

To give some examples of collisions, these WordPress-based sites have rel="alternate" type="application/json+oembed" which can get matched when checking for application/json:

• http://bearmageddon.com/
• http://www.justinkownacki.com/

Example:

<link rel="alternate" type="text/xml+oembed" href="http://www.justinkownacki.com/wp-json/oembed/1.0/embed?url=http%3A%2F%2Fwww.justinkownacki.com%2F&#038;format=xml" />

[Serkan-devel]

Could this thing be a w3c standard?

[dissolve]

Its possible, but its a rigorous process to go through getting something to be a w3c recommendation, and I don't know what working group is currently open that would be interested in taking this on now that the social web working group has closed.

[timbray]

It's dead simple to register a media type via the IETF, assuming Brent wants to adopt the idea.

…

On Tue, May 1, 2018, 5:20 PM Ben Roberts, ***@***.***> wrote: Its possible, but its a rigorous process to go through getting something to be a w3c recommendation, and I don't know what working group is currently open that would be interested in taking this on now that the social web working group has closed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABEk1wcyqVIevZxBOtudMy2t3QkhzPWks5tuPvcgaJpZM4NfzEU> .

[dret]

just to be clear: deciding on defining/registering a media type, and deciding on possible standardization groups for JSONFeed are two different and independent things. the former is much easier than the latter. like @timbray, i also volunteer to add the necessary text to the spec, if that's what's wanted. i think it would be a good idea to have a media type for people to label things in a unique and well-defined way.

[aaronpk]

This is causing problems for me again.

I had someone ask why my reader thought there was a json feed at a Twitter URL. It turns out Twitter still advertises an oembed link with alternate rel=application/json, so my software has no way to know that's not actually a JSONFeed.

We really need something unique to JSONFeed so this doesn't happen.

[dshanske]

Could we register it on behalf of the spec?

[manton]

It sounds like there was consensus around using application/feed+json. Makes sense to me to move toward that. I think clients will need to support application/json for the foreseeable future, though. I would also like to test what happens with popular readers like Feedbin when they encounter application/feed+json today.

[dshanske]

Why not start contacting them?

[da2x]

Any progress on this? The spec needs to define a content type for there to be any progress on clients and deployments.

[jpawlowski]

Good to see this was already discussed, otherwise I was about to open a new issue to suggest using the very same application/feed+json definition ;-)

I'm actually giving the advice already for people using my Hugo Web Feeds theme.

Sending application/feed+json is simply the most logical thing to do.

[skyzyx]

@brentsimmons @manton: Can we please get some leadership here? This ticket has been open for more than 2 years.

[manton]

I'm still good with updating the spec to reflect this. I think we need to add something to mention that clients should still look for application/json if feed+json isn't there.

[dshanske]

Did we register the type?

[da2x]

To clarify, would "application/feed+json" also be the "Content-Type" HTTP header value for the feed itself?

Yes. That’s what the Content-Type response header communicates. Feed readers use the Accept header to communicate their media type preferences to servers. E.g.:
Accept: application/feed+json, application/atom+xml, application/rss+xml, application/xml, text/xml, text/*

However, clients should support less specific content types. for compatibility E.g. going from more specific to less specific:
application/feed+json, application/json, application/*, text/plain, text/*

Atom and RSS feeds have similar media type specificity requirements, e.g.:
application/atom+xml, application/xml, text/xml, application/*, text/plain, text/*

However, the most specific media type should always be used for the feed auto-discovery mechanism. E.g. <link type="application/feed+json" …><link type="application/atom+xml" …>.

It’s how clients can tell the difference between these three files:

<link href="manifest.webmanifest" rel="manifest" type="application/manifest+json">
<link href="feed.json" rel="alternate feed" type="application/feed+json">
<link href="oembed.json" rel="alternate" type="application/json+oembed">

[manton]

I'm finally following up on this. Thanks @timbray for starting this, and everyone for your thoughts. Here's what I have for the application to register application/feed+json, which is used in JSON Feed version 1.1. If anyone has any changes or other tips before I submit it at https://www.iana.org/form/media-types, let me know.

Type Name: application
Subtype Name: feed+json
Required Parameters: None
Optional Parameters: None
Encoding Considerations: binary, Feeds use the UTF-8 encoding.
Security Considerations: Feeds may include HTML, so clients displaying that HTML may need to sanitize the content before displaying it or executing JavaScript in that HTML. Feeds are JSON and include URLs, so other security considerations apply from RFC 8259 and RFC 3986.
Interoperability Considerations: Using a subtype helps differentiate JSON Feed from other JSON formats when clients discover feeds and API endpoints in HTML link tags.
Published specification: https://jsonfeed.org/version/1.1
Application Usage: Feed readers, blog servers, and podcast clients. JSON Feed is used in apps such as NetNewsWire, Feedbin, NewsBlur, and Micro.blog, as well as open source libraries.
Fragment Identifier Considerations:
Restrictions on Usage:
Provisional Registrations:
Additional Information - File extension: .json
Intended Usage: Common
Other Information:

[manton]

This registration is currently stalled because IANA would like it to be submitted on behalf of a recognized standards organization or with an independent-stream RFC. We are exploring both those options, but I'm happy to hear other suggestions for how to move forward.

[bcomnes]

This is done in 1.1. Can be closed.

[Dreamsorcerer]

After 4 years, the type has still not been registered, and even jsonfeed.org itself doesn't use it?

[manton]

We should update the feeds, thanks. Unfortunately the registration of the type is still stalled. Not much has happened since my comment above a few years ago. I'd love to dust this off and make sure it's formalized.