[standards-jig] JEP 65 - Bytestreams

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Thu Dec 19 03:16:11 UTC 2002


I'm effectively dropping JEP-0042 in it's current manifestation, because
this makes more sense, and can accomodate JOBS' additional functionality
with addtional layers (on top of this).  I might introduce JOBS again,
but as an application of this and other protocols, but at this time, I
have "seeing the light" and am supporting this proposal.

That said, let's get on to the replies...

On Wed, 2002-12-18 at 17:48, Justin Karneges wrote:
> 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.

"Clients should be prepared for anything" should *NEVER* be a valid
condition.  Being prepared for anything means we are subject to chaos. 
This is what specifications do; they remove as much of the chaos as
possible.

(highly-theoretical math) Adding chaos generally makes things worse, not
better.  In my opinion, by stating that chaos is expected means this
specification has failed its purpose.

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

>From my own reading, I can't figure out which is "first".  If you have
multiple connections attempted simultaneously, one client might pick
"connection A" first (since that's how their machine's process scheduler
came about), while "connection B" is first for the other.  So...which
one is actually first?

Now, if you're single-threaded here...oh, wait.  If you're
single-threaded, you end up doing each connection serially. But now
you're hoping for a certain behavior from an implementation without
specifying what that expected behavior is...which leads to chaos.

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

And which TCP channel is that?  If you start multiple connections at the
same time, you'll probably run into the problem above; each client is
connected on different "channel" (host/port), so which one is really
right?  Reliance on (one of) the OOB-side to correctly identify the
connection is likely to result in chaos.

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

Peter Millard stated this, Thomas Muldowny agreed with him, and now I'll
say it:  This is a lot less complex than DTCP.

The possible states for bytestream are small, and the transitions are
clearly-defined.  This is not the case with DTCP, especially so with
"clients need to be prepared for anything" as part of the proposal. 
Being small in words makes one simple not.  It usually leads to chaos,
because not all of the states, transitions, and conditions have been
clearly outlined.

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

I would not start considering TLS at the wire-level (which we're at
now), because the applications (read: what you want to do with this, not
the client that implements it) of specs like these need to agree that it
makes sense.  Just tossing features into a pot usually leads to chaos.


PS:  RFC-2817 documents an alternative method of using TLS with HTTP/1.1

-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)




More information about the Standards mailing list