[Standards-JIG] RE: Jingle vs. Zoep
jean-louis.seguineau at laposte.net
Thu Feb 9 23:48:11 UTC 2006
I believe Akito has put forward a number of valid points. And I am joining
him in expressing that reducing a protocol discussion to A vs B, or to
details in the technology before even asking ourselves what problems we are
trying to solves is somewhat void of any sense. This is even more true, when
it leads to a JEP.
Just declaring that "Jingle is a benefit to client implementers" or that one
is "committed to ensuring that Jingle gateways to SIP" does not shed any
light on why we should prefer Jingle (Sorry I have chosen those excerpts on
Jingle has no value per se. I nevertheless feel it is a natural trial at
bringing media sessions negotiations to the XMPP world. But we could have
gone other ways. We could have used the existing stream negotiation and
adapt it to establishing RTP streams. We could tunnel SIP inside XMPP, but I
feel it adds up weight and complexity were not needed. We could use CSTA-XML
to perform all the voice call control functions. There may be other options.
Now for the purpose. Why do we want to negotiate media sessions? Just
because it's cool? Because we want to re-invent what Skype has done before?
Because we do not like SIP and we want to re-do what SIP is already doing?
Because clients' developers want to interoperate with GTalk? [insert your
own good reason here]
I haven't seen anything but vague hints at the real values that XMPP could
derive from enabling media session negotiation. What benefit can the XMPP
community derive for this? What benefit can commercial entities supporting
XMPP derive from this?
I personally have only partial answers to this, but I entirely agree that
asking one self "Does XMPP really need the complex feature set SIP
provides?" is an excellent starting point. Jingle in its current form (and
under the umbrella of two commercial entities) has given the community the
documentation of an existing prototype and the beginning of a return on
experience. Is this sufficient for a viable robust protocol definition? With
all recognition for the achievement and the dedication of the authors, I do
not believe it is. It has taken much more than 250 pages of RFCs and
countless hours of discussions to get SIP where it is now. We can certainly
benefit from it and leverage that invested time, especially if we join and
have real non antagonistic exchanges of views. If all boils down to lobbying
a particular technology for no other merit than, for example, an installed
base, where is the need for a discussion list? We would be better off using
P.S. I do not have any alternative solution to promote, and I do not 'like'
any protocol better. Let me just reiterate that in the XMPP context, some
technologies are more adequate than other, easier and simpler to implement.
This is what I would like to be able to discuss in this list. And yes I
think every protocol must try to be simple...
More information about the Standards