Re: Let's fix THE PROBLEM

Hi all,
I've been working with both SIP and XMPP protocols for over a year now and I
find both protocols and the momentum behind them exciting and technically
stimulating. However I've also been wondering about the sense in both SIMPLE
& XMPP groups competing to evolve their specifications faster so one emerges
as a 'clear winner'.

In my opinion it definitely makes sense to split presence activities into
Information (pdif?) and Transport (PubSub events) concerns.

In a sense, mechanisms such as SIP and XMPP form a transport overlay
protocol which may be used to route data around the network based on certain
rules with varying connectivity between transmitting and receiving nodes.
Their primary concern is information routing whereas the format of the
information should be separate.

Therefore, we have an excellent opportunity to decouple information protocol
from transport protocol.  In much the same was as protocols such as HTTP
work over/with TCP but are defined independently within the IETF.

There aren't just SIP & XMPP mechanisms for Events or PubSub to consider but
there are a range of options available or under development based on other
emerging technologies (WebServices, P2P etc.) and their resulting protocols
(GENA, JXTA etc.).

The use of the MS specified GENA in Universal Plug and Play in interesting.
Arguably my toaster has as much right to produce presence information as I
do and that information will need to be transported as reliably and
efficiently as possible to interested users >:-)

It seems like a good idea to abstract these activities under the umbrella of
a Internet Interoperable Events Pubish/Subcribe Mechanism Working Group.
Suggestions on the title are welcome!

The development of an Internet-scalable, efficient and reliable Pub/Sub
mechanism could be a goal. Ideally the group would tackle the problem on
technical rather than political merits. I'm not proposing discarding any
existing work.

Existing groups that are currently engaged in work in this area (e.g. IMPP,
SIMPLE, XMPP) may (SHOULD) contribute to the new group and work towards
interoperability-between or unification-of existing standards and
specifications.

The IMPP group would then continue development of the information models for
presence, leaving SIP and XMPP camps to discuss the pros and cons of each
protocol with the new working group.

Forgive me naivety and idealism but it's just a thought.

regards,

    ...shane


//====================================
// Telecommunications Software and Systems Group
// TSSG: http://www.tssg.org
//
// Shane Dempsey: [email protected]
// Research Lead:  Services & Frameworks
// ===================================

----- Original Message -----
From: "Bob Wyman" <[email protected]>
To: "'Rob Batchelder'" <[email protected]>; <[email protected]>
Sent: Tuesday, July 15, 2003 5:44 PM
Subject: RE: Let's fix THE PROBLEM


