[standards-jig] Serious Issues with JEP 0024
theo at theoretic.com
Wed Jul 10 18:00:10 UTC 2002
First, the minor things of typos:
* Section 2, 2nd item of the list, "the distribution is tied to closely
to presence", s/to/too/.
* Example 12, in the IQ-Result, there are many > where there should
be <, resulting in messed up XML tag examples.
* Example 13 is missing an </x> tag.
I do not understand why the restriction of forcing only one type of
IQ-Set at a time. Why not allow both <subscribe>'s and <unsubscribe>'s
in the same IQ/Query packet? It would save some space, and the user
could likely be doing both at the same time anyway when they manage
their subscriptions (spring cleaning, of sorts).
Do all publishings need to be in an IQ packet? I am helping to design a
new conferencing protocol for Jabber, to replace GroupChat and pick up
where JCF left off. A generic pub/sub would be a great tool to use, but
only if it can send out <message> tags instead of <iq> tags containing
the published data. It doesn't make sense to have humans talking and
chatting through IQ packets.
Also, in addition to allowing subscribers to be published to only when
they are online by allowing the pubsub component to have their presence,
they could also have the same result by having published packets be set
to expire after a certain amount of time, using JEP 0023, and the end
clients could just ignore or better yet strip the expiration time from
all received packets. They would expire in the end user's server if they
were not online in time to get it.
At first I did not like the fact that the JEP assumes that subscribers
and publishers will know what pubsub component to use and what
namespaces can be subscribed to. But then I realized, as DJ wrote, that
that is better left up to a discovery mechanism that the pubsub
components and clients can make use of.
The same with authorization and permission to subscribe. JEP 0024 has
none of that, allowing anyone to subscribe to anything without
permission from the publisher. But then I realized that this too is best
left to a seperate mechanism. jabber:iq:permission, anyone? ;-)
But, a real problem I do have is that 0024 allows subscribers to
subscribe to *everything* from *everyone* on a component. This allows
spammers to seek subscriptions to everything on the popular pubsub
components, and look to see what publishers they have subscribed to.
Once they have done that, they can list those publishers on a "white
list" of addresses that most likely have a human behind them, and can
proceed to send spam. This is not helped by having an authorization
mechanism. When the spammer subscribes to everything, authorization
requests are sent to all the publishers. With the amount of spam in the
email world, publishers would be swamped with subscription requests
daily. The foolish ones that responded would be put on that same white
list and proceed to be spammed. Either 0024 needs to drop the "subscribe
to everything" option, or change it in some serious, fundamental way.
Also, I don't think I like the "anonymous subscriber" methodology. There
really does need to be a way for publishers to see who is subscribed to
them. At the very least you can allow subscribers to explicitly request
anonymous status and have them kept off the list, but others should be
seen. Besides, what is hoped to be accomplished by this? Keeping the
subscriber's privacy intact? Any publisher that has the intention of
farming for addresses will just set up their own pubsub component anyway
and get the addys from that. All this would do is frustrate small-time
publishers that want to make sure they know who is getting their info.
Finally, publishers need a way to remove and manage subscribers. I see
no way for publishers to "wipe the list clean" and remove all or even
certain subscribers. This should be allowed in case a publisher stops
publishing and wants to notify their subscribers.
Finally, however. I really like the proxy subscription system. It will
not only help create a "smarter" network when it comes to bandwidth, but
also help subscribers manage all their subscriptions in one place. This
could be a great step in helping me make sure I never loose track of
another mailing list or newsletter subscription again.
/\ Adam Theo, Age 22, Tallahassee FL USA
//\\ Email & Jabber: theo at theoretic.com
// \\ MSN: theo at theoretic.com YIM: adamtheo2
=//====\\= (Boycotting AOL, therefore no AIM or ICQ)
// || \\ Theoretic Solutions: http://www.theoretic.com
|| "Bringing Ideas Together"
|| Jabber Protocol: http://www.jabber.org
|| "The Coolest IM on the Planet"
|| "A Free-Market Socialist Patriotic American Buddhist"
More information about the Standards