[Standards-JIG] JEP-0060 Publisher Model - nodehirarchy permissions
jean-louis.seguineau at laposte.net
Fri May 26 09:01:18 UTC 2006
I strongly agree with Bob's statement. In a properly designed pubsub
brokering system Node IDs must be opaque. When using application semantic in
addresses or IDs, relying systems become difficult to scale or to interface
with other systems. For those interested, there are a number of pointers on
Bob's blog to studies and papers explaining pros and cons of different
If one model is used in a particular implementation, the pubsub system must
advertise support through disco, not 'imply' it by adding semantic to the
IDs. Similarly, a client must not be built on the assumption the pubsusb
system follows a specific model.
Bob is not saying an implementation cannot use hierarchies. He is just
saying the implementation must follow the protocol and expose this behavior
through service discovery. Protocols are published to describe the expected
service behaviors. Any shortcut, assumption or private interpretation
defeats the purpose of a protocol and must be flagged as a bug. Aren't we
complaining when MSFT is doing it all the time?
It just happens that most implementers are more at ease with hierarchies
than with distributions. It just happens that users are more comfortable
with 'topics' and 'sub-topics'... There are provisions in the JEP for a
hierarchical design. But this is in no way the only possible model. In
certain contexts, a different model, such as content based, may be more
appropriate. Studies have long ago exposed the shortcomings of the
hierarchical pubsub model when designing Internet wide systems. Allowing
this bug would de-facto lock XMPP into a model that is not extensible. And
this is not only a bad thing, it is a mistake.
Glad you brought this up Bob.
Date: Thu, 25 May 2006 16:24:33 -0400
From: "Bob Wyman" <bob at wyman.us>
Subject: RE: [Standards-JIG] JEP-0060 Publisher Model - nodehirarchy
To: "'Jabber protocol discussion list'" <standards-jig at jabber.org>
<200605252025.k4PKP350012108 at omr6.networksolutionsemail.com>
Content-Type: text/plain; charset="us-ascii"
> ejabberd builds a hierarchy based on the id - this is not specified in
If ejabberd "builds a hierarchy based on the id" then that is
completely *OUTSIDE* JEP-0060. It is a bug. Node IDs in JEP-0060 are opaque
and no client or server should ever treat them otherwise.
My personal and very strongly held opinion is that if ejabberd is
actually doing what you say it is doing, this should be flagged as a bug and
the bug should be fixed as soon as possible. It is exceptionally difficult
to maintain standards if implementers insist on diverging from the standard.
Given the prominence of ejabberd, it is likely that people will come to
perceive this bug to be normal behavior and thus attempt to get others to
implement the same bug. This is not a good thing.
Hierarchy in JEP-0060 collections should be established using the
mechanisms provided in JEP-0060 and those same mechanisms should be used to
discover the hierarchy. Shortcuts that violate the specification should not
More information about the Standards