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

Jonas Schäfer jonas at wielicki.name
Wed Jan 19 16:08:19 UTC 2022


On Mittwoch, 19. Januar 2022 12:20:56 CET Florian Schmaus wrote:
> On 19/01/2022 11.17, Daniel Gultsch wrote> 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.
> 
> 
> Returning different results to disco#info (and disco#items) depending on 
> who queries seems like something that has the potential to great damage. 
> I also think that this is nothing we currently endorse, specify or see 
> in the wild.

This already exists, I think. Prosody does only offer some Ad-Hoc commands to 
admins (and those are disco#items), albeit not on the default node. 
disco#items on MUCs also is different depending on whether you are joined or 
not.

> I always think if a disco#info response as a description of the 
> (software) features a given entity supports. And this is typically very 
> static (it mostly changes due software updates or changes). Whether or 
> not the requesting entity has access to these features is a different 
> question, and hence asked via different mechanisms.
> 
> We should carefully consider if adding more dynamic to disco# responses 
> is something we really want or need.
> 
> Reading the mails from Georg, Ralph, and you, it appears we could avoid 
> in this case by adding a simple clarification ala "if the account's 
> existence is already leaked, then returning the full disco# response is 
> fine".

I agree with what Ralph and Georg said -- it should go into '222 (or '277?) as 
a note overriding or clarifying the exception in '30.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220119/90db0a01/attachment.sig>


More information about the Standards mailing list