[standards-jig] Serious Issues with JEP 0024

Adam Theo theo at theoretic.com
Fri Jul 19 05:46:17 UTC 2002

OK, Here's my full idea for a better pubsub protocol.

First of all, here are its prerequisites:
* A complete Discovery & Navigation protocol to allow potential 
subscribers (whether they are end users or proxies acting on behalf of 
end users) to find out what pubsub component particular publishers use 
for certain namespaces/topicIDs.
* A comprehensive Packet Headers protocol to allow finer-grained 
addressing of not only users, hosts, and resources in a JID, but also be 
able to specify destination "topicIDs" for a pubsub component.
* A powerful Permissions & Access Control protocol to protect both 
subscribers and publishers, filtering by namespace, recipient JID/host, 
and sender JID/host, as well as others.

A potential subscriber would "disco" the publisher, get a list back of 
the <entities> (I'm assuming it would not be <features>) associated with 
that publisher, and see which one covered the desired namespace/topicID. 
I imagine this would be done by including application-specific XML 
within the <entity> tag corresponding to the pubsub component the 
publisher used. This application-specific XML would list off the 
namespaces/topicIDs that that particular entity covered for the publisher.

Also, by using Disco, we eliminate the need for the first half of a 
"publisher query protocol" within pubsub. When a publisher Disco's the 
component, they could get a return list of subscriber/client <entities> 
associated with that component. Disco should be used to get the list of 
subscribers to a particular topic.

Any type of packet (a message or an iq of any purpose) needs to be able 
to be published to and sent out by the pubsub component. This would 
allow a groupchat/conferencing protocol (such as Conflux 
[http://www.theoretic.com/?Conflux]) to easily use <message> packets, 
which is what groupchat should use. It would also eliminate the need for 
  the second half of a "publisher query protocol" by allowing publishers 
to send <iq> packets to subscribers requesting their vCard (for full 
name and home location), etc... Some iq namespaces may be blocked from 
being broadcast to the subscribers. This would be done in the component 
configuration by the server admin.

If the "real" subscriber is behind a proxy subscriber as presented in 
JEP 0024 (quite likely, if I have my way :-), then the proxy would 
receive the <iq> requests just like normal published material, and 
should forward it on to the real subscriber after authorizing it (it may 
be a major benefit of using a proxy subscriber that it could filter out 
certain <iq>s that you don't approve of, before it ever reaches you).

With Disco and Packet Headers, the need for a query protocol to allow 
publishers to see who their subscriber base is is completely covered.

Here's an equally far-reaching concept. Adopt a Permissions & Access 
Control protocol into pubsub even farther and remove the lines between 
publisher and subscriber completely and allow entirely new relationships 
in generic pubsub. Here's how:

There are topics within pubsub components. These topics do not 
necissarily belong to anyone except the component itself. There is no 
inherent publisher. Instead there are subscribers/members with different 
permissions. One or two (or a few) may have "write" and "destroy" 
permissions in the topic, meaning they are essentially the publishers 
and administrators of the topic, able to destroy the topic or 
remove/silence subscribers. Others may have only "read" permissions, 
only able to receive published materials but not post or change metadata 
about the topic. There could be other combinations of permissions that 
creates other relationships to the topic.

Topics would not be owned by "publishers". Users could request a pubsub 
component to creatre a new topic and put them in charge as the first 
user with all permissions. That user could then add co-publishers or 
co-adminsitrators, set passwords, allow subscribers with read-only 
access, or allow subscribers with read-and-write access (to create a 
chat room-type topic). Permissions could be on moderator approval only, 
or could be granted by password given upon subscription. This would 
provide for a great level of customizability and flexability, while 
keeping the pubsub protocol very simple since other protocols (such as 
Disco, Headers, and Perms) would do most of the gritty details.

     /\  Adam Theo, Age 23, Tallahassee FL USA
    //\\   Email & Jabber: theo at theoretic.com
   //  \\  (Boycotting AOL, therefore no AIM or ICQ)
//  ||  \\  Theoretic Solutions: http://www.theoretic.com
     ||         "Building Ideas by Bringing them Together"
     ||      Jabber Protocol: http://www.jabber.org
     ||         "The Next Generation Communications Protocol"
     ||  "A Free-Market Socialist Patriotic American Buddhist"

More information about the Standards mailing list