[standards-jig] JEP 65 - Bytestreams

Peter Saint-Andre stpeter at jabber.org
Wed Dec 18 17:46:21 UTC 2002


As JEP Editor, I cleave to several principles:

1. Competition is good -- this is a free marketplace of ideas, and
competing JEPs usually result in better protocols

2. There is no rush -- the main priority is to develop technically strong
standards, because we will be living with these protocols for a long time

3. Protocol matters -- not the existence of implementations

4. Process matters -- in particular, the Council has final say regarding the protocol

That said, I move on to particulars (don your asbestos suits)...

On Wed, 18 Dec 2002, Justin Karneges wrote:

> I understand the need to solve this problem, and there are various methods of 
> going about it.  Introducing a competing JEP while DTCP is in Last Call is 
> not going to get us a solution any faster though. 

See principle #1 above. Actually it seems to have moved the discussion along quite nicely. 

> It would be one thing if 
> DTCP were some informational draft, and JEP 65 was intended to replace it.  
> Instead, these are two specifications in direct competition of each other 
> (they do exactly the same thing), and this would likely only cause the 
> council to throw up their hands once they set to vote on JEP 46.

DTCP was introduced after JOBS. It was good to have multiple JEPs at that
point, since both proposals were strengthened. The same is happening now
with the changes introduced to JEP 46 since Diz introduced the SOCKS5 idea
and formalized it in JEP 65. Competition is good. May the best proposal
win.

> Having a differing opinion is fine, and I like how you've laid everything out 
> in JEP 65.  However, in the interest of everyone seeking a standard, I 
> suggest we combine our efforts into one JEP, particularly into DTCP so that 
> the council can vote on it "real soon now".  Peter should make an extension 
> to the Last Call, to give us more time to discuss.

An extension to the Last Call may or may not be appropriate, but with the
upcoming holidays I don't think that it will necessarily be useful to
extend the current Last Call by one or even two weeks (personally I'm
going to be absent much of that time, and I'm sure others will be
distracted as well). Farther along in this mail I propose a possible
solution, but it is up to the Council to weigh in on this issue and
resolve the impasse.

> Personally, I just want a standard already.  

See principle #2 above.

> I don't really see any problems 
> in your JEP 65, and had I not written JEP 46, I would probably use your spec 
> in my client.  However, back in May when I first investigated this topic, 
> there was no such JEP, and I had to come up with my own solution.  Your JEP 
> 65 actually reminds me of some early ideas I was kicking around for DTCP.  
> This is not to say anything bad about your JEP, but I do feel that DTCP may 
> be more optimized for the job.  After months of tweaking the specification 
> and my implementation, I believe I have come up with a solid solution.

