On Fri Dec 23 00:50:06 2011, Florian Zeitz wrote:
"inspired" by the recent PEP thread I read up on the PEP and PubSub
XEPs
again, and honestly I'm currently under the impression we need to
fix
them, badly.
We need to fix the specifications, yes. They're not simple, and
they're often confusing. In some cases, they don't match what's
deployed.
The first thing I have always found irritating is that filtered
notifications are not actually filters. Unless you specify interest
in a
node, you won't get notifications, right?
Well, while that is the realitiy of some PEP implementations it is
not
what the XEP says (as far as I can tell anyway).
Unless you perform filtering you are supposed to get all PEP events
once
you have subscription="to" or "both". And if you are not sending
someone
your presence, because you only have subscription="to" you're not
filtering.
Also deem this underspecified. Does announcing no "foo+notify"
feature
imply that you're not filtering, or does it imply that you're not
interested in any PEP notifications?
Agreed, implementations generally differ from the specification, in
as much as they assume that they always know about filtering. And the
very word "filtering" is indeed a misnomer, really. But actually, as
long as you forget about filtering - which comes from a legacy where
we expected to filter on payload namespace - and talk about
presence-based auto-subscribe, then it all works.
The problem comes with those cases where we want events but don't
share presence with the source - ie, "to" - because we don't want to
give away our presence state, yet we also don't want to get
everything.
The solution we have is to use manual subscriptions to fill this gap,
and I do think there are better solutions possible - but replacing
the whole of PEP is not one of them. The existing, deployed protocol
works perfectly well for the majority of cases.
The second thing I'm super uncomfortable with are the defaults
mandated
by PEP. PEP mandates defaults for PubSub configuration options. Just
that PubSub never specifies some of those options. The only
descriptions
of those options (e.g. deliver_notifications or access_model) are in
labels of form fields in the field standardization.
I personally don't deem those normative and would rather have some
normative text somewhere. Even if it's just a table with the same
content.
http://xmpp.org/extensions/xep-0060.html#accessmodels
... seems pretty good to me. I implemented the access models in our
PEP/PubSub based on that.
deliver_notifications is pretty sparse, I agree - we should ensure
there's some better specification on those - but it's worth noting
that the form field standardizations certainly should be normative
(but should be pointing to more discussion where needed).
What else were you missing?
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
