[Foundation] New protocol out of SIMPLE+XMPP :?

David Yitzchak Cohen dave at bigfatdave.com
Tue Oct 28 17:22:46 CST 2003

On Tue, Oct 28, 2003 at 04:43:00PM -0600, Peter Saint-Andre wrote:

> To me, there are three possible "solutions" to this "problem":

> 2. A higher-level negotiation protocol, which enables two servers to
> negotiate which server-to-server protocol they will speak, if any. So
> you either do SIP/SIMPLE or XMPP (or Wireless Village, or some other s2s
> protocol that you negotiate). This seems harmless, even useful.

...but mechanisms for deciding on this kind of stuff is going to appear in the XMPP docs, no?  The net effect is making XMPP more complex for the sole purpose of being able to interoperate natively with SIP, and I fail to see any advantage there. . .

> 3. A "hybrid" protocol (the only such hybrid I've seen mentioned is SIP
> for presence and XMPP for messaging). As I said, this doesn't make much
> sense to me (would you combine HTTP and Gopher?).

I'd be curious to see such a proposal ... but without knowing anything
more about one, I'm forced to speculate that the idea seems a bit crazy.
Letting native SIP stuff into an XMPP network means complexity, AFAICT.

> > If we're going to expand XMPP to interface natively with SIP, does that
> > mean we'll have a repeat when AOL decides to add "rich IM" features
> > and is forced to open its network?  Where do we stop?  
> XMPP shall not be changed, and no one will ever be required to interface
> natively with SIP or any other protocol if they support XMPP.

...even if the IETF guys decide that they "want" XMPP and SIP to
"interoperate" before they'll grant us an RFC?

> > The XMPP drafts
> > don't even include all the funcionality that the old "Jabber" system had
> > (although to be fair, they include MANY "neat" features that the original
> > didn't), and they're already getting _really_ long.  Whatever happened
> > to the ancient goal of keeping everything simple?
> As editor of the XMPP I-Ds, I try hard to keep things as simple as I 
> possibly can within the IETF. I apologize if any work output from the
> XMPP WG falls short of that goal.

As the JSF's premier troll, I try hard to point fingers at everybody.
The reality of the situation is that protocols naturally become complex as
time passes by, no matter how hard people try to prevent said phenomenum.
I don't think anybody would disagree that we kinda lucked out with you,
but that said,

> Also, what are the features that
> exist now in Jabber but are missing from XMPP?

it's worth noting that a bunch of JEPs are simply pieces of the old Jabber protocol that were taken out of the drafts.

> (I'm not talking about 
> things that were deliberately left out because they were not required,
> naturally -- the drafts would have been way too long otherwise!)

Let me repeat that I'm not saying that was bad.  I was simply
pointing out that the drafts are "incomplete" from any type of
real-world-standard-IM-app standpoint, and yet are rather long.  Do we
really have to add _more_ stuff that simply duplicates functionality
already available through transports?

> > > but at this point the discussions are highly preliminary. 
> > 
> > /me thinks it's probably better they stay that way, unless politics at
> > the IETF dictate otherwise.
> Dave, you are an astute observer. However, "politics" will not dictate 
> changes to XMPP itself.

I really hope you're right.

 - Dave

Uncle Cosmo, why do they call this a word processor?
It's simple, Skyler.  You've seen what food processors do to food, right?

Please visit this link:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://jabber.org/pipermail/members/attachments/20031028/598669a5/attachment.pgp

More information about the Members mailing list