Moving RFC 2518 to Draft Standard

It's time to start the process of revising RFC 2518 to move it from Proposed
Standard to Draft Standard status.

Revising protocol specifications based on operational experience is a normal
part of the IETF process. Standards-track protocol specifications begin at
"Proposed Standard", then progress to "Draft Standard" and full "Standard".
Currently RFC 2518 is a Proposed Standard. According to RFC 2026 ("The
Internet Standards Process -- Revision 3"), a Proposed Standard has the
following characteristics:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

A Draft Standard, in contrast, has the following characteristics:

   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.

   ...

   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.

At last count, there are 22 independent WebDAV server code bases, and 9
indepdent client code bases, as well as 10 independent client APIs (see
http://www.ics.uci.edu/pub/ietf/webdav/ for a listing).  The WebDAV protocol
is in daily use by a large number of people who are using it to do useful
work. As a result, I believe the two criteria for advancing to Draft
Standard have been met: (1) there are at least two interoperable
implementations (from distinct code bases) of each feature, on the client
and server side, and (2) sufficient operational experience has been
developed for the WebDAV protocol.

Therefore, as Chair, I hereby initiate the process of revising RFC 2518 and
documenting interoperability experience for the purpose of advancing RFC
2518 to Draft Standard status.

A following email will detail the process WebDAV WG will to follow to
achieve this goal.

- Jim Whitehead
Chair, WebDAV WG

Received on Tuesday, 10 April 2001 16:48:14 UTC