[Standards-JIG] JEP-0060 Publisher Model - nodehirarchy permissions

Peter Saint-Andre stpeter at jabber.org
Tue May 30 20:14:47 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jean-Louis Seguineau wrote:
> 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
> pubsub models. 
> 
> 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.

The fact that a NodeID can have semantic meaning does not imply that the
only form of semantic meaning is hierarchical. For instance, in PEP we
have NodeIDs like "http://jabber.org/protocol/tune" -- that has semantic
meaning ("this is a node for this user's music info") but it does not
have hierarchical meaning.

If folks would like me to add some hardline text to the spec about not
depending on the (seeming) structure of the NodeID to enforce hierarchy
then I would be happy to do so. Probably the examples need to be changed
as well (I was lazy about NodeID examples in the spec).

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEfKe3NF1RSzyt3NURAjDPAKDZrJo7mbmEfLnHFBnPPc0arfxWLQCgmv6Q
3f8ktHxpW6WJFEH1W7tCFR0=
=nOxL
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060530/7cee4a37/attachment.bin>


More information about the Standards mailing list