[Jingle] summit Jingle braindump

[Robert McQueen]

* 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
  session.
* 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:
  http://events.linuxfoundation.org/events/linuxcon

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! :)

Regards,
Rob

-- 
Robert McQueen                                 +44 7876 562 564
Director, Collabora Ltd.             http://www.collabora.co.uk