Unnecessarily complicated

[kevinmarks]

If you want a lightweight way to do this, serve the rel="alternate" links in the head, and respond to HTTP HEAD including them.
That's backwards compatible with the existing method and doesn't place the burden of checking your new magic place on user agents.

[Dan-Q]

If you're going down that route, you can put them in Link: headers and you get HEAD support for free, as well as support for non-HTML resources.

But the problem is that in either case rel="alternate" should only provide an alternative to the resource being requested. But a domain might host multiple RSS feeds, not all of which are associated with a particular URL. For example:

• A blog might have RSS feeds for posts, comments, posts with a particular tag, posts with a particular category, etc. This is the case for a WordPress-based blog, for example, but the default behaviour is for the rel="alternate" link to only indicate the "main" one.
• A news site might have RSS feeds for different topics or authors. This is the case for BBC News, for example, but they have to use a separate page to list all of the feeds.
• A community might have an arbitrary number of feeds which are not otherwise related to one another nor directly to the main site. DreamWidth for example has numerous communities each consisting of one or more feeds: a cascade of (dynamically-generated, one would assume) OPML outputs would allow feeds to be identified and subscribed-to on a category-by-category basis, rather than finding each one individually.

In all of the above cases, one could use either a <link> element or Link: header, but it certainly wouldn't be lightweight to include them all, and it might well not be semantically correct (is the feed of "sports news" really an alternate version of the BBC News homepage, like the feed of "all news" is?).

.well-known/feeds proposes a mechanism by which a site (at a domain level) can list some or all of the feeds that the domain controller thinks are relevant and representative of the site, without associating every feed with every page (or even, simply, with the homepage).

---

I think that we agree that it might be unnecessary to have another mechanism to find feeds on a site. But I don't think the level of complexity (it's relatively uncomplicated, especially compared to other .well-known/ standards like e.g. Webfinger) is a significant problem.

(All IMHO, obviously. I genuinely love that somebody's disgreeing with me!)