Subject: [hybi] Resolving Issue 11 - Amateur programmer requirement [was: Extensibility mechanisms?]

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 22 Jul 2010 13:34:52 -0700

http://trac.tools.ietf.org/wg/hybi/trac/ticket/11 has been opened, and I'm
glad to see this explicitly tracked. It seems like we have a divergence of
objectives. Hixie has stated he wants to "[write] a protocol that
amateur programmers can implement easily." Many others on this thread have
shared their own opinion, and then the thread turned again to other topics.

Maciej referenced http://tools.ietf.org/html/rfc2026 and
http://tools.ietf.org/html/rfc4677 as specifying how such disputes are to be
resolved.

4677 seems to indicate that voting isn't the way to go, but instead the
chairs should direct the group towards rough consensus. I'm not sure we will
ever make everyone happy, but given the number of +1's on the thread I am
hopeful we might have "rough consensus" and make a large number of people
happy on resolving this issue. Are the chairs comfortable in declaring rough
consensus on this issue?

If not, looking at 6.5 of 2026 it seems to indicate that the Area Director
acts as an arbiter when the group / chairs cannot bring the group to rough
consensus. How do we move forward on this?

I think it is important that this issue get resolved, as many other issues
are ultimately coming back to this one after some amount of discussion, and
so while we've taken the first step of noting it as an issue, now we need to
resolve it. Leaving it open for any period of time I don't think is going to
help.

Apologies for forking the thread, but having a discussion in the middle of a
centi-thread that encompasses multiple conversations seems fraught with
perils of things getting lost.

-Ian

---------- Forwarded message ----------
From: Mike Belshe <[email-masked]>
Date: Tue, Jul 20, 2010 at 4:10 PM
Subject: Re: [hybi] Extensibility mechanisms?
To: Ian Hickson <[email-masked]>
Cc: Hybi <[email-masked]>

On Tue, Jul 20, 2010 at 3:14 PM, Ian Hickson <[email-masked]> wrote:

