[jdev] The future of Jabber/XMPP?
xramtsov at gmail.com
Fri Aug 27 07:18:15 CDT 2010
27.08.2010 21:02, Dave Cridland wrote:
> On Fri Aug 27 11:23:09 2010, Evgeniy Khramtsov wrote:
>> If you have caps and valid disco#info then there will not be such
>> problem. So it works in practice.
> You're misunderstanding me.
> If a client sends an explicit subscription to a node on a pubsub
> service held on a foreign domain whose jid happens to be a bare jid,
> then notifications will be filtered by the client's local server,
> effectively breaking the subscription.
Indeed, and I still don't understand what you are talking about.
>> Yes, but http://xmpp.org/extensions/xep-0163.html#notify-addressing
>> para 4 says:
>> "... if the PEP service does not have presence information about a
>> subscriber, it MUST address the notification to the subscriber's bare
>> JID (<localpart at domain.tld> or <domain.tld>)."
> But you *do* have presence information - or at the very least the only
> reason you don't is because you've thrown it away. I don't see how
> this can be described as conformant behaviour.
No I *don't*. ejabberd doesn't store any remote presences/resources.
Thus, ejabberd doesn't violate the XEP.
>>> So because you filter on the subscriber's end, you restrict
>>> PubSub-onna-jid to the PEP subset, and because you don't filter on
>>> the service end, you break even that if the subscriber isn't on
>> Well, strictly speaking yes. However such situation is uncommon it
>> practice: all popular clients provide caps and disco#info.
> What, it's uncommon for subscribers not to be on ejabberd?
Very funny :)
> I reiterate - the only case your protocol works like PEP is when the
> remote subscriber is on ejabberd too.
Yes. That's why I suggested to add those two statements in the XEP.
This discussion is boring me. I've suggested a XEP fix which is even not
mandatory to implement. If you disagree, you can ignore it.
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.
More information about the JDev