Re: Let's fix THE PROBLEM

Hi all,

Having visited the WISEN website and read some of the presentations
available there I concluded that things are indeed quite different 5 years
on.  We now have an Working Group that IS looking at Internet Scalable
Events. Unfortunately it's doing it under the auspices of Presence and
Instant Messaging. This is for historical rather than technical reasons.

Presence is a consumer of an Internet Scalable Events Mechanism. Through a
quirk of fate IM has evolved as one of the first technologies to justify the
development of ISEM. However there are other technologies (ubiquitous
computing, P2P etc., web services) that will also require this mechanism.

Here are the predictions from the breakout session on Applications notes of
the Workshop on Internet Scalable Events Notification (WISEN) in 1998
Available @
http://www.isr.uci.edu/events/twist/wisen98/presentations/Summary-Applicatio
ns/Final_notes.html
"Predictions:

  a.. involves wireless
  b.. everything can plug in
  c.. ubiquitous
  d.. over used - SPAM
  e.. more geographic oriented events
  f.. social implications
  g.. JIT everything
  h.. increased network instability
  i.. event mining "
These are very pertinent to the current developments in several industries
(mobile communications and applications, entertainment, electronic CRM, the
list goes on). Indeeed the 3GPP do seem to have sided with SIP. Perhaps this
is in the absense of a viable alternative.

However, I 'm not convinced that SIP versus XMPP is a good argument. The
question is what are the best bits of each protocol and how do we combine
them/unify them to achieve Internet Scalable Events.  I fear that if we
don't attempt this now then we'll end up with different Internet
PubSub/Events mechanisms for different industries.
SIP for Telco's, XMPP as the darling of the open source, GENA for Microsoft
and other WebService technology vendors etc.  This could be an
interoperability nightmare and would probably be detrimental to the
evolution of the Internet as a whole as it creates uncertainty and reduces
scale. If there were several incompatible versions of IP the Internet would
not have caught on. Commercial pressures often dictate proprietary systems
as a mechanism to 'lock-in' customers. This is too important to allow that
to happen.

regards,

    ...shane



----- Original Message -----
From: "Bob Wyman" <[email protected]>
To: "'Joe Hildebrand'" <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>
Sent: Friday, July 18, 2003 12:39 AM
Subject: RE: Let's fix THE PROBLEM


> Joe Hildebrand wrote:
> > Yes, there are times when I want to publish and subscribe
> > to a different list of people than the people that are
> > subscribed to my presence, but that's pub/sub, not presence.
> Sorry if I'm being dense here, but can you explain why one is
> "presence" and the other is "PubSub" even though I'm subscribing to
> "Presence" data in both cases?
>
> > I can imagine implementations that use pub/sub for
> > presence, that don't require anything drastic:
> What I meant by "drastic" wasn't a technical comment, but rather
> a process comment. As your example shows, doing Presence over PubSub is
> pretty obvious and doesn't present major technical problems. The
> "drastic" thing that I was referring to would be a redefinition of
> Presence in XMPP to rely on PubSub rather than using the existing
> mechanism.
>
> >I'm not sure how that's a single, monolithic package.
> Sorry. Bad word choice. A better word might be "stand-alone." In
> XMPP, Presence doesn't use either PubSub or an events package like in
> SIP/SIMPLE. This may tend to result in people overloading Presence to
> accomplish things that would be better done with PubSub since Presence
> is almost guaranteed to be implemented by everyone whereas PubSub, as an
> optional protocol extension, is now and probably will remain less
> commonly implemented.
>
> bob wyman
>
>
>
>
>   [reminder: [email protected] for non-technical discussions, please]
>
>




  [reminder: [email protected] for non-technical discussions, please]