On Thu, Feb 19, 2015 at 10:16 AM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> 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.