IM/Presence is PubSub ( was: RE: [xmppwg] privacy list cleanup)
jean-louis.seguineau at antepo.com
jean-louis.seguineau at antepo.com
Mon Feb 17 17:12:54 CST 2003
Funnily it seems my english is never good enough to
properly convey my thinking.
The point I wanted to make is more simple that what Bob has
brilliantly exposed, and if he has come up with it, it
proves that my point of view was not expressed adequately.
1/ we want to design a protocol, and this has to be done
without any specific implementation in mind.
2/ we want an extension that would be able to convey the
requirements of a JID in terms of privacy to a service
without pre-judging of the way this service will be
3/ I was mentioning filtering because in the mind of many
on the mailing list, this is how they would actually be
implementing it, and I also have to convey easily
understandable notions. I never implied this how it should
be implemented. It was simply an easy reference.
4/ talking about pubsub at this stage is already making an
assumption in the way the resulting implementation will
work (although I totaly agree with Bob that at least for
presence the pubsup concept apply, but we may discuss the
applicability for messages that can be included in a pure
So to come back to the subject of privacy lists, I was not
advocating any particular underlying concept. I just wanted
to highlight the need for a thorough definition of the
problem ( I personnaly think this must be the base of any
engineering and design project :)
I not only have the feeling, but I have proofs that the
actual JEP0016 is even more a subset ot the subset
IM/presence that Bob mentioned, and as such cannot
constitute a solid ground for an adequate protocol
In in all fair examination, the actual proposal
for "privicy lists" has been hastily adopted by "client
minded" developpers, without a thorough examination of the
real needs. This is why it imposes many constraints that
bearely limit its use to PC based clients. It does not
consider usage by limited devices, and it poorly takes into
account the actual "user experience" when implemented at a
(These conclusions comes from our attempt at implementing
it in live user base, and are only here to illustrate the
point, not to start a flame)
This is why I made my earlier statement, in the view that
this forum is the right place and it is the right time to
rectify some of the flaw we have noticed in this extension.
We have noted a definite need and also requirement from
service providers to provide the end user with ways to
manage some aspect of their communication privacy (or the
details of their subscription to certain service).
My only conclusion is that to date XMPP lacks a simple
mechanism to "manage" the expression of these privacy
preferences. And don't misinterpret what I am saying, I am
only concerned by the enveloppe protocol. What I would
really like to have is a generic "list of items" protocol
that would allow to select, add, modify, delete lists and
items in a list without even caring about the actual
content of the items.
When I see that we are allredy down to discussing a
specific application through the format of the <item/>
element I simply say that we have overlooked some
intermediary steps: have we clearly enough defined the
scope and goal of the extension?
I personally believe that we havent, or I have missed
something. I believe that the standardization process
should be geared to defining the outer container part of
extensions thus allowing the maximum flexibility and ease
of adoption. Today, if I am obliged to use the privacy
lists as they are, I have come across limitation that make
them too limited and therefore have obliged us to develop
yet another flavour of yet another list management.
To make it short, I personnaly think that privacy list are
just a specific application of a generic list management
extension. In such conditions, we would only have:
1/ to define the generic list management extension, i.e.
the container part.
2/ to specify the privacy list management as a subset of
the generic extension, which boils down to specifying the
actaul content of the <item/> elements.
Doing so would allow reuse of existing protocol part such
as the x:data extension to finely detail the privacy
support. Or include any content reauired by a specific
Hope this clarify my position, once again from a pure
Quoting Bob Wyman <bobwyman at earthlink.net>:
> An Instant Messaging system can be modeled, and I
> be* modeled, as a PubSub or Publish and Subscribe system.
> functions of the system are limited to simply passing all
> "published" to or by a particular node or entity to some
> subscribers, then what you have is a "Topic-based" PubSub
> the moment you start talking about filtering out some
subset of the
> messages based on the content of those messages (such as
> identity) then you have a "content-based" PubSub system
and you have
> achieved a significantly higher level of complexity in the
> that must, or will eventually, be addressed.
> I personally believe that it is a mistake to
attempt to address,
> via privacy lists or other ad hoc measures, a subset of
> content-based filtering problem since it is inevitable
that doing so
> will simply raise expectations and start one down
> that will eventually force a broader range of
requirements to be
> addressed -- perhaps on an inadequate foundation. What
will happen is
> that you'll start off coming up with a reasonable
solution to the
> people come back and say that they want to filter on
other bits of
> content. (i.e. they don't want any message with "bad"
words in them.
> they *only* want messages that refer to "Britney
> messages on this list from Jack Erwin and Jean-Louis
> anticipate the slide down this slippery slope as they
seem to be
> for more flexibility in the filtering mechanism. Erwin
> well known principle (and problem) with content-based
> the trade-off between "expressiveness and performance."...
> At the risk of muddying the already-muddy waters of
> Presence, I would like to suggest that we look carefully
> the efforts being put into both XMPP and the more general
> (see: JEP-0060) to come up with a single protocol that
> purposes and supports IM/Presence as a subset. I have
> the PubSub debates and the IM/Presence debates for some
time now and
> assure you that such a combined effort can be
> compromising significantly the goal of getting an
> specification put to bed. The only concern, of course, is
> implementations... But, they would have to upgrade to the
> specification anyway.
> IM/Presence is simply a subset of the PubSub space.
If we don't
> deal with this fact sooner, rather than later, we'll find
> protocols being used as inadequately designed PubSub
> find PubSub protocols competing with IM/Presence
protocols. It is bad
> enough to have multiple IM protocols as we do today...
> the relationship between IM/Presence and PubSub will
> more "competition" between the protocols in the future.
> their natural relationship today would result in less
> as a stronger protocol base for a wide range of
> bob wyman
> For those interested in a "historical effort" to define
> PubSub in the context of Apex, take a look at:
> Note: This document needs much updating...
More information about the xmppwg