Re: [hybi] Process! was: [whatwg] HttpOnly cookie for WebSocket?

[Ian Fette (イアンフェッティ) <[e-mail]>]

I'm not saying "it's deployed so it's too late to make any changes." What I
am saying is that, from what I can see, things are in a very disfunctional
state. A simple question comes up and it's not clear who is responsible for
doing what, and how we actually move forward. That's what bothers me. I
could personally care less what the actual process ends up being, so long as
when a simple question gets asked it gets answered quickly and we can move
forward. That was not happening in this case.

As for "IETF is a proven process that has worked well in the past" -- I
think there are a number of things that have changed between when HTTP was
going through the IETF process and today. First, I really don't know how
much it matters anymore whether things have an official IETF stamp of
approval, so long as implementers agree on an interface. Second, I think the
dynamics (number of people with a significant stake in the game) are
different, as is the shift from a more research-oriented (DARPA and then big
research labs like Bell Labs etc) to industry-driven environment with
manufacturers / vendors / whatever coming out with new functionality. Third,
I think things today are moving much more quickly in terms of the pace of
innovation. Fourth, I think the number of people waiting on these
innovations is much larger (look at the number of users and the amount of
commerce / transactions going on in the Internet).

So, I guess all I'm trying to say is that I don't think "IETF has worked
before so it works now" is necessarily a great argument, in much the same
vein that "it's deployed so it's too late to make any changes" is a great
argument. There are legitimate pros of the IETF process, and I don't mean to
dismiss that, but I'm not willing to take "It worked for HTTP" as some sort
of gospel truth reason why it should work for WS.

If it works, great. If it doesn't, let's figure out some process that does
work.

-Ian

2010/1/28 Greg Wilkins <[e-mail]>

> Ian Fette (イアンフェッティ) wrote:
> > Instead, we are bogged down in politics.
>
> Work is proceeding on all fronts on the actual implementations,
> so I don't think we are bogged down.   Nobody is saying hold
> any releases for this.   In fact I think it will be good to
> get experience from wider usage of the protocol as it currently
> stands.
>
> But there are important issues to be discussed here and they
> should not be derided as just unproductive politics.
> Who will edit the specification document is a key question that
> needs to be answered (but probably not in the HttpOnly cookie
> thread).
>
> For me (and my company, project & community), I have a problem
> with the WhatWG process as it is not sufficiently open. It boils
> down to:
>
>  0) Ian has been appointed AFAICT by an industry consortium
>    of browser vendors.
>  1) you can talk all you like
>  2) but you have to convince Ian to change anything
>  3) you have to be prepared to be unhappy if you can't
>    convince Ian
>
> I don't mean to dis Ian or the whatwg and I understand they've
> done great work on HTML5.  But this is hardly the right
> process to standardize a protocol that will fundamentally
> affect the entire network infrastructure, with many components
> that cannot easily as easily updated as issuing a new point
> release on a browser.  I don't see how we can put 1 person
> (any person) as the sole final arbiter of such a important
> decisions.
>
> The IETF has a proven process for producing internet standards
> that the entire industry follow.    Why is websocket so special
> that it needs a different process?
>
>
> > If we can't figure out how to move forward on such a simple issue, it
> > seems to me that we are in an unworkable situation, and should probably
> > just continue the work in WHATWG through to a final spec, let
> > implementations settle for a while, and then hand it off to IETF for
> > refinement and finalization in a v2 spec... (my $0.02)
>
> I'm not a IETF process expert, but what I do know indicates
> that the IETF is just as unlikely to rubber stamp a V2 as they
> are to rubber stamp a V1.
>
> The whatwg is perfectly entitle to keep the specification
> under their own auspices, but if they want the specification
> to be given the gravitas of an official IETF document, then it
> has to be  exposed to the IETF process and achieve a rough
> consensus of all who are involved - including the whatwg.
>
> Delaying the IETF process to v2 is unlikely to change many
> of those voices from whom rough consensus is required.
> The "it's deploy now, so it's too late to change", is not
> a great argument to rely on.
>
> The whatwg has done a great job getting it this far,
> but I really think they should trust (and be involved in)
> the IETF process to take it to the next stage.
>
>
> regards
>
>
>
>
>
>