On Fri Aug 27 11:23:09 2010, Evgeniy Khramtsov wrote:
27.08.2010 19:54, Dave Cridland wrote:
So you're snooping all messages even from remote sources to guess
if they're PEP events intended to be filtered? How would you know?
If I (or my client) explicitly subscribes to a particular node on
PEP/PubSub-onna-jid service, you'd filter it out anyway.
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.
I'm struggling to understand how that does not violate the XEP?
auto-subscribe is defined as a depth=all items subscription to the
root node from the bare_jid, and filtered-notifications then only
sends the notifications to those full jids that have requested
them. Both are required for PEP. I don't see how you can claim to
be conformant to PEP without doing both.
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 (<localp...@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.
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?
If a subscriber is on a remote server that's implementing standard
PEP (or indeed no PEP at all), then you're breaking, caps and
disco#info or not. I reiterate - the only case your protocol works
like PEP is when the remote subscriber is on ejabberd too.
Or do you mean that it's uncommon for PEP services to speak more than
just the PEP subset? This I'll agree with, but we should not design
to preclude that.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
_______________________________________________
