[standards-jig] Serious Issues with JEP 0024

DJ Adams dj.adams at pobox.com
Wed Jul 10 19:07:09 UTC 2002


On Wed, Jul 10, 2002 at 02:00:10PM -0400, Adam Theo wrote:
> 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.

Adam, as I mentioned to you this morning, I've already got a draft of 
fixes that take care of these things. I can't understand why you bring
this up here, especially under the (somewhat alarmist) "serious issues"
title of your mail.

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

KISS. There also may be some problems that arise due to false inference
on the part of the client (implementation) or the server (implementation)
as to how (in what order, collectively, etc) the individual subscribe and
unsubscribe tags are processed.

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

Nor does it make sense to assume that the only traffic that can be carried
in IQ payloads is non-human talk data. While the point is debatable (and 
has been debated more than once) it becomes moot eventually. IMHO the IQ
model aligns itself with pubsub more than the message model does. 

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

Packet TTL and presence-based sending are two totally different things.

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

Yup :-)

> 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?  ;-)

It's worth pointing out too that some (not necessarily all) of the concerns
regarding authorization could be addressed by having pubsub components for
specific areas of publishing, and auth-proxying those components in conjunction
with advertising. (Auth-proxying in the sense shown in
Jabber::Component::Proxy).

> But, a real problem I do have is that 0024 allows subscribers to 
> subscribe to *everything* from *everyone* on a component. This allows 
> [...]
> list and proceed to be spammed. Either 0024 needs to drop the "subscribe 
> to everything" option, or change it in some serious, fundamental way.

Alternatively, you could re-read the JEP, especially near example 7:

  "Subscribing to everything from everyone is probably not a good idea
   and we should not allow this."

> Also, I don't think I like the "anonymous subscriber" methodology. There 

There isn't really a methodology - the anonymity is de facto, not
intentional. This is why I was asking questions in that section, rather
than stating a definition.

> 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 

As I mentioned, it's not intentional, just as a result of trying to keep
things to an absolute minimum. 

> 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 

How will that work? Presumably the spamming publishers will have something
juicy to tempt people to subscribe to? 

> 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 

In some ways I see this as a parallel to the argument people have against
'deep' linking. If you're going to publish something, publish it. If you
want to be selective, use a pubsub mechanism with authentication in front
of it. 

> publishing and wants to notify their subscribers.

Regarding notifying subscribers that they're not publishing anymore - hmm,
I've seen this suggested elsewhere (outside of the Jabber pubsub discussions)
and I'm not sure what I think... Hmmm. 

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

Well, this was temas's excellent idea. Nice one temas. 

Anyway, thanks for the comments. Even though the JEP was published over 
4 months ago, all input is gratefully received.

:-)
dj



More information about the Standards mailing list