If you want ordering, the semantics will need to be carefully defined in the FEP (to be useful). Otherwise, one developer might use the ordering for preferences and another to represent some semantics we haven’t anticipated.
It would be odd to have a set of capabilities where two of them (somewhere in the list) are a preference ordering and the rest aren’t. I can think of ways to represent the preference ordering for specific capabilities that need it, but I’ll wait to see your ordering proposal.
I think @id is ok. It’s the @list that may not be correct (unless you really want ordering).
They can, if the server implementation allows it. But I understand that part of the serialized actor data is intended to be server-wide information and not actor-specific. Another case where available server capabilities might be actor-specific is when the different actors are acting in different roles (user, moderator, admin, etc.). I wouldn’t want to hard-code role-dependent capability sets in a C2S client when that client is designed to work with any C2S-capable server.
Just for clarification, if a server implementation supports nodeinfo, for example, but it’s been disabled by a server admin, are you expecting a nodeinfo entry to be in the implements list or not? The meaning of the word implements implies it would be in the list although it’s not an available “capability” because of server configuration,.
Yes, I saw that. I’m not a fan of the MUST NOT. I would probably ignore that if I use the FEP. Inferencing is fine, but it’s too ill-defined and error-prone. If there were an FEP that describes specific valid inferences, I might have different opinion. I’ve seen inferencing-related discussions where too much was inferred/assumed from the presence or absence of specific properties, etc. As a developer, I prefer that I don’t have to write inferencing code to fill the gaps in the capabilities list (that would also require code to process).
That said, I’m not sure if “implementers” refer to implementers of the capability list or implementers of servers consuming the list. But either way, I’m not convinced this should be a MUST NOT.