Re: [hybi] Process, was: Technical feedback. was: Process!

[Maciej Stachowiak <[e-mail]>]

On Jan 31, 2010, at 12:16 AM, Greg Wilkins wrote:

> Maciej Stachowiak wrote:
> 
>> I think you have raised some valid issues, and I personally think they should be addressed 
>> (if not in 1.0 of the protocol, at least understand how a later protocol revision could handle it).
>> However, I must admit that some of your comments sound like handwaving that assumes the solution
>> without clearly stating the problem. For example, when you talk about the problem of figuring
>> out your idle timeout, it seems like the problem statement is very clear. Whenever you talk
>> about the desire to have arbitrary metadata, I haven't seen you clearly relate that back to a
>> specific use case or concrete problem to be solved. I can see why feedback of that second sort
>> might not get much of a hearing. I think if you focus on concrete problems you have run into
>> as an implementor, you will have much better luck.
> 
> Maciej,
> 
> I think that is a pretty unfair comment.
> 
> I've not provided much detail this time around because the points have been
> made so many times before.

Like I said, I think some of your points are really good. But the ones where you don't give a clear grounding in use cases or concrete problems to be solved read to me like you've assumed the solution. 

> I have previously provided many lengthy detailed discussions about these
> points.  I have proposed several concrete enhancements to websocket, I've
> blogged at length about some other ways to improve websocket
> 
>  http://blogs.webtide.com/gregw/entry/how_to_improve_websocket

I just read that post, and I don't see any concrete use cases for arbitrary metadata. You give some reasonable arguments for specifying a MIME type, but leap from there to arbitrary name/value fields. I did not see any connecting logic.

To me it seems that transfer encoding (or similar) information might be useful if the UA, rather than the JS client, is expected to do some processing, otherwise, you can just as easily define it by convention for a subprotocol to run over WebSocket. WebSocket does have a way to identify a subprotocol, and that seems like a sufficient hook to define subprotocols with per-frame metadata. If you want to promote going further, I'd like to hear the concrete use case or problem that would be addressed by having the functionality at the protocol level.

I should note that I'm not personally against open-ended metadata fields. It has certainly worked well for HTTP, and enabled us to enhance the protocol after the fact in many ways. But I don't feel like I can make a case for include it in the base protocol based solely on design taste, so I'd like to know what problems it solves. As you may have seen on other issues, if you give convincing use cases, then I at least will back you up. (I hope other implementors are still reading some of these subthreads and will make their own evaluations.)

> 
> and I've even drafted two versions of an alternative protocol BWTP
> that has gained some interest:
> 
>  http://www.ietf.org/id/draft-wilkins-hybi-bwtp-00.txt
>  http://bwtp.wikidot.com/
> 
> There are two implementations of BWTP available.

I appreciate that you've spent considerable time designing, implementing and promoting a different protocol. That's good technical work, and a useful exploration. But that does not answer the question of why particular features are required.

> 
> I've got deployed comet services with millions of users and am happy to
> answer any questions asked about my experiences or comments expressed here.
> 
> There has been plenty of support expressed on this list for the issues
> raised and plenty of other issues raised by others on this list as well.
> 
> This is not hand waiving.

I apologize for using overly judgmental language. Let me try to state it in more neutral terms: In some cases, you seem to be pushing some preferred design approaches without presenting a clear grounding in concrete use cases. Now that you have taken a shot at implementing the WebSocket protocol on the server side, I think your feedback is enormously valuable. But I find it much more useful when it is grounded in concrete problems that you tried to solve, but could not. If you've given clear use cases for some of the features you advocate before, then great.

> 
>>> Hence my strong words against the WHATWG process.  It has disenfranchised a
>>> significant part of the internet community and is not addressing the concerns
>>> that are being raised.
>> 
>> Now you have the opportunity to discuss these things under the IETF process. Go for it.
> 
> Well perhaps you are correct.
> We should treat this a day 0 and start again and restate the problems, requirements
> etc.  I do believe this is exactly the schedule outlined in the charter - which has
> now been questioned by the WHATWG.

Here's the kind of requirements information what would be useful to me as a browser implementor:

- Are there details of WebSocket that would hamper deployment, or fail to solve some problems in the way comet is done today?

- Are these things that could reasonably be fixed in a future revision of the protocol, or do they need to be addressed in 1.0? (One thing that concerns me about the latter is the lack of versioning in the WebSocket protocol - if we solve some problems later by introducing new frame types, then how can you tell if the party at the other end understands those new frame types? We need some way for a client and server to be able to negotiate use of WebSocket 2.0 while still interoperating with endpoints that only speak 1.0. I'd like to understand the story for this before we push wide deployment.)

- For the problems that aren't solved, are there reasonable solutions that can plausibly address the issue? (Note: solutions that assume all intermediaries have to change before the WebSocket protocol can be used at all do not seem viable to me, but the ability for intermediaries to optionally opt in seems like a reasonable approach.) I'm particularly concerned about the fact that all early deployment is likely to be over SSL (since that is probably your only option for going through unmodified proxies), but a lot of the solutions we have discussed for intermediaries to participate do not work with SSL.

That's the kind of information that will help us client-side implementors know if there are critical things to fix before promoting wide deployment.

> 
>> It seems plausible that we may need a revision of the protocol down the line. But 
>> I think that developing the two versions in two separate standards organizations,
>> and doing so simultaneously and without trying to agree together on the right
>> outcome, is not likely to lead to a coherent outcome.
> 
> The WHATWG have not expressed any interest in further extending the protocol.
> They say their current goal is to achieve interoperability, which I assume means
> solving  any ambiguities of misunderstandings of the current document.
> 
> If that truly is their only current objective, then don't see a particular
> problem if the IETF moves forward with proposals/discussion/consideration of
> how to improve websocket to deal with issues like orderly close and idle
> timeouts.  Of course coordination will be required and the whatwg need to
> be part of any consensus on new features.

If we're thinking about two protocol versions, then ideally I'd like to see both groups collaborate on both. If we identify any true showstopper issues in the 1.0 protocol, then I at least would like to see them fixed before it is too late. To me a showstopper issue would be one that completely prevents deployment in a common situation, or that precludes solving a problem in a future protocol revision.

Regards,
Macie