"Jack Moffitt" wrote:
>> First we open a session with Jingle, open an IBB as
>> transport, and start an e2e stream which will be secured by the starttls
>> feature. The log can be found at: http://www.tzi.de/~dmeyer/jingle.log
>> My first thought when I saw the complete log: wow, that is a lot of
>> stanzas.
>
> It does not look that verbose to me.  In fact, it's not that much
> different that the other examples, except that the stanzas themselves
> are slightly larger.
>
>> If you have a Jingle
>> implementation and also support link-local messaging, it is actual
>> _easier_ to implement.
>
> It seems to me that the Jingle way is the best.  The added complexity
> you discuss is from xep 247, which is pretty familiar to all XMPP
> developers since a similar procedure is used to set up any stream in
> the first place.  A decent XMPP library could probably be modified so
> that XMPP stream setup is factored out from c2s streams so that the
> same code and TLS auth can by used in both c2s and c2c cases.  When
> that happens, this little bit of extra work becomes completely free.

Yes, that is what my library does. The Jingle based E2E plugin hooks
into Jingle to open the stream and after that passes the stream to the
part handling the stream setup also used by link-local messaging.

> The more I read about Jingle, the more I like, and I think that it is
> the right tool for the job here.

I also like Jingle, but after some thinking, I prefer the stuff I wrote
after the comparison. It would be very nice to have a general TLS
mechanism directy in Jingle. You will not only get secure communication,
you can also get secure file transfer and other use cases are possible
as well: secure VNC connections (we all know people we have to help with
their computer from time to time) or something like "Back to my Mac".

> Moreover, basic Jingle support will be quite useful for other XMPP
> tools we make in the future I suspect, and encouraging library authors
> to start adding this is a good thing.  E2E encryption is a pretty
> compelling reason to implement Jingle, where VoIP maybe isn't (unless
> you're specifically wanting to support voice/video chats).

Agreed. Jingle is much more than VoIP. And most of the complexity in
Jingle implementations comes from VoIP: choosing RTP parameter, codecs,
etc. TCP-like streams over Jingle are much simpler.


Dirk

-- 
AIRPORTS: A place where people hurry up and wait.
           (Terry Pratchett, Wings)

Reply via email to