my recent search for how to do Atom Feed Autodiscovery only returned rather outdated material when i tried to come up with recommendations for that particular part of how to design some of the Stimulus Feeds Details.
as it turns out, while the IETF drafts i found were in fact outdated, it is not the only option to wait for what HTML5 will come up with, and to hope that they will get it right. in a separate effort, IANA registry for link relations.
one interesting technical question of such a registry and the values in it is what these values are, and how these values are supposed or allowed to appear in syntaxes (such as HTTP headers or HTML attribute values). possible choices here are local names, namespace names, URIs, or CURIEs. local names and namespace names are just names, URIs and CURIEs are URIs. local names are nice and short, but there is a high risk of conflict. namespace names look nice and short, but only make sense in environments with a well-defined framework for defining namespace prefixes; and they a brittle because they depend on context. the same things can be said about CURIEs; they, too, need a framework and they are brittle. URIs are nice because conflicts are unlikely and they are self-contained, but they are not as easy to read as the other types of names. and it seems like various specifications are already doing different things when it comes to defining link relations, which makes it even harder to come up with general framework.
the current list of initial link relations listed in the draft seems to be based on HTML4, Atom, Atom extensions, and AtomPub, and thus does not include HTML5's proposed
link relation. however, this draft will probably evolve, and i have thus added it to the Atom Landscape Overview because it definitely is a relevant activity in that space.