One of the advantages of the technique that I described is that the
server/proxy isn't required to keep a table of every outstanding
IQ.  I think that was one of the concerns that motivated this
discussion in the first place.<br>
<br>
Joe<br><br><div><span class="gmail_quote">On 2/14/06, <b class="gmail_sendername">Simon Guindon</b> <<a href="mailto:simon.guindon@tomahawk.ca">simon.guindon@tomahawk.ca</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="direction: ltr;">




<div align="left" dir="ltr"><span><font color="#0000ff" face="Arial" size="2">Yup I agree. </font></span></div>
<div align="left" dir="ltr"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div align="left" dir="ltr"><span><font color="#0000ff" face="Arial" size="2">XMPP already has tracking via IQ ID's so really the gateway 
just has to store and keep track etc. I like the way you suggest they store, but 
really they can store it various ways internally in the gateway however they 
please as long as they give the original ID back in the IQ 
responses.</font></span></div>
<div align="left" dir="ltr"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div align="left" dir="ltr"><span><font color="#0000ff" face="Arial" size="2">Take care,</font></span></div>
<div align="left" dir="ltr"><span><font color="#0000ff" face="Arial" size="2">Simon</font></span></div>
<div><font color="#0000ff" face="Arial" size="2"></font> </div>
<div align="left"><font color="#000080" face="Courier New" size="2">-------------------------------------------------------</font></div>
<div align="left"><font color="#000080" face="Courier New" size="2"><strong>Simon 
Guindon</strong></font></div>
<div align="left"><strong><font color="#000080" face="Courier New" size="2">Tomahawk 
Technologies Inc.</font></strong></div>
<div align="left"><font color="#000080" face="Courier New" size="2"><a href="mailto:simon.guindon@tomahawk.ca" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">simon.guindon@tomahawk.ca</a></font></div>

<div align="left"><font color="#000080" face="Courier New" size="2"><a href="http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.tomahawk.ca" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.tomahawk.ca
</a></font></div>
<div align="left">
<div align="left"><font color="#000080" face="Courier New" size="2">-------------------------------------------------------</font></div></div>
<div> </div><br>
<div align="left" dir="ltr" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:standards-jig-bounces@jabber.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">standards-jig-bounces@jabber.org</a> 
[mailto:<a href="mailto:standards-jig-bounces@jabber.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">standards-jig-bounces@jabber.org</a>] <b>On Behalf Of </b>Joe 
Beda<br><b>Sent:</b> Tuesday, February 14, 2006 2:23 PM<br><b>To:</b> Jabber 
protocol discussion list<br><b>Subject:</b> Re: [Standards-JIG] Jingle: tracking 
stanzas<br></font><br></div></div><div style="direction: ltr;"><span class="e" id="q_1096a24b0779e694_1">
<div></div>My suggestion is that any server JID/endpoint that is proxying 
stanzas can rewirte the id to encode enough information to forward to the 
correct connect/session.<br><br>So -- if we have A->S->B:<br>* S has a map 
of 'connection id'->connection/session.  Each incoming connection gets 
assigned an id as it connects<br>* A sends a stanza with id='AAA'<br>* S 
rewrites that id as '123:AAA' where 123 is the connection ID and forwards the 
stanza to B<br>* B responds with an error or result to S<br>* S decodes the id 
and gets both the connection index and the original stanza id<br>* S rewrites 
the id on the response back to 'AAA' and forwards it on to A.<br><br>Depending 
on how and where you are using this there may be security concerns.  S may 
want to verify that the response is coming from an expected JID by perhaps 
keeping a map of communication pairs (so 123->(A,B)).  S may also want 
to use a cryptographically secure random number generator to assign the IDs to 
further prevent spoofing (so that X can't send a message to A through 
S).<br><br>Because this technique is easy enough to implement, I really don't 
think that we need to require the jingle stanza in 
responses/errors.<br><br>Joe<br><br>
<div><span class="gmail_quote">On 2/14/06, <b class="gmail_sendername">Peter 
Saint-Andre</b> <<a href="mailto:stpeter@jabber.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">stpeter@jabber.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-----BEGIN 
  PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>In XMPP, you track packets based 
  on the 'id' attribute. However, those<br>are generated by a client. If an 
  intermediary (such as Asterisk) wants<br>to keep track of all the Jingle 
  traffic flowing around, it may want <br>something more advanced. Many 
  Jingle-related stanzas include a <jingle/><br>child element with a 
  session ID ('sid') attribute. However, that does<br>not normally apply to 
  IQ-results and IQ-errors because RFC 3920 says <br>it's optional to include 
  the original child element(s) when sending IQ<br>stanzas of type "result" and 
  "error". While it might be nice for<br>intermediaries to have that 'sid' on 
  each and every stanza, it would get <br>quite verbose. I think we probably 
  have the 'sid' on the packets that<br>matter, but discussion is welcome from 
  implementors on the topic.<br><br>Peter<br><br>- --<br>Peter 
  Saint-Andre<br>Jabber Software Foundation<br><a href="http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.jabber.org%2Fpeople%2Fstpeter.shtml" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.jabber.org/people/stpeter.shtml
</a><br><br>-----BEGIN 
  PGP SIGNATURE-----<br>Version: GnuPG v1.4.1 (Darwin)<br>Comment: Using GnuPG 
  with Mozilla - <a href="http://www.google.com/url?sa=D&q=http%3A%2F%2Fenigmail.mozdev.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://enigmail.mozdev.org</a><br><br>iD8DBQFD8iuRNF1RSzyt3NURAhE1AJwJVzA4ZDjM/AgIbw6wyhjBVxbO3ACg2lHR
<br>CTmum6X1NMqXcdXTlNtaW2U=<br>=z0dL<br>-----END 
  PGP SIGNATURE-----<br><br><br></blockquote></div><br>

</span></div></blockquote></div><br>