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

Goffi goffi at goffi.org
Wed Jan 19 11:25:30 UTC 2022


Hi,

Thanks for all you feedbacks.

Daniel:

> Or in other words. Without presence subscription you get only the
> <identity category='pubsub' type='pep'/> (and related features) and
> with presence subscription you also get <identity category='account'
> type='registered'/> and features related to the account.

In this case you can still find that the account exists. As long as there are "open" nodes, it's probably not a problem though.


> With my council hat on I'll probably vote against this PR today. But
> I'd be open to a change to the PEP XEP that partially overwrites the
> security considerations in XEP30 with words like "if open nodes exists
> the PEP service MAY respond to disco#info requests even if there is no
> presence subscription)

 It's not a problem to veto this PR in current state, it was created mainly to start discussion, and I understand the reluctance to drop entirely this section.


Georg:

> > 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.

XEP-0277 is just an example, it should be done for any "open" node, thus I think XEP-0030 must be modified or at least clarified (or maybe it could go to XEP-0163).

By checking XEP-0163, I've seen https://xmpp.org/extensions/xep-0163.html#support-contact:

>A contact MAY send service discovery requests to the account owner's bare JID (<localpart at domain.tld> or <domain.tld>). If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in XEP-0060.

If I'm not mistaken, that means that a user without presence subscription must be able to do a disco request to the bare jid, thus contradicting XEP-0030 in current state, right?


I propose following changes:

1) rewrite the https://github.com/xsf/xeps/pull/1145 PR to restore the section and change the wording to display infos only if there is at least one "open" node. Implementation is free to choose which #infos are relevant if the requesting user has not presence subscription. If there is no "open" node and user has not presence subscription, a " <service-unavailable/>" error MUST be returned.

2) create a new PR to update XEP-0163 to indicate that a disco#info request with an "open" PEP node used as disco node MUST return the whole data whatever is the presence subscription status of the requesting entity.


1) is a bit complicating implementations (you have to check  if at least one node is open, and disco result can't really be cached by client as it may change according to your presence subscription), but we can deal with that.
2) is good enough for my uses cases, as I know the node that I want to check, and RSM or other relevant features will be advertised on the PEP node disco#info too.

If it's fine, I'll go this way and modify the PR and propose one for XEP-0163 later this week.

Cheers
Goffi




More information about the Standards mailing list