Subject: RE: Jabber BOF afterthoughts

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Jul 2002 12:11:26 -0700

At 09:49 PM 7/23/2002 -0400, Peterson, Jon wrote:
>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

Jon (et al)

The IETF does technical work.  It does not do marketing work.  We let the 
market do marketing work.

The primary criteria for doing work in the IETF are:

         - our having adequate technical competence for the task

         - the proposed work having adequate clarity and feasibility

         - a sufficient pool of people willing to work on it

         - a reasonable indication that there will be suppliers of the result

         - some indication that there will be consumers of the result

All of these conditions are satisfied by Jabber, pending a working group 
charter that is clear, tight and practical.  I'm not too worried about the 
charter satisfying these requirements.

When the IETF tries to stifle competition, it usually does a bad job all 
around.

When the IETF tries to listen to "market" factors with any more subtlety 
than "there appear to be some ready suppliers and consumers of the work" 
then it usually does a bad job.

Sometimes, yes, the IETF stifles competition, but the only times it does 
that constructively is when there is a good technical basis.  Otherwise, it 
lets the work of the constituencies and the reaction of the market do the 
filtering.

The IETF has been working on IM&P for 4 years.  You may have noticed that 
the balkanization of the IM&P world has not been reduced after all that 
time.  One might even take the recent AOL announcement that it is backing 
off from interoperability efforts as a good indication of just how bad the 
situation remains.

>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

and we should all remember that CPIM represents a very explicit 
acknowledgement that there are -- and will be -- multiple IM&P protocols.

>- which was a significant
>accomplishment - and three competing WGs that were CPIM-compliant. By most
>measures SIMPLE

In terms of my own understanding of IETF culture, priorities and rules, 
with respect to the Jabber initiative, the accuracy of your assessment is 
frankly irrelevant.  And the failure to recognize that it is irrelevant is 
the core of the problem with the misbehavior by a number of SIMPLE 
advocates.

>  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

People often choose to interpret things in a way that has nothing to do 
with reality.  Another thing the IETF does very badly is try to 
second-guess inaccurate interpretations of things.  For that matter, most 
people outside the IETF do that rather badly too.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Jeremie <[email-masked]>
Date: Wed, 24 Jul 2002 18:35:50 -0500 (CDT)

> I happened to be at the Jabber BOF, which since has turned out to be a
> hot topic, at least judging from the discussions at the IESG plenary.
> As far as I understood, the objectives of the Jabber community were,
> that they mainly wanted a place for the protocol documentation to be
> published, and needed some expert review and help in sorting out the
> security services for the protocol.

A simple misunderstanding: they are some of the motivations, but not the
main ones.  We "mainly" want to keep the protocol from fragmenting into
disarray, diverging implementations, lack of agreeance, poorly
implemented/upgraded security additions as they come along, just all
around poor support for a multi-domain multi-use protocol, where that poor
support can directly impact the effectiveness and usability of other parts
of the network.

> I didn't see an overwhealming desire to release the control for the
> development of the protocol to the IETF, but I may have misinterpreted
> things.

I never got my chance at the mic to explain my viewpoint on this.  The
protocol is based on namespaces, and the JSF is primarily a forum where
people create NEW namespaces, which is as separate from HTTP as is new
content types served over it.  There is very little activity in the JSF
around the core protocol, nor has there been any "change control" asserted
beyond independently updated software releases.  The "core" protocol, that
primarily documented best by the drafts, isn't controlled by anyone at
this point, you could say the JSF is the closest, but it has not taken
that role.

Again, we're coming to the IETF because we *need* a strong and
proven process for managing this important layer in the Jabber
architecture.  We're not giving up any control, we simply don't have it.

> My perhaps a rather simplistic suggestion at the BOF was that the
> Jabber community submit their protocol specifications to the IESG to
> be published as Informational RFCs. After an addmittedly quick skim
> through the I-Ds, in my opinion they seemed to describe a pretty
> mature protocol which arguably works. And my understanding of the IETF
> process has also been that the IESG does commit to a fairly thorough
> review for even documents intended as Informational, i.e., give expert
> review, possibly referring to relevant WGs in the process.

Another angle on the same theme: it's not the documents or publications
themselves that help force consensus and stabilize a growing-unwieldy
network protocol, it's the process of involving all the interested parties
in a WG to iron out issues from their varied perspectives and having
control of the protocol exist in the hands of a recognized standards body.

I didn't say it very clearly at the BOF, but the reason we weren't doing
this two years ago was because we didn't care about the protocol (our
focus has always been open interoperability and accessibility), and had
the expectation that anything the IMPP could come up with would be a
superset of what we had and we could migrate to it, after all the IMPP
architecture descriptions were almost identical to Jabber.

That didn't happen, there is no protocol with comparable characteristics,
and now we're faced with the popularity of our own protocol and the
implications of new quasi-implementations on the network when nobody has
the ability to say or enforce anything.

> Why is that? After all, the Informational RFC should work equally well
> for the Jabber community, and would even allow them to retain control
> for the development of the protocol. I understand the Internet Relay
> Chat is in fact Informational, but that doesn't seem to have hampered
> its adoption in the Internet.

Funny that you should mention IRC, that's exactly what we're trying to
avoid, a protocol full of problems and holes with only patchwork fixes and
"get a better implementation" solutions to work around it's deficiencies,
and numerous extensions that aren't exactly optimal :)

Jer