tr.html
author charles
Wed, 12 Jul 2017 19:24:28 +0200
changeset 224 5fb97d1539fe
parent 109 2ad4ac628dce
permissions -rw-r--r--
Sigh. Fix the pointer
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="content-type">
    <title>Editor's Draft 7 Technical Report Development Process</title>
    <link rel="contents" href="cover.html#toc">
    <link rel="next" href="acreview.html">
    <link rel="previous" href="groups.html">
    <link href="https://www.w3.org/StyleSheets/TR/base.css" type="text/css" rel="stylesheet">
    <style type="text/css">
      .rfc2119 {font-variant:small-caps}
</style> <link href="https://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet">
    <!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
  </head>
  <body>
    <div class="noprint">
      <div class="navbar"><map name="navbar-top" title="Navigation Bar" id="navbar-top">
          <p>[<a accesskey="n" rel="Next" href="acreview.html">next chapter</a>]
            &nbsp; [<a accesskey="p" rel="Prev" href="groups.html">previous
              chapter</a>] &nbsp; [<a accesskey="c" rel="Contents" href="cover.html#toc">contents</a>]</p>
          <hr></map>
      </div>
    </div>
    <h1>Editor's draft proposed new W3C Process Document</h1>
    <h2 id="Reports">7 W3C Technical Report Development Process</h2>
    <p>The W3C technical report development process is the set of steps and
      requirements followed by W3C <a href="groups#GroupsWG">Working Groups</a>
      to standardize Web technology. The W3C technical report development
      process is designed to </p>
    <ul>
      <li>support multiple specification development methodologies</li>
      <li>maximize <a href="policies.html#def-consensus" rel="glossary" title="Definition of Consensus"><span
            class="dfn-instance">consensus</span></a> about the content of
        stable technical reports</li>
      <li>ensure high technical and editorial quality</li>
      <li>promote consistency among specifications</li>
      <li>facilitate royalty-free, interoperable implementations of Web
        Standards, and</li>
      <li>earn endorsement by W3C and the broader community.</li>
    </ul>
    <p>See also the licensing goals for W3C Recommendations in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Licensing">section
        2</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>]. </p>
    <h3>Table of Contents</h3>
    <ul>
      <li><a href="#rec-advance">7.1 W3C Technical Reports</a>
        <ul>
          <li><a href="#recs-and-notes">7.1.1 Recommendations and Notes</a></li>
          <li><a href="#maturity-levels">7.1.2 Maturity Levels</a></li>
        </ul>
      </li>
      <li><a href="#requirements-and-definitions">7.2 General requirements and
          definitions</a>
        <ul>
          <li><a href="#general-requirements">7.2.1 General requirements for
              Technical Reports</a></li>
          <li><a href="#transition-reqs">7.2.2 Advancement on the Recommendation
              Track</a>
            <ul>
              <li><a href="#substantive-change">7.2.2.1 Substantive Change</a></li>
            </ul>
          </li>
          <li><a href="#doc-reviews">7.2.3 Reviews and Review Responsibilities</a>
            <ul>
              <li><a href="#wide-review">7.2.3.1 Wide Review</a></li>
            </ul>
          </li>
          <li><a href="#implementation-experience">7.2.4 Implementation
              Experience</a> </li>
          <li><a href="#correction-classes">7.2.5 Classes of Changes to a
              Recommendation</a></li>
        </ul>
      </li>
      <li><a href="#working-draft">7.3 Working Draft</a>
        <ul>
          <li><a href="#first-wd">7.3.1 First Public Working Draft</a></li>
          <li><a href="#revised-wd">7.3.2 Revising Public Working Drafts</a></li>
          <li><a href="#tr-end"><span style="text-decoration: underline;">7.3.3
                Stopping work on a specification</span></a></li>
        </ul>
      </li>
      <li><a href="#candidate-rec">7.4 Candidate Recommendation</a>
        <ul>
          <li><a href="#revised-cr">7.4.1 Revising a Candidate Recommendation</a></li>
        </ul>
      </li>
      <li> <a href="#rec-pr">7.5 Proposed Recommendation</a></li>
      <li> <a href="#rec-publication">7.6 W3C Recommendation</a></li>
      <li><a href="#rec-modify">7.7 Modifying a W3C Recommendation</a>
        <ul>
          <li><a href="#errata">7.7.1 Errata Management</a></li>
          <li><a href="#revised-rec">7.7.2 Revising a Recommendation</a></li>
        </ul>
      </li>
      <li><a href="#Note">7.8 Publishing a Working Group or Interest Group Note</a></li>
      <li><a href="#rec-rescind">7.9 Rescinding a W3C Recommendation</a></li>
      <li><a href="#further-reading">Further reading</a></li>
    </ul>
    <h3 id="rec-advance">7.1 W3C Technical Reports</h3>
    <p>Please note that <dfn>publishing</dfn> as used in this document refers
      to producing a version which is listed as a W3C Technical Report on its <a
        href="http://www.w3.org/TR">Technical Reports page http://www.w3.org/TR</a>.</p>
    <p>This chapter describes the formal requirements for publishing and
      maintaining a W3C Recommendation or Note.</p>
    <p>Typically a series of Working Drafts are published, each of which refines
      a document under development to complete the scope of work envisioned by a
      Working Group's charter. For a technical specification, once review
      suggests the Working Group has met their requirements satisfactorily for a
      new standard, there is a Candidate Recommendation phase. This allows the
      entire W3C membership to provide feedback on whether the specification
      should become a W3C Recommendation, while the Working Group formally
      collects&nbsp; implementation experience to demonstrate that the
      specification works in practice. The next phase is a Proposed
      Recommendation, to finalize the review of W3C Members. If the Director
      determines that W3C member review supports a specification becoming a
      standard, W3C publishes it as a Recommendation.</p>
    <p>Groups may also publish documents as W3C Notes, typically either to
      document information other than technical specifications, such as use
      cases motivating a specification and best practices for its use, or to
      clarify the status of work that is abandoned. </p>
    <p>Some W3C Notes are developed through successive Working Drafts, with an
      expectation that they will become Notes, while others are simply
      published. There are few formal requirements to publish a document as a
      W3C Note, and they have no standing as a recommendation of W3C but are
      simply documents preserved for historical reference.</p>
    <p>Individual Working Groups and Interest Groups may adopt additional
      processes for developing publications, so long as they do not conflict
      with the requirements in this chapter.</p>
    <h4 id="recs-and-notes">7.1.1 Recommendations and Notes</h4>
    <p>W3C follows these steps when advancing a technical report to
      Recommendation.</p>
    <ol>
      <li>Publication of the <a href="#first-wd">First Public Working Draft</a>,</li>
      <li>Publication of zero or more revised <a href="#hb-wd">Public Working
          Drafts</a>.</li>
      <li>Publication of a <a href="#last-call">Candidate Recommendation</a>.</li>
      <li>Publication of a <a href="#rec-pr">Proposed Recommendation</a>.</li>
      <li>Publication as a <a href="#rec-publication">W3C Recommendation</a>.</li>
      <li>Possibly, Publication as an <a href="#rec-edited">Edited
          Recommendation</a></li>
    </ol>
    <p>
      <svg xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"
        viewBox="0 0 450 60" height="5em" width="45em">
        <g id="ToFPWD" stroke="black" fill="black">
          <a xlink:href="#first-wd"><text font-size="8" font-family="Times,serif"
              y="38" x="66" text-anchor="left" stroke="none">First WD</text></a>
          <path d="M66,40h33"></path>
          <polygon points="98,36 108,40 98,44"></polygon> </g>
        <g id="nodeWD">
          <ellipse ry="18" rx="38" cy="40" cx="147" stroke="black" fill="none"></ellipse>
          <a xlink:href="#RecsWD"><text font-size="14" font-family="Times,serif"
              y="44" x="147" text-anchor="middle">WD</text></a> </g>
        <g id="repeatWD" stroke="black">
          <path d="M128,24C123,14 129,4 147,4 158,4 165,8 167,14" fill="none" stroke-dasharray="6 1"></path>
          <polygon points="170,14 166,24 164,13"></polygon> </g>
        <g class="edge" id="toCR" stroke="black" fill="black">
          <path d="M185,40h31"></path>
          <polygon points="211,36 221,40 211,44"></polygon> </g>
        <g id="nodeCR">
          <ellipse ry="18" rx="38" cy="40" cx="260" stroke="black" fill="none"></ellipse>
          <a xlink:href="#RecsCR"><text font-size="14" font-family="Times,serif"
              y="44" x="260" text-anchor="middle">CR</text></a> </g>
        <g class="edge" id="repeatCR" stroke="black" fill="black">
          <path d="M242,24C238,14 244,4 260,4 271,4 277,8 279,14" stroke-dasharray="5 3"
            fill="none"></path>
          <polygon points="282,14 277,24 275,13"></polygon> </g>
        <g id="backToWD" stroke="#666" fill="#666">
          <path d="M190,47h34" stroke-dasharray="4 4"></path>
          <polygon points="190,45 183,47 190,49"></polygon> </g>
        <g class="edge" id="ToPR" stroke="black" fill="black">
          <path d="M298,40h27"></path>
          <polygon points="324,36 334,40 324,44"></polygon> </g>
        <g id="nodePR">
          <ellipse ry="18" rx="28" cy="40" cx="363" stroke="black" fill="none"></ellipse>
          <a xlink:href="#RecsPR"><text font-size="14" font-family="Times,serif"
              y="44" x="363" text-anchor="middle">PR</text></a> </g>
        <g id="BackToCR" stroke="#aaa" fill="#aaa">
          <path d="M301,47h38" stroke-dasharray="2 5"></path>
          <polygon points="301,45 296,47 301,49"></polygon> </g>
        <g id="ToRec" stroke="black" fill="black">
          <path d="M391,40h20"></path>
          <polygon points="404,36 414,40 404,44"></polygon> </g>
        <g id="nodeRec">
          <ellipse ry="18" rx="28" cy="40" cx="443" stroke="black" fill="none"></ellipse>
          <a xlink:href="#RecsW3C"><text font-size="14" font-family="Times,serif"
              y="44" x="443" text-anchor="middle">REC</text></a> </g> </svg> </p>
    <p>W3C <em class="rfc2119">may</em> <a href="#tr-end">end work on a
        technical report</a> at any time.</p>
    <p>The Director <em class="rfc2119">may</em> decline a request to advance
      in maturity level, requiring a Working Group to conduct further work, and
      <em class="rfc2119">may</em> require the specification to return to a
      lower <a href="#maturity-level">maturity level</a>. The Director <em class="rfc2119">must</em>
      inform the <a href="organization.html#AC">Advisory Committee</a> and
      Working Group Chairs when a Working Group's request for a specification to
      advance in maturity level is declined and the specification is returned to
      a Working Group for further work.</p>
    <h4 id="maturity-levels">7.1.2 Maturity Levels</h4>
    <dl>
      <dt id="RecsWD">Working Draft (WD)</dt>
      <dd>A Working Draft is a document that W3C has published for review by the
        community, including W3C Members, the public, and other technical
        organizations. Some, but not all, Working Drafts are meant to advance to
        Recommendation; see the <a href="#DocumentStatus">document status
          section</a> of a Working Draft for the group's expectations. Any
        Working Draft not, or no longer, intended to advance to Recommendation <em
          class="rfc2119">should</em> be published as a Working Group Note.
        Working Drafts do not necessarily represent a consensus of the Working
        Group, and do not imply any endorsement by W3C or its members beyond
        agreement to work on a general area of technology.</dd>
      <dt id="RecsCR">Candidate Recommendation (CR)</dt>
      <dd class="changed">A Candidate Recommendation is a document that
        satisfies the Working Group's technical requirements, and has already
        received wide review. W3C publishes a Candidate Recommendation to
        <ul>
          <li>signal to the wider community that a final review should be done</li>
          <li>gather <a href="#implementation-experience">implementation
              experience</a></li>
          <li>begin formal review by the Advisory Committee, who <em class="rfc2119">may</em>
            recommend that the document be published as a W3C Recommendation,
            returned to the Working Group for further work, or abandoned.</li>
          <li>Provide an exclusion opportunity as per the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
              Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>].
            A Candidate Recommendation under this process corresponds to the
            "Last Call Working Draft" discussed in the Patent Policy.</li>
        </ul>
      </dd>
      <dd><strong>Note:</strong> Candidate Recommendations are expected to be
        acceptable as Recommendations. Announcement of a different next step <em
          class="rfc2119">should</em> include the reasons why the change in
        expectations comes at so late a stage.</dd>
      <dt id="RecsPR">Proposed Recommendation</dt>
      <dd>A Proposed Recommendation is a document that has been accepted by the
        W3C Director as of sufficient quality to become a W3C Recommendation.
        This phase establishes a deadline for the Advisory Committee review
        which begins with Candidate Recommendation. Substantive changes <span class="rfc2119">must</span>
        not be made to a Proposed Recommendation except by publishing a new
        Working Draft or Candidate Recommendation.</dd>
      <dt id="RecsW3C">W3C Recommendation (REC)</dt>
      <dd>A W3C Recommendation is a specification or set of guidelines or
        requirements that, after extensive consensus-building, has received the
        endorsement of W3C Members and the Director. W3C recommends the wide
        deployment of its Recommendations as standards for the Web. The W3C
        Royalty-Free IPR licenses granted under the Patent Policy apply to W3C
        Recommendations.</dd>
      <dt id="WGNote">Working Group Note, Interest Group Note (NOTE) </dt>
      <dd>A Working Group Note or Interest Group Note is published by a
        chartered Working Group or Interest Group to provide a stable reference
        for a useful document that is not intended to be a formal standard, or
        to document work that was abandoned without producing a Recommendation.</dd>
      <dt id="RescindedRec">Rescinded Recommendation</dt>
      <dd>A Rescinded Recommendation is an entire Recommendation that W3C no
        longer endorses. See also clause 10 of the licensing requirements for
        W3C Recommendations in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Requirements">section
          5</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
          Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>].</dd>
    </dl>
    <p>Working Groups and Interest Groups <em class="rfc2119">may</em> make
      available "Editor's drafts". Editor's drafts have no official standing
      whatsoever, and do not necessarily imply consensus of a Working Group or
      Interest Group, nor are their contents endorsed in any way by W3C.</p>
    <h3 id="requirements-and-definitions">7.2 General requirements and
      definitions</h3>
    <p>Please note that <dfn>publishing</dfn> as used in this document refers
      to producing a version which is listed as a W3C Technical Report on its <a
        href="http://www.w3.org/TR">Technical Reports page http://www.w3.org/TR</a>.</p>
    <h4 id="general-requirements">7.2.1 General requirements for Technical
      Reports</h4>
    <p>Every document published as part of the technical report development
      process <em class="rfc2119 old">must</em> be a public document. The <a href="http://www.w3.org/TR/">index
        of W3C technical reports</a> [<a href="refs.html#ref-doc-list">PUB11</a>]
      is available at the W3C Web site. W3C strives to make archival documents
      indefinitely available at their original address in their original form.</p>
    <p>Every document published as part of the technical report development
      process <em class="rfc2119 old">must</em> clearly indicate its <a href="#maturity-levels">maturity
        level</a>, and <em id="DocumentStatus" class="rfc2119">must</em>
      include information about the status of the document. This status
      information</p>
    <ul>
      <li><em class="rfc2119">must</em> be unique each time a specification is
        published,<br>
        <em class="rfc2119"></em></li>
      <li><em class="rfc2119">must</em> state which Working Group developed the
        specification, </li>
      <li><em class="rfc2119">must</em> state how to send comments or file bugs,
        and where these are recorded, </li>
      <li><em class="rfc2119">must</em> include expectations about next steps,</li>
      <li><em class="rfc2119">should</em> explain how the technology relates to
        existing international standards and related work inside or outside W3C,
        and</li>
      <li><em class="rfc2119">should</em> explain or link to an explanation of
        significant changes from the previous version.</li>
    </ul>
    <p>Every Technical Report published as part of the Technical Report
      development process is edited by one or more editors appointed by a Group
      Chair. It is the responsibility of these editors to ensure that the
      decisions of the Group are correctly reflected in subsequent drafts of the
      technical report. An editor <em class="rfc2119">must</em> be a
      participant, as a Member representative, Team representative, or Invited
      Expert in the Group responsible for the document(s) they are editing. </p>
    <p>The Team is <em class="rfc2119">not required</em> to publish a Technical
      Report that does not conform to the Team's <a href="http://www.w3.org/Guide/pubrules">Publication
        Rules</a> (e.g., for <a name="DocumentName" id="DocumentName">naming</a>,
      status information, style, and <a name="document-copyright" id="document-copyright">copyright
        requirements</a>). These rules are subject to change by the Team from
      time to time. The Team <em class="rfc2119">must</em> inform group Chairs
      and the Advisory Committee of any changes to these rules.</p>
    <p>The primary language for W3C Technical Reports is English. W3C encourages
      the translation of its Technical Reports. <a href="http://www.w3.org/Consortium/Translation/">Information
        about translations of W3C technical reports</a> [<a href="refs.html#ref-translations">PUB18</a>]
      is available at the W3C Web site.</p>
    <h4 id="transition-reqs">7.2.2 Advancement on the Recommendation Track</h4>
    <p>For <em>all</em> requests to advance a specification to a new maturity
      level other than Note the Working Group:</p>
    <ul>
      <li><em class="rfc2119">must</em> record the group's decision to request
        advancement.</li>
      <li><em class="rfc2119">must </em> obtain Director approval.</li>
      <li><em class="rfc2119 ">must</em> provide public documentation of all <a
          href="#substantive-change">substantive changes</a> to the technical
        report since the previous publication.</li>
      <li><em class="rfc2119">must</em> <a href="policies.html#formal-address">formally
          address</a> all issues raised about the document since the previous
        maturity level.</li>
      <li><em class="rfc2119">must</em> provide public documentation of any <a
          href="policies.html#FormalObjection">Formal Objections</a>.</li>
      <li><span class="rfc2119">should</span> provide public documentation of
        changes that are not substantive.</li>
      <li><em class="rfc2119">should</em> report which, if any, of the Working
        Group's requirements for this document have changed since the previous
        step.</li>
      <li><em class="rfc2119">should</em> report any changes in dependencies
        with other groups.</li>
      <li><em class="rfc2119">should</em> provide information about
        implementations known to the Working Group.</li>
    </ul>
    <p>For a First Public Working Draft there is no "previous maturity level",
      so many requirements do not apply, and approval is normally fairly
      automatic. For later stages, especially transition to Candidate or
      Proposed Recommendation, there is generally a formal review meeting to
      ensure the requirements have been met before Director's approval is given.</p>
    <h4 id="doc-reviews">7.2.3 Reviews and Review Responsibilities</h4>
    <p>A document is available for review from the moment it is first published.
      Working Groups <em class="rfc2119">should</em> <a href="policies.html#formal-address">formally
        address</a> <em>any</em> substantive review comment about a technical
      report in a timely manner. </p>
    Reviewers <em class="rfc2119">should</em> send substantive technical
    reviews as early as possible. Working Groups are often reluctant to make <a
      href="#substantive-change">substantive changes</a> to a mature document,
    particularly if this would cause significant compatibility problems due to
    existing implementation. Working Groups <em class="rfc2119">should</em>
    record substantive or interesting proposals raised by reviews but not
    incorporated into a current specification.
    <h5>7.2.3.1 <a id="wide-review">Wide Review</a></h5>
    <p>The requirements for <dfn>wide review</dfn> are not precisely defined by
      the W3C Process. The objective is to ensure that the entire set of
      stakeholders of the Web community, including the general public, have had
      adequate notice of the progress of the Working Group and thereby an
      opportunity to comment on the specification. Before approving transitions,
      the Director will consider who has been explicitly offered a reasonable
      opportunity to review the document, who has provided comments, the record
      of requests to and responses from reviewers, especially groups identified
      as dependencies in the charter, and seek evidence of clear communication
      to the general public about appropriate times and which content to review.
    </p>
    <p>For example, inviting review of new or significantly revised sections
      published in Working Drafts, and tracking those comments and the Working
      Group's responses, is generally a good practice which would often be
      considered positive evidence of wide review. Working Groups <span class="rfc2119">should</span>
      announce to other W3C Working Groups as well as the general public,
      especially those affected by this specification, a proposal to enter
      Candidate Recommendation (for example in approximately four weeks). By
      contrast a generic statement in a document requesting review at any time
      is likely not to be considered as sufficient evidence that the group has
      solicited wide review. </p>
    <p>A Working Group could present evidence that wide review has been
      received, irrespective of solicitation. But it is important to note that
      receiving many detailed reviews is not necessarily the same as wide
      review, since they may only represent comment from a small segment of the
      relevant stakeholder community.</p>
    <h4 id="implementation-experience">7.2.4 Implementation Experience</h4>
    <p>Implementation experience is required to show that a specification is
      sufficiently clear, complete, and relevant to market needs, to ensure that
      independent interoperable implementations of each feature of the
      specification will be realized. While no exhaustive list of requirements
      is provided here, when assessing that there is <dfn>adequate
        implementation experience</dfn> the Director will consider (though not
      be limited to):</p>
    <ul>
      <li>is each feature of the current specification implemented, and how is
        this demonstrated?</li>
      <li>are there independent interoperable implementations of the current
        specification?</li>
      <li>are there implementations created by people other than the authors of
        the specification?</li>
      <li>are implementations publicly deployed?</li>
      <li>is there implementation experience at all levels of the
        specification's ecosystem (authoring, consuming, publishing…)?</li>
      <li>are there reports of difficulties or problems with implementation?</li>
    </ul>
    <p>Planning and accomplishing a demonstration of (interoperable)
      implementations can be very time consuming. Groups are often able to work
      more effectively if they plan how they will demonstrate interoperable
      implementations early in the development process; for example, they may
      wish to develop tests in concert with implementation efforts.</p>
    <h4 id="correction-classes">7.2.5 Classes of Changes</h4>
    <p>This document distinguishes the following 4 classes of changes to a
      specification. The first two classes of change are considered <dfn id="editorial-change">editorial
        changes</dfn>, the latter two <dfn id="substantive-change">substantive
        changes</dfn>.</p>
    <dl>
      <dt>1. No changes to text content</dt>
      <dd>These changes include fixing broken links, style sheets or invalid
        markup.</dd>
      <dt>2. Corrections that do not affect conformance</dt>
      <dd>Editorial changes or clarifications that do not change the technical
        content of the specification.</dd>
      <dt>3. Corrections that do not add new features</dt>
      <dd>These changes <span class="rfc2119">may</span> affect conformance to
        the specification. A change that affects conformance is one that:
        <ul>
          <li>makes conforming data, processors, or other conforming agents
            become non-conforming according to the new version, or</li>
          <li>makes non-conforming data, processors, or other agents become
            conforming, or</li>
          <li>clears up an ambiguity or under-specified part of the
            specification in such a way that data, a processor, or an agent
            whose conformance was once unclear becomes clearly either conforming
            or non-conforming.</li>
        </ul>
      </dd>
      <dt>4. New features</dt>
    </dl>
    <h3 id="working-draft">7.3 Working Draft</h3>
    <p>A Public Working Draft is published on the <a href="http://www.w3.org/TR">W3C's
        Technical Reports page</a> [TR] for review, and for simple historical
      reference. For all Public Working Drafts a Working Group</p>
    <ul>
      <li> <em class="rfc2119">should</em> document outstanding issues, and
        parts of the document on which the Working Group does not have
        consensus, and</li>
      <li> <em class="rfc2119">may</em> request publication of a Working Draft
        even if its content is considered unstable and does not meet all Working
        Group requirements.</li>
    </ul>
    <h4 id="first-wd">7.3.1 First Public Working Draft</h4>
    <p>To publish the First Public Working Draft of a document, a Working Group
      must meet the applicable <a href="#transition-reqs">general requirements
        for advancement</a>.</p>
    <p>The Director <em class="rfc2119">must</em> announce the publication of a
      First Public Working Draft publication to other W3C groups and to the
      public. </p>
    <p>Publishing the First Public Working Draft triggers a Call for Exclusions,
      per <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
        4</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>].</p>
    <h4 id="revised-wd">7.3.2 Revising Public Working Drafts</h4>
    <p>A Working Group <em class="rfc2119">should</em> publish a Working Draft
      to the W3C Technical Reports page when there have been significant changes
      to the previous published document that would benefit from review beyond
      the Working Group<em class="rfc2119"></em>. </p>
    <p>If 6 months elapse without significant changes to a specification a
      Working Group <em class="rfc2119">should</em> publish a revised Working
      Draft, whose status section <em class="rfc2119">should</em> indicate
      reasons for the lack of change. </p>
    <p>To publish a revision of a Working draft, a Working Group </p>
    <ul>
      <li><em class="rfc2119">must</em> record the group's decision to request
        publication. Consensus is not required, as this is a procedural step,</li>
      <li><em class="rfc2119">must</em> provide public documentation of <a href="#substantive-change">substantive
          changes</a> to the technical report since the previous Working Draft,</li>
      <li><em class="rfc2119">should</em> provide public documentation of
        significant <a href="#editorial-change">editorial changes</a> to the
        technical report since the previous step,</li>
      <li><em class="rfc2119">should</em> report which, if any, of the Working
        Group's requirements for this document have changed since the previous
        step,</li>
      <li><em class="rfc2119">should</em> report any changes in dependencies
        with other groups,</li>
    </ul>
    <p>Possible next steps for any Working Draft:</p>
    <ul>
      <li>Revised <a href="#hb-wd">Public Working Draft</a></li>
      <li><a href="#last-call">Candidate recommendation</a>.</li>
      <li><a href="#Note">Working Group Note</a></li>
    </ul>
    <h4 id="tr-end">7.3.3 Stopping Work on a specification</h4>
    <p>Work on a technical report <em class="rfc2119">may</em> cease at any
      time. Work <em class="rfc2119 new">should</em> cease if W3C or a Working
      Group determines that it cannot productively carry the work any further.
      If the Director <a href="groups.html#GeneralTermination">closes a Working
        Group</a> W3C <em class="rfc2119">must </em> publish any unfinished
      specifications on the Recommendation track as <a href="#Note">Working
        Group Notes</a>. If a Working group decides, or the Director requires,
      the Working Group to discontinue work on a technical report before
      completion, the Working Group <em class="rfc2119">should</em> publish the
      document as a <a href="#Note">Working Group Note</a>. </p>
    <ul>
    </ul>
    <h3 id="candidate-rec"><a name="last-call" id="last-call">7.4 Candidate
        Recommendation </a></h3>
    <p>To publish a Candidate recommendation, in addition to meeting the <a href="#transition-reqs">general
        requirements for advancement</a> a Working Group:</p>
    <ul>
      <li><em class="rfc2119">must</em> show that the specification has met all
        Working Group requirements, or explain why the requirements have changed
        or been deferred,</li>
      <li><em class="rfc2119">must</em> document changes to dependencies during
        the development of the specification,</li>
      <li><em class="rfc2119">must</em> document how adequate <a href="#implementation-experience">
          implementation experience</a> will be demonstrated,</li>
      <li><em class="rfc2119">must</em> specify the deadline for comments, which
        <em class="rfc2119">must</em> be <strong>at least</strong> four weeks
        after publication, and <em class="rfc2119">should</em> be longer for
        complex documents,</li>
      <li><em class="rfc2119">must</em> show that the specification has received
        <a href="#wide-review">wide review</a>, and</li>
      <li><em class="rfc2119">may</em> identify features in the document as "at
        risk". These features <em class="rfc2119">may</em> be removed before
        advancement to Proposed Recommendation without a requirement to publish
        a new Candidate Recommendation.</li>
    </ul>
    <p>The Director <em class="rfc2119">must</em> announce the publication of a
      Candidate Recommendation to other W3C groups and to the public, and <em class="rfc2119">must</em>
      begin an Advisory Committee Review on the question of whether W3C should
      publish the specification as a W3C Recommendation.</p>
    <p> A Candidate Recommendation corresponds to a "Last Call Working Draft" as
      used in the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>].
      Publishing a Candidate Recommendation triggers a Call for Exclusions, per
      <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
        4</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>].</p>
    <p>Possible next steps:</p>
    <ul>
      <li>Return to <a href="#hb-wd">Working Draft</a></li>
      <li>A revised <a href="#last-call">Candidate Recommendation</a></li>
      <li><a href="#rec-pr">Proposed Recommendation</a> (The expected next step)</li>
      <li><a href="#Note">Working Group Note</a></li>
    </ul>
    <p>If there was any <a href="policies.html#def-Dissent" rel="glossary" title="Definition of Dissent"><span
          class="dfn-instance">dissent</span></a>&nbsp;to the Working Group
      decision to request advancement <a href="organization.html#AC">Advisory
        Committee</a> representatives <em class="rfc2119">may</em> <a href="acreview.html#ACAppeal">appeal</a>
      the decision to advance the technical report.</p>
    <h4 id="revised-cr">7.4.1 Revising a Candidate Recommendation</h4>
    <p>If there are any <a href="#substantive-change">substantive changes</a>
      made to a Candidate Recommendation other than to remove features
      explicitly identified as "at risk", the Working Group <em class="rfc2119">must</em>
      obtain the Director's approval to publish a revision of a Candidate
      Recommendation. This is because substantive changes will generally require
      a new Exclusion Opportunity per <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
        4</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>]. Note
      that approval is <em>expected</em> to be fairly simple compared to
      getting approval for a transition from Working Draft to Candidate
      Recommendation.</p>
    <p>In addition the Working Group:</p>
    <ul>
      <li><em class="rfc2119">must</em> show that the revised specification
        meets all Working Group requirements, or explain why the requirements
        have changed or been deferred,</li>
      <li><em class="rfc2119">must</em> specify the deadline for further
        comments, which <em class="rfc2119">must</em> be <strong>at least</strong>
        four weeks after publication, and <em class="rfc2119">should</em> be
        longer for complex documents,</li>
      <li><em class="rfc2119">must</em> document the changes since the previous
        Candidate Recommendation, </li>
      <li><em class="rfc2119">must</em> show that the proposed changes have
        received <a href="#wide-review">wide review</a>, and</li>
      <li><em class="rfc2119">may</em> identify features in the document as "at
        risk". These features <em class="rfc2119">may</em> be removed before
        advancement to Proposed Recommendation without a requirement to publish
        a new Candidate Recommendation.</li>
    </ul>
    <p>The Director <span class="rfc2119">must</span> announce the publication
      of a revised Candidate Recommendation to other W3C groups and the Public.</p>
    <ul>
    </ul>
    <h3 id="rec-pr">7.5 Proposed Recommendation</h3>
    <p>In addition to meeting the <a href="#transition-reqs">general
        requirements for advancement</a>,</p>
    <ul>
      <li>The status information <em class="rfc2119">must</em> specify the
        deadline for Advisory Committee review, which <em class="rfc2119">must</em>
        be <strong>at least</strong> 28 days after the publication of the
        Proposed Recommendation and <em class="rfc2119">should</em> be at least
        10 days after the end of the last Exclusion Opportunity per <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
          4</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
          Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>].</li>
    </ul>
    <p>A Working Group:</p>
    <ul>
      <li><em class="rfc2119">must</em> show adequate <a href="#implementation-experience">implementation
          experience</a> except where an exception is approved by the Director,</li>
      <li><em class="rfc2119">must</em> show that the document has received <a
          href="#wide-review">wide review,</a></li>
      <li><em class="rfc2119">must</em> show that all issues raised during the
        Candidate Recommendation review period other than by Advisory Committee
        representatives acting in their formal AC representative role have been
        <a href="policies.html#formal-address">formally addressed</a>,</li>
      <li><em class="rfc2119">must </em>identify any substantive issues raised
        since the close of the Candidate Recommendation review period by parties
        other than Advisory Committee representatives acting in their formal AC
        representative role,</li>
      <li><em class="rfc2119">may</em> have removed features identified in the
        Candidate Recommendation document as "at risk" without republishing the
        specification as a Candidate Recommendation.</li>
    </ul>
    <p>The Director:</p>
    <ul>
      <li><em class="rfc2119">must</em> announce the publication of a Proposed
        Recommendation to the <a href="organization.html#AC">Advisory Committee</a>,
        and</li>
      <li><span><em class="rfc2119">may</em> approve a Proposed Recommendation
          with minimal implementation experience where there is a compelling
          reason to do so. In such a case, the Director <em class="rfc2119">should</em>
          explain the reasons for that decision.</span></li>
    </ul>
    <p>Since a W3C Recommendation <span class="rfc2119">must not</span> include
      any substantive changes from the Proposed Recommendation it is based on,
      to make any substantive change to a Proposed Recommendation the Working
      Group <span class="rfc2119">must</span> return the specification to
      Candidate Recommendation or Working Draft.</p>
    <ul>
    </ul>
    <p>Possible Next Steps:</p>
    <ul>
      <li>Return to <a href="#hb-wd">Working Draft</a></li>
      <li>Return to <a href="#last-call">Candidate Recommendation</a></li>
      <li><a href="#rec-publication">Recommendation status</a> (The expected
        next step)</li>
      <li><a href="#Note">Working Group Note</a></li>
    </ul>
    <ul>
    </ul>
    <h3 id="rec-publication">7.6 W3C Recommendation</h3>
    <p>The decision to advance a document to Recommendation is a <a href="acreview.html#def-w3c-decision">W3C
        Decision</a>.</p>
    <p>In addition to meeting the <a href="#transition-reqs">general
        requirements for advancement</a>,</p>
    <ul>
      <li>A Recommendation <em class="rfc2119">must</em> identify where errata
        are tracked, and</li>
      <li>A Recommendation <em class="rfc2119">must not</em> include any
        substantive changes from the Proposed Recommendation on which it is
        based.</li>
      <li>If there was any <a href="policies.html#def-Dissent" rel="glossary" title="Definition of Dissent"><span
            class="dfn-instance">dissent</span></a> in Advisory Committee
        reviews, the Director <em class="rfc2119">must</em> publish the
        substantive content of the dissent to W3C and the general public, and <em
          class="rfc2119">must</em> <a href="policies.html#formal-address">formally
          address</a> the comment at least 14 days before publication as a W3C
        Recommendation. In this case the <a href="organization.html#AC">Advisory
          Committee</a> <em class="rfc2119">may</em> <a href="acreview.html#ACAppeal">appeal</a>
        the decision,</li>
      <li>The Director <em class="rfc2119">must</em> announce the publication
        of a W3C Recommendation to <a href="organization.html#AC">Advisory
          Committee</a>, other W3C groups and to the public.</li>
    </ul>
    <p>Possible next steps:</p>
    <p>A W3C Recommendation normally retains its status indefinitely. However it</p>
    <ul>
      <li><em class="rfc2119">may</em> be republished as an <a href="#rec-modify">(Edited)

          Recommendation</a>, or</li>
      <li><em class="rfc2119">may</em> be <a href="#rec-rescind">rescinded</a>.</li>
    </ul>
    <h3 id="rec-modify">7.7 Modifying a W3C Recommendation</h3>
    <p>This section details the management of errors in, and the process for
      making changes to a Recommendation. Please see also the <a href="http://www.w3.org/2003/01/republishing/">Requirements
        for modification of W3C Technical Reports</a> [<a href="refs.html#in-place-tr-mod">PUB35</a>].</p>
    <p>
      <svg xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"
        viewBox="0 0 500 160" height="12em" width="50em">
        <g id="basicProcess" opacity=".6">
          <g id="nodeWD">
            <ellipse ry="18" rx="38" cy="40" cx="147" stroke="black" fill="none"></ellipse>
            <a xlink:href="#RecsWD"><text font-size="14" font-family="Times,serif"
                y="44" x="147" text-anchor="middle">WD</text></a> </g>
          <g id="repeatWD" stroke="black">
            <path d="M128,24C123,14 129,4 147,4 158,4 165,8 167,14" fill="none"
              stroke-dasharray="6 1"></path>
            <polygon points="170,14 166,24 164,13"></polygon> </g>
          <g class="edge" id="toCR" stroke="black" fill="black">
            <path d="M185,40h31"></path>
            <polygon points="211,36 221,40 211,44"></polygon> </g>
          <g id="nodeCR">
            <ellipse ry="18" rx="38" cy="40" cx="260" stroke="black" fill="none"></ellipse>
            <a xlink:href="#RecsCR"><text font-size="14" font-family="Times,serif"
                y="44" x="260" text-anchor="middle">CR</text></a> </g>
          <g class="edge" id="repeatCR" stroke="black" fill="black">
            <path d="M242,24C238,14 244,4 260,4 271,4 277,8 279,14" stroke-dasharray="5 3"
              fill="none"></path>
            <polygon points="282,14 277,24 275,13"></polygon> </g>
          <g id="backToWD" stroke="#666" fill="#666">
            <path d="M190,47h34" stroke-dasharray="4 4"></path>
            <polygon points="190,45 183,47 190,49"></polygon> </g>
          <g class="edge" id="ToPR" stroke="black" fill="black">
            <path d="M298,40h27"></path>
            <polygon points="324,36 334,40 324,44"></polygon> </g>
          <g id="nodePR">
            <ellipse ry="18" rx="28" cy="40" cx="363" stroke="black" fill="none"></ellipse>
            <a xlink:href="#RecsPR"><text font-size="14" font-family="Times,serif"
                y="44" x="363" text-anchor="middle">PR</text></a> </g>
          <g id="BackToCR" stroke="#aaa" fill="#aaa">
            <path d="M301,47h38" stroke-dasharray="2 5"></path>
            <polygon points="301,45 296,47 301,49"></polygon> </g>
          <g id="ToRec" stroke="black" fill="black">
            <path d="M391,40h20"></path>
            <polygon points="404,36 414,40 404,44"></polygon> </g> </g>
        <g id="nodeRec" stroke="black">
          <ellipse ry="18" rx="28" cy="40" cx="443" fill="none" stroke-width="2"></ellipse>
          <a xlink:href="#RecsW3C"><text font-size="16" font-family="Times,serif"
              y="44" x="443" text-anchor="middle" stroke-width=".3">REC</text></a></g>
        <g id="changeARec" stroke="black">
          <path d="M443,58 v20"></path><polygon points="443,78 441,71 445,71"></polygon>
          <polygon points="443,78 486,103 443,128 400,103" fill="none"></polygon>
          <text x="445" y="68" font-size="10" stroke="none">Changes to text</text>
          <text x="443" y="103" text-anchor="middle" font-size="10" stroke-width="0.2"><tspan>Substantive</tspan><tspan
              x="443" y="113" text-anchor="middle">changes?</tspan></text></g>
        <g id="RecToPR">
          <text x="370" y="100" font-size="10" stroke="none">No</text>
          <path d="M400,103h-37v-45" stroke="black" fill="none"></path><polygon
            stroke="black" points="363,58 361,65 365,65"></polygon></g>
        <g id="RecSubstantiveChanges" stroke="black">
          <text x="488" y="100" font-size="10" stroke-width="0.2">Yes</text>
          <path d="M486,103h20v40h-246v-15" fill="none"></path>
          <polygon points="260,128 262,133 258,133"></polygon>
          <polygon points="260,128 300,103 260,78 220,103" fill="none"></polygon>
          <text font-size="10" stroke-width="0.2" x="260" y="98" text-anchor="middle">New<tspan
              x="260" y="108" text-anchor="middle">Features?</tspan></text></g>
        <g id="NoNewFeatures">
          <path d="M260,78v-20" stroke="black"></path>
          <text x="262" y="75" font-size="10">No</text>
          <polygon points="260,58 262,63 258,63" stroke="black"></polygon> </g>
        <g id="BackToFPWD" stroke="black">
          <a xlink:href="#first-wd"><text font-size="8" font-family="Times,serif"
              y="38" x="66" stroke="none">First WD</text></a>
          <path d="M220,103h-160v-63h43" fill="none"></path>
          <text x="200" y="100" stroke-width="0.2" fill="black" font-size="10">Yes</text>
          <polygon points="103,38 108,40 103,42"></polygon> </g> </svg></p>
    <h4 id="errata">7.7.1 Errata Management</h4>
    <p>Tracking errors is an important part of a Working Group's ongoing care of
      a Recommendation; for this reason, the scope of a Working Group charter
      generally allows time for work after publication of a Recommendation. In
      this Process Document, the term "erratum" (plural "errata") refers to any
      class of mistake, from mere editorial to a serious error that may affect
      the conformance with the Recommendation by software or content (e.g.,
      content validity).</p>
    <p>Working Groups <em class="rfc2119">must</em> track errata on an "errata
      page." An errata page is a list of enumerated errors, possibly accompanied
      by corrections. Each Recommendation links to an errata page; see the
      Team's <a href="http://www.w3.org/Guide/pubrules">Publication Rules</a>.</p>
    <p>A correction is first "proposed" by the Working Group. A correction
      becomes part of the Recommendation by the process for Revising a
      Recommendation described in the next section.</p>
    <p>A Working Group <em class="rfc2119">should</em> keep their errata pages
      up-to-date, as errors are reported by readers and implementers. A Working
      Group <em class="rfc2119">must</em> report errata page changes to
      interested parties, notably when corrections are proposed or incorporated
      into an Edited Recommendation, according to the Team's requirements.</p>
    <h4 id="revised-rec">7.7.2 Revising a Recommendation</h4>
    <p>A Working group <em class="rfc2119">may</em> request republication of a
      Recommendation, or W3C <em class="rfc2119">may</em> republish a
      Recommendation, to make corrections that do not result in any changes to
      the text of the specification.</p>
    <p><a href="#editorial-change">Editorial changes</a> to a Recommendation
      require no technical review of the proposed changes. A Working Group <span
        class="rfc2119">may</span> request publication of a <a href="#rec-pr">Proposed
        Recommendation</a>&nbsp; or W3C <span class="rfc2119">may</span>
      publish a <a href="#rec-pr">Proposed Recommendation</a> to make this
      class of change without passing through earlier maturity levels. Such
      publications are <em class="rfc2119">may</em> be called a <dfn>Proposed
        Edited Recommendation</dfn>.</p>
    <p>To make corrections to a Recommendation that produce <a href="#substantive-change">substantive
        changes</a> but do not add new features, a Working Group <span class="rfc2119">may</span>
      request publication of a <a href="#last-call">Candidate Recommendation</a>,
      without passing through earlier maturity levels.</p>
    <p>In the latter two cases, the resulting Recommendation <em class="rfc2119">may</em>
      be called an <dfn>Edited Recommendation</dfn>.</p>
    <p>When requesting the publication of an edited Recommendation as described
      in this section, in addition to meeting the requirements for the relevant
      maturity level, a Working Group</p>
    <ul>
      <li><em class="rfc2119">must</em> show that the changes to the document
        have received <a href="#wide-review">wide review</a>, and </li>
      <li><em class="rfc2119">should</em> address all recorded errata.</li>
    </ul>
    <ul>
    </ul>
    <p>For changes which introduces a new feature or features, W3C <span class="rfc2119">must</span>
      follow the full process of <a href="#rec-advance">advancing a technical
        report to Recommendation</a> beginning with a new First Public Working
      Draft.</p>
    <h3 id="Note">7.8 Publishing a Working Group or Interest Group Note</h3>
    <p>Working Groups and Interest Groups publish material that is not a formal
      specification as Notes. This includes supporting documentation for a
      specification such as explanations of design principles or use cases and
      requirements, non-normative guides to good practices, as well as
      specifications where work has been stopped and there is no longer
      consensus for making them a new standard.</p>
    <p>In order to publish a Note, a Working Group or Interest Group: </p>
    <ul>
      <li> <em class="rfc2119">may</em> publish a Note with or without its
        prior publication as a Working Draft.</li>
      <li><em class="rfc2119">must</em> record the group's decision to request
        publication as a Note, and</li>
      <li><em class="rfc2119">should</em> publish documentation of significant
        changes to the technical report since any previous publication.</li>
    </ul>
    <p>Possible next steps:</p>
    <ul>
      <li>End state: A technical report <em class="rfc2119">may</em> remain a
        Working Group Note indefinitely</li>
      <li>A Working Group <em class="rfc2119">may</em> resume work on technical
        report within the scope of its charter at any time, at the maturity
        level the specification had before publication as a Note</li>
    </ul>
    <p>The <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent
        Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>] does not
      specify any licensing requirements or commitments for Working Group Notes.</p>
    <h3 id="rec-rescind">7.9 Rescinding a W3C Recommendation</h3>
    <p>W3C <em class="rfc2119">may</em> rescind a Recommendation, for example
      if the Recommendation contains many errors that conflict with a later
      version or if W3C discovers burdensome patent claims that affect
      implementers and cannot be resolved; see the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="refs.html#ref-patentpolicy">PUB33</a>] and
      in particular <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Requirements">section
        5</a> (bullet 10) and <a href="http://www.w3.org/Consortium/Patent-Policy#sec-PAG-conclude">section
        7.5</a>. A Working Group <em class="rfc2119">may</em> request the
      Director to rescind a Recommendation which was a deliverable, or the
      Director <em class="rfc2119">may</em> directly propose to rescind a
      Recommendation. </p>
    <p>W3C only rescinds entire specifications. To rescind some <em>part</em>
      of a Recommendation, W3C follows the process for <a href="#rec-modify">modifying
        a Recommendation</a>.</p>
    <p>Once W3C has published a Rescinded Recommendation, future W3C technical
      reports <em class="rfc2119">must not</em> include normative references to
      that technical report.</p>
    <p>To propose rescinding a W3C Recommendation, a Working Group or the
      Director</p>
    <ul>
      <li><em class="rfc2119">must</em> publish rationale for rescinding the
        Recommendation.</li>
      <li><em class="rfc2119">should</em> document known implementation.</li>
    </ul>
    <p>In addition a Working Group requesting to rescind a Recommendation</p>
    <ul>
      <li><em class="rfc2119">must</em> show that the request to rescind has
        received <a href="#wide-review">wide review</a></li>
    </ul>
    <p>In addition the Director, if proposing to rescind a Recommendation</p>
    <ul>
      <li><em class="rfc2119">must</em> show that the request to rescind is
        based on public comment</li>
    </ul>
    <p>The Director <em class="rfc2119">must</em> announce the proposal to
      rescind a W3C Recommendation to other W3C groups, the public, and the <a
        href="organization.html#AC">Advisory Committee</a>. The announcement <em
        class="rfc2119">must</em>:</p>
    <ul>
      <li>indicate that this is a Proposal to Rescind a Recommendation</li>
      <li>specify the deadline for review comments, which <em class="rfc2119">must</em>
        be at least <span class="time-interval">four weeks after announcing</span>
        the proposal to rescind.</li>
      <li>identify known dependencies and solicit review from all dependent
        Working Groups;</li>
      <li>solicit public review.</li>
    </ul>
    <p>If there was any <a href="policies.html#def-Dissent" rel="glossary" title="Definition of Dissent"><span
          class="dfn-instance">dissent</span></a> in Advisory Committee reviews,
      the Director <em class="rfc2119">must</em> publish the substantive
      content of the dissent to W3C <strong>and the public</strong>, and <em class="rfc2119">must</em>
      <a href="policies.html#formal-address">formally address</a> the comment at
      least 14 days before publication as a Rescinded Recommendation. In this
      case the <a href="organization.html#AC">Advisory Committee</a> <em class="rfc2119">may</em>
      <a href="#ACAppeal">appeal</a> the decision.</p>
    <p> A Rescinded Recommendation <em class="rfc2119">must</em> be published
      with up to date status. The updated version <em class="rfc2119">may</em>
      remove the rescinded content (i.e. the main body of the document).</p>
    <p><span style="font-weight: bold;">Note:</span> the original Recommendation
      document will continue to be available at its version-specific URL.</p>
    <h3 id="further-reading">Further reading</h3>
    <p>Refer to <a href="http://www.w3.org/2003/05/Transitions">"How to
        Organize a Recommendation Track Transition"</a> in the <a href="http://www.w3.org/Guide/">Member
        guide</a> for practical information about preparing for the reviews and
      announcements of the various steps, and <a href="http://www.w3.org/2002/05/rec-tips">tips
        on getting to Recommendation faster</a> [<a href="refs.html#ref-rec-tips">PUB27</a>].</p>
    <div class="noprint">
      <div class="navbar"><map name="navbar-bottom" title="Navigation Bar" id="navbar-bottom">
          <hr>
          <p>[<a accesskey="n" rel="Next" href="acreview.html">next chapter</a>]
            &nbsp; [<a accesskey="p" rel="Prev" href="groups.html">previous
              chapter</a>] &nbsp; [<a accesskey="c" rel="Contents" href="cover.html#toc">contents</a>]</p>
        </map>
      </div>
    </div>
  </body>
</html>