Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

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

On Thu, Sep 2, 2010 at 10:31 AM, Olli Pettay <[e-mail]>wrote:

> On 09/02/2010 07:53 PM, Ian Fette (イアンフェッティ) wrote:
>
>> On Thu, Sep 2, 2010 at 7:18 AM, Olli Pettay <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>    On 09/02/2010 02:37 AM, Ian Fette (イアンフェッティ) wrote:
>>
>>        +1. Adam, I share your concerns about versions on the web, but the
>>        reality is there is no other way right now. Suggestions welcome
>>        as to
>>        alternatives.
>>
>>
>>    Couldn't web applications use different subprotocols for different
>>    versions of the web socket protocol.
>>    That wouldn't be the nicest solution, but could work
>>    well enough while we're trying to get some stable protocol.
>>
>>
>>    -Olli
>>
>>
>>    (I haven't read properly the current draft, but the framing looks too
>>      complicated. I'll send comments once I've reviewed the draft
>>    properly.)
>>
>>
>>
>>
>> Subprotocols are intended to be an application level indication, and IMO
>> should affect base framing. This seems to be conflating issues.
>>
>
> I understand what subprotocols are meant for, but while we're trying to
> stabilize the protocol, subprotocols could be used for versioning too.
>
>
>
>
>> Also, in addition to reviewing the draft, I would ask that you try to
>> review the comments that led up the draft being what it is, otherwise we
>> are likely to just revisit old discussions.
>>
>
> Yeah, I know that there is a risk that I will complain about things what
> others have complained too, and what others like about.
> In general it is not clear to me why we have to change framing so much.
> The old hixie-style framing allow all sorts for extensions. There are
> plenty of bits left for different kinds of frame types.
>
>

I really suggest you read the archive before trying to re-hash debates that
have gone on for hundreds of email messages


> (And for things like multiplexing shared workers some
>  people have just said that it doesn't work without even trying.)
>
>
> -Olli
>
>
>
>>
>>
>>
>>        On Sep 1, 2010 4:27 PM, "John Tamplin" <[e-mail]
>>        <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>         > On Wed, Sep 1, 2010 at 7:18 PM, Greg Wilkins
>>        <[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>         >> my proposal was not to add versioning to the protocol - as I
>>        know some
>>         >> think it is an anti pattern.
>>         >>
>>         >> I just want to be able to implement the next draft without
>>        breaking
>>         >> all my users that have been working on the last draft.   So my
>>         >> proposal is only for a draft version to be added by
>>        implementers as
>>         >> non-standard convenience at this time. The lack of a draft
>>        version can
>>         >> be taken to mean the final stable version.
>>         >>
>>         >> How else do you expect servers to track the drafts and deal
>>        with the
>>         >> various browser implementations out there?
>>         >
>>         > The problem is that the framing of v75, v76, v00, and v01 are
>>         > incompatible. If you want to write a server that
>>        interoperates with
>>         > browsers implementing these drafts (I know at least v75 and
>>        v76 are in
>>         > the wild), then you have to rely on heuristics to figure out
>>        which one
>>         > you are talking to. Even if there isn't a version in the 1.0
>>        spec,
>>         > any attempt to get real-world data while the spec is changing
>>        means
>>         > you either have a version number or you heuristically
>>        determine one --
>>         > the latter is obviously more prone to error.
>>         >
>>         > I would suggest adding Sec-WebSocket-Draft: 01 to
>>        implementations of
>>         > this draft, and that header will only be present before the
>>        spec is
>>         > finalized.
>>         >
>>         > --
>>         > John A. Tamplin
>>         > Software Engineer (GWT), Google
>>         > _______________________________________________
>>         > hybi mailing list
>>         > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>
>>        <mailto:[e-mail]>>
>>
>>         > https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>>
>>        _______________________________________________
>>        hybi mailing list
>>        [e-mail] <mailto:[e-mail]>
>>        https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>>
>>
>