[Jingle] [Fwd: [Summit] Jingle topics (was: Re: introduction)]
stpeter at stpeter.im
Sun Jul 27 21:44:39 CDT 2008
Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> Robert McQueen wrote:
>>> * getting rid of weird SIP hang-overs in jingle like profiles
> Lets just do that. Redundant stuff is bad.
Done in my working version of XEP-0167.
> We can determine the
> transport and that RTP is beong used by inspecting the XML namespaces in
> use, and determine whether SRTP is there by looking for the appropriate
> element. This is a good reason to put the SRTP element in the RTP
> description XEP itself, because otherwise a gateway could fail by not
> understanding the <crypto xmlns="...srtp"> element, and turning the SRTP
> offer into a plain RTP/AVP one.
>>> * sensible fallbacks between jingle transports, content-replace is kinda
>> I think we also need to figure out renegotiation of an existing session
>> (IMHO this is closely connected to what you are calling "sensible
> I think we covered this, transport-replace seems OK, and we're going to
> try and avoid other renegotiations if we can get away with it. :)
>>> * TLS over jingle stuff
>> By this do you mean (1) encryption of Jingle-negotiated media such as
>> voice or video (e.g., via SRTP or DTLS) or (2) use of Jingle to
>> negotiate an encrypted end to end XMPP session as in XEP-0247?
> I meant TLS'd XMPP streams over Jingle. Seems pretty good, most of what
> we need to do is just define some best practices for clients to generate
> keys, and do some continuity checking at least.
Right. Separate thread, separate list. :)
>>> * jingle descriptions for "arbitrary stream protocol" transportation,
>>> like any DNS-SD service (rfb, chess, whatever)
>> Looking forward to hearing what this is.
> I think I should just write this, it's pretty trivial, and we really
> want it for Telepathy Tubes. Just so you can invite your contacts to
> connect to your local DAAP/VNC/HTTP/whatever service.
Whee, tubes! Sounds like fun!
>>> * other APIs which are useful for collaborative applications (shared
>>> document models, but not weird bonghits like SXE)
>> Please, tell us what you really think. :) Is this connected to the stuff
>> we talked about in Brussels for exchanging DOM object changes (or even
>> random JSON data etc.)?
> Yeah, we didn't talk at all about this. I think SXE is pretty crazy
> because it seems like some huge explosion of the XML to make totally
> minor changes. If you have a shared DOM, you can use existing standards
> like xpath to name an existing node and say "insert a child node",
> "delete this node", or "replace this node". I didn't look at SXE in a
> lot of detail, but it seemed like an incredibly verbose way of achieving
> not a lot more than this. I don't think it actually addresses the hard
> stuff like how do you keep a consistent document model across multiple
> clients, which is what actually makes collaborative applications hard to
> develop, not the "how do I stuff bytes from A to B".
> The background to this is that OLPC has fed back to us and said that
> they don't think Telepathy Tubes are a particularly good API for writing
> collaborative applications on. I don't disagree, we just had two
> requirements in mind - one was allowing people to re-use existing wire
> protocols when appropriate, but have Telepathy take care of NAT punching
> or relating, which we invented stream tubes for, and the other was
> exposing a multi-user primitive that we could implement on top of MUC or
> multicast, which we invented D-Bus tubes for.
> We were hoping to get some push back from OLPC activity authors about
> what they'd rather see in the APIs, because we had very unclear
> requirements when we started out, other than "enable collaborative
> applications somehow", but we never really got that feedback. People who
> try to write collaborative activities on OLPC in general fail to do it,
> because they still have to know distributed computing and network stuff,
> even for simple things like a game which has shared state and only one
> player changing it at a time.
> Lots of people (Inkscape, Abiword) have also got code which just speaks
> XMPP directly with their own ad-hoc extensions, but this doesn't have
> any prospects of interoperating, sends lots of data through IBB, doesn't
> encourage code sharing (Telepathy's NAT traversal or Jingle
> implementation isn't really available, nor UI elements, etc), and
> wouldn't work in situations where Telepathy could do something different
> (like our link-local backend's multicast MUCs).
> I'd like to see something that will a) allow us to make life easier for
> application developers, b) be implementable by us on both link-local and
> server-based XMPP (and maybe even other protocols), and c) ideally be
> interoperable with other clients.
> This probably isn't the right forum to discuss this however, but feel
> free to forward me around a bit more... :D
Yeah the right list is probably here:
Or something. Maybe we need a "collaboration" list.
>>> * stacking/layering/nesting jingle transports, so we can say "here's a
>>> reliability layer, on top of an unreliable transport" or "here's a TLS
>>> layer on top of this unsecure transport"
>> Again, I'm looking forward to hearing your descriptions of these.
> We kinda decided a generic stacking thing was a bad idea, but I did come
> up with a way to run several reliable streams on top of one pseudo
> TCP-on-ICE connection, which I'll come back to in my later post on
> pseudo TCP.
>>> I'm also interested in seeing if people have interest in Jingle
>>> descriptions for including existing stream protocols, datagram
>>> protocols, and D-Bus IPC, so that we can standardise/interoperate
>>> Telepathy's Tubes (http://telepathy.freedesktop.org/wiki/Tubes,
> This is the same as what I meant above. :D
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080727/66929a34/attachment-0001.bin
More information about the Jingle