>
> (By the way, I spoke to Joe and he suggested that I post an e-mail to each
> thread to which I was replying, rather than replying to all threads in one
> bulk e-mail or replying to all the e-mails I'm replying to individually. I
> hope this compromise works for everyone; I know there was some controversy
> when I replied in bulk a few months ago. I apologise in advance if this
> causes a spike in traffic to the list.)
>
> On Mon, 19 Apr 2010, Roberto Peon wrote:
> > On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke wrote:
> > > > On 19.04.2010 10:48, Ian Hickson wrote:
> > > > >
> > > > > There are many many implementations of HTTP. Some fast, some not
> > > > > so.  Some complete, some not so.
> > > >
> > > > I think we can get orders of magnitude more complete implementations
> > > > of Web Sockets than of HTTP if we keep the protocol trivial.
> > >
> > > Yes. That's a given. Make it less complex, and it will be easier to
> > > completely implement.
> >
> > This isn't true! Make it (the protocol) less complex and it will be easy
> > to implement something which *conforms to the spec*, but not necessarily
> > something which scales and is robust, reliable, and scalable in the face
> > of all the stuff that happens out there.
>
> Not all implementations have to scale to a million QPS or withstand DDOS
> attacks for weeks at a time. Most implementations of Web Sockets will
> likely be for small amateur projects that are lucky if they average 1 QPH,
> let alone 1 QPS.
>
>
> > The latter part is what really worries me. We really need to be sure
> > that the protocol that we create allows for an implementation of a
> > server to do these things.
>
> I agree that we shouldn't make the protocol impossible to scale. If there
> are specific features in the protocol that make it impossible to scale,
> please do raise these as issues. However, one doesn't have to make a
> protocol complex to make it scale.
>
>
> > If the (hopefully small) added complexity is too much for the amateur
> > programmer, then they should use the API level.
>
> What I'm interested in personally is writing a protocol that amateur
> programmers can implement easily. If we say they have to use someone
> else's code to do this, then that's a failure, IMHO. (Though as I've
> mentioned before, if people have different goals or priorities, I have no
> problem with separate protocols also being designed to address those --
> Web Sockets doesn't have to be everything for everybody.)
>

For as adamantly as Ian states that it should be a requirement, I am just as
adamant that it should not.

But more importantly, this single issue has been holding protocol progress
hostage.  Naturally, any feature has some amount of complexity.   But this
requirement creates an invisible, and subjective barrier to each feature.
 Is the feature too complex for an amateur programmer?  Nobody knows, and
everyone disagrees, because it is a subjective criteria.  So we spin and
can't agree.

Every protocol expert I've spoken with agrees that amateur protocol
implementors should not be a requirement.

Is there some way we can vote to either keep or nullify this requirement now
and never come back to it again?  I'm tired of this obstacle holding
everything up.

Mike

>
> --
>
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

_______________________________________________
hybi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hybi

---

From: Robert Sayre <[email-masked]>
Date: Thu, 22 Jul 2010 20:02:23 -0700 (PDT)

----- Original Message -----
> 
> 4677 seems to indicate that voting isn't the way to go, but instead
> the chairs should direct the group towards rough consensus. I'm not
> sure we will ever make everyone happy, but given the number of +1's on
> the thread I am hopeful we might have "rough consensus" and make a
> large number of people happy on resolving this issue. Are the chairs
> comfortable in declaring rough consensus on this issue?
> 
> 
> If not, looking at 6.5 of 2026 it seems to indicate that the Area
> Director acts as an arbiter when the group / chairs cannot bring the
> group to rough consensus. How do we move forward on this?

It is better for the WG to just handle it. Those provisions are basically failure states.

> 
> 
> I think it is important that this issue get resolved

Well, I'm not sure. The "amateur programmer" is a pretty terrible construct.

It's unmeasurable and untestable, so it makes no sense as a requirement. The only way to find out whether hobbyists will be interested in writing servers is to finish the standard and see what they do. It's ultimately not that interesting though--many successful standards have relatively few implementations that everyone relies on.

Any argument for simplicity probably has a better rationale than the needs of an imaginary "amateur programmer." Let's stick to substance.

- Rob

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 22 Jul 2010 21:50:08 -0700

The amateur programmer argument keeps coming up. Search google for hybi
amateur programmer. It's been raised as an argument against suggestions that
are meant to help the protocol scale, it's been raised in discussions of
keepalives, it's been raised in multiple framing discussions... I'm not
arguing it's a great construct. I don't actually agree that we should be
designing for an amateur programmer. What I'm saying is that I do believe
that this issue being outstanding is preventing further progress on other
issues, so I want to see it put to rest.

On Thu, Jul 22, 2010 at 8:02 PM, Robert Sayre <[email-masked]> wrote:

> It's unmeasurable and untestable, so it makes no sense as a requirement.
> The only way to find out whether hobbyists will be interested in writing
> servers is to finish the standard and see what they do. It's ultimately not
> that interesting though--many successful standards have relatively few
> implementations that everyone relies on.
>
> Any argument for simplicity probably has a better rationale than the needs
> of an imaginary "amateur programmer." Let's stick to substance.
>
> - Rob
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Jul 2010 07:55:06 +0200

On 23.07.2010 06:50, Ian Fette (イアンフェッティ) wrote:
> amateur programmer. It's been raised as an argument against suggestions
> that are meant to help the protocol scale, it's been raised in
> discussions of keepalives, it's been raised in multiple framing
> discussions... I'm not arguing it's a great construct. I don't actually
> agree that we should be designing for an amateur programmer. What I'm
> saying is that I do believe that this issue being outstanding is
> preventing further progress on other issues, so I want to see it put to
> rest.
> ...

+1

---

From: <[email-masked]>
Date: Fri, 23 Jul 2010 09:07:09 +0100

Do we have an issue open about amateur protocol designers and amateur editors?
amateur chairs?

---

From: Pieter Hintjens <[email-masked]>
Date: Fri, 23 Jul 2010 10:38:21 +0200

> Any argument for simplicity probably has a better rationale than the needs of an imaginary "amateur programmer." Let's stick to substance.

Indeed.  That requirement by itself makes some serious unproven assumptions.

* First, that amateur programmers are somehow lacking in knowledge and
experience.  Many people program for fun, as amateurs, but with years
or decades of professional experience.  If we want to make the
protocol accessible to programmers with less than a year or so of
practical experience, let's say so explicitly.  "WebSockets must be
comprehensible for programmers with less than 12 months of
experience".

* Second, that explaining the protocol in baby steps and using
dumbed-down constructs is easier to understand, for programmers with
more or less experience.  That is patronising and makes no sense.  Are
we trying to address programmers with lower IQs rather than less
experience?  Then we should say so explicitly.  "WebSockets must be
comprehensible for programmers with IQs of 90".

* Third, that this pandering to the weak-minded correlates with
simplicity, while building a protocol for smarter programmers with
sufficient experience ("professionals", to continue this nasty use of
language), correlates to complexity.  No, simplicity comes from
reusing experience and doing it *right*, and that requires massive
experience, which is why organisations like the IETF exist.

* Fourth, that making a protocol accessible to inexperienced, less
intelligent programmers will ensure its success.  That suggests that
the successful protocols of the world were build by inexperienced
idiots, which would be insulting if it was not so obviously taken from
The Onion.  "Schoolkid (5) invents Internet 2, sells to Google for
$50bn".

I'm not sure whether it's more tragic to consider this requirement as
"serious editorial input", or as a sophisticated troll.

If the goal is to achieve wide implementation, the protocol should be
clearly written so that experienced, smart programmers can implement
it without shock or surprise, and build interoperable stacks that work
as expected.  That might make a concrete requirement.

Here are some Twitter comments I found from one (smart and
experienced) developer implementing server-side support for
WebSockets:

* "No! You idiots, do not make HTTP headers in WebSockets *unicode*
when HTTP itself is not: http://is.gd/dz13m  Protocol layers do not
need it!"
* "Putting crap between 0x00 and 0xFF characters is NOT FRAMING:
http://is.gd/dz13m  A frame has a size component so you can send
binary data."
* "Ok, if you've written forty-five (!) steps for how a *client*
connects a WebSocket then you should realize you need to redesign
something."

-Pieter

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 23 Jul 2010 10:52:14 +0200

On Fri, Jul 23, 2010 at 07:55:06AM +0200, Julian Reschke wrote:
> On 23.07.2010 06:50, Ian Fette (????????????????????????) wrote:

+1

Also, IMHO there's a contradiction between the fact that we're trying to
do our best to ensure that the protocol prevents any form of cross-proto
attacks, and the protocol is easily implementable by "amateurs" (which I
parse as "the guys who want a quick and dirty implementation and who
don't mind about small side effects as long as it works").

I think that most of the ML subscribers have already written in a hurry
very simple shell script based web servers to be run from inetd and
which did not care about the method, "../" in file names, permissions,
keep-alive, content-length, etc... This is exactly what is permitted by
the simplicity of the HTTP protocol : easy, possibly incomplete and
possibly insecure implementations for amateurs.

If we want amateurs to be able to make full and complete implementations
of WS, then we'll always be limited in the features and security level
(and we'll never agree on what the amater is able to do). If we define
an extensible protocol that amateurs can implement partially because
they only care about the most common denominator, then we have no
problem adding new features and improving security.

While HTTP talks about "implementations", meaning that everyone might
implement a different subset of it, WS seems to focus only on one way
to get it right. This strict view is probably what will finally make
it hard for amateurs to implement it right !

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Jul 2010 11:19:44 +0200

> The Onion.  "Schoolkid (5) invents Internet 2, sells to Google for

+1. Protocol design is not simple (e.g., <http://research.sun.com/techrep/1994/smli_tr-94-29.pdf>*), and making it "easy" by exposing low-level constructs without any guidance seems to be the very definition of an attractive nuisance.

* Kudos to Oracle for putting a proper redirect in place, even if they are getting rid of old Sun URIs :(

--
Mark Nottingham     http://www.mnot.net/

---

From: James Graham <[email-masked]>
Date: Fri, 23 Jul 2010 11:55:55 +0200

On 07/23/2010 10:38 AM, Pieter Hintjens wrote:
> On Fri, Jul 23, 2010 at 5:02 AM, Robert Sayre<[email-masked]>
> wrote:
>
>> It's unmeasurable and untestable, so it makes no sense as a
>> requirement. The only way to find out whether hobbyists will be
>> interested in writing servers is to finish the standard and see
>> what they do. It's ultimately not that interesting though--many
>> successful standards have relatively few implementations that
>> everyone relies on.
>>
>> Any argument for simplicity probably has a better rationale than
>> the needs of an imaginary "amateur programmer." Let's stick to
>> substance.
>

[...]

There seems to be some gaps between my understanding of the "amateur
programmer" requirement and that of others. Possibly the word "amateur"
is causing confusion here; I don't think it should be taken literally to
mean "one who is not paid to program professionally". Instead I see it
as a requirement for simplicity and explicitness. That is:

* The protocol should be designed and specified in a way that does not
presume significant prior experience implementing servers (for clients
some — hopefully minimal — additional complexity is OK because client
authors will typically be browser vendors). We should always assume that
anything that is common knowledge amongst those who have previously 
implemented servers for other protocols is unknown to implementors of 
websockets servers. Notably we should assume that implementors are 
totally unaware of any security considerations, and therefore any 
required security properties should, as far as possible, come for free 
from making a working implementation.

* We should make design decisions that reduce the number of naive
mistakes that one can make. Particularly we should make design decisions
that reduce the number of mistakes that can lead to apparently working,
but buggy, implementations (e.g. those that work for ascii but not for
other characters) since many authors will not test adequately.

* Where non-essential features add complexity, we should avoid those
features.

I believe this kind of requirement is important to all technologies that
are to succeed on top of the web.

> http://is.gd/dz13m  A frame has a size component so you can send

As an aside, it seems to have been missed that there is a clear
timescale for supporting binary data in websockets, that is "when web
browsers support binary data in javascript". That is a rather short
timescale; both WebGL and the File API also need binary data support so
it seems that this timescale is measured in months. At that point both
the API and the protocol can be changed to support binary data. I don't
understand why this is an issue.

> connects a WebSocket then you should realize you need to redesign

At this point I should note that I am not a professional programmer. I
am, however a professional browser QA and I find the explicit
description of steps in the protocol to be enormously helpful in
constructing testcases, determining what the error conditions are,
finding edge cases, and so on. It is a style of spec I much prefer over
something like "parse this grammar" which typically makes it very
unclear what is supposed to happen when something goes wrong. I
understand that the style may not suit everyone. But quoting one
derogatory tweet hardly represents a considered discussion of the pros
and cons of the spec style.

On a slightly different topic, I do not recall seeing any discussion of 
making a testsuite for server implementations. Is that something that 
the group plans to work on?