<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Agreed.  Although I have not had significant time to read the jeps
fully. <br>
    The point about TCP timeouts would be an issue, considering the
variance in timeout delays between clients and os's... To the end-user,
a 1+ minute wait before the transmission even starts would probably put
the user off from using file transfer in the client...   <br>
<br>
Ill keep an eye on this thread, and reply with some content once I have
had time to read and compare both jeps in full...<br>
<br>
-Dan<br>
<br>
Justin Karneges wrote:<br>
<blockquote type="cite"
 cite="mid200212181557.48125.justin-jdev@affinix.com">
  <pre wrap="">Hi pgm / psa,

Thank you for your long replies.  I agree with nearly everything that has been 
said.

  </pre>
  <blockquote type="cite">
    <pre wrap="">- I still have issues w/ the chaos of mutliple entities attempting multiple
connections at once.. If we change that, than what we have left is
basically JEP-65. Specifically, this sentence, REALLY scares me about
implementations: "As such, clients that are listening for connections
should be prepared for anything."
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This seems to be the major difference in operation between the two JEPs.  
However, I think this is not as chaotic as it may appear.

Both JEP-46 and JEP-65:

1) Do not require a client or server implementation, but should have at least 
one of them. :)
2) When acting as a server, the application SHOULD be able to handle multiple 
simultaneous connections.
3) When acting as a client, the application MAY connect to multiple hosts at 
once of the same peer.  This is optional in both JEPs, there is nothing for 
or against it.
4) Clients should be prepared for anything :)

In other words, JEP-65 has the same chaos.  What JEP-46 allows is for both 
sides to connect to each other at the same time, which is something your 
application would need to handle anyway, at least for connections of separate 
contexts.  What difference does it make if they are in the same context?

The benefit of connecting at the same time is that the existence of NATs 
should not affect the speed at which a connection can be made.  So forming a 
DTCP connection should not take much longer than a normal TCP connect.  With 
JEP-65, there could be a delay of at least one TCP connect timeout (often 
nearly a minute, quite significant) when the original initiator is behind 
NAT, and possibly more if a client does not connect to multiple hosts at 
once.

  </pre>
  <blockquote type="cite">
    <pre wrap="">- JEP-65 also has fewer round-trip IQ packets (which is also easier to
implement).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I don't think JEP-46 is any more complex.  There is just a single round-trip 
iq-set/result, with a possible one-way iq-error.  There is more involved if a 
proxy is used, but that is even the case with JEP-65, and should be expected.

  </pre>
  <blockquote type="cite">
    <pre wrap="">- JEP-46 specifies a <ssl/> identifier. IMO, this is outside the scope of a
bytestream... if the protocol I want to use supports SSL, then maybe I use
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The idea here is that I wanted to simplify the application layer.  HTTP, for 
instance, has no support for "start-TLS" that I am aware of.  This means that 
either the stream spec or FT spec is going to have to take care of TLS, and I 
prefer doing it in the stream.  This is also a more sensible path when you 
consider alternative bytestreams, like JEP-47, which would provide its own 
encryption layer (XES or what-not).

  </pre>
  <blockquote type="cite">
    <pre wrap="">If another existing JEP has consensus (note that consensus != unanimous) in
the community, then thats the JEP that should move forward, and all other
JEPs which are trying to solve the problem should be withdrawn IMO. I think
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes, I agree.

-Justin

_______________________________________________
Standards-JIG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Standards-JIG@jabber.org">Standards-JIG@jabber.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.jabber.org/listinfo/standards-jig">http://mailman.jabber.org/listinfo/standards-jig</a>
  </pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<p><b><font face="Arial, Helvetica, sans-serif">• Daniel Chote</font></b><font
 face="Arial, Helvetica, sans-serif"><br>
email/jabber: <a class="moz-txt-link-abbreviated" href="mailto:daniel@chote.net">daniel@chote.net</a><br>
web: <a class="moz-txt-link-abbreviated" href="http://www.chote.net">www.chote.net</a></font></p>
</div>
</body>
</html>