wrt the codeberg headers and content-type, this was detailed extensively above and would be addressed by using a static deploy host that can correctly set CORS and Content-Type headers, i.e. not codeberg.
wrt low availability of codeberg, this would also be addressed by using a host other than codeberg.
these are not strictly part of the fep, though. the fep is about using https://w3id.org/fep as a prefix for fep resources. the fep going to FINAL does not imply that the .htaccess rules can never be changed.
a PURL service is not a link shortener. the point of using a PURL service is to allow for consistent references while also allowing the ultimate network location to change. in practical terms, this means that we can move off of codeberg and all PURLs will continue to work fine simply by updating the redirects. the bet being made is that w3id.org/fep will be longer-lived than codeberg.org/fediverse/fep.
the fep site can use w3id.org/fep as well, if desired. if it’s not hosted on codeberg, it can address the above issues as well.
wrt “official fep policy”, that is a different matter than individuals deciding to use these PURLs or not. the fep exists and the redirects have been set up already. anyone is free to use or not use them.
maybe? i would instead heavily advise people not to request application/json. but i’m not sure if there is any harm in allowing this. it would be like allowing application/xml instead of application/rdf+xml, or allowing text/plain instead of text/turtle. technically incorrect, but forgiving.
these links will likewise break if codeberg ever goes down, if codeberg ever discontinues codeberg.page, or if the fep project ever migrates away from codeberg.