[standards-jig] Serious Issues with JEP 0024
dj.adams at pobox.com
Thu Jul 18 19:18:27 UTC 2002
On Wed, Jul 10, 2002 at 10:27:52PM -0400, Adam Theo wrote:
> Well, I can accept this, although your JEP does cover order of
> processing after Example 11: "In the case where multiple <subscribe/>s
> or <unsubscribe/>s appear in an action, each element will be processed
> in turn, as they appear in the payload.". Unless this means that the
> order in which they come in may not be the same order as they are sent
> by the subscriber due to mid-transport jumbling?
Well, I guess it's down to belt-n-braces, that's all. It's not a big point,
and if we could dictate the processing order then there shouldn't be any
problems (famous last words). I just prefer simplicity over complexity[*].
We could strengthen the wording around the implementation requirement, and
perhaps relax the restriction. I'm ambivalent, if push comes to shove.
> Well, this issue I'm still pretty concerned about. I don't think the
> issue becomes moot eventually simply because there is existing
> infrastructure that makes heavy, and proper, use of the <message>
> packets. Without support for <message>, you cannot publish email-like
> I'm not asking to support <message> instead of <iq>, but support *both*.
> Possibly by by specifying what type of element (iq or message) to use as
> well as type of message/iq (normal, chat, headline...).
Well, as it happens, I am already experimenting with this - see
http://www.pipetree.com/qmacro/2002/Jul/3#weblogspubsub for details.
But while I agree that supporting both is a possibility (and forgoing
IQs because "it's too complex"/"no existing client supports it" is a
difficult one to debate :-), the problem is how to come up with a generic
definition of what format the content of the <message/> elements should
be. Let alone the negotiation of what the client wants. In my weblogs-
pubsub mechanism mentioned, I, as the author of the component, was able
to decide what the clients would receive. But how do you decide what to
put in a <message/>?
> Now, I feel the ultimate solution to this problem would be what was
> started with JNG, where there was only one top level element <route
> to="" from="" xmlns=""> that carried any XML data to the intended
> destination. No <message>, no <iq>, just different namespaces covering
> custom XML. But we are not in JNG yet, so I guess we have to make
> solutions for the here and now.
> > It's worth pointing out too that some (not necessarily all) of the
> > regarding authorization could be addressed by having pubsub
> components for
> > specific areas of publishing, and auth-proxying those components in
> > with advertising. (Auth-proxying in the sense shown in
> > Jabber::Component::Proxy).
> Not sure what you mean here. I can't follow the perl module (I'm not a
> programmer). Would you or someone else mind explaining this to me?
There's some docu here: http://www.pipetree.com/jabber/jabbercomponentproxy/
I've written an article on it too, it should be coming out soon... :-/
> Sorry, I should have used "subscribe to everyone" instead of adding
> "everything" in there, too. I am not concerned with the everything part,
> but I am with the everyone. Just mass-requesting a presence subscription
> from everyone on the component is what I'm talking about, really. This
> would allow spammers to see what accounts likely have humans behind them
> and put them on spam lists.
I'm not sure how you see this happening...why would a subscription request
to receive any publications from a particular publisher turn into a mass-
request of presence "from everyone on the component"? (I may have
misunderstood what you mean). In any case, presence subscription is only
reciprocated by the component, not initiated, and certainly not done
> > How will that work? Presumably the spamming publishers will have
> > juicy to tempt people to subscribe to?
> Well, yes, of course. Publishers that have a subscriber base and have
> the intention of farming then selling the addresses of that base will
> likely just run their own pubsub component that people must subscribe
> to. Then they will fetch the addresses from that. Keeping subscribers
> anonymous in any way from the publisher but not the component won't
I must admit, I've never managed to get too concerned about this sort of
spam. On the one hand, there's a concern about presence subscriptions
(which I can't quite see the reasoning behind), presumably to protect
the identity of the subscriber JIDs, but on the other hand this addition
goes in the other direction (i.e. a publisher can "harvest" the JIDs
by requesting who has subscribed).
> So, how is this for a query protocol for publishers to use?
> <iq type='get' to='pubsub.localhost'
> from='subscriber at localhost/resource' id='s1'>
> <query xmlns='jabber:iq:pubsub'>
> Note the <subscribers> instead of <subscribe>. This probably is not the
> best solution, but it's a start, in an attempt to get the ball rolling.
Well, I would say the tagnames themselves are secondary. Do we assume
from the discussion so far, though, that subscribers don't have a choice
about anonymity? Does it matter? And what worth is knowing a subscriber
list when the subscribers are just pubsub repeaters in a hierarchical
> Do you mean authentication or authorization? Two different things. I'll
> assume you mean authorization since you use the word "selective". And
> the point to being able to remove and manage subscribers is not about
> preventing people from participating in the first place, as a pubsub
> component with an authorization layer in front of it would be for. In
> the case of a chat room, it may be desirable to remove or "delete" a
> user that is behaving badly.
THis of course assumes that we extend the proposal to allow publishers
to discover the subscribers in the first place :-)
More information about the Standards