[Standards] Disco conflict between 30 and 163

Dave Cridland dave at cridland.net
Tue Aug 26 18:42:24 UTC 2014

On 26 Aug 2014 16:42, "Kurt Zeilenga" <kurt.zeilenga at isode.com> wrote:
> On Aug 26, 2014, at 7:55 AM, Simon McVittie <
simon.mcvittie at collabora.co.uk> wrote:
> > On 26/08/14 15:10, Kevin Smith wrote:
> >> 30 says not to reply with disco to entities not authorised for your
> >
> > Should the server follow this pseudocode for a disco instead?
> >
> >    if target JID is bare:
> >        # any IQ to user at host is expected to be replied to by the server
> >        reply to it on the user's behalf, describing features of the
> >        server and the account (but nothing about the logged-in
> >        resources on that account, if any)
> JID existence leak.

Certainly is. But if we're to block all possible jid existence leaks,
everything breaks anyway.

Consider: If I send made.up.name at isode.com a subscription request, it will
behave differently to sending one to kurt.zeilenga at isode.com (here I'm
assuming your email address is the same as your jid of course).

Sending you a message versus sending a non-existent jid a message will also
typically behave differently.

These are, in general, desirable effects from a UX standpoint. The downside
is that one can use them to harvest real jids for abuse and other nefarious
purposes. However, it's not specific to Disco, and we should be careful of
being distinctly uneven in our protection here.

As such, my gut feeling is that this one case of jid existence leaking
isn't worth worrying ourselves over.

> >
> >    else if peer is authorized to see user's presence:
> >        # any IQ to user at host/resource is expected to be replied to
> >        # by that resource
> >        forward message to the named resource so it can respond
> >
> >    else:
> >        <service-unavailable/>
> >
> > Regards,
> >    S
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140826/ed72b294/attachment.html>

More information about the Standards mailing list