[standards-jig] JEP 65 - Bytestreams

Justin Karneges justin-jdev at affinix.com
Thu Dec 19 01:48:17 UTC 2002

On Wednesday 18 December 2002 04:58 pm, Dave Smith wrote:
> now). Sweeping statements such as "Clients should be prepared for
> anything.." have no business being in a specification.

True, I suppose it is a given when writing a server application.  I just threw 
it in there as a reminder.

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

This is not a problem in JEP-46.  The target and initiator have all of the 
information they need to make a decision about which connection is considered 
"the first".  After all, JEP-65, which can support multiple connections from 
one side, does not suffer from this problem either, does it?

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

Sure it does.  The target needs only to identify itself over the TCP channel.

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

And have they said this on the list?  Perhaps I missed them.  Even so, my 
"independent polling" of other developers has shown more preference to 
JEP-46.  IMO, we need to see some greater discussion on the list from other 
client developers before we can make any real assumption about what they 

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

Well, this can be argued either way.  I think it is a good idea to consider 
other stream protocols (ie, JEP-47) at the same time, so that we come up with 
solutions that work together.  However, in the interest of getting a 
standard, I am willing to go either way.


More information about the Standards mailing list