Your beliefs are immaterial (see principle #4 above). What matters is the
opinion of the Council. Convincing technical arguments will need to be
made to the Council that one JEP or the other (or a hybrid) is the best
solution. The Council won't base their decision on your belief that your
spec "may be more optimized for the job", but on the technical strength of
the proposals presented to the Council.

> It is important to also consider that there are several implementations of 
> DTCP already: tkabber, imcom, psi.  

No, it is not important. See principle #3 above. What matters is the
strength of the technical solution.

Further, given the changes to JEP 46, are those implementations consistent
with your most recently posted version? Can we even say that they are
compliant implementations? And if so, what do they comply with as far as
the Council is concerned, since your most recent version has not been
sent through the JEP process, checked into CVS, or posted on the JSF
website? Documents posted on personal websites are not JEPs.

> As the author of the latter, I can say 
> that I would rather not change my specification a whole lot from the current 
> draft.

That is your problem, not the Council's.

> I can't speak for the others, but I would really like them to comment 
> (aleksey, casey?).  However, I don't think this should be construed as an act 
> of stubbornness.  True, DTCP is not a standard yet, but as I mentioned above, 
> it is also not 'informational' either.

All experimental protocols have the same status: experimental. They are
called that for a reason.

> That is, it is not waiting for a replacement.

Immaterial. You can't replace something that is experimental. But someone
can come up with a better protocol.

> If there are areas that need improvement, then there is no need 
> to throw out the entire specification when the existing one can simply be 
> improved.

Maybe, maybe not -- it all depends on the underlying strength of the proposal.

> I feel I have already come up with some nice solutions to the 
> critiques of DTCP (see my recent posts to this list), like for proxying, 
> which I was the most stubborn about initially.

Yes, and the improvements are a step in the right direction (as a result
of list discussion and the competing JEP). It's up to the Council to
decide which proposal is best (or to recommend a hybrid approach) based on
the requirements for bytestreaming.

> Now, getting to the actual specs themselves.  JEP 46 and 65 essentially do the 
> same thing.

They may attempt to solve the same problem, but they most pointedly do not
do the same thing. JEP 65 makes use of an IETF standard protocol -- JEP 46
invents its own. JEP 65 addresses the serious issue of ensuring safe and
consistent timing of the incoming and outgoing connections -- JEP 46
assumes that the sender and receiver will listen for incoming connections
and initiate outgoing connections simultaneously, which could result in
all manner of problems.

> The end goal is to have a TCP stream between two entities.  You 
> lay out some good points of 65:
> 
> > * Uses an IETF standard protocol for the out-band negotiation (SOCKS5)
> > * Supports proxied bytestreams
> 
> Now how do we make DTCP just as capable?  Consider this revision of my 
> document, which supports proxying:
> http://www.affinix.com/~justin/jep-0046.html
>
> This leaves the wire protocol, which is actually quite easy to change.  My 
> resistance to HTTP in earlier discussion is mainly because I felt it was 
> unnecessary syntax.  Your idea of using SOCKS seems like a better fit for an 
> arbitrary bytestream.

So do you plan to change JEP 46 to use SOCKS5?
 
> What do others think about the use of SOCKS ?  If there are developers not 
> satisified with the 'proprietary' DTCP handshake, would a SOCKS-based 
> protocol be interesting?  

It's not a question of interesting, it's a question of what is the best
solution. Why succumb to the Not Invented Here syndrome? Let's use what we
can from the IETF, W3C, etc. -- they have a lot more brilliant people
designing their protocols than we do and SOCKS5 has been around since
1996.

> As it stands, I still don't see the need to create 
> an entirely new specification, when we can just roll good ideas back into JEP 
> 46.  

Um, we already have an entirely new specification. It's called JEP 65. It
may be better than JEP 46. Why change JEP 46 when we already have a spec
that uses SOCKS5? What does it matter which JEP number gets approved? What
matters is the strength of the technical solution. JEP 46 proposes a new
wire protocol. JEP 65 proposes SOCKS. One is most likely better than the
other. Let the Council decide.

> SOCKS could very well be one of those good ideas, and Diz of course 
> would be credited.
>
> > Please consider this JEP as a candidate for a community driven standard.
> 
> This is fair, and I would be interested to see comments from other client 
> developers as well.  As stated above, I'm mostly interested in just getting a 
> capable spec, of which both of ours are, soon standardized.  Even though I 
> may prefer my spec, if everyone else prefers your spec then we'll go with 
> yours!  Very simple.
> 
> _PLEASE_ comment, people !  :)

I did. Be careful what you wish for. :)

As to a solution, I propose the following:

1. JEP 46 has changed enough (though outside the JEP process) during Last
Call that an extension to the Last Call (or another Last Call) is
appropriate. Given the impending holidays, I would prefer to let this Last
Call lapse and issue another one (after the discussion has settled down)
on or about January 6.

2. Let's not fold everything from JEP 65 into JEP 46 -- rather, let the
Standards-JIG discuss the two concurrently (as we've been doing quite
productively here) and let the Council weigh in. IMHO it would be
appropriate to issue a Last Call on JEP 65 concurrently with the second
Last Call on JEP 46 so that all technical merits could be discussed.

3. The concurrent Last Calls should result in a good consensus (from the
community and the Council) as to which proposal provides the best
technical solution for the requirements we have in this area (and indeed
it might be helpful for the Council to enunciate those requirements). Such
a consensus seems to have been emerging over the last week and it would be
silly to put a halt to that because the first Last Call is ending (putting
aside the question of whether that Last Call was premature, which I think
it was).

4. After the concurrent Last Calls, let the Council vote up or down on the
competing proposals. If all goes according to schedule, we could send
these JEPs to Council around January 17th and they could finish voting by
the end of January. That seems long enough to wait for a strong technical
solution. We've lacked a bytestreaming protocol for 3+ years now, a few
weeks' wait isn't the end of the world.

That's just a proposal -- I will encourage the Council to provide their
perspective as well so that we can solve this impasse.

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php





More information about the Standards mailing list