[standards-jig] Serious Issues with JEP 0024
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