Re: [hybi] Issue tracker

Greg Wilkins wrote:
> On 23 May 2010 17:43, Scott Ferguson <ferg@caucho.com> wrote:
>   
>> Correct. It's clear the spec will not reflect the consensus.
>>     
>
> Scott,
>
> The fundamental problem is that Ian as editor of the draft does not
> appear willing to accept the consensus view if he thinks it contradicts his
> personal view of what is technically sound.  He  rejects the concept
> that technical soundness can be determined by rough consensus.
>
> As such, I do not believe that the IETF process can work  with Ian as editor.
>   
That is my concern.

The outstanding issues that I've been following fall into the following 
groupings:

1. simple but important issues that are easily resolvable:
1a. HTTP compliance and/or avoiding the HTTP port
1b. binary support
1c. binary fragmentation/chunking (required for 1b)

The above are all trivial and fixing them are important for WebSockets 
to have a broad application base, but progress has stalled for months 
because the editor opposes the necessary changes to the spec, despite 
the broad support and technical value.

2. RTT fixes/client pipelining

This group is tougher, but important because not fixing it restricts the 
classes of applications that can use WebSockets, making HTTP itself a 
better solution. However, any real discussion of this issue is stymied 
by the editors opposition (without any solid reason for opposition.)

3. multiplexing/server load/resource issues

Whether or not we want to treat multiplexing as an extension, part of 
the main spec, or not addressed at all, it's an issue that needs to be 
discussed and has been brought up repeatedly as an issue by most of the 
server vendors and by others. Yet, this issue is entirely ignored, 
mostly I think because if we can't even resolve no-brainer issues like 
HTTP compliance while using the HTTP port, there's no point discussing 
anything as complicated as a multiplexing extension.

4. server events and the associated long-lived connection problem

As Roy Fielding pointed out, we may want to broaden the discussion space 
for this topic beyond ideas like multiplexing (e.g. to discussion client 
accept() ports/callbacks, proxies, etc.) And the server-sent event topic 
is at the heart of making WebSockets work.  Yet, if we can't discuss #3 
because it's too complicated, we have no hope of opening up this discussion.

Oh, and also,

5. security

The "security" features in the current draft like the key1/key2 and the 
random bytes are absurd, but there's almost no point discussing them 
because, really, where do you start discussing something that confused?

All these topics can be addressed by this group, because we have the 
expertise collectively, but those discussions are stuck because it's 
clear that the specification itself will not reflect any consensus.

-- Scott
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>   