Isn't rss used as a format for other extensions to consume joomla content eg mailchimp, acyba??

Remove what exactly? Joomla\CMS\Feed library? Newsfeeds extensions? Component feed views?

@SharkyKZ All of the above. Perhaps decouple them as Weblinks was so they can still be downloaded from JED

I'm not sure why it would be an argument for dropping RSS on the server side when some clients removed their support. They probably removed it because there are better RSS readers out there (don't know - never used RSS myself except for Podcasts).
Imho, there is no reason to remove RSS support as it is something that is done very easily.

edit: I'm speaking about the component views. I don't mind about the RSS reading extensions.

RSS stands for the open web and is part of every blog software. Removing the support for it doesn't add any value to Joomla, at least you haven't described any.

@SharkyKZ All of the above. Perhaps decouple them as Weblinks was so they can still be downloaded from JED

yeah that works really well, plz check weblinks repo there is a discussion to drop it or merge it back into core. Because there is no/less interested in most of the repo beside the main repo.

Please keep in mind that RSS is widely used to post automatically to Social networks through third-party systems

Everyone here is arguing for keeping RSS support but nobody wants to put in the effort to make RSS a first class citizen of core (#13647 and #14176 as examples). Either RSS needs to be supported as well as HTML or it should not be a core feature because the current implementation just sucks.

because the current implementation just sucks.

Can it be improved? Sure. Does it suck? Certainly not.
Is there interest in improving it? Apparently not enough. But that doesn't mean it has to be removed.

Most of the issues with RSS aren't really tied to RSS anyway. It's the various plugins which silently assume a HTML document type and try to load JS or whatever into the document. Removing RSS doesn't solve this.

Most of the issues with RSS aren't really tied to RSS anyway. It's the various plugins which silently assume a HTML document type and try to load JS or whatever into the document. Removing RSS doesn't solve this.

That's exactly why it sucks. Part of Joomla's selling point is its extensibility and the ability for users and developers to interact with data throughout the request cycle. Show me one non-HTML request where plugins can hook the view outside the application's system events. Compare that to the number of controllers that early abort the request cycle because it's easier to call $app->close() than it is to get plugins to behave correctly. Do a test and figure out how many of the core plugins are broken if you try to emit the usual events in JSON or RSS context (e-mail cloaking unless you prepend {emailcloak=off} to the text object before emitting the event, the load module plugin, the page break plugin, the page navigation plugin, the voting plugin; that's just inside the content group). These are real roadblocks to improving the system, and if anyone without the name @wilsonge is serious about having webservices support in core then these roadblocks either need to be addressed or Joomla needs to be "dumbed down" to HTML only because that is essentially all the project gives full support to (or, let me paraphrase something @brianteeman is always telling me, "Joomla is something you run in a web browser" and it very clearly shows because how much attention do concerns that have nothing to do with the core templates actually get on this tracker?).

I know that. Because I maintain an extension which serves also podcasts and another one which does XLS output. So I know firsthand where you come from.
I just don't think dropping support is the answer.

I'd rather it not be dropped either, but being realistic here, if core were to actually take the time to make plugin integrations in non-HTML views work correctly for just the core stack, it would still wreak just enough havoc on the ecosystem that the move to whatever version that were introduced in would be almost as painful as the 1.5 to 2.5 migration. I would safely bet that 85% of plugins out there would break something in a JSON or feed view format if the existing suite of events were used, and if it were decided to implement a new suite of events and deprecate the existing that would add a lot of maintenance burden over the 4.x lifetime. And that's in part why I just closed out my issues pointing out this lack of support, even though I know core needs to be improved, the current state of affairs doesn't offer much as far as sane solutions that don't involve just giving up.

There are a lot of use cases for RSS. I use it to bring feeds into Intranets for example. Although the death of readers is true, the use of RSS for other things, as Luca said, posting to social networks is still high.

There can be a lot of case... but I want to remove RSS feed from my J 4.x website anyway

Why?

why what ?

Why not something in-between? An option to disable feeds at the category level or globally? Those who don't want them can shut them off.

Disabling feed makes sense. other question wouldn't the feed fit better to the webservices?

What is the gain in disabling feed views?
I don't see a reason to add yet another option to disable something that doesn't hurt anyone.

what is the gain to have feed on 90% of the websites ?

What is adding an option to effectively force something that has no frontend routing and you have to explicitly expose through other options actually do to benefit users? Or, what is so bad about RSS resource use that those who might discover your sites have RSS support need to be chased away from adding your site's RSS feed to their list?

The only reason I could give to disable the feed view is to protect a portion of the site from syndication.

One of my customers has a problem with their competitors plagiarizing their content. Rather than keep up with rapid changes in their industry - their competitors find it easier to copy the work of others, RSS makes that easy to do. I prevent it with a system plugin now. It doesn't prevent the plagiarism, it just slows it down.

function onAfterRoute() {
   if(JFactory::getDocument()->getType() === 'feed') die('forbidden');
}

It would be nice to be able to turn it off for specific areas. That's the only use case I can come up with, and I've already solved it for my customer.

I'd say if you can already solve it with a simple plugin for the whole site, then that issue can be closed.
I seriously see no reason in doing that in core.

it should definitively be an option , I even wonder if it is legal in Europe to allow feed directly without the possibility to forbid it

Of course it is legal in Europe, why should it be illegal?
You publish something in the internet with the intention it's read by someone. It doesn't make a difference if it's read by a RSS reader or a browser.
Btw: One can also easily scrape HTML documents automatically. Ask Google. You don't need RSS at all to steal content from another company.

And after all, you have already the possibility to disable it with a plugin or .htaccess rule. It's not that hard if you really think it's worth the effort. It certainly doesn't need another option.

I dont want to install a plugin, or disable it, I want the possibility to enable it if I want, or install a plugin to enable it

Still don't see a single reason to implement this, sorry.

And no, "outsourcing" the RSS functionality to a plugin would be even more wrong than adding an option (which is wrong as well).

@ymages there will always be a Gap between "i want that in Core cause ..." and "there are other Solutions, its not for Core".

I don't think we're going to remove RSS support. Clearly we're going to have to do quite a bit of work on fields to make it work in more cases than just HTML - as it's going to be required for web services work as well.