Note on interoperability reports...

Jim Gettys (jg@pa.dec.com)
Fri, 27 Mar 1998 11:35:35 -0800 

For those of you who are sending in interoperability reports, thanks.

For those of you who have not yet sent one in who have HTTP/1.1 
implementations, we encourage you to do so as soon as possible.  See: 
http://www.w3.org/Protocols/HTTP/Forum/Reports/

Please NOTE: for the purposes of the IETF, a feature is tested if you've 
implemented and tested it.  It does NOT have to be in shipping or otherwise 
availabile software. (so much the better, of course).  This is a common 
confusion.

The point of the interoperability report is to show that the protocol
has been tested in all regards, not a status report on what is in current
shipping product.

					- Jim

To quote from BCP 9, The Internet Standards Process:

4.1.2  Draft Standard

   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.  For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.  If patented or otherwise controlled technology
   is required for implementation, the separate implementations must
   also have resulted from separate exercise of the licensing process.
   Elevation to Draft Standard is a major advance in status, indicating
   a strong belief that the specification is mature and will be useful.

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

   The Working Group chair is responsible for documenting the specific
   implementations which qualify the specification for Draft or Internet
   Standard status along with documentation about testing of the
   interoperation of these implementations.  The documentation must
   include information about the support of each of the individual
   options and features.  This documentation should be submitted to the
   Area Director with the protocol action request. (see Section 6)

   A Draft Standard must be well-understood and known to be quite
   stable, both in its semantics and as a basis for developing an
   implementation.  A Draft Standard may still require additional or
   more widespread field experience, since it is possible for
   implementations based on Draft Standard specifications to demonstrate
   unforeseen behavior when subjected to large-scale use in production
   environments.

   A Draft Standard is normally considered to be a final specification,
   and changes are likely to be made only to solve specific problems
   encountered.  In most circumstances, it is reasonable for vendors to
   deploy implementations of Draft Standards into a disruption sensitive
   environment.