[standards-jig] Serious Issues with JEP 0024

Adam Theo 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 mailing list