[standards-jig] JEP 65 - Bytestreams

Thomas Muldowney temas at box5.net
Fri Dec 20 02:05:42 UTC 2002

On Fri, Dec 20, 2002 at 01:59:04AM +0100, Tijl Houtbeckers wrote:
> Ben Schumacher <ben at blahr.com> wrote on 20-12-2002 0:55:07:
> >
> >Hash: SHA1
> >
> >The 'connect in both directions simultaneously' mechanism does not
> >ensure that the TCP connection sets up quickly, just like Diz said.
> >Actually, on low bandwidth connections (maybe even the hardware in
> >embedded systems -- I don't have enough experience with these), I
> >wouldn't be surprised if it slows down the amount of time it takes to
> >establish a TCP connection.
> Many embedded systems will prefer to set up a bytestream inband cause 
> of this overhead. Neither JEPs address this but at least DTCP doesn't 
> claim to be "A protocol for establishing bytestreams between any two 
> Jabber entities.". JEP-0065 is *not* a generic way of setting up 
> bytestreams, just bytestreams over sockets. IMHO the JEP should reflect 
> this! It should be changed to SOCKS5 based, socket based or TCP based 
> bytestreams. 

This is understandable and I'm sure diz could make this more clear.

> >
> >|
> >| No safety system can provide any guarantee that people survive a car
> >| accident. But cars contain airbags and even much more complex 
> >systems, | which make a car more difficult to 'implement'...
> >
> >I don't understand your logic, or Justin's, for that matter. You have
> >both regularly stated that DTCP is an easier protocol to implement, yet
> >you continually reject complaints from *client developers* that 
> >disagree (namely, PGM and DizzyD).
> 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 =)

> >| In the end, this is a philosophical question - we could argue 
> >endlessly | if it's more important to have a nice protocol, or if we 
> >should | sacrifice some elegance in favor of people with broken setups.
> >| So let's not hold up adoption of a standard because of this issue.
> >
> >I agree. I say let both JEPs move forward as they are (as PSA has
> >already proposed), and let the council decided ultimately which JEP 
> >they feel is the more technically sound solution.
> 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20021219/f22a3807/attachment.sig>

More information about the Standards mailing list