[jdev] The future of Jabber/XMPP?

[Evgeniy Khramtsov]

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

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.