[Standards] [XEP-0030] we can't get basic information on a bare JID without presence subscription

Ralph Meijer ralphm at ik.nu
Wed Jan 19 10:03:59 UTC 2022

On 19/01/2022 10.11, Georg Lukas wrote:
>> The problem is that I need to have presence subscription to do that on a bare JID (due to "https://xmpp.org/extensions/xep-0030.html#security"), even if the node I want to request (in the presence case, it's XEP-0277's microblog node) is open and thus publicly accessible.
>> I've made a pull request to update XEP-0030 at https://github.com/xsf/xeps/pull/1145[1] . My proposal is to remove entirely those considerations (but to keep ones regarding available resources).
> Thanks for providing the PR. I see the rationale and the need for a
> change, and I don't disagree with a backward-compatible change.
> However, in the specific PR you are completely removing the
> "algorithmic" description of what a server is supposed to do and which
> exact replies it has to send.
> Instead, I would very much welcome a PR that retains the overall
> structure that you removed, and instead improves the wording of the
> conditions to cover the additional use cases, like nodes with "open"
> access model.
>> An other option could be to keep the consideration, but allow disco#info when a node is specified, thus one could disco#info with node "urn:xmpp:microblog:0" even without pubsub subscription, that would keep the "service-unavailble" when no node is specified (but I think this measure will become totally useless as open nodes will become more common).
> If you prefer to go down this path, this would be a change to XEP-0277,
> where it can just override the default "MUST NOT" behavior of 0030
> without touching the text of 0030, but I really see a need to update
> 0030 to cover the "open" nodes.

I suppose the concept of open nodes implies that the entity (in this 
case a user's bare JID) can no longer be hidden. Then, to me the partial 
sentence “or is not otherwise trusted” applies. I.e. everyone is 
“otherwise trusted” now. A service may still choose to restrict what it 
returns in response to a disco#info request, based on the existence of a 
presence relationship. E.g. will respond with pubsub#rsm but not other 

Given the above, potentially no changes are needed, but clarifications 
might help.


More information about the Standards mailing list