On Thu, Feb 19, 2015 at 10:16 AM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca>
wrote:
I'm very concerned about this part:
A key point in the protocol development process was the iteration the
working group did between protocol updates, and implementations and
testing. Certain draft protocol versions were labelled by the working
group
as "implementation drafts", and the participants -- many web browser and
web server providers -- updated their implementations and tested out the
protocol changes. Most of the interim meetings included part of a day
spent
on hands-on interoperability testing and discussion. The result is a
thoroughly validated protocol that has been shown to interoperate and
that
meets the needs of many major stakeholders.
It sure seems to me like those "implementation drafts" are what used to be
called proposed standards.
What I see is a new step in the standardization process, along with a view
that the step after internet-draft seems to include proven
interoperability.
I propose that this document skip PS, and go straight to Internet Standard
to
accurately reflect the status of this document.
Yep, this change was one of the reasons we went from the three step process
to two. The requirement for getting a proposed standard published in 2005
was way higher than getting to DRAFT status in 1995.
Not sure about short cutting from Proposed Standard to Standard. I think
the process is still bjorked but in a different way.
One problem is that we have a bunch of RFCs that have widely varying
quality and status but to the rest of the world an RFC is an RFC. But the
bigger problem is that the levels are mostly static.
BEEP was rushed through IETF process and is still PROPOSED STANDARD despite
the fact nobody has ever used it or expressed an interest in doing so.
HTTP/2 is really a maintenance effort on an existing IETF standard. Only I
don't think it ever got that status (would check the ietf.org site is down
right now).
STANDARD should mean that a specification is current. So if HTTP/2 is the
best HTTP specification then it should have the STANDARD designation.
There is a little complication though. HTTP/2 is optimized for Web
browsing. Which is fine. HTTP/1.1 is also used as a presentation layer for
Web Services and for Web Sockets. So this isn't a case where HTTP/2 is a
straight upgrade. It is an upgrade for the original intended purpose of
HTTP but not necessarily advantageous for non browsing applications.
I think we probably want to think about bifurcating the HTTP moniker to
reflect that. HTTP/T for Web Sockets (which establish transport over HTTP)
and HTTP/P for a stripped down version for use as a presentation layer for
Web Services maybe.