[standards-jig] JEP 65 - Bytestreams

Dave Smith dizzyd at jabber.org
Thu Dec 19 00:58:34 UTC 2002

Hash: SHA1

On Wednesday, Dec 18, 2002, at 16:57 America/Denver, Justin Karneges 

> 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 :)

As pgm noted, there needs to be finite set of states for a client to 
track -- we can at least represent those with JEP 65 -- JEP 46 is too 
generic to even attempt this mapping (as I've commented on 5 times 
now). Sweeping statements such as "Clients should be prepared for 
anything.." have no business being in a specification.

> 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 difference is that neither the Target or Initiator knows which 
connection to actually use in JEP 46. You can't simply say "the first 
connection". We live in a networked environment and any one of these 
connections may be "the first", depending on who you ask.

> 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.

I think the important, distinguishing point here is that 65 provides a 
mechanism for informing the Initiator what StreamHost was used for 
establishing a connection. This puts the onus of selecting one of 
several possible connections on the Target. The Initiator may certainly 
have to listen for connections from the Target, but it doesn't have to 
do anything meaningful with those connections until the Target informs 
it which connection is relevant. JEP 46 has no way to identify the 
connection the Target would prefer to use.

The other important point here is 65 does not _preclude_ you from 
making multiple connections, it just provides an ordered framework for 
doing so.

>> - JEP-65 also has fewer round-trip IQ packets (which is also easier to
>> implement).
> 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.

The funny thing here is that so far, I have yet to see _anyone_ say 
that they agree with your sentiment about JEP 46's complexity. Even the 
people who seconded the Last Call have noted that 65 is _less_ complex.

>> - 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
> 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).

Having a start-TLS in the stream doesn't make a whole lot of sense to 
me, either. It is not the responsibility of the bytestream layer to 
"simplify" the application protocol. That's assuming way too much about 
how the applications will be utilizing the bytestream. I would note 
that JEP 47 has little to no bearing on this issue (due to the fact 
that it is solving this of data transfer problem in a _completely_ 
different way) and as such should not be used as a reason to include an 
encryption layer.


Version: PGP 8.0 (Build 349) Beta


More information about the Standards mailing list