I believe that the industry, the press and even some governments have
consistently looked to the IETF to produce a single standard for instant
messaging and presence precisely because IM&P is an unusually balkanized
application on the Internet - unlike email and the web and so on instant
messaging is carried mostly by proprietary protocols; it grew up as a
product rather than an interoperable standard. It would be nice if we were
part of the solution rather than part of the problem.
Starting from the idealistic conceit that we could eventually arrive at
consensus on one IM&P protocol, the IETF went through a lengthy, bitter
process (echoes of which were the root cause of much of the ugliness at the
Jabber BoF) to arrive eventually at CPIM - which was a significant
accomplishment - and three competing WGs that were CPIM-compliant. By most
measures SIMPLE has been more successful than the other children of IMPP,
and for that reason many outside consortia and major companies that
previously espoused proprietary solutions have adopted a direction towards
SIMPLE as the product of the IETF's attempt to standardize instant
messaging. I don't think it is unreasonable to suggest that chartering a new
WG today that competes directly with SIMPLE would be taken by many to mean
that the IETF still has not arrived at a workable solution (and no doubt
some proponents of XMPP feel that to be the case). Will other protocols
that, like Jabber, did not advance to WG status after the selection process
in July of 2000 in IMPP (there were 15, IIRC) also come forward now
requesting their own WGs? Should the IESG have chosen 7 IMPP child WGs to go
forward instead of 3?
All that said, I actually support the chartering of an XMPP WG, but I would
prefer that it adopt a charter that is not just a "me too" for IM&P
(competing directly with APEX, SIMPLE and PRIM) but rather one that focuses
on unique competencies of the Jabber approach. Chartering something along
the lines of general XML transport, as was discussed at the Jabber BoF,
could be quite complementary to SIP, SIMPLE and no doubt many other groups
in the IETF, and this would most certainly satisfy the goal of "helping
Jabber out". In any event, I doubt that chartering a fifth (!) currently
active working group specifically focused on IM&P is likely to shed much new
light on the problem.
Jon Peterson
NeuStar, Inc.
(admittedly) SIMPLE co-chair
-----Original Message-----
From: Marshall Rose [mailto:mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us]
Sent: Tuesday, July 23, 2002 4:55 PM
To: Richard Shockey
Cc: ietf(_at_)ietf(_dot_)org; Marshall Rose
Subject: Re: Jabber BOF afterthoughts
[ lots of stuff deleted that was designed to distract... ]
But I wish that those proponents of a Jabber WG would
understand that some
of us in the SIP community have some real concerns about
the effect or
perceptions in the marketplace that chartering this work in
the IETF might
have. They are real and probably cloud our thinking ..but simply
dismissing
them as irrelevant or stupid is not going to help gain consensus on
chartering this work.
richard - whether simple succeeds or fails will have nothing
to do with
whether the ietf helps out the jabber folks. each will
succeed or fail on
their own merits.
i am at a loss to understand the extraordinary amount of fear
and loathing
from the simple camp that i witnessed in the jabber bof. i
could be more
unkind here, but i'm making an extraordinary effort to be inoffensive.
regardless, there are numerous precedents to invalidate your
position that
we can work on only one. the most obvious is cpim, which explicitly
acknowledges the existence of many.
however, if you insist that there can be only one, then
perhaps the logical
thing to do is for the iesg to put eveything on hold while we
do a detailed
analysis of the technical merits of the various approaches.
oh, wait, we already did that, and the result was that we did
cpim. go back
two paragraphs.
for myself, i think that the simple folks would be much
better served by
focusing on their work product than on political posturing.
/mtr