> Rob Batchelder wrote:
> > it is patently obvious that "presence" is a capability which
> > should become part of the intrinsic operation of the Internet
> > AND that instant messaging is but one of many messaging /
> >collaborative applications which can be enabled by presence.
>
> I believe that you only state half the problem here. I would
> suggest that:
>
>   It is patently obvious that *PubSub* is a capability
>   which should become part of the intrinsic operation
>   of the Internet and that "presence" is but one of many
>   messaging/collaborative applications which can be
>   implemented using PubSub.
>
> The fact that "presence" has been given so much attention as a
> specific protocol, rather than as a use of a more general PubSub
> protocol is, in my opinion, a clear indication of the continued
> inability of the IETF community to carefully consider the architectural
> implications of its work as various interest groups attempt to rush to
> standardize specific, untested solutions. Since we've become engulfed by
> the Jabber vs SIMPLE war, we've been focusing more on handicapping the
> contestants than we have on doing solid, thoughtful protocol design...
> Personally, I believe that "presence" should be little more than
> PDIF. All the rest should be independent of presence and should be part
> of a general PubSub definition. There is nothing inherently "presence
> specific" about such protocol elements as Subscribe, Notify, etc. In
> fact, exactly the same pattern of elements exists in most PubSub
> protocols. It is ridiculous that we're going to end up with machines
> that implement *both* presence and PubSub.
>
> > Presence deserves its own working group.
> > It should start with a clean sheet of paper, and
> > not be unduly influenced by the SIP and XMPP camps.
> PubSub is the thing that needs the working group (i.e. as first
> proposed during the Notify-BOF many, many years ago). Presence should
> simply be a specialized payload type defined to be passed over PubSub
> connections.
> Just as we have Jabber/XMPP and SIP fighting over Presence etc.
> we're going to have the same thing for PubSub. Jabber has a PubSub JEP
> in "final call" right now and the SIP folk have been defining similar
> capabilities. The battle between these camps will continue and expand --
> although I am confident that it won't be fought on technical merits --
> rather, it will be fought with bluster, statements of market
> penetration, force of personality, etc.
>
> bob wyman
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Rob Batchelder
> Sent: Saturday, July 12, 2003 10:09 PM
> To: [email protected]
> Subject: Let's fix THE PROBLEM
>
>
> Dear IETF Contributors:
> To this point I have refrained from editorializing on the collective
> activities of the IMPP / SIMPLE / XMPP working groups.  Admittedly, I
> have not attended many of the IETF meetings - or actively contributed to
> the working groups.  Nevertheless, I am extremely active in the IM
> vendor community and do provide high level strategic counsel to the
> leading firms in this field.  That being said, I feel confident that I
> can articulate some of their concerns with IETF IM initiatives.
> First of all, I would like to point out the obvious overlap in the three
> groups charters.  As previous threads (and history) show there are a
> plethora of reasons for this.  My goal is not to analyze how the IETF
> got to where it is today - but to suggest where the IETF needs to go in
> order to credibly meet the needs of IM vendors and enterprise users.
> To those of us who are knowledgeable in this field - it is patently
> obvious that "presence" is a capability which should become part of the
> intrinsic operation of the Internet AND that instant messaging is but
> one of many messaging / collaborative applications which can be enabled
> by presence.
> Regrettably, working group efforts to date have not separated presence
> from IM within their scope and goals.  Although some would argue that IM
> is so closely related to presence that such a division does not make
> sense.  I and my peers disagree.  We suggest that presence so
> fundamental, far-reaching in impact, and involved technology that it
> deserves a working group of its own.  Concomitantly, IM (and other
> presence-enabled applications) should then have their own separate,
> clearly defined working groups - which leverage advances made on the
> presence front.
> Today, to the contrary, presence is still tangled up with IM and
> continues to be a political football - the "ownership" of which is being
> contested by multiple working groups.  This is "THE PROBLEM."
> There are those who argue that Presence is a natural extension of SIP's
> signaling capabilities - and thus SIP should be extended to define how
> presence should operate.  There are those who counter that XMPP's
> federated presence model is sufficient for building a global presence
> infrastructure.  I submit there is some validity to both points of view.
> The problem is that there are two (or more) points of view that have not
> converged - and that each working group continues to bang away at BOTH
> presence and IM issues in its own way.  And for the record - few in
> industry give any credibility to (IETF) platitudes that these efforts
> are collaborative and integrative.
> I submit that what is needed in the Internet is a Global Presence
> Architecture (GPA) which builds upon and extends all that we have
> learned from running DNS.  What needs to be recognized in developing a
> GPA is that presence will act like a next generation "dial-tone" upon
> which a wide variety of near "real-time" applications will be built.  As
> such, this dial-tone should be such that companies can privately employ
> it to serve their internal needs - as well as securely extend it between
> enterprises.  The presumption is that such a capability must be run at
> carrier-class (five-nines) reliability levels - and employ a universally
> agreed-upon name-space and security infrastructure.
> Candidly, I and my peers in the industry believe that the IETF has
> failed to grasp this reality.  Rather, the IETF seems bent on forging
> ahead with well-intentioned but fundamentally misdirected efforts of
> sincere, intelligent, hard-working volunteers.  Many of us view the
> current state of affairs as a reflection of an IETF "face-saving"
> exercise - because no one has the temerity to stand up and say that
> defining and specifying how presence should manifest itself has been
> fundamentally mis-understood, mis-scoped, and mis-managed.
> The time has come to confront this issue candidly - lest the industry
> continue to be paralyzed by IETF managerial ineptitude.  Presence
> deserves its own working group.  It should start with a clean sheet of
> paper, and not be unduly influenced by the SIP and XMPP camps.  And to
> the retort that key members of the IM industry should put aside their
> partisan issues and contribute to such a process I say, "Get your act
> together and they will!"
>
>
> Yours truly,
>
>
> Rob Batchelder
> President - Relevance
>
>
>
>
>   [reminder: [email protected] for non-technical discussions, please]
>
>




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