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


Hi all,

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 
rendered.

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 
routing paradigm)

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 
extension.

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 
client level. 

(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 
apllication.

Hope this clarify my position, once again from a pure 
protocol perspective.

Jean-Louis Seguineau



Quoting Bob Wyman <bobwyman at earthlink.net>:

> 	An Instant Messaging system can be modeled, and I 
think *should
> be* modeled, as a PubSub or Publish and Subscribe system. 
If the
> functions of the system are limited to simply passing all 
traffic
> "published" to or by a particular node or entity to some 
set of
> subscribers, then what you have is a "Topic-based" PubSub 
system. But,
> the moment you start talking about filtering out some 
subset of the
> messages based on the content of those messages (such as 
their
> authors'
> identity) then you have a "content-based" PubSub system 
and you have
> achieved a significantly higher level of complexity in the
> requirements
> 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 
the
> content-based filtering problem since it is inevitable 
that doing so
> will simply raise expectations and start one down 
a "slippery-slope"
> 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
> privacy policy (filtering based on authorship) and then 
later have
> 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.
> Or,
> they *only* want messages that refer to "Britney 
Spears."...). Recent
> messages on this list from Jack Erwin and Jean-Louis 
Sequineau already
> anticipate the slide down this slippery slope as they 
seem to be
> calling
> for more flexibility in the filtering mechanism. Erwin 
even invokes
> the
> well known principle (and problem) with content-based 
PubSub systems
> of
> the trade-off between "expressiveness and performance."...
> 	At the risk of muddying the already-muddy waters of 
IM and
> Presence, I would like to suggest that we look carefully 
at combining
> the efforts being put into both XMPP and the more general 
PubSub
> problem
> (see: JEP-0060) to come up with a single protocol that 
serves both
> purposes and supports IM/Presence as a subset. I have 
been watching
> both
> the PubSub debates and the IM/Presence debates for some 
time now and
> can
> assure you that such a combined effort can be 
accomplished without
> compromising significantly the goal of getting an 
IM/Presence
> specification put to bed. The only concern, of course, is 
with
> existing
> implementations... But, they would have to upgrade to the 
new
> 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 
IM/Presence
> protocols being used as inadequately designed PubSub 
protocols and
> we'll
> find PubSub protocols competing with IM/Presence 
protocols. It is bad
> enough to have multiple IM protocols as we do today... 
Not addressing
> the relationship between IM/Presence and PubSub will 
inevitably lead
> to
> more "competition" between the protocols in the future. 
Dealing with
> their natural relationship today would result in less 
complexity as
> well
> as a stronger protocol base for a wide range of 
applications.
> 
> 		bob wyman
> 
> For those interested in a "historical effort" to define 
content based
> PubSub in the context of Apex, take a look at:
> http://www.ietf.org/internet-drafts/draft-wyman-apex-
pubsub-00.txt
> Note: This document needs much updating...
> 
> 



More information about the xmppwg mailing list