[standards-jig] Serious Issues with JEP 0024

Adam Theo theo at theoretic.com
Thu Jul 11 02:27:52 UTC 2002


DJ Adams wrote:
 > 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.

Very sorry about that. I had already started this email before
contacting you about it. I should have paid more attention when proof
reading it to notice I had already brought those up with you. Very sorry.

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

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?

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

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
newsletters that look and work just like normal messages nor can you
publish/broadcast headlines via the old <message type="headline"> tag.
Everything is done in IQ from this point on, except direct one-to-one
communications between humans.

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

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.

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

Hmm... OK, I can see that. After all, presence-based sending includes
not only offline/online, but also busy, away, and others.

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

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?

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

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.

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

I see. Well, I do think it needs to be resolved before it is accepted.
I'll post some ideas on how I think it could be done in a bit.

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

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
work. Now, I understand the anonymous status exists because a query
protocol has not been added, but I am just expressing my hope that such
a thing is made and widely used before the JEP becomes accepted. I
should have clarified that in my original post.

There are many good reasons why publishers should be able to see who has
subscribed. One is to know how many subscribers they have in order to
attract paying advertisers for newsletters. Another is to know how
popular a mailing list or chat room is (besides, without a way to query
who is subscribed, how would chatrooms like jdev at conference.jabber.org
be created? No-one would know who the other participants are until they
spoke.).

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'>
           <subscribers/>
         </query>
       </iq>

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.

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

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.

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

Would be a useful feature. Possibly done through a special tag such as
<admin>, like <subscribe>, <unsubscribe>, and <publish>.

SEND: <iq type='set' to='pubsub.localhost'
              from='publisher at localhost/resource' id='s1'>
         <query xmlns='jabber:iq:pubsub'>
           <admin ns='foo'/>
             <remove/>
           </admin>
         </query>
       </iq>

This would send out some sort of notification code to all subscribers. 
Clients and components could use it to automatically unsubscribe and/or 
notify the user.

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

Good to hear. It is an excellent idea, and one I know I'll be using alot of.

-- 
      /\  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