I've just learned about paged feeds: an RFC proposal for linking separate feed URIs together via <link rel=prev, <link rel=next etc. to specify an ordering.

The purpose is to support pagination of feeds: have (say) 5 entries in your most recent URI, and then the next 5 (or so) in another file/URI, (etc etc) that a compliant reader could fetch if required (or not, if not desired).

This might improve bandwidth for full-text entry/large entry feeds. It also might help with flooding aggregators, assuming the aggregators didn't blindly follow the links.

I've no idea what client support is like. Does this sound interesting to anyone? — Jon, 2024-09-23

Really interesting! Sounds like something we should implement, IMHO, if only as a way to pull "all the articles from this blog" kind of thing in a mechanical way. No idea what client support is either, as a RSS feed reader author myself, I had no idea this existed in the first place, yet this has been around for almost 20 years at this point, fascinating! (But then again, I've never really done much work trying to support that stuff and assumed the feedresader python module would do everything for me... Unfortunately, it doesn't, particularly with poorly formatted feeds, of course. See also RSS Podcast Feed Inefficiency. --anarcat