[Jingle] summit Jingle braindump
robert.mcqueen at collabora.co.uk
Mon Feb 9 11:18:25 CST 2009
* Tighten up the security considerations to say: don't trust the
initiator field unless you trust the from field.
* Tweak the transfer XEP to cover the notification you need to send when
you're making an outgoing session via a proxy (forward transfer? some
better name?), so that the endpoint knows to trust it.
* Perhaps also formalise that the correct way to get a proxy to relay
for you is to set the responder differently to the to= field, and that
the initiator/responder/SID tuple should be preserved in the relayed
* Lose the "transport-info" from Raw UDP - the responder's candidate can
just go in the "session-accept".
* Allow putting some candidates in the "session-initiate" and
"session-accept" when doing ICE UDP, as it might avoid the need for
separate "transport-info" messages
* Maybe we can have the US summit in September at LinuxCon in Portland,
co-located with the Linux Plumber's Conference and the Kernel Summit:
File transfer stuff:
* Stream transports should explicitly allow multiple connections
* We want a Jingle IBB XEP which has some kind of stream IDs and puts
the base64 in the <jingle> container.
* We should stick to using the S5B wire format, except the Jingle schema
can cover "fast start" (a la
http://delta.affinix.com/specs/stream.html) which means people can
attempt connecting in both ways. Dirk might have a hack at that first.
* Stick to non-HTTP initially, one file per content.
* When/if we do PseudoTCP/Enet/whatever later, we can put one ICE
transport in the jingle session, and use it as multiplexing as well as
reliability. Each file can use one "port" as a transport.
That's about it I think! :)
Robert McQueen +44 7876 562 564
Director, Collabora Ltd. http://www.collabora.co.uk
More information about the Jingle