[standards-jig] JEP 65 - Bytestreams

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Dec 20 14:16:57 UTC 2002

Thomas Muldowney <temas at box5.net> wrote on 20-12-2002 3:05:42:
>> Well, I'm not sure about Jan actually, but I'm "pretty convinced" 
>> that Justin is a very capable client developer. Without Psi I doubt 
>> I would be using Jabber on any desktop system. Let's not get down to 
>> the point where we have to start saying "but I'm a client 
>> developer!" cause I am a client developer too, maybe you are, and 
>> I'm sure that so are many many more on this list. 
>Let's not take this over the top.  Let's stay on the protocol =)

Exactly my proposal :)

>> Then let the council note that DTCP set out to solve (among other 
>> things) the situation where 1 peer is behind a NAT, since this is 
>> one of the most common problems concerning filetransfer, and that 
>> JEP65 addresses this (very) poorly compared DTCP. And should JEP65 
>> be accepted without addressing this problem correctly than we're 
>> still left with this problem, and we'll still need for a standard 
>> for it. Also let the council be aware that neither JEP solves the 
>> problem of setting up a generic bytestream ;) 
>> -- 
>> Tijl Houtbeckers
>> Java/J2ME/GPRS Software Engineer @ Splendo
>> The Netherlands
>As it stands (from a rough count of hands raised) the council would go
>with bytestreams, but I honestly don't want to vote on something that
>people are still arguing about.  Especially if someone has a good 
>point. Now, you suggest that -65 "(very) poorly" handles one side 
>being NATted. Could you expand on this?  I'm not sure I see where that 
>comment is coming from, but if it is founded, we don't need a vote yet.

Exactly what has been discussed. Both JEPs were created with 
filetransfer in mind, though other uses could be thought of. In the 
real world people won't have their NAT/firewall configured properly (or 
won't have acces to it). In the real world clients won't know if they 
are behind a NAT or firewall, and in the real world people won't wait 
much longer then 30 seconds for their transfer to start. 

Your could add to that, in the real world (many) people won't run an 
open proxy like that. Considered could be making the proxy a jabber 
component, but this would ofcourse be a big change, both in 
implementation and thinking. 

Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list