[Standards] Simple Jingle example(s) and spec(s) wanted

[Matt Tucker]

Remko,

Focusing on file transfer as a way to get initial Jingle support in clients is a great idea. ICE-based transfers would be the current way to work around firewall issues, but it's not a very simple approach for initial implementations (we've seen this same problem on the audio side). Simple UDP and TCP proxy specifications for Jingle would go a long way towards solving that problem. 

Regards,
Matt 

> -----Original Message-----
> From: standards-bounces at xmpp.org 
> [mailto:standards-bounces at xmpp.org] On Behalf Of Remko Tronçon
> Sent: Saturday, February 03, 2007 10:07 AM
> To: XSF Standards
> Subject: [Standards] Simple Jingle example(s) and spec(s) wanted
> 
> Hi,
> 
> I think it would be good for Jingle's popularity to have clarifying
> example(s) and at least one easy-to-implement description 
> format and transport specification. Due to the lack of an 
> example encompassing the complete flow of a Jingle session 
> and an easy-to-implement (yet maybe not very effective) 
> transport, there is no way to get
> *something* implemented in a decent amount of time, which is 
> very demotivating (at least for me). For example, it would be 
> great if there was a description format for file transfers, 
> and a SOCKS5 transport spec to transfer the files over. 
> Correct me if i'm wrong, but this sounds like the easiest 
> Jingle session to implement, and as such allow people to 
> implement the framework of Jingle support in their 
> application fast, without having to bother with the low-level 
> details of transports (and even worse, multimedia implementations).
> 
> As for the clarifying example, I would like to know how the 
> following use case goes (in terms of XML stanzas sent and 
> received, and actions performed by both clients):
> - Client A wants to send a file to Client B, and supports 
> SOCKS5 and Raw UDP. Client A is NATed (with a port forward), 
> and as such has both a local IP and a global IP through which 
> it is reachable.
> - Client B only supports SOCKS5, and is outside of Client A's 
> local network.
> This flow would already clarify a lot (at least it would for 
> me). An extension of this example would be where Client A 
> supports 3 transport methods, and Client B doesn't support 
> one of the 3, and is unable to reach Client A using one of 
> the 2 remaining.
> 
> Thoughts?
> 
> cheers,
> Remko
>