Hopefully cleaned linebreaks, which hopefully makes the HTMLdiff a little less horrible
authorcharles
Thu, 29 Jan 2015 16:14:28 +0100
changeset 140 8826b6bccaec
parent 139 eb7f42988a56
child 141 9879d992ac84
Hopefully cleaned linebreaks, which hopefully makes the HTMLdiff a little less horrible
cover.html
--- a/cover.html	Wed Jan 28 10:21:58 2015 +0100
+++ b/cover.html	Thu Jan 29 16:14:28 2015 +0100
@@ -1,77 +1,2173 @@
-<!DOCTYPE html>
<html lang="en">
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="content-type">
    <meta name="keywords" content="W3C, World Wide Web, Web, WWW, Consortium, process, Team, Recommendation, Advisory Committee, Advisory Board, Working Group, Coordination Group, Interest Group, W3C Activity, Workshop, Symposium, charter, Activity Proposal, Working Draft, Process Document, Candidate Recommendation, Director, Proposed Recommendation, Last Call, Submission request">
    <link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/base.css">
    <title>World Wide Web Consortium Process Document</title>
    <style type="text/css">
     .about { margin-left: 3em; margin-right: 3em; font-size: .83em}
     table { margin-left: auto; margin-right: auto }
     .diagram { text-align: center; margin: 2.5em 0 }
      .issue:before {content: "Issue: "}
      .issue {border: 2px dashed red; background-color: #ffa;}
      .issue .issue {background-color: #fcc;}
      .rfc2119 {font-variant:small-caps}
</style> <!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
  </head>
  <body>
    <div class="head"><a href="http://www.w3.org/"><img alt="W3C" src="https://www.w3.org/Icons/w3c_home" height="48" width="72"></a>
      <h1>W3C Draft Process Document</h1>
      <h2 class="notoc">28 January 2015 Editor's Draft</h2>
      <dl>
        <dt>Latest Editor's version:</dt>
        <dd> <a href="https://dvcs.w3.org/hg/AB/raw-file/default/cover.html">https://dvcs.w3.org/hg/AB/raw-file/default/cover.html</a></dd>
        <dt>Latest operative version:</dt>
        <dd><a href="http://www.w3.org/Consortium/Process/">http://www.w3.org/Consortium/Process/</a></dd>
        <dt>Editor:</dt>
        <dd>Charles McCathie Nevile, <a style="color:black" href="http://yandex.com"><span style="color: red;">Y</span>andex</a>—<a style="color:black"
            href="http://yandex.ru"><span
              style="color: red;">Я</span>ндекс</a></dd>
        <dt>Previous editor:</dt>
        <dd>Ian Jacobs, <a href="http://www.w3.org/">W3C</a></dd>
      </dl>
      <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 1996-2015 <a href="/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr
            title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved. W3C <a href="/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
        <a href="/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a rel="Copyright" href="/Consortium/Legal/copyright-documents">document
-          use</a> and <a rel="Copyright" href="/Consortium/Legal/copyright-software">software licensing</a> rules apply. Your interactions
        with this site are in accordance with our <a href="/Consortium/Legal/privacy-statement#Public">public</a> and <a href="/Consortium/Legal/privacy-statement#Members">Member</a>
        privacy statements.</p>
      <hr></div>
    <h2 class="notoc"><a id="abstract">Abstract</a></h2>
    <p>The mission of the World Wide Web Consortium (<abbr>W3C</abbr>) is to lead the World Wide Web to its full potential by developing
      common protocols that promote its evolution and ensure its interoperability. The W3C Process Document describes the organizational
      structure of the W3C and the processes related to the responsibilities and functions they exercise to enable W3C to accomplish its
      mission. This document does not describe the internal workings of the Team or W3C's public communication mechanisms.</p>
    <p>For more information about the W3C mission and the history of W3C, please refer to <a href="http://www.w3.org/Consortium/">About W3C</a>
      [<a href="#ref-mission">PUB15</a>].</p>
    <h2 class="notoc" id="status">Status of this Document</h2>
    <p>W3C, including all existing chartered groups, follows the <a href="http://www.w3.org/Consortium/Process/">most recent operative
        Process Document</a> announced to the Membership.</p>
    <p>This document is developed by the Advisory Board's Process Task Force (which anyone may join) working within the <a href="http://www.w3.org/community/w3process/">Revising
-        W3C Process Community Group</a>. This is the 28 January 2015 Editor's draft for the proposed next version of the W3C Process
      Document. This document is based on the 30 September review draft, itself based on the 1 August 2014 Process, developed between the <a
        href="/2002/ab/">W3C
-        Advisory Board</a> and the <a href="http://www.w3.org/community/w3process/">Revising W3C Process Community Group</a> and adopted as
      the currently operative Process.</p>
    <p>Note that sections have not been renumbered from the current Operative version. This is intended to facilitate comparison for review,
      but renumbering will occur before adoption of a New Process document.</p>
    <p>In <em>this draft</em> various minor editorial and markup corrections have been made. A <a href="#changes">change history</a>
      (compared to the 2014 Process Document) forms part of the draft.</p>
    <p>The document will continue to be developed in preparation for adopting a revised process in 2015. A further revision is anticipated,
      to be adopted in 2016.</p>
    <p>Comment is invited on the draft. Please send comments to <a href="mailto:public-w3process@w3.org">public-w3process@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-w3process/">Mailing
+<!DOCTYPE html>
+<html lang="en">
+  <head>
+    <meta content="text/html; charset=utf-8" http-equiv="content-type">
+    <meta name="keywords" content="W3C, World Wide Web, WWW, Consortium, process, Team, Recommendation, Advisory Committee,
+Advisory Board, Working Group, Coordination Group, Interest Group, W3C Activity, Workshop, Symposium, charter, Activity Proposal,
+Working Draft, Process Document, Candidate Recommendation, Director, Proposed Recommendation, Last Call, Submission request">
+    <link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/base.css">
+    <title>World Wide Web Consortium Process Document</title>
+    <style type="text/css">
+     .about { margin-left: 3em; margin-right: 3em; font-size: .83em}
+     table { margin-left: auto; margin-right: auto }
+     .diagram { text-align: center; margin: 2.5em 0 }
+      .issue:before {content: "Issue: "}
+      .issue {border: 2px dashed red; background-color: #ffa;}
+      .issue .issue {background-color: #fcc;}
+      .rfc2119 {font-variant:small-caps}
+</style> <!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
+  </head>
+  <body>
+    <div class="head"><a href="http://www.w3.org/"><img alt="W3C" src="https://www.w3.org/Icons/w3c_home" height="48" width="72"></a>
+      <h1>W3C Draft Process Document</h1>
+      <h2 class="notoc">29 January 2015 Editor's Draft</h2>
+      <dl>
+        <dt>Latest Editor's version:</dt>
+        <dd> <a href="https://dvcs.w3.org/hg/AB/raw-file/default/cover.html">https://dvcs.w3.org/hg/AB/raw-file/default/cover.html</a></dd>
+        <dt>Latest operative version:</dt>
+        <dd><a href="http://www.w3.org/Consortium/Process/">http://www.w3.org/Consortium/Process/</a></dd>
+        <dt>Editor:</dt>
+        <dd>Charles McCathie Nevile, <a style="color:black" href="http://yandex.com"><span style="color: red;">Y</span>andex</a>—<a style="color:black"
+            href="http://yandex.ru"><span style="color: red;">Я</span>ндекс</a></dd>
+        <dt>Previous editor:</dt>
+        <dd>Ian Jacobs, <a href="http://www.w3.org/">W3C</a></dd>
+      </dl>
+      <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 1996-2015 
+        <a href="/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr
+            title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>,
+        <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved. W3C <a href="/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+        <a href="/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a rel="Copyright" href="/Consortium/Legal/copyright-documents">document
+          use</a> and <a rel="Copyright" href="/Consortium/Legal/copyright-software">software licensing</a> rules apply. Your interactions
+        with this site are in accordance with our <a href="/Consortium/Legal/privacy-statement#Public">public</a> and 
+        <a href="/Consortium/Legal/privacy-statement#Members">Member</a>
+        privacy statements.</p>
+      <hr></div>
+    <h2 class="notoc"><a id="abstract">Abstract</a></h2>
+    <p>The mission of the World Wide Web Consortium (<abbr>W3C</abbr>) is to lead the World Wide Web to its full potential by developing
+      common protocols that promote its evolution and ensure its interoperability. The W3C Process Document describes the organizational
+      structure of the W3C and the processes related to the responsibilities and functions they exercise to enable W3C to accomplish its
+      mission. This document does not describe the internal workings of the Team or W3C's public communication mechanisms.</p>
+    <p>For more information about the W3C mission and the history of W3C, please refer to <a href="http://www.w3.org/Consortium/">About W3C</a>
+      [<a href="#ref-mission">PUB15</a>].</p>
+    <h2 class="notoc" id="status">Status of this Document</h2>
+    <p>W3C, including all existing chartered groups, follows the <a href="http://www.w3.org/Consortium/Process/">most recent operative
+        Process Document</a> announced to the Membership.</p>
+    <p>This document is developed by the Advisory Board's Process Task Force (which anyone may join) working within the 
+      <a href="http://www.w3.org/community/w3process/">Revising
+        W3C Process Community Group</a>. This is the 28 January 2015 Editor's draft for the proposed next version of the W3C Process
+      Document. This document is based on the 30 September review draft, itself based on the 1 August 2014 Process, developed between the <a
+        href="/2002/ab/">W3C Advisory Board</a> and the <a href="http://www.w3.org/community/w3process/">Revising W3C Process Community
+        Group</a> and adopted as the currently operative Process.</p>
+    <p>Note that sections have not been renumbered from the current Operative version. This is intended to facilitate comparison for review,
+      but renumbering will occur before adoption of a New Process document.</p>
+    <p>In <em>this draft</em> line feed characters have been used in the source. A <a href="#changes">change history</a>
+      (compared to the 2014 Process Document) forms part of the draft.</p>
+    <p>The document will continue to be developed in preparation for adopting a revised process in 2015. A further revision is anticipated,
+      to be adopted in 2016.</p>
+    <p>Comment is invited on the draft. Please send comments to <a href="mailto:public-w3process@w3.org">public-w3process@w3.org</a> 
+      (<a href="http://lists.w3.org/Archives/Public/public-w3process/">Mailing
         list archive</a>, publicly available) or to process-issues@w3.org (<a href="http://lists.w3.org/Archives/Member/process-issues">Member-only
         archive</a>). A <a href="https://www.w3.org/community/w3process/track/">Public Issue Tracker</a> and <a href="https://dvcs.w3.org/hg/AB/">detailed
-        changelogs</a> are available online. </p>
    <h2 class="notoc" id="pp">Relation of Process Document to Patent Policy</h2>
    <p>W3C Members' attention is called to the fact that provisions of the Process Document are binding on Members per the <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
+        changelogs</a> are available online. </p>
+    <h2 class="notoc" id="pp">Relation of Process Document to Patent Policy</h2>
+    <p>W3C Members' attention is called to the fact that provisions of the Process Document are binding on Members per the 
+      <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
         Agreement</a> [<a href="#ref-member-agreement">PUB6</a>]. The Patent Policy <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
-        Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>] is incorporated by normative reference as a part of the Process Document,
      and is thus equally binding.</p>
    <p>The Patent Policy places additional obligations on Members, Team, and other participants in W3C. The Process Document does not
      restate those requirements but includes references to them. The Process Document and Patent Policy have been designed so that they may
      evolve independently.</p>
    <p>In the Process Document, the term "participant" refers to an individual, not an organization.</p>
    <h2 class=".notoc">Conformance and specialized terms</h2>
    <p>The terms <em class="rfc2119">must</em>, <em class="rfc2119">must not</em>, <em class="rfc2119">should</em>, <em class="rfc2119">should
-        not</em>, <em class="rfc2119">required</em>, and <em class="rfc2119">may</em> are used in accordance with <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC
-        2119</a> [<a href="#ref-RFC2119">RFC2119</a>]. The term <dfn><em class="rfc2119">not required</em></dfn> is equivalent to the term
      <em class="rfc2119">may</em> as defined in RFC 2119.&nbsp;</p>
    <p>Some terms have been capitalized in this document (and in other W3C materials) to indicate that they are entities with special
      relevance to the W3C Process. These terms are defined herein, and readers should be aware that the ordinary (English) definitions are
      incomplete for purposes of understanding this document.</p>
    <div class="toc" role="navigation">
      <h2 class="notoc" id="toc">Table of Contents</h2>
      <div class="noprint">
        <ul class="toc">
          <li class="tocline2"><a href="#Intro" class="tocxref">1 Introduction</a></li>
          <li class="tocline2"><a href="#Organization" class="tocxref">2 Members, Advisory Committee, Team, Advisory Board, Technical
              Architecture Group</a></li>
          <li class="tocline2"><a href="#Policies" class="tocxref">3 General Policies for W3C Groups</a></li>
          <li class="tocline2"><a href="#dissemination" class="tocxref">4 Dissemination Policies</a></li>
          <li class="tocline2"><s>5 Activities</s></li>
          <li class="tocline2"><a href="#GAGeneral" class="tocxref">6 Working Groups and Interest Groups</a></li>
          <li class="tocline2"><a href="#Reports" class="tocxref">7 W3C Technical Report Development Process</a></li>
          <li class="tocline2"><a href="#ReviewAppeal" class="tocxref">8 Advisory Committee Reviews, Appeals, and Votes</a></li>
          <li class="tocline2"><a href="#GAEvents" class="tocxref">9 Workshops and Symposia</a></li>
          <li class="tocline2"><a href="#Liaisons" class="tocxref">10 Liaisons</a></li>
          <li class="tocline2"><a href="#Submission" class="tocxref">11 Member Submission Process</a></li>
          <li class="tocline2"><a href="#GAProcess" class="tocxref">12 Process Evolution</a></li>
          <li class="tocline2"><a href="#references" class="tocxref">13 References</a></li>
          <li class="tocline2"><a href="#acks" class="tocxref">14 Acknowledgments</a></li>
          <li class="tocline2"><a href="#changes" class="tocxref">15 Changes</a></li>
        </ul>
      </div>
    </div>
    <div class="longtoc">
      <div class="noprint">
        <h3 class="notoc" id="fulltoc">Expanded table of contents</h3>
      </div>
      <ul class="toc">
        <li class="tocline2"><a href="#Intro">1 Introduction</a></li>
        <li class="tocline2"><a href="#Organization">2 Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group</a>
          <ul class="toc">
            <li class="tocline3"><a href="#Members">2.1 Members</a>
              <ul class="toc">
                <li class="tocline4"><a href="#MemberBenefits">2.1.1 Rights of Members</a></li>
                <li class="tocline4"><a href="#MemberRelated">2.1.2 Related Members</a></li>
                <li class="tocline4"><a href="#AC">2.1.3 Advisory Committee (AC)</a></li>
              </ul>
            </li>
            <li class="tocline3"><a href="#Team">2.2 The W3C Team</a>
              <ul class="toc">
                <li class="tocline4"><a href="#TeamSubmission">2.2.1 Team Submissions</a></li>
              </ul>
            </li>
            <li class="tocline3"><a href="#AB">2.3 Advisory Board (AB)</a>
              <ul class="toc">
                <li class="tocline4"><a href="#ABParticipation">2.3.1 Advisory Board Participation</a></li>
              </ul>
            </li>
            <li class="tocline3"><a href="#TAG">2.4 Technical Architecture Group (TAG)</a>
              <ul class="toc">
                <li class="tocline4"><a href="#tag-participation">2.4.1 Technical Architecture Group Participation</a></li>
              </ul>
            </li>
            <li class="tocline3"><a href="#AB-TAG-participation">2.5 Advisory Board and Technical Architecture Group Participation</a>
              <ul class="toc">
                <li class="tocline4"><a href="#AB-TAG-constraints">2.5.1 Advisory Board and Technical Architecture Group Participation
                    Constraints</a></li>
                <li class="tocline4"><a href="#AB-TAG-elections">2.5.2 Advisory Board and Technical Architecture Group Elections</a></li>
                <li class="tocline4"><a href="#AB-TAG-vacated">2.5.3 Advisory Board and Technical Architecture Group Vacated Seats</a></li>
              </ul>
            </li>
          </ul>
        </li>
        <li class="tocline2"><a href="#Policies">3 General Policies for W3C Groups</a>
          <ul class="toc">
            <li class="tocline3"><a href="#ParticipationCriteria">3.1 Individual Participation Criteria</a>
              <ul class="toc">
                <li class="tocline4"><a href="#coi">3.1.1 Conflict of Interest Policy</a></li>
                <li class="tocline4"><a href="#member-rep">3.1.2 Individuals Representing a Member Organization</a></li>
              </ul>
            </li>
            <li class="tocline3"><a href="#GeneralMeetings">3.2 Meetings</a></li>
            <li class="tocline3"><a href="#Consensus">3.3 Consensus</a>
              <ul class="toc">
                <li class="tocline4"><a href="#managing-dissent">3.3.1 Managing Dissent</a></li>
                <li class="tocline4"><a href="#WGArchiveMinorityViews">3.3.2 Recording and Reporting Formal Objections</a></li>
                <li class="tocline4"><a href="#formal-address">3.3.3 Formally Addressing an Issue</a></li>
                <li class="tocline4"><a href="#WGChairReopen">3.3.4 Reopening a Decision When Presented With New Information</a></li>
              </ul>
            </li>
            <li class="tocline3"><a href="#Votes">3.4 Votes</a></li>
            <li class="tocline3"><a href="#WGAppeals">3.5 Appeal of a Chair's Decision</a></li>
            <li class="tocline3"><a href="#resignation">3.6 Resignation from a Group</a></li>
          </ul>
        </li>
        <li class="tocline2"><a href="#dissemination">4 Dissemination Policies</a>
          <ul class="toc">
            <li class="tocline3"><a href="#confidentiality-levels">4.1 Confidentiality Levels</a>
              <ul class="toc">
                <li class="tocline4"><a href="#confidentiality-change">4.1.1 Changing Confidentiality Level</a></li>
              </ul>
            </li>
          </ul>
        </li>
        <li class="tocline2"><a href="#GAGeneral">6 Working Groups and Interest Groups</a>
          <ul class="toc">
            <li class="tocline3"><a href="#ReqsAllGroups">6.1 Requirements for All Working and Interest Groups</a></li>
            <li class="tocline3"><a href="#GroupsWG">6.2 Working Groups and Interest Groups</a>
              <ul class="toc">
                <li class="tocline4"><a href="#group-participation">6.2.1 Working Group and Interest Group Participation Requirements</a></li>
                <li class="tocline4"><a href="#WGCharterDevelopment">6.2.2 Working Group and Interest Group Charter Development</a></li>
                <li class="tocline4"><a href="#CharterReview">6.2.3 Advisory Committee Review of a Working Group or Interest Group Charter</a></li>
                <li class="tocline4"><a href="#cfp">6.2.4 Call for Participation in a Working Group or Interest Group</a></li>
                <li class="tocline4"><a href="#charter-extension">6.2.5 Working Group and Interest Group Charter Extension</a></li>
                <li class="tocline4"><a href="#WGCharter">6.2.6 Working Group and Interest Group Charters</a></li>
                <li class="tocline4"><a href="#GeneralTermination">6.2.8 Working Group and Interest Group Closure</a></li>
              </ul>
            </li>
          </ul>
        </li>
        <li class="tocline2"><a href="#Reports">7 W3C Technical Report Development Process</a>
          <ul class="toc">
            <li><a href="#rec-advance">7.1 W3C Technical Reports</a>
              <ul class="toc">
                <li><a href="#recs-and-notes" id="return-to-wg">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 class="toc">
                <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 class="toc">
                    <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 class="toc">
                    <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 class="toc">
                <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">7.3.3 Stopping work on a specification</a></li>
              </ul>
            </li>
            <li><a href="#candidate-rec" id="cfi">7.4 Candidate Recommendation</a>
              <ul class="toc">
                <li><a href="#revised-cr">7.4.1 Revising a Candidate Recommendation</a></li>
              </ul>
            </li>
            <li> <a href="#rec-pr" id="cfr">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 class="toc">
                <li><a href="#errata">7.7.1 Errata Management</a></li>
                <li><a href="#revised-rec" id="cfr-edited">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>
        </li>
        <li class="tocline2"><a href="#ReviewAppeal">8 Advisory Committee Reviews, Appeals, and Votes</a>
          <ul class="toc">
            <li class="tocline3"><a href="#ACReview">8.1 Advisory Committee Reviews</a>
              <ul class="toc">
                <li class="tocline4"><a href="#ACReviewStart">8.1.1 Start of a Review Period</a></li>
                <li class="tocline4"><a href="#ACReviewAfter">8.1.2 After the Review Period</a></li>
              </ul>
            </li>
            <li class="tocline3"><a href="#ACAppeal">8.2 Appeal by Advisory Committee Representatives</a></li>
            <li class="tocline3"><a href="#ACVotes">8.3 Advisory Committee Votes</a></li>
          </ul>
        </li>
        <li class="tocline2"><a href="#GAEvents">9 Workshops and Symposia</a></li>
        <li class="tocline2"><a href="#Liaisons">10 Liaisons</a></li>
        <li class="tocline2"><a href="#Submission">11 Member Submission Process</a>
          <ul class="toc">
            <li class="tocline3"><a href="#SubmissionRights">11.1 Submitter Rights and Obligations</a>
              <ul class="toc">
                <li class="tocline4"><a href="#SubmissionScope">11.1.1 Scope of Member Submissions</a></li>
                <li class="tocline4"><a href="#SubmissionReqs">11.1.2 Information Required in a Submission Request</a></li>
              </ul>
            </li>
            <li class="tocline3"><a href="#TeamSubmissionRights">11.2 Team Rights and Obligations</a></li>
            <li class="tocline3"><a href="#SubmissionYes">11.3 Acknowledgment of a Submission Request</a></li>
            <li class="tocline3"><a href="#SubmissionNo">11.4 Rejection of a Submission Request</a></li>
          </ul>
        </li>
        <li class="tocline2"><a href="#GAProcess">12 Process Evolution</a></li>
        <li class="tocline2"><a href="#references">13 References</a>
          <ul class="toc">
            <li class="tocline3"><a href="#public-refs">13.1 Public Resources</a></li>
            <li class="tocline3"><a href="#member-refs">13.2 Member-only Resources</a></li>
            <li class="tocline3"><a href="#other-refs">13.3 Other References</a></li>
          </ul>
        </li>
        <li class="tocline2"><a href="#acks">14 Acknowledgments</a></li>
        <li class="tocline2"><a href="#changes">15 Changes</a></li>
      </ul>
    </div>
    <main>
      <h2 id="Intro">1 Introduction</h2>
      <p>Most W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that promote
        the development of high-quality standards based on the <a href="#Consensus">consensus</a> of the Membership, Team, and public. W3C
        processes promote fairness, responsiveness, and progress: all facets of the W3C mission. This document describes the processes W3C
        follows in pursuit of its mission.</p>
      <p>Here is a general overview of how W3C standardizes a Web technology. In many cases, the goal of this work is a <a href="#RecsW3C">W3C
-          Recommendation</a>, the W3C equivalent of a Web standard.</p>
      <ol>
        <li>People generate interest in a particular topic (e.g., Web services). For instance, Members express interest in the form of <a href="#Submission">Member
-            Submissions</a>, and the <a href="#Team">Team</a> monitors work inside and outside of W3C for signs of interest. Also, W3C is
          likely to organize a <a href="#GAEvents">Workshop</a> to bring people together to discuss topics that interest the W3C community.</li>
        <li>When there is enough interest in a topic (e.g., after a successful Workshop and/or discussion on an <a href="#ACCommunication">Advisory
-            Committee mailing list</a>), the Director announces the <a href="#ActivityDevelopment">development of a proposal for one or
            more new</a> or Interest Group or <a href="#WGCharterDevelopment">Working Group charter</a>, depending on the breadth of the
          topic of interest. W3C Members <a href="#ActivityCreation">review</a> the proposed charters. When there is support within W3C for
          investing resources in the topic of interest, the Director approves the group(s) and they begin their work.</li>
        <li>There are three types of Working Group participants: <a href="#member-rep">Member representatives</a>, <a href="#invited-expert-wg">Invited
-            Experts</a>, and <a href="#Team">Team representatives</a>. Team representatives both contribute to the technical work and help
          ensure the group's proper integration with the rest of W3C. The <a href="#WGCharter">Working Group charter</a> sets expectations
          about each group's deliverables (e.g., <a href="#Reports">technical reports</a>, test suites, and tutorials).</li>
        <li>Working Groups generally create specifications and guidelines that undergo cycles of revision and review as they <a href="#rec-advance">advance
-            to W3C Recommendation</a> status. The W3C process for producing these technical reports includes significant review by the
          Members and public, and requirements that the Working Group be able to show implementation and interoperability experience. At the
          end of the process, the Advisory Committee reviews the mature technical report, and if there is support, W3C publishes it as a <a
            href="#RecsW3C">Recommendation</a>.</li>
      </ol>
      <p>The Process Document promotes the goals of quality and fairness in technical decisions by encouraging <a href="#Consensus">consensus</a>,
        requiring reviews (by both Members and public) as part of the <a href="#Reports">technical report development process</a>, and
        through an <a href="#ACAppeal">appeal process</a> for the Advisory Committee.</p>
      <p>The other sections of the Process Document:</p>
      <ol>
        <li>set forth <a href="#Policies">policies</a> for participation in W3C groups,</li>
        <li>establish two permanent groups within W3C: the <a href="#TAG">Technical Architecture Group (TAG)</a>, to help resolve
          Consortium-wide technical issues; and the <a href="#AB">Advisory Board (AB)</a>, to help resolve Consortium-wide non-technical
          issues, and to manage the <a href="#GAProcess">evolution of the W3C process</a>, and</li>
        <li>describe other interactions between the <a href="#Members">Members</a> (as represented by the <a href="#AC">W3C Advisory
            Committee</a>), the Team, and the general public.</li>
      </ol>
      <h2 id="Organization">2 Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group</h2>
      <p>W3C's mission is to lead the Web to its full potential. W3C <a href="#Members">Member</a> organizations provide resources to this
        end, and the W3C <a href="#Team">Team</a> provides the technical leadership and organization to coordinate the effort.</p>
      <h3 id="Members">2.1 Members</h3>
      <p>W3C Members are primarily represented in W3C processes as follows:</p>
      <ol>
        <li>The <a href="#AC">Advisory Committee</a> is composed of one representative from each Member organization (refer to the <a href="#Member-only">Member-only</a>
          list of <a href="http://www.w3.org/Member/ACList">current Advisory Committee representatives</a> [<a href="#ref-current-ac">MEM1</a>]).
-          The Advisory Committee:
          <ul>
            <li>reviews plans for W3C at each <a href="#ACMeetings">Advisory Committee meeting</a>;</li>
            <li>reviews formal proposals from the W3C Director: <a href="#CharterReview">Charter Proposals</a>, <a href="#RecsPR">Proposed
                Recommendations</a>, and <a href="#GAProcess">Proposed Process Documents</a>.</li>
            <li>elects the <a href="#AB">Advisory Board</a> participants other than the Advisory Board Chair.</li>
            <li>elects 5 of the 9 participants on the <a href="#TAG">Technical Architecture Group</a>.</li>
          </ul>
          Advisory Committee representatives have <a href="#ACAppeal">appeal</a> powers for some processes described in this document.</li>
        <li>Representatives of Member organizations participate in <a href="#GAGeneral">Working Groups and Interest Groups</a> and author
          and review <a href="#Reports">technical reports</a>.</li>
      </ol>
      <p id="MemberSubscription">W3C membership is open to all entities, as described in "<a href="http://www.w3.org/Consortium/join">How to
          Join W3C</a>" [<a href="#ref-join-w3c">PUB5</a>]; (refer to the public list of <a href="http://www.w3.org/Consortium/Member/List">current
-          W3C Members</a> [<a href="#ref-current-mem">PUB8</a>]). Organizations subscribe according to the <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
-          Agreement</a> [<a href="#ref-member-agreement">PUB6</a>]. The <a href="#Team">Team</a> <em class="rfc2119">must</em> ensure that
        Member participation agreements remain <a href="#Team-only">Team-only</a> and that no Member receives preferential treatment within
        W3C.</p>
      <p id="IndividualParticipation">W3C does not have a class of membership tailored to, or priced for individuals. However, an individual
        <em class="rfc2119">may</em> join W3C as an Affiliate Member. In this case the same restrictions pertaining to <a href="#MemberRelated">related
-          Members</a> apply when the individual also <a href="#member-rep">represents</a> another W3C Member.</p>
      <h4 id="MemberBenefits">2.1.1 Rights of Members</h4>
      <p>Each Member organization enjoys the following rights and benefits:</p>
      <ul>
        <li>A seat on the <a href="#AC">Advisory Committee</a>;</li>
        <li>Access to <a href="#Member-only">Member-only</a> information;</li>
        <li>The <a href="#Submission">Member Submission</a> process;</li>
        <li>Use of the W3C Member logo on promotional material and to publicize the Member's participation in W3C. For more information,
          please refer to the Member logo usage policy described in the <a href="http://www.w3.org/Member/Intro">New Member Orientation</a>
          [<a href="#ref-new-member">MEM4</a>].</li>
      </ul>
      <p>Furthermore, representatives of Member organizations participate in W3C as follows:</p>
      <ul>
        <li>In <a href="#GAGeneral">Working Groups and Interest Groups</a>.</li>
        <li>In <a href="#GAEvents">Workshops and Symposia</a>;</li>
        <li>On the Team, as <a href="#fellows">W3C Fellows</a>.</li>
      </ul>
      <p>In the case (described in paragraph 5g of the <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
          Agreement</a>), where a Member organization is itself a consortium, user society, or otherwise has members or sponsors, the
        organization's paid staff and Advisory Committee representative exercise all the rights and privileges of W3C membership. In
        addition, the Advisory Committee representative <em class="rfc2119">may</em> designate up to four (or more at the Team's
        discretion) individuals who, though not employed by the organization, <em class="rfc2119">may</em> exercise the rights of <a href="#member-rep">Member
-          representatives</a>. These individuals <em class="rfc2119">must</em> disclose their employment affiliation when participating in
        W3C work. Provisions for <a href="#MemberRelated">related Members</a> apply. Furthermore, these individuals are expected to
        represent the broad interests of the W3C Member organization and not the parochial interests of their employers.</p>
      <p>The rights and benefits of W3C membership are contingent upon conformance to the processes described in this document. The vast
        majority of W3C Members faithfully follow the spirit as well as the letter of these processes. When serious and/or repeated
        violations do occur, and repeated attempts to address these violations have not resolved the situation, the Director <em class="rfc2119">may</em>
        take disciplinary action. Arbitration in the case of further disagreement is governed by paragraph 19 of the Membership Agreement.
        Refer to the <a href="http://www.w3.org/2002/09/discipline">Guidelines for Disciplinary Action</a> [<a href="#ref-discipline-gl">MEM14</a>].</p>
      <h4 id="MemberRelated">2.1.2 Related Members</h4>
      <p>In the interest of ensuring the integrity of the consensus process, Member involvement in some of the processes in this document is
        affected by related Member status. As used herein, two Members are related if:</p>
      <ol>
        <li>Either Member is a subsidiary of the other, or</li>
        <li>Both Members are subsidiaries of a common entity, or</li>
        <li>The Members have an employment contract or consulting contract that affects W3C participation.</li>
      </ol>
      <p>A <em>subsidiary</em> is an organization of which effective control and/or majority ownership rests with another, single
        organization.</p>
      <p>Related Members <em class="rfc2119">must</em> disclose these relationships according to the mechanisms described in the <a href="http://www.w3.org/Member/Intro">New
-          Member Orientation</a> [<a href="#ref-new-member">MEM4</a>].</p>
      <h4 id="AC">2.1.3 Advisory Committee (AC)</h4>
      <p>When an organization joins W3C (see "<a href="http://www.w3.org/Consortium/join">How to Join W3C</a>" [<a href="#ref-join-w3c">PUB5</a>]),
-        it <em class="rfc2119">must</em> name its Advisory Committee representative as part of the Membership Agreement. The <a href="http://www.w3.org/Member/Intro">New
-          Member Orientation</a> explains how to subscribe or unsubscribe to Advisory Committee mailing lists, provides information about
        Advisory Committee meetings, explains how to name a new Advisory Committee representative, and more. Advisory Committee
        representatives <em class="rfc2119">must</em> follow the <a href="#coi">conflict of interest policy</a> by disclosing information
        according to the mechanisms described in the New Member Orientation. See also the additional roles of Advisory Committee
        representatives described in the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
      <p>Additional information for Members is available at the <a href="http://www.w3.org/Member/">Member Web site</a> [<a href="#ref-member-web">MEM6</a>].</p>
      <h5 id="ACCommunication">2.1.3.1 Advisory Committee Mailing Lists</h5>
      <p>The Team <em class="rfc2119">must</em> provide two mailing lists for use by the Advisory Committee:</p>
      <ol>
        <li>One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. This list is
          read-only for Advisory Committee representatives.</li>
        <li>One for discussion among Advisory Committee representatives. Though this list is primarily for Advisory Committee
          representatives, the Team <em class="rfc2119">must</em> monitor discussion and <em class="rfc2119">should</em> participate in
          discussion when appropriate. Ongoing detailed discussions <em class="rfc2119">should</em> be moved to other appropriate lists
          (new or existing, such as a mailing list created for a <a href="#GAEvents">Workshop</a>).</li>
      </ol>
      <p>An Advisory Committee representative <em class="rfc2119">may</em> request that additional individuals from their organization be
        subscribed to these lists. Failure to contain distribution internally <em class="rfc2119">may</em> result in suspension of
        additional email addresses, at the discretion of the Team.</p>
      <h5 id="ACMeetings">2.1.3.2 Advisory Committee Meetings</h5>
      <p>The Team organizes a <a href="#ftf-meeting">face-to-face meeting</a> for the Advisory Committee <span class="time-interval">twice
          a year</span>. The Team appoints the Chair of these meetings (generally the <a href="#def-W3CChair">CEO</a>). At each Advisory
        Committee meeting, the Team <em class="rfc2119">should</em> provide an update to the Advisory Committee about:</p>
      <dl>
        <dt><em>Resources</em></dt>
        <dd>
          <ul>
            <li>The number of Full and Affiliate W3C Members.</li>
            <li>An overview of the financial status of W3C.</li>
          </ul>
        </dd>
        <dt><em>Allocations</em></dt>
        <dd>
          <ul>
            <li>The allocation of the annual budget, including size of the Team and their approximate deployment.</li>
            <li>A list of all activities (including but not limited to Working and Interest Groups) and brief status statement about each,
              in particular those started or terminated since the previous Advisory Committee meeting.</li>
            <li>The allocation of resources to pursuing <a href="#Liaisons">liaisons</a> with other organizations.</li>
          </ul>
        </dd>
      </dl>
      <p>Each Member organization <em class="rfc2119">should</em> send one <a href="#member-rep">representative</a> to each Advisory
        Committee meeting. In exceptional circumstances (e.g., during a period of transition between representatives from an organization),
        the meeting Chair <em class="rfc2119">may</em> allow a Member organization to send two representatives to a meeting.</p>
      <p>The Team <em class="rfc2119">must</em> announce the date and location of each Advisory Committee meeting no later than at the end
        of the previous meeting; <span class="time-interval">one year's</span> notice is preferred. The Team <em class="rfc2119">must</em>
        announce the region of each Advisory Committee meeting at least <span class="time-interval">one year</span> in advance.</p>
      <p>More information about <a href="http://www.w3.org/Member/Meeting/">Advisory Committee meetings</a> [<a href="#ref-ac-meetings">MEM5</a>]
        is available at the Member Web site.</p>
      <h3 id="Team">2.2 The W3C Team</h3>
      <p>The Team consists of the Director, CEO, W3C paid staff, unpaid interns, and W3C Fellows. <dfn id="fellows">W3C Fellows</dfn> are
        Member employees working as part of the Team; see the <a href="http://www.w3.org/Consortium/Recruitment/Fellows">W3C Fellows
          Program</a> [<a href="#ref-fellows">PUB32</a>]. The Team provides technical leadership about Web technologies, organizes and
        manages W3C activities to reach goals within practical constraints (such as resources available), and communicates with the Members
        and the public about the Web and W3C technologies.</p>
      <p>The Director and CEO <em class="rfc2119">may</em> delegate responsibility (generally to other individuals in the Team) for any of
        their roles described in this document.</p>
      <p>The <dfn id="def-Director">Director</dfn> is the lead technical architect at W3C. His responsibilities are identified throughout
        this document in relevant places Some key ones include: assessing <a href="#def-Consensus" id="DirectorDecision">consensus</a>
        within W3C for architectural choices, publication of <a href="#Reports">technical reports</a>, and new activities; appointing group
        <a href="#GeneralChairs">Chairs</a>; "tie-breaker" for <a href="#WGAppeals">appeal of a Working Group decision</a> and deciding on
        the outcome of formal objections; the Director is generally Chair of the <a href="#TAG">TAG</a>.</p>
      <p>Team administrative information such as Team salaries, detailed budgeting, and other business decisions are <a href="#Team-only">Team-only</a>,
        subject to oversight by the Host institutions.</p>
      <p><strong>Note:</strong> W3C is not currently incorporated. For legal contracts, W3C is represented by four <dfn id="hosts">"Host"
          institutions</dfn>: Beihang University, the European Research Consortium for Informatics and Mathematics (<abbr>ERCIM</abbr>),
        Keio University, and the Massachusetts Institute of Technology (<abbr>MIT</abbr>). Within W3C, the Host institutions are governed by
        hosting agreements; the Hosts themselves are not W3C Members.</p>
      <h4 id="TeamSubmission">2.2.1 Team Submissions</h4>
      <p>Team members <em class="rfc2119">may</em> request that the Director publish information at the W3C Web site. At the Director's
        discretion, these documents are published as "Team Submissions". These documents are analogous to <a href="#Submission">Member
          Submissions</a> (e.g., in <a href="#SubmissionScope">expected scope</a>). However, there is no additional Team comment. The <a href="#DocumentStatus">document
-          status section</a> of a Team Submission indicates the level of Team consensus about the published material.</p>
      <p>Team Submissions are <strong>not</strong> part of the <a href="#Reports">technical report development process</a>.</p>
      <p>The list of <a href="http://www.w3.org/TeamSubmission/">published Team Submissions</a> [<a href="#ref-team-submission-list">PUB16</a>]
        is available at the W3C Web site.</p>
      <h3 id="AB">2.3 Advisory Board (AB)</h3>
      <p>Created in March 1998, the Advisory Board provides ongoing guidance to the Team on issues of strategy, management, legal matters,
        process, and conflict resolution. The Advisory Board also serves the Members by tracking issues raised between Advisory Committee
        meetings, soliciting Member comments on such issues, and proposing actions to resolve these issues. The Advisory Board manages the <a
          href="#GAProcess">evolution
          of the Process Document</a>. The Advisory Board hears appeals of <a href="#SubmissionNo">Member Submission requests</a> that are
        rejected for reasons unrelated to Web architecture; see also the <a href="#TAG">TAG</a>.</p>
      <p>The Advisory Board is <strong>not</strong> a board of directors and has no decision-making authority within W3C; its role is
        strictly advisory.</p>
      <p>The Team <em class="rfc2119">must</em> make available a mailing list for the Advisory Board to use for its communication,
        confidential to the Advisory Board and Team.</p>
      <p>The Advisory Board <em class="rfc2119">should</em> send a summary of each of its meetings to the Advisory Committee and other
        group Chairs. The Advisory Board <em class="rfc2119">should</em> also report on its activities at each <a href="#ACMeetings">Advisory
-          Committee meeting</a>.</p>
      <p>Details about the Advisory Board (e.g., the list of Advisory Board participants, mailing list information, and summaries of
        Advisory Board meetings) are available at the <a href="http://www.w3.org/2002/ab/">Advisory Board home page</a> [<a href="#ref-ab-home">PUB30</a>].</p>
      <h4 id="ABParticipation">2.3.1 Advisory Board Participation</h4>
      <p>The Advisory Board consists of nine elected participants and a Chair. The Team appoints the Chair of the <a href="#AB">Advisory
          Board</a>, who is generally the <a href="#def-W3CChair">CEO</a>.</p>
      <p>The remaining nine Advisory Board participants are elected by the W3C Advisory Committee following the <a href="#AB-TAG-elections">AB/TAG
-          nomination and election process</a>.</p>
      <p>With the exception of the Chair, the terms of all Advisory Board participants are for <span class="time-interval">two years</span>.
        Terms are staggered so that each year, either four or five terms expire. If an individual is elected to fill an incomplete term,
        that individual's term ends at the normal expiration date of that term. Regular Advisory Board terms begin on 1 July and end on 30
        June.</p>
      <h3 id="TAG">2.4 Technical Architecture Group (TAG)</h3>
      <p>Created in February 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:</p>
      <ol>
        <li>to document and build consensus around principles of Web architecture and to interpret and clarify these principles when
          necessary;</li>
        <li>to resolve issues involving general Web architecture brought to the TAG;</li>
        <li>to help coordinate cross-technology architecture developments inside and outside W3C.</li>
      </ol>
      <p>The TAG hears appeals of <a href="#SubmissionNo">Member Submission requests</a> that are rejected for reasons related to Web
        architecture; see also the <a href="#AB">Advisory Board</a>.</p>
      <p>The TAG's scope is limited to technical issues about Web architecture. The TAG <em class="rfc2119">should not</em> consider
        administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee,
        Advisory Board, and Team. Please refer to the <a href="http://www.w3.org/2001/07/19-tag">TAG charter</a> [<a href="#ref-tag-charter">PUB25</a>]
        for more information about the background and scope of the TAG, and the expected qualifications of TAG participants.</p>
      <p>The Team <em class="rfc2119">must</em> make available two mailing lists for the TAG:</p>
      <ul>
        <li>a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business on this list.</li>
        <li>a <a href="#Member-only">Member-only</a> list for discussions within the TAG and for requests to the TAG that, for whatever
          reason, cannot be made on the public list.</li>
      </ul>
      <p>The TAG <em class="rfc2119">may</em> also request the creation of additional topic-specific, public mailing lists. For some TAG
        discussions (e.g., an appeal of a <a href="#SubmissionNo">rejected Member Submission request</a>), the TAG <em class="rfc2119">may</em>
        use a list that will be <a href="#Member-only">Member-only</a>.</p>
      <p>The TAG <em class="rfc2119">should</em> send a summary of each of its <a href="#GeneralMeetings">meetings</a> to the Advisory
        Committee and other group Chairs. The TAG <em class="rfc2119">should</em> also report on its activities at each <a href="#ACMeetings">Advisory
-          Committee meeting</a>.</p>
      <p>When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote; see also the
        section on <a href="http://www.w3.org/2001/07/19-tag#Voting">voting in the TAG charter</a> [<a href="#ref-tag-charter">PUB25</a>]
        and the general section on <a href="#Votes">votes</a> in this Process Document.</p>
      <p>Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) are available
        at the <a href="http://www.w3.org/2001/tag/">TAG home page</a> [<a href="#ref-tag-home">PUB26</a>].</p>
      <h4 id="tag-participation">2.4.1 Technical Architecture Group Participation</h4>
      <p>The TAG consists of eight elected or appointed participants and a Chair. The Team appoints the Chair of the TAG, who is generally
        the <a href="#def-Director">Director</a>.</p>
      <p>Three TAG participants are appointed by the Director. Appointees are <em class="rfc2119">not required</em> to be on the W3C Team.
        The Director <em class="rfc2119">may</em> appoint <a href="#fellows">W3C Fellows</a> to the TAG.</p>
      <p>The remaining five TAG participants are elected by the W3C Advisory Committee following the <a href="#AB-TAG-elections">AB/TAG
          nomination and election process</a>.</p>
      <p>With the exception of the Chair, the terms of all TAG participants are for <span class="time-interval">two years</span>. Terms are
        staggered so that each year, either two or three elected terms, and either one or two appointed terms expire. If an individual is
        appointed or elected to fill an incomplete term, that individual's term ends at the normal expiration date of that term. Regular TAG
        terms begin on 1 February and end on 31 January.</p>
      <h3 id="AB-TAG-participation">2.5 Advisory Board and Technical Architecture Group Participation</h3>
      <p>Advisory Board and TAG participants have a special role within W3C: they are elected by the Membership and appointed by the
        Director with the expectation that they will use their best judgment to find the best solutions for the Web, not just for any
        particular network, technology, vendor, or user. Advisory Board and TAG participants are expected to participate regularly and
        fully. Advisory Board and TAG participants <em class="rfc2119">should</em> attend <a href="#ACMeetings">Advisory Committee
          meetings</a>.</p>
      <p>An individual participates on the Advisory Board or TAG from the moment the individual's term begins until the term ends or the
        seat is <a href="#AB-TAG-vacated">vacated</a>. Although Advisory Board and TAG participants do not advocate for the commercial
        interests of their employers, their participation does carry the responsibilities associated with Member representation, Invited
        Expert status, or Team representation (as described in the section on the <a href="#AB-TAG-elections">AB/TAG nomination and
          election process</a>). See also the licensing obligations on TAG participants in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
-          3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>],
        and the claim exclusion process of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">section 4</a>.</p>
      <h4 id="AB-TAG-constraints">2.5.1 Advisory Board and Technical Architecture Group Participation Constraints</h4>
      <p>Given the few seats available on the Advisory Board and the TAG, and in order to ensure that the diversity of W3C Members is
        represented:</p>
      <ul>
        <li>A Member organization is permitted at most one participant on the TAG except when having more than one participant is caused by
          a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the
          Member organization MUST have returned to having at most one participant.</li>
        <li>A Member organization is permitted at most one participant on the AB.</li>
        <li>An individual <em class="rfc2119">must not</em> participate on both the TAG and the AB.</li>
      </ul>
      <p>If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participant <span
          class="rfc2119">MUST</span>
        cease AB participation until the situation has been resolved. If after <span class="time-interval">30 days</span> the situation has
        not been resolved, the Chair will declare one participant's seat to be vacant. When more than one individual is involved, the <a href="#random">verifiable
          random selection procedure</a> described below will be used to choose one person for continued participation.</p>
      <h4 id="AB-TAG-elections">2.5.2 Advisory Board and Technical Architecture Group Elections</h4>
      <p>The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee. An election begins when
        the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the number of available seats,
        the deadline for nominations, and the address where nominations are sent. The Director <em class="rfc2119">should</em> announce
        appointments no later than the start of a nomination period, and generally as part of the Call for Nominations.</p>
      <p>Each Member (or group of <a href="#MemberRelated">related Members</a>) <em class="rfc2119">may</em> nominate one individual. A
        nomination <em class="rfc2119">must</em> be made with the consent of the nominee. In order for an individual to be nominated as a
        Member representative, the individual <em class="rfc2119">must</em> qualify for <a href="#member-rep">Member representation</a>
        and the Member's Advisory Committee representative <em class="rfc2119">must</em> include in the nomination the (same) <a href="#member-rep-info">information
          required for a Member representative in a Working Group</a>. In order for an individual to be nominated as an Invited Expert, the
        individual <em class="rfc2119">must</em> provide the (same) <a href="#inv-expert-info">information required for an Invited Expert
          in a Working Group</a> and the nominating Advisory Committee representative <em class="rfc2119">must</em> include that
        information in the nomination. In order for an individual to be nominated as a Team representative, the nominating Advisory
        Committee representative <em class="rfc2119">must</em> first secure approval from Team management. A nominee is <span class="rfc2119">NOT
-          REQUIRED</span> to be an employee of a Member organization, and <em class="rfc2119">may</em> be a <a href="#fellows">W3C Fellow</a>.
        Each nomination <em class="rfc2119">should</em> include a few informative paragraphs about the nominee.</p>
      <p>If, after the deadline for nominations, the number of nominees is:</p>
      <ul>
        <li>Equal to the number of available seats, those nominees are thereby elected. This situation constitutes a tie for the purposes of
          assigning <a href="#short-term">short terms</a>.</li>
        <li>Less than the number of available seats, Calls for Nominations are issued until a sufficient number of people have been
          nominated. Those already nominated do not need to be renominated after a renewed call.</li>
        <li>Greater than the number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the
          number of available seats, the deadline for votes, and the address where votes are sent.</li>
      </ul>
      <p>When there is a vote, each Member (or group of <a href="#MemberRelated">related Members</a>) <em class="rfc2119">may</em> vote
        for as many candidates as there are available seats; see the section on <a href="#ACVotes">Advisory Committee votes</a>. Once the
        deadline for votes has passed, the Team announces the results to the Advisory Committee. The candidates with the most votes are
        elected to the available seats. In case of a tie where there are more apparent winners than available seats (e.g., three candidates
        receive 10 votes each for two seats), the <a href="#random">verifiable random selection procedure</a> described below will be used
        to fill the available seats.</p>
      <p id="short-term">The shortest term is assigned to the elected individual who received the fewest votes, the next shortest to the
        elected individual who received the next fewest, and so on. In the case of a tie among those eligible for a short term, the <a href="#random">verifiable
-          random selection procedure</a> described below will be used to assign the short term.</p>
      <p>Refer to <a href="http://www.w3.org/2002/10/election-howto">How to Organize an Advisory Board or TAG election</a> [<a href="#ref-election-howto">MEM15</a>]
        for more details.</p>
      <h5 id="random">2.5.2.1 Verifiable Random Selection Procedure</h5>
      <p>When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to "draw straws" in case of a
        tie or to fill a short term), W3C uses the random and verifiable procedure defined in <a href="http://www.ietf.org/rfc/rfc2777.txt">RFC
-          2777</a> [<a href="#ref-RFC2777">RFC2777</a>]. The procedure orders an input list of names (listed in alphabetical order by family
        name unless otherwise specified) into a "result order."</p>
      <p>W3C applies this procedure as follows:</p>
      <ol>
        <li>When N people have tied for M (less than N) seats. In this case, only the names of the N individuals who tied are provided as
          input to the procedure. The M seats are assigned in result order.</li>
        <li>After all elected individuals have been identified, when N people are eligible for M (less than N) short terms. In this case,
          only the names of those N individuals are provided as input to the procedure. The short terms are assigned in result order.</li>
      </ol>
      <h4 id="AB-TAG-vacated">2.5.3 Advisory Board and Technical Architecture Group Vacated Seats</h4>
      <p>An Advisory Board or TAG participant's seat is vacated when either of the following occurs:</p>
      <ul>
        <li>the participant <a href="#resignation">resigns</a>, or</li>
        <li>the Chair asks the participant to <a href="#resignation">resign</a>.</li>
      </ul>
      <p>When an Advisory Board or TAG participant changes affiliations, as long as <a href="#AB-TAG-constraints">Advisory Board and TAG
          participation constraints</a> are respected, the individual <em class="rfc2119">may</em> continue to participate until the next
        regularly scheduled election for that group. Otherwise, the seat is vacated.</p>
      <p>Vacated seats are filled according to this schedule:</p>
      <ul>
        <li>When an appointed TAG seat is vacated, the Director <em class="rfc2119">may</em> re-appoint someone immediately, but no later
          than the next regularly scheduled election.</li>
        <li>When an elected seat on either the AB or TAG is vacated, the seat is filled at the next regularly scheduled election for the
          group unless the group Chair requests that W3C hold an election before then (for instance, due to the group's workload). The group
          Chair <em class="rfc2119">should not</em> request an exceptional election if the next regularly scheduled election is fewer than
          three months away.</li>
      </ul>
      <h2 id="Policies">3 General Policies for W3C Groups</h2>
      <p>This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making. These
        policies apply to <span id="participant">participants</span> in the following groups: <a href="#AC">Advisory Committee</a>, <a href="#ABParticipation">Advisory
          Board</a>, <a href="#tag-participation">TAG</a>, <a href="#wgparticipant">Working Groups</a>, and <a href="#igparticipant">Interest
          Groups</a>.</p>
      <h3 id="ParticipationCriteria">3.1 Individual Participation Criteria</h3>
      <p>There are three qualities an individual is expected to demonstrate in order to participate in W3C:</p>
      <ol>
        <li>Technical competence in one's role</li>
        <li>The ability to act fairly</li>
        <li>Social competence in one's role</li>
      </ol>
      <p>Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities are
        responsible for assessing and attesting to the qualities of those nominees.</p>
      <p>See also the participation requirements described in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">section 6</a>
        of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
      <h4 id="coi">3.1.1 Conflict of Interest Policy</h4>
      <p>Individuals participating materially in W3C work <em class="rfc2119">must</em> disclose significant relationships when those
        relationships might reasonably be perceived as creating a conflict of interest with the individual's role at W3C. These disclosures
        <em class="rfc2119">must</em> be kept up-to-date as the individual's affiliations change and W3C membership evolves (since, for
        example, the individual might have a relationship with an organization that joins or leaves W3C). Each section in this document that
        describes a W3C group provides more detail about the disclosure mechanisms for that group.</p>
      <p>The ability of an individual to fulfill a role within a group without risking a conflict of interest is clearly a function of the
        individual's affiliations. When these affiliations change, the individual's assignment to the role <em class="rfc2119">must</em> be
        evaluated. The role <em class="rfc2119">may</em> be reassigned according to the appropriate process. For instance, the Director <em
          class="rfc2119">may</em>
        appoint a new group Chair when the current Chair changes affiliations (e.g., if there is a risk of conflict of interest, or if there
        is risk that the Chair's new employer will be over-represented within a W3C activity).</p>
      <p>The following are some scenarios where disclosure is appropriate:</p>
      <ul>
        <li>Paid consulting for an organization whose activity is relevant to W3C, or any consulting compensated with equity (shares of
          stock, stock options, or other forms of corporate equity).</li>
        <li>A decision-making role/responsibility (such as participating on the Board) in other organizations relevant to W3C.</li>
        <li>A position on a publicly visible advisory body, even if no decision making authority is involved.</li>
      </ul>
      <p>Individuals seeking assistance on these matters <em class="rfc2119">should</em> contact the Team.</p>
      <p>Team members are subject to the <a href="http://www.w3.org/2000/09/06-conflictpolicy">W3C Team conflict of interest policy</a> [<a
          href="#ref-coi">PUB23</a>].</p>
      <h4 id="member-rep">3.1.2 Individuals Representing a Member Organization</h4>
      <p>Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization. However,
        an Advisory Committee representative <em class="rfc2119">may</em> designate a non-employee to represent the Member. Non-employee
        Member representatives <em class="rfc2119">must</em> disclose relevant affiliations to the Team and to any group in which the
        individual participates.</p>
      <p>In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a <a href="#coi">conflict
          of interest</a>), the <a href="#def-Director">Director</a> <em class="rfc2119">may</em> decline to allow an individual
        designated by an Advisory Committee representative to participate in a group.</p>
      <p>A group charter <em class="rfc2119">may</em> limit the number of individuals representing a W3C Member (or group of <a href="#MemberRelated">related
-          Members</a>).</p>
      <h3 id="GeneralMeetings">3.2 Meetings</h3>
      <p>W3C groups (including the <a href="#ACMeetings">Advisory Committee</a>, <a href="#AB">Advisory Board</a>, <a href="#TAG">TAG</a>,
        and <a href="#GroupsWG">Working Groups</a>) <em class="rfc2119">should</em> observe the meeting requirements in this section.</p>
      <p>W3C distinguishes two types of meetings:</p>
      <ol>
        <li>A <dfn id="ftf-meeting">face-to-face meeting</dfn> is one where most of the attendees are expected to participate in the same
          physical location.</li>
        <li>A <dfn id="distributed-meeting">distributed meeting</dfn> is one where most of the attendees are expected to participate from
          remote locations (e.g., by telephone, video conferencing, or <abbr title="Internet Relay Chat">IRC</abbr>).</li>
      </ol>
      <p>A Chair <em class="rfc2119">may</em> invite an individual with a particular expertise to attend a meeting on an exceptional basis.
        This person is a meeting guest, not a group <a href="#participant">participant</a>. Meeting guests do not have <a href="#Votes">voting
+        Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>] is incorporated by normative reference as a part of the Process Document,
+      and is thus equally binding.</p>
+    <p>The Patent Policy places additional obligations on Members, Team, and other participants in W3C. The Process Document does not
+      restate those requirements but includes references to them. The Process Document and Patent Policy have been designed so that they may
+      evolve independently.</p>
+    <p>In the Process Document, the term "participant" refers to an individual, not an organization.</p>
+    <h2 class=".notoc">Conformance and specialized terms</h2>
+    <p>The terms <em class="rfc2119">must</em>, <em class="rfc2119">must not</em>, <em class="rfc2119">should</em>, <em class="rfc2119">should
+        not</em>, <em class="rfc2119">required</em>, and <em class="rfc2119">may</em> are used in accordance with 
+      <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC
+        2119</a> [<a href="#ref-RFC2119">RFC2119</a>]. The term <dfn><em class="rfc2119">not required</em></dfn> is equivalent to the term
+      <em class="rfc2119">may</em> as defined in RFC 2119.&nbsp;</p>
+    <p>Some terms have been capitalized in this document (and in other W3C materials) to indicate that they are entities with special
+      relevance to the W3C Process. These terms are defined herein, and readers should be aware that the ordinary (English) definitions are
+      incomplete for purposes of understanding this document.</p>
+    <div class="toc" role="navigation">
+      <h2 class="notoc" id="toc">Table of Contents</h2>
+      <div class="noprint">
+        <ul class="toc">
+          <li class="tocline2"><a href="#Intro" class="tocxref">1 Introduction</a></li>
+          <li class="tocline2"><a href="#Organization" class="tocxref">2 Members, Advisory Committee, Team, Advisory Board, Technical
+              Architecture Group</a></li>
+          <li class="tocline2"><a href="#Policies" class="tocxref">3 General Policies for W3C Groups</a></li>
+          <li class="tocline2"><a href="#dissemination" class="tocxref">4 Dissemination Policies</a></li>
+          <li class="tocline2"><s>5 Activities</s></li>
+          <li class="tocline2"><a href="#GAGeneral" class="tocxref">6 Working Groups and Interest Groups</a></li>
+          <li class="tocline2"><a href="#Reports" class="tocxref">7 W3C Technical Report Development Process</a></li>
+          <li class="tocline2"><a href="#ReviewAppeal" class="tocxref">8 Advisory Committee Reviews, Appeals, and Votes</a></li>
+          <li class="tocline2"><a href="#GAEvents" class="tocxref">9 Workshops and Symposia</a></li>
+          <li class="tocline2"><a href="#Liaisons" class="tocxref">10 Liaisons</a></li>
+          <li class="tocline2"><a href="#Submission" class="tocxref">11 Member Submission Process</a></li>
+          <li class="tocline2"><a href="#GAProcess" class="tocxref">12 Process Evolution</a></li>
+          <li class="tocline2"><a href="#references" class="tocxref">13 References</a></li>
+          <li class="tocline2"><a href="#acks" class="tocxref">14 Acknowledgments</a></li>
+          <li class="tocline2"><a href="#changes" class="tocxref">15 Changes</a></li>
+        </ul>
+      </div>
+    </div>
+    <div class="longtoc">
+      <div class="noprint">
+        <h3 class="notoc" id="fulltoc">Expanded table of contents</h3>
+      </div>
+      <ul class="toc">
+        <li class="tocline2"><a href="#Intro">1 Introduction</a></li>
+        <li class="tocline2"><a href="#Organization">2 Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group</a>
+          <ul class="toc">
+            <li class="tocline3"><a href="#Members">2.1 Members</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#MemberBenefits">2.1.1 Rights of Members</a></li>
+                <li class="tocline4"><a href="#MemberRelated">2.1.2 Related Members</a></li>
+                <li class="tocline4"><a href="#AC">2.1.3 Advisory Committee (AC)</a></li>
+              </ul>
+            </li>
+            <li class="tocline3"><a href="#Team">2.2 The W3C Team</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#TeamSubmission">2.2.1 Team Submissions</a></li>
+              </ul>
+            </li>
+            <li class="tocline3"><a href="#AB">2.3 Advisory Board (AB)</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#ABParticipation">2.3.1 Advisory Board Participation</a></li>
+              </ul>
+            </li>
+            <li class="tocline3"><a href="#TAG">2.4 Technical Architecture Group (TAG)</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#tag-participation">2.4.1 Technical Architecture Group Participation</a></li>
+              </ul>
+            </li>
+            <li class="tocline3"><a href="#AB-TAG-participation">2.5 Advisory Board and Technical Architecture Group Participation</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#AB-TAG-constraints">2.5.1 Advisory Board and Technical Architecture Group Participation
+                    Constraints</a></li>
+                <li class="tocline4"><a href="#AB-TAG-elections">2.5.2 Advisory Board and Technical Architecture Group Elections</a></li>
+                <li class="tocline4"><a href="#AB-TAG-vacated">2.5.3 Advisory Board and Technical Architecture Group Vacated Seats</a></li>
+              </ul>
+            </li>
+          </ul>
+        </li>
+        <li class="tocline2"><a href="#Policies">3 General Policies for W3C Groups</a>
+          <ul class="toc">
+            <li class="tocline3"><a href="#ParticipationCriteria">3.1 Individual Participation Criteria</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#coi">3.1.1 Conflict of Interest Policy</a></li>
+                <li class="tocline4"><a href="#member-rep">3.1.2 Individuals Representing a Member Organization</a></li>
+              </ul>
+            </li>
+            <li class="tocline3"><a href="#GeneralMeetings">3.2 Meetings</a></li>
+            <li class="tocline3"><a href="#Consensus">3.3 Consensus</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#managing-dissent">3.3.1 Managing Dissent</a></li>
+                <li class="tocline4"><a href="#WGArchiveMinorityViews">3.3.2 Recording and Reporting Formal Objections</a></li>
+                <li class="tocline4"><a href="#formal-address">3.3.3 Formally Addressing an Issue</a></li>
+                <li class="tocline4"><a href="#WGChairReopen">3.3.4 Reopening a Decision When Presented With New Information</a></li>
+              </ul>
+            </li>
+            <li class="tocline3"><a href="#Votes">3.4 Votes</a></li>
+            <li class="tocline3"><a href="#WGAppeals">3.5 Appeal of a Chair's Decision</a></li>
+            <li class="tocline3"><a href="#resignation">3.6 Resignation from a Group</a></li>
+          </ul>
+        </li>
+        <li class="tocline2"><a href="#dissemination">4 Dissemination Policies</a>
+          <ul class="toc">
+            <li class="tocline3"><a href="#confidentiality-levels">4.1 Confidentiality Levels</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#confidentiality-change">4.1.1 Changing Confidentiality Level</a></li>
+              </ul>
+            </li>
+          </ul>
+        </li>
+        <li class="tocline2"><a href="#GAGeneral">6 Working Groups and Interest Groups</a>
+          <ul class="toc">
+            <li class="tocline3"><a href="#ReqsAllGroups">6.1 Requirements for All Working and Interest Groups</a></li>
+            <li class="tocline3"><a href="#GroupsWG">6.2 Working Groups and Interest Groups</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#group-participation">6.2.1 Working Group and Interest Group Participation Requirements</a></li>
+                <li class="tocline4"><a href="#WGCharterDevelopment">6.2.2 Working Group and Interest Group Charter Development</a></li>
+                <li class="tocline4"><a href="#CharterReview">6.2.3 Advisory Committee Review of a Working Group or Interest Group Charter</a></li>
+                <li class="tocline4"><a href="#cfp">6.2.4 Call for Participation in a Working Group or Interest Group</a></li>
+                <li class="tocline4"><a href="#charter-extension">6.2.5 Working Group and Interest Group Charter Extension</a></li>
+                <li class="tocline4"><a href="#WGCharter">6.2.6 Working Group and Interest Group Charters</a></li>
+                <li class="tocline4"><a href="#GeneralTermination">6.2.8 Working Group and Interest Group Closure</a></li>
+              </ul>
+            </li>
+          </ul>
+        </li>
+        <li class="tocline2"><a href="#Reports">7 W3C Technical Report Development Process</a>
+          <ul class="toc">
+            <li><a href="#rec-advance">7.1 W3C Technical Reports</a>
+              <ul class="toc">
+                <li><a href="#recs-and-notes" id="return-to-wg">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 class="toc">
+                <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 class="toc">
+                    <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 class="toc">
+                    <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 class="toc">
+                <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">7.3.3 Stopping work on a specification</a></li>
+              </ul>
+            </li>
+            <li><a href="#candidate-rec" id="cfi">7.4 Candidate Recommendation</a>
+              <ul class="toc">
+                <li><a href="#revised-cr">7.4.1 Revising a Candidate Recommendation</a></li>
+              </ul>
+            </li>
+            <li> <a href="#rec-pr" id="cfr">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 class="toc">
+                <li><a href="#errata">7.7.1 Errata Management</a></li>
+                <li><a href="#revised-rec" id="cfr-edited">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>
+        </li>
+        <li class="tocline2"><a href="#ReviewAppeal">8 Advisory Committee Reviews, Appeals, and Votes</a>
+          <ul class="toc">
+            <li class="tocline3"><a href="#ACReview">8.1 Advisory Committee Reviews</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#ACReviewStart">8.1.1 Start of a Review Period</a></li>
+                <li class="tocline4"><a href="#ACReviewAfter">8.1.2 After the Review Period</a></li>
+              </ul>
+            </li>
+            <li class="tocline3"><a href="#ACAppeal">8.2 Appeal by Advisory Committee Representatives</a></li>
+            <li class="tocline3"><a href="#ACVotes">8.3 Advisory Committee Votes</a></li>
+          </ul>
+        </li>
+        <li class="tocline2"><a href="#GAEvents">9 Workshops and Symposia</a></li>
+        <li class="tocline2"><a href="#Liaisons">10 Liaisons</a></li>
+        <li class="tocline2"><a href="#Submission">11 Member Submission Process</a>
+          <ul class="toc">
+            <li class="tocline3"><a href="#SubmissionRights">11.1 Submitter Rights and Obligations</a>
+              <ul class="toc">
+                <li class="tocline4"><a href="#SubmissionScope">11.1.1 Scope of Member Submissions</a></li>
+                <li class="tocline4"><a href="#SubmissionReqs">11.1.2 Information Required in a Submission Request</a></li>
+              </ul>
+            </li>
+            <li class="tocline3"><a href="#TeamSubmissionRights">11.2 Team Rights and Obligations</a></li>
+            <li class="tocline3"><a href="#SubmissionYes">11.3 Acknowledgment of a Submission Request</a></li>
+            <li class="tocline3"><a href="#SubmissionNo">11.4 Rejection of a Submission Request</a></li>
+          </ul>
+        </li>
+        <li class="tocline2"><a href="#GAProcess">12 Process Evolution</a></li>
+        <li class="tocline2"><a href="#references">13 References</a>
+          <ul class="toc">
+            <li class="tocline3"><a href="#public-refs">13.1 Public Resources</a></li>
+            <li class="tocline3"><a href="#member-refs">13.2 Member-only Resources</a></li>
+            <li class="tocline3"><a href="#other-refs">13.3 Other References</a></li>
+          </ul>
+        </li>
+        <li class="tocline2"><a href="#acks">14 Acknowledgments</a></li>
+        <li class="tocline2"><a href="#changes">15 Changes</a></li>
+      </ul>
+    </div>
+    <main>
+      <h2 id="Intro">1 Introduction</h2>
+      <p>Most W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that promote
+        the development of high-quality standards based on the <a href="#Consensus">consensus</a> of the Membership, Team, and public. W3C
+        processes promote fairness, responsiveness, and progress: all facets of the W3C mission. This document describes the processes W3C
+        follows in pursuit of its mission.</p>
+      <p>Here is a general overview of how W3C standardizes a Web technology. In many cases, the goal of this work is a <a href="#RecsW3C">W3C
+          Recommendation</a>, the W3C equivalent of a Web standard.</p>
+      <ol>
+        <li>People generate interest in a particular topic (e.g., Web services). For instance, Members express interest in the form of <a href="#Submission">Member
+            Submissions</a>, and the <a href="#Team">Team</a> monitors work inside and outside of W3C for signs of interest. Also, W3C is
+          likely to organize a <a href="#GAEvents">Workshop</a> to bring people together to discuss topics that interest the W3C community.</li>
+        <li>When there is enough interest in a topic (e.g., after a successful Workshop and/or discussion on an <a href="#ACCommunication">Advisory
+            Committee mailing list</a>), the Director announces the <a href="#ActivityDevelopment">development of a proposal for one or
+            more new</a> or Interest Group or <a href="#WGCharterDevelopment">Working Group charter</a>, depending on the breadth of the
+          topic of interest. W3C Members <a href="#ActivityCreation">review</a> the proposed charters. When there is support within W3C for
+          investing resources in the topic of interest, the Director approves the group(s) and they begin their work.</li>
+        <li>There are three types of Working Group participants: <a href="#member-rep">Member representatives</a>, <a href="#invited-expert-wg">Invited
+            Experts</a>, and <a href="#Team">Team representatives</a>. Team representatives both contribute to the technical work and help
+          ensure the group's proper integration with the rest of W3C. The <a href="#WGCharter">Working Group charter</a> sets expectations
+          about each group's deliverables (e.g., <a href="#Reports">technical reports</a>, test suites, and tutorials).</li>
+        <li>Working Groups generally create specifications and guidelines that undergo cycles of revision and review as they <a href="#rec-advance">advance
+            to W3C Recommendation</a> status. The W3C process for producing these technical reports includes significant review by the
+          Members and public, and requirements that the Working Group be able to show implementation and interoperability experience. At the
+          end of the process, the Advisory Committee reviews the mature technical report, and if there is support, W3C publishes it as a <a
+            href="#RecsW3C">Recommendation</a>.</li>
+      </ol>
+      <p>The Process Document promotes the goals of quality and fairness in technical decisions by encouraging <a href="#Consensus">consensus</a>,
+        requiring reviews (by both Members and public) as part of the <a href="#Reports">technical report development process</a>, and
+        through an <a href="#ACAppeal">appeal process</a> for the Advisory Committee.</p>
+      <p>The other sections of the Process Document:</p>
+      <ol>
+        <li>set forth <a href="#Policies">policies</a> for participation in W3C groups,</li>
+        <li>establish two permanent groups within W3C: the <a href="#TAG">Technical Architecture Group (TAG)</a>, to help resolve
+          Consortium-wide technical issues; and the <a href="#AB">Advisory Board (AB)</a>, to help resolve Consortium-wide non-technical
+          issues, and to manage the <a href="#GAProcess">evolution of the W3C process</a>, and</li>
+        <li>describe other interactions between the <a href="#Members">Members</a> (as represented by the <a href="#AC">W3C Advisory
+            Committee</a>), the Team, and the general public.</li>
+      </ol>
+      <h2 id="Organization">2 Members, Advisory Committee, Team, Advisory Board, Technical Architecture Group</h2>
+      <p>W3C's mission is to lead the Web to its full potential. W3C <a href="#Members">Member</a> organizations provide resources to this
+        end, and the W3C <a href="#Team">Team</a> provides the technical leadership and organization to coordinate the effort.</p>
+      <h3 id="Members">2.1 Members</h3>
+      <p>W3C Members are primarily represented in W3C processes as follows:</p>
+      <ol>
+        <li>The <a href="#AC">Advisory Committee</a> is composed of one representative from each Member organization (refer to the <a href="#Member-only">Member-only</a>
+          list of <a href="http://www.w3.org/Member/ACList">current Advisory Committee representatives</a> [<a href="#ref-current-ac">MEM1</a>]).
+          The Advisory Committee:
+          <ul>
+            <li>reviews plans for W3C at each <a href="#ACMeetings">Advisory Committee meeting</a>;</li>
+            <li>reviews formal proposals from the W3C Director: <a href="#CharterReview">Charter Proposals</a>, <a href="#RecsPR">Proposed
+                Recommendations</a>, and <a href="#GAProcess">Proposed Process Documents</a>.</li>
+            <li>elects the <a href="#AB">Advisory Board</a> participants other than the Advisory Board Chair.</li>
+            <li>elects 5 of the 9 participants on the <a href="#TAG">Technical Architecture Group</a>.</li>
+          </ul>
+          Advisory Committee representatives have <a href="#ACAppeal">appeal</a> powers for some processes described in this document.</li>
+        <li>Representatives of Member organizations participate in <a href="#GAGeneral">Working Groups and Interest Groups</a> and author
+          and review <a href="#Reports">technical reports</a>.</li>
+      </ol>
+      <p id="MemberSubscription">W3C membership is open to all entities, as described in "<a href="http://www.w3.org/Consortium/join">How to
+          Join W3C</a>" [<a href="#ref-join-w3c">PUB5</a>]; (refer to the public list of <a href="http://www.w3.org/Consortium/Member/List">current
+          W3C Members</a> [<a href="#ref-current-mem">PUB8</a>]). Organizations subscribe according to the 
+        <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
+          Agreement</a> [<a href="#ref-member-agreement">PUB6</a>]. The <a href="#Team">Team</a> <em class="rfc2119">must</em> ensure that
+        Member participation agreements remain <a href="#Team-only">Team-only</a> and that no Member receives preferential treatment within
+        W3C.</p>
+      <p id="IndividualParticipation">W3C does not have a class of membership tailored to, or priced for individuals. However, an individual
+        <em class="rfc2119">may</em> join W3C as an Affiliate Member. In this case the same restrictions pertaining to <a href="#MemberRelated">related
+          Members</a> apply when the individual also <a href="#member-rep">represents</a> another W3C Member.</p>
+      <h4 id="MemberBenefits">2.1.1 Rights of Members</h4>
+      <p>Each Member organization enjoys the following rights and benefits:</p>
+      <ul>
+        <li>A seat on the <a href="#AC">Advisory Committee</a>;</li>
+        <li>Access to <a href="#Member-only">Member-only</a> information;</li>
+        <li>The <a href="#Submission">Member Submission</a> process;</li>
+        <li>Use of the W3C Member logo on promotional material and to publicize the Member's participation in W3C. For more information,
+          please refer to the Member logo usage policy described in the <a href="http://www.w3.org/Member/Intro">New Member Orientation</a>
+          [<a href="#ref-new-member">MEM4</a>].</li>
+      </ul>
+      <p>Furthermore, representatives of Member organizations participate in W3C as follows:</p>
+      <ul>
+        <li>In <a href="#GAGeneral">Working Groups and Interest Groups</a>.</li>
+        <li>In <a href="#GAEvents">Workshops and Symposia</a>;</li>
+        <li>On the Team, as <a href="#fellows">W3C Fellows</a>.</li>
+      </ul>
+      <p>In the case (described in paragraph 5g of the <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
+          Agreement</a>), where a Member organization is itself a consortium, user society, or otherwise has members or sponsors, the
+        organization's paid staff and Advisory Committee representative exercise all the rights and privileges of W3C membership. In
+        addition, the Advisory Committee representative <em class="rfc2119">may</em> designate up to four (or more at the Team's
+        discretion) individuals who, though not employed by the organization, <em class="rfc2119">may</em> exercise the rights of <a href="#member-rep">Member
+          representatives</a>. These individuals <em class="rfc2119">must</em> disclose their employment affiliation when participating in
+        W3C work. Provisions for <a href="#MemberRelated">related Members</a> apply. Furthermore, these individuals are expected to
+        represent the broad interests of the W3C Member organization and not the parochial interests of their employers.</p>
+      <p>The rights and benefits of W3C membership are contingent upon conformance to the processes described in this document. The vast
+        majority of W3C Members faithfully follow the spirit as well as the letter of these processes. When serious and/or repeated
+        violations do occur, and repeated attempts to address these violations have not resolved the situation, the Director <em class="rfc2119">may</em>
+        take disciplinary action. Arbitration in the case of further disagreement is governed by paragraph 19 of the Membership Agreement.
+        Refer to the <a href="http://www.w3.org/2002/09/discipline">Guidelines for Disciplinary Action</a> [<a href="#ref-discipline-gl">MEM14</a>].</p>
+      <h4 id="MemberRelated">2.1.2 Related Members</h4>
+      <p>In the interest of ensuring the integrity of the consensus process, Member involvement in some of the processes in this document is
+        affected by related Member status. As used herein, two Members are related if:</p>
+      <ol>
+        <li>Either Member is a subsidiary of the other, or</li>
+        <li>Both Members are subsidiaries of a common entity, or</li>
+        <li>The Members have an employment contract or consulting contract that affects W3C participation.</li>
+      </ol>
+      <p>A <em>subsidiary</em> is an organization of which effective control and/or majority ownership rests with another, single
+        organization.</p>
+      <p>Related Members <em class="rfc2119">must</em> disclose these relationships according to the mechanisms described in the
+        <a href="http://www.w3.org/Member/Intro">New
+          Member Orientation</a> [<a href="#ref-new-member">MEM4</a>].</p>
+      <h4 id="AC">2.1.3 Advisory Committee (AC)</h4>
+      <p>When an organization joins W3C (see "<a href="http://www.w3.org/Consortium/join">How to Join W3C</a>" [<a href="#ref-join-w3c">PUB5</a>]),
+        it <em class="rfc2119">must</em> name its Advisory Committee representative as part of the Membership Agreement. The
+        <a href="http://www.w3.org/Member/Intro">New
+          Member Orientation</a> explains how to subscribe or unsubscribe to Advisory Committee mailing lists, provides information about
+        Advisory Committee meetings, explains how to name a new Advisory Committee representative, and more. Advisory Committee
+        representatives <em class="rfc2119">must</em> follow the <a href="#coi">conflict of interest policy</a> by disclosing information
+        according to the mechanisms described in the New Member Orientation. See also the additional roles of Advisory Committee
+        representatives described in the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+      <p>Additional information for Members is available at the <a href="http://www.w3.org/Member/">Member Web site</a> [<a href="#ref-member-web">MEM6</a>].</p>
+      <h5 id="ACCommunication">2.1.3.1 Advisory Committee Mailing Lists</h5>
+      <p>The Team <em class="rfc2119">must</em> provide two mailing lists for use by the Advisory Committee:</p>
+      <ol>
+        <li>One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. This list is
+          read-only for Advisory Committee representatives.</li>
+        <li>One for discussion among Advisory Committee representatives. Though this list is primarily for Advisory Committee
+          representatives, the Team <em class="rfc2119">must</em> monitor discussion and <em class="rfc2119">should</em> participate in
+          discussion when appropriate. Ongoing detailed discussions <em class="rfc2119">should</em> be moved to other appropriate lists
+          (new or existing, such as a mailing list created for a <a href="#GAEvents">Workshop</a>).</li>
+      </ol>
+      <p>An Advisory Committee representative <em class="rfc2119">may</em> request that additional individuals from their organization be
+        subscribed to these lists. Failure to contain distribution internally <em class="rfc2119">may</em> result in suspension of
+        additional email addresses, at the discretion of the Team.</p>
+      <h5 id="ACMeetings">2.1.3.2 Advisory Committee Meetings</h5>
+      <p>The Team organizes a <a href="#ftf-meeting">face-to-face meeting</a> for the Advisory Committee <span class="time-interval">twice
+          a year</span>. The Team appoints the Chair of these meetings (generally the <a href="#def-W3CChair">CEO</a>). At each Advisory
+        Committee meeting, the Team <em class="rfc2119">should</em> provide an update to the Advisory Committee about:</p>
+      <dl>
+        <dt><em>Resources</em></dt>
+        <dd>
+          <ul>
+            <li>The number of Full and Affiliate W3C Members.</li>
+            <li>An overview of the financial status of W3C.</li>
+          </ul>
+        </dd>
+        <dt><em>Allocations</em></dt>
+        <dd>
+          <ul>
+            <li>The allocation of the annual budget, including size of the Team and their approximate deployment.</li>
+            <li>A list of all activities (including but not limited to Working and Interest Groups) and brief status statement about each,
+              in particular those started or terminated since the previous Advisory Committee meeting.</li>
+            <li>The allocation of resources to pursuing <a href="#Liaisons">liaisons</a> with other organizations.</li>
+          </ul>
+        </dd>
+      </dl>
+      <p>Each Member organization <em class="rfc2119">should</em> send one <a href="#member-rep">representative</a> to each Advisory
+        Committee meeting. In exceptional circumstances (e.g., during a period of transition between representatives from an organization),
+        the meeting Chair <em class="rfc2119">may</em> allow a Member organization to send two representatives to a meeting.</p>
+      <p>The Team <em class="rfc2119">must</em> announce the date and location of each Advisory Committee meeting no later than at the end
+        of the previous meeting; <span class="time-interval">one year's</span> notice is preferred. The Team <em class="rfc2119">must</em>
+        announce the region of each Advisory Committee meeting at least <span class="time-interval">one year</span> in advance.</p>
+      <p>More information about <a href="http://www.w3.org/Member/Meeting/">Advisory Committee meetings</a> [<a href="#ref-ac-meetings">MEM5</a>]
+        is available at the Member Web site.</p>
+      <h3 id="Team">2.2 The W3C Team</h3>
+      <p>The Team consists of the Director, CEO, W3C paid staff, unpaid interns, and W3C Fellows. <dfn id="fellows">W3C Fellows</dfn> are
+        Member employees working as part of the Team; see the <a href="http://www.w3.org/Consortium/Recruitment/Fellows">W3C Fellows
+          Program</a> [<a href="#ref-fellows">PUB32</a>]. The Team provides technical leadership about Web technologies, organizes and
+        manages W3C activities to reach goals within practical constraints (such as resources available), and communicates with the Members
+        and the public about the Web and W3C technologies.</p>
+      <p>The Director and CEO <em class="rfc2119">may</em> delegate responsibility (generally to other individuals in the Team) for any of
+        their roles described in this document.</p>
+      <p>The <dfn id="def-Director">Director</dfn> is the lead technical architect at W3C. His responsibilities are identified throughout
+        this document in relevant places Some key ones include: assessing <a href="#def-Consensus" id="DirectorDecision">consensus</a>
+        within W3C for architectural choices, publication of <a href="#Reports">technical reports</a>, and new activities; appointing group
+        <a href="#GeneralChairs">Chairs</a>; "tie-breaker" for <a href="#WGAppeals">appeal of a Working Group decision</a> and deciding on
+        the outcome of formal objections; the Director is generally Chair of the <a href="#TAG">TAG</a>.</p>
+      <p>Team administrative information such as Team salaries, detailed budgeting, and other business decisions are <a href="#Team-only">Team-only</a>,
+        subject to oversight by the Host institutions.</p>
+      <p><strong>Note:</strong> W3C is not currently incorporated. For legal contracts, W3C is represented by four <dfn id="hosts">"Host"
+          institutions</dfn>: Beihang University, the European Research Consortium for Informatics and Mathematics (<abbr>ERCIM</abbr>),
+        Keio University, and the Massachusetts Institute of Technology (<abbr>MIT</abbr>). Within W3C, the Host institutions are governed by
+        hosting agreements; the Hosts themselves are not W3C Members.</p>
+      <h4 id="TeamSubmission">2.2.1 Team Submissions</h4>
+      <p>Team members <em class="rfc2119">may</em> request that the Director publish information at the W3C Web site. At the Director's
+        discretion, these documents are published as "Team Submissions". These documents are analogous to <a href="#Submission">Member
+          Submissions</a> (e.g., in <a href="#SubmissionScope">expected scope</a>). However, there is no additional Team comment. The
+        <a href="#DocumentStatus">document
+          status section</a> of a Team Submission indicates the level of Team consensus about the published material.</p>
+      <p>Team Submissions are <strong>not</strong> part of the <a href="#Reports">technical report development process</a>.</p>
+      <p>The list of <a href="http://www.w3.org/TeamSubmission/">published Team Submissions</a> [<a href="#ref-team-submission-list">PUB16</a>]
+        is available at the W3C Web site.</p>
+      <h3 id="AB">2.3 Advisory Board (AB)</h3>
+      <p>Created in March 1998, the Advisory Board provides ongoing guidance to the Team on issues of strategy, management, legal matters,
+        process, and conflict resolution. The Advisory Board also serves the Members by tracking issues raised between Advisory Committee
+        meetings, soliciting Member comments on such issues, and proposing actions to resolve these issues. The Advisory Board manages the <a
+          href="#GAProcess">evolution of the Process Document</a>. The Advisory Board hears appeals of <a href="#SubmissionNo">Member
+          Submission requests</a> that are rejected for reasons unrelated to Web architecture; see also the <a href="#TAG">TAG</a>.</p>
+      <p>The Advisory Board is <strong>not</strong> a board of directors and has no decision-making authority within W3C; its role is
+        strictly advisory.</p>
+      <p>The Team <em class="rfc2119">must</em> make available a mailing list for the Advisory Board to use for its communication,
+        confidential to the Advisory Board and Team.</p>
+      <p>The Advisory Board <em class="rfc2119">should</em> send a summary of each of its meetings to the Advisory Committee and other
+        group Chairs. The Advisory Board <em class="rfc2119">should</em> also report on its activities at each <a href="#ACMeetings">Advisory
+          Committee meeting</a>.</p>
+      <p>Details about the Advisory Board (e.g., the list of Advisory Board participants, mailing list information, and summaries of
+        Advisory Board meetings) are available at the <a href="http://www.w3.org/2002/ab/">Advisory Board home page</a> [<a href="#ref-ab-home">PUB30</a>].</p>
+      <h4 id="ABParticipation">2.3.1 Advisory Board Participation</h4>
+      <p>The Advisory Board consists of nine elected participants and a Chair. The Team appoints the Chair of the <a href="#AB">Advisory
+          Board</a>, who is generally the <a href="#def-W3CChair">CEO</a>.</p>
+      <p>The remaining nine Advisory Board participants are elected by the W3C Advisory Committee following the <a href="#AB-TAG-elections">AB/TAG
+          nomination and election process</a>.</p>
+      <p>With the exception of the Chair, the terms of all Advisory Board participants are for <span class="time-interval">two years</span>.
+        Terms are staggered so that each year, either four or five terms expire. If an individual is elected to fill an incomplete term,
+        that individual's term ends at the normal expiration date of that term. Regular Advisory Board terms begin on 1 July and end on 30
+        June.</p>
+      <h3 id="TAG">2.4 Technical Architecture Group (TAG)</h3>
+      <p>Created in February 2001, the mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:</p>
+      <ol>
+        <li>to document and build consensus around principles of Web architecture and to interpret and clarify these principles when
+          necessary;</li>
+        <li>to resolve issues involving general Web architecture brought to the TAG;</li>
+        <li>to help coordinate cross-technology architecture developments inside and outside W3C.</li>
+      </ol>
+      <p>The TAG hears appeals of <a href="#SubmissionNo">Member Submission requests</a> that are rejected for reasons related to Web
+        architecture; see also the <a href="#AB">Advisory Board</a>.</p>
+      <p>The TAG's scope is limited to technical issues about Web architecture. The TAG <em class="rfc2119">should not</em> consider
+        administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee,
+        Advisory Board, and Team. Please refer to the <a href="http://www.w3.org/2001/07/19-tag">TAG charter</a> [<a href="#ref-tag-charter">PUB25</a>]
+        for more information about the background and scope of the TAG, and the expected qualifications of TAG participants.</p>
+      <p>The Team <em class="rfc2119">must</em> make available two mailing lists for the TAG:</p>
+      <ul>
+        <li>a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business on this list.</li>
+        <li>a <a href="#Member-only">Member-only</a> list for discussions within the TAG and for requests to the TAG that, for whatever
+          reason, cannot be made on the public list.</li>
+      </ul>
+      <p>The TAG <em class="rfc2119">may</em> also request the creation of additional topic-specific, public mailing lists. For some TAG
+        discussions (e.g., an appeal of a <a href="#SubmissionNo">rejected Member Submission request</a>), the TAG <em class="rfc2119">may</em>
+        use a list that will be <a href="#Member-only">Member-only</a>.</p>
+      <p>The TAG <em class="rfc2119">should</em> send a summary of each of its <a href="#GeneralMeetings">meetings</a> to the Advisory
+        Committee and other group Chairs. The TAG <em class="rfc2119">should</em> also report on its activities at each <a href="#ACMeetings">Advisory
+          Committee meeting</a>.</p>
+      <p>When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote; see also the
+        section on <a href="http://www.w3.org/2001/07/19-tag#Voting">voting in the TAG charter</a> [<a href="#ref-tag-charter">PUB25</a>]
+        and the general section on <a href="#Votes">votes</a> in this Process Document.</p>
+      <p>Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) are available
+        at the <a href="http://www.w3.org/2001/tag/">TAG home page</a> [<a href="#ref-tag-home">PUB26</a>].</p>
+      <h4 id="tag-participation">2.4.1 Technical Architecture Group Participation</h4>
+      <p>The TAG consists of eight elected or appointed participants and a Chair. The Team appoints the Chair of the TAG, who is generally
+        the <a href="#def-Director">Director</a>.</p>
+      <p>Three TAG participants are appointed by the Director. Appointees are <em class="rfc2119">not required</em> to be on the W3C Team.
+        The Director <em class="rfc2119">may</em> appoint <a href="#fellows">W3C Fellows</a> to the TAG.</p>
+      <p>The remaining five TAG participants are elected by the W3C Advisory Committee following the <a href="#AB-TAG-elections">AB/TAG
+          nomination and election process</a>.</p>
+      <p>With the exception of the Chair, the terms of all TAG participants are for <span class="time-interval">two years</span>. Terms are
+        staggered so that each year, either two or three elected terms, and either one or two appointed terms expire. If an individual is
+        appointed or elected to fill an incomplete term, that individual's term ends at the normal expiration date of that term. Regular TAG
+        terms begin on 1 February and end on 31 January.</p>
+      <h3 id="AB-TAG-participation">2.5 Advisory Board and Technical Architecture Group Participation</h3>
+      <p>Advisory Board and TAG participants have a special role within W3C: they are elected by the Membership and appointed by the
+        Director with the expectation that they will use their best judgment to find the best solutions for the Web, not just for any
+        particular network, technology, vendor, or user. Advisory Board and TAG participants are expected to participate regularly and
+        fully. Advisory Board and TAG participants <em class="rfc2119">should</em> attend <a href="#ACMeetings">Advisory Committee
+          meetings</a>.</p>
+      <p>An individual participates on the Advisory Board or TAG from the moment the individual's term begins until the term ends or the
+        seat is <a href="#AB-TAG-vacated">vacated</a>. Although Advisory Board and TAG participants do not advocate for the commercial
+        interests of their employers, their participation does carry the responsibilities associated with Member representation, Invited
+        Expert status, or Team representation (as described in the section on the <a href="#AB-TAG-elections">AB/TAG nomination and
+          election process</a>). See also the licensing obligations on TAG participants in
+        <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
+          3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>],
+        and the claim exclusion process of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">section 4</a>.</p>
+      <h4 id="AB-TAG-constraints">2.5.1 Advisory Board and Technical Architecture Group Participation Constraints</h4>
+      <p>Given the few seats available on the Advisory Board and the TAG, and in order to ensure that the diversity of W3C Members is
+        represented:</p>
+      <ul>
+        <li>A Member organization is permitted at most one participant on the TAG except when having more than one participant is caused by
+          a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the
+          Member organization MUST have returned to having at most one participant.</li>
+        <li>A Member organization is permitted at most one participant on the AB.</li>
+        <li>An individual <em class="rfc2119">must not</em> participate on both the TAG and the AB.</li>
+      </ul>
+      <p>If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participant <span
+          class="rfc2119">MUST</span> cease AB participation until the situation has been resolved. If after <span class="time-interval">30
+          days</span> the situation has not been resolved, the Chair will declare one participant's seat to be vacant. When more than one
+        individual is involved, the <a href="#random">verifiable random selection procedure</a> described below will be used to choose one
+        person for continued participation.</p>
+      <h4 id="AB-TAG-elections">2.5.2 Advisory Board and Technical Architecture Group Elections</h4>
+      <p>The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee. An election begins when
+        the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the number of available seats,
+        the deadline for nominations, and the address where nominations are sent. The Director <em class="rfc2119">should</em> announce
+        appointments no later than the start of a nomination period, and generally as part of the Call for Nominations.</p>
+      <p>Each Member (or group of <a href="#MemberRelated">related Members</a>) <em class="rfc2119">may</em> nominate one individual. A
+        nomination <em class="rfc2119">must</em> be made with the consent of the nominee. In order for an individual to be nominated as a
+        Member representative, the individual <em class="rfc2119">must</em> qualify for <a href="#member-rep">Member representation</a>
+        and the Member's Advisory Committee representative <em class="rfc2119">must</em> include in the nomination the (same)
+        <a href="#member-rep-info">information
+          required for a Member representative in a Working Group</a>. In order for an individual to be nominated as an Invited Expert, the
+        individual <em class="rfc2119">must</em> provide the (same) <a href="#inv-expert-info">information required for an Invited Expert
+          in a Working Group</a> and the nominating Advisory Committee representative <em class="rfc2119">must</em> include that
+        information in the nomination. In order for an individual to be nominated as a Team representative, the nominating Advisory
+        Committee representative <em class="rfc2119">must</em> first secure approval from Team management. A nominee is <span class="rfc2119">NOT
+          REQUIRED</span> to be an employee of a Member organization, and <em class="rfc2119">may</em> be a <a href="#fellows">W3C Fellow</a>.
+        Each nomination <em class="rfc2119">should</em> include a few informative paragraphs about the nominee.</p>
+      <p>If, after the deadline for nominations, the number of nominees is:</p>
+      <ul>
+        <li>Equal to the number of available seats, those nominees are thereby elected. This situation constitutes a tie for the purposes of
+          assigning <a href="#short-term">short terms</a>.</li>
+        <li>Less than the number of available seats, Calls for Nominations are issued until a sufficient number of people have been
+          nominated. Those already nominated do not need to be renominated after a renewed call.</li>
+        <li>Greater than the number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the
+          number of available seats, the deadline for votes, and the address where votes are sent.</li>
+      </ul>
+      <p>When there is a vote, each Member (or group of <a href="#MemberRelated">related Members</a>) <em class="rfc2119">may</em> vote
+        for as many candidates as there are available seats; see the section on <a href="#ACVotes">Advisory Committee votes</a>. Once the
+        deadline for votes has passed, the Team announces the results to the Advisory Committee. The candidates with the most votes are
+        elected to the available seats. In case of a tie where there are more apparent winners than available seats (e.g., three candidates
+        receive 10 votes each for two seats), the <a href="#random">verifiable random selection procedure</a> described below will be used
+        to fill the available seats.</p>
+      <p id="short-term">The shortest term is assigned to the elected individual who received the fewest votes, the next shortest to the
+        elected individual who received the next fewest, and so on. In the case of a tie among those eligible for a short term, the
+        <a href="#random">verifiable
+          random selection procedure</a> described below will be used to assign the short term.</p>
+      <p>Refer to <a href="http://www.w3.org/2002/10/election-howto">How to Organize an Advisory Board or TAG election</a>
+        [<a href="#ref-election-howto">MEM15</a>]
+        for more details.</p>
+      <h5 id="random">2.5.2.1 Verifiable Random Selection Procedure</h5>
+      <p>When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to "draw straws" in case of a
+        tie or to fill a short term), W3C uses the random and verifiable procedure defined in <a href="http://www.ietf.org/rfc/rfc2777.txt">RFC
+          2777</a> [<a href="#ref-RFC2777">RFC2777</a>]. The procedure orders an input list of names (listed in alphabetical order by family
+        name unless otherwise specified) into a "result order."</p>
+      <p>W3C applies this procedure as follows:</p>
+      <ol>
+        <li>When N people have tied for M (less than N) seats. In this case, only the names of the N individuals who tied are provided as
+          input to the procedure. The M seats are assigned in result order.</li>
+        <li>After all elected individuals have been identified, when N people are eligible for M (less than N) short terms. In this case,
+          only the names of those N individuals are provided as input to the procedure. The short terms are assigned in result order.</li>
+      </ol>
+      <h4 id="AB-TAG-vacated">2.5.3 Advisory Board and Technical Architecture Group Vacated Seats</h4>
+      <p>An Advisory Board or TAG participant's seat is vacated when either of the following occurs:</p>
+      <ul>
+        <li>the participant <a href="#resignation">resigns</a>, or</li>
+        <li>the Chair asks the participant to <a href="#resignation">resign</a>.</li>
+      </ul>
+      <p>When an Advisory Board or TAG participant changes affiliations, as long as <a href="#AB-TAG-constraints">Advisory Board and TAG
+          participation constraints</a> are respected, the individual <em class="rfc2119">may</em> continue to participate until the next
+        regularly scheduled election for that group. Otherwise, the seat is vacated.</p>
+      <p>Vacated seats are filled according to this schedule:</p>
+      <ul>
+        <li>When an appointed TAG seat is vacated, the Director <em class="rfc2119">may</em> re-appoint someone immediately, but no later
+          than the next regularly scheduled election.</li>
+        <li>When an elected seat on either the AB or TAG is vacated, the seat is filled at the next regularly scheduled election for the
+          group unless the group Chair requests that W3C hold an election before then (for instance, due to the group's workload). The group
+          Chair <em class="rfc2119">should not</em> request an exceptional election if the next regularly scheduled election is fewer than
+          three months away.</li>
+      </ul>
+      <h2 id="Policies">3 General Policies for W3C Groups</h2>
+      <p>This section describes general policies for W3C groups regarding participation, meeting requirements, and decision-making. These
+        policies apply to <span id="participant">participants</span> in the following groups: <a href="#AC">Advisory Committee</a>,
+        <a href="#ABParticipation">Advisory
+          Board</a>, <a href="#tag-participation">TAG</a>, <a href="#wgparticipant">Working Groups</a>, and <a href="#igparticipant">Interest
+          Groups</a>.</p>
+      <h3 id="ParticipationCriteria">3.1 Individual Participation Criteria</h3>
+      <p>There are three qualities an individual is expected to demonstrate in order to participate in W3C:</p>
+      <ol>
+        <li>Technical competence in one's role</li>
+        <li>The ability to act fairly</li>
+        <li>Social competence in one's role</li>
+      </ol>
+      <p>Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities are
+        responsible for assessing and attesting to the qualities of those nominees.</p>
+      <p>See also the participation requirements described in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">section 6</a>
+        of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+      <h4 id="coi">3.1.1 Conflict of Interest Policy</h4>
+      <p>Individuals participating materially in W3C work <em class="rfc2119">must</em> disclose significant relationships when those
+        relationships might reasonably be perceived as creating a conflict of interest with the individual's role at W3C. These disclosures
+        <em class="rfc2119">must</em> be kept up-to-date as the individual's affiliations change and W3C membership evolves (since, for
+        example, the individual might have a relationship with an organization that joins or leaves W3C). Each section in this document that
+        describes a W3C group provides more detail about the disclosure mechanisms for that group.</p>
+      <p>The ability of an individual to fulfill a role within a group without risking a conflict of interest is clearly a function of the
+        individual's affiliations. When these affiliations change, the individual's assignment to the role <em class="rfc2119">must</em> be
+        evaluated. The role <em class="rfc2119">may</em> be reassigned according to the appropriate process. For instance, the Director <em
+          class="rfc2119">may</em> appoint a new group Chair when the current Chair changes affiliations (e.g., if there is a risk of
+        conflict of interest, or if there is risk that the Chair's new employer will be over-represented within a W3C activity).</p>
+      <p>The following are some scenarios where disclosure is appropriate:</p>
+      <ul>
+        <li>Paid consulting for an organization whose activity is relevant to W3C, or any consulting compensated with equity (shares of
+          stock, stock options, or other forms of corporate equity).</li>
+        <li>A decision-making role/responsibility (such as participating on the Board) in other organizations relevant to W3C.</li>
+        <li>A position on a publicly visible advisory body, even if no decision making authority is involved.</li>
+      </ul>
+      <p>Individuals seeking assistance on these matters <em class="rfc2119">should</em> contact the Team.</p>
+      <p>Team members are subject to the <a href="http://www.w3.org/2000/09/06-conflictpolicy">W3C Team conflict of interest policy</a> [<a
+          href="#ref-coi">PUB23</a>].</p>
+      <h4 id="member-rep">3.1.2 Individuals Representing a Member Organization</h4>
+      <p>Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization. However,
+        an Advisory Committee representative <em class="rfc2119">may</em> designate a non-employee to represent the Member. Non-employee
+        Member representatives <em class="rfc2119">must</em> disclose relevant affiliations to the Team and to any group in which the
+        individual participates.</p>
+      <p>In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a <a href="#coi">conflict
+          of interest</a>), the <a href="#def-Director">Director</a> <em class="rfc2119">may</em> decline to allow an individual
+        designated by an Advisory Committee representative to participate in a group.</p>
+      <p>A group charter <em class="rfc2119">may</em> limit the number of individuals representing a W3C Member (or group of <a href="#MemberRelated">related
+          Members</a>).</p>
+      <h3 id="GeneralMeetings">3.2 Meetings</h3>
+      <p>W3C groups (including the <a href="#ACMeetings">Advisory Committee</a>, <a href="#AB">Advisory Board</a>, <a href="#TAG">TAG</a>,
+        and <a href="#GroupsWG">Working Groups</a>) <em class="rfc2119">should</em> observe the meeting requirements in this section.</p>
+      <p>W3C distinguishes two types of meetings:</p>
+      <ol>
+        <li>A <dfn id="ftf-meeting">face-to-face meeting</dfn> is one where most of the attendees are expected to participate in the same
+          physical location.</li>
+        <li>A <dfn id="distributed-meeting">distributed meeting</dfn> is one where most of the attendees are expected to participate from
+          remote locations (e.g., by telephone, video conferencing, or <abbr title="Internet Relay Chat">IRC</abbr>).</li>
+      </ol>
+      <p>A Chair <em class="rfc2119">may</em> invite an individual with a particular expertise to attend a meeting on an exceptional basis.
+        This person is a meeting guest, not a group <a href="#participant">participant</a>. Meeting guests do not have <a href="#Votes">voting
           rights</a>. It is the responsibility of the Chair to ensure that all meeting guests respect the chartered <a href="#confidentiality-levels">level
-          of confidentiality</a> and other group requirements.</p>
      <p>Meeting announcements <em class="rfc2119">should</em> be sent to all appropriate group mailing lists, i.e., those most relevant to
        the anticipated meeting participants.</p>
      <p>The following table lists requirements for organizing a meeting:</p>
      <table border="1">
        <tbody>
          <tr>
            <th><br>
            </th>
            <th>Face-to-face meetings</th>
            <th>Distributed meetings</th>
          </tr>
          <tr>
            <th>Meeting announcement (before)</th>
            <td><span class="time-interval">eight weeks<sup>*</sup></span></td>
            <td><span class="time-interval">one week<sup>*</sup></span></td>
          </tr>
          <tr>
            <th>Agenda available (before)</th>
            <td><span class="time-interval">two weeks</span></td>
            <td><span class="time-interval">24 hours</span> (or longer if a meeting is scheduled after a weekend or holiday)</td>
          </tr>
          <tr>
            <th>Participation confirmed (before)</th>
            <td><span class="time-interval">three days</span></td>
            <td><span class="time-interval">24 hours</span></td>
          </tr>
          <tr>
            <th>Action items available (after)</th>
            <td><span class="time-interval">three days</span></td>
            <td><span class="time-interval">24 hours</span></td>
          </tr>
          <tr>
            <th>Minutes available (after)</th>
            <td><span class="time-interval">two weeks</span></td>
            <td><span class="time-interval">48 hours</span></td>
          </tr>
        </tbody>
      </table>
      <p><sup>*</sup> To allow proper planning (e.g., travel arrangements), the Chair is responsible for giving sufficient advance notice
        about the date and location of a meeting. Shorter notice for a meeting is allowed provided that there are no objections from group
        participants.</p>
      <h3 id="Consensus">3.3 Consensus</h3>
      <p>Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all
        legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active
        participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public). Decisions
        <em class="rfc2119">may</em> be made during meetings (<a href="#ftf-meeting">face-to-face</a> or <a href="#distributed-meeting">distributed</a>)
        as well as through email. <strong>Note:</strong> The Director, CEO, and COO have the role of assessing consensus within the
        Advisory Committee.</p>
      <p>The following terms are used in this document to describe the level of support for a decision among a set of eligible individuals:</p>
      <ol>
        <li><dfn id="def-Consensus">Consensus</dfn>: A substantial number of individuals in the set support the decision and nobody in the
          set registers a <a href="#FormalObjection">Formal Objection</a>. Individuals in the set may abstain. Abstention is either an
          explicit expression of no opinion or silence by an individual in the set. <dfn id="def-Unanimity">Unanimity</dfn> is the
          particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).</li>
        <li><dfn id="def-Dissent">Dissent</dfn>: At least one individual in the set registers a <a href="#FormalObjection">Formal Objection</a>.</li>
      </ol>
      <p>By default, the set of individuals eligible to participate in a decision is the set of group participants. The Process Document
        does not require a quorum for decisions (i.e., the minimal number of eligible participants required to be present before the Chair
        can call a question). A charter <em class="rfc2119">may</em> include a quorum requirement for consensus decisions.</p>
      <p>Where unanimity is not possible, a group <em class="rfc2119">should</em> strive to make consensus decisions where there is
        significant support and few abstentions. The Process Document does not require a particular percentage of eligible participants to
        agree to a motion in order for a decision to be made. To avoid decisions where there is widespread apathy, (i.e., little support and
        many abstentions), groups <em class="rfc2119">should</em> set minimum thresholds of active support before a decision can be
        recorded. The appropriate percentage <em class="rfc2119">may</em> vary depending on the size of the group and the nature of the
        decision. A charter <em class="rfc2119">may</em> include threshold requirements for consensus decisions. For instance, a charter
        might require a supermajority of eligible participants (i.e., some established percentage above 50%) to support certain types of
        consensus decisions.</p>
      <h4 id="managing-dissent">3.3.1 Managing Dissent</h4>
      <p>In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The
        Chair <em class="rfc2119">may</em> record a decision where there is dissent (i.e., there is at least one <a href="#FormalObjection">Formal
-          Objection</a>) so that the group may make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot
        stop a group's work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly
        considered the legitimate concerns of dissenters as far as is possible and reasonable, the group <em class="rfc2119">should</em>
        move on.</p>
      <p>Groups <em class="rfc2119">should</em> favor proposals that create the weakest objections. This is preferred over proposals that
        are supported by a large majority but that cause strong objections from a few people. As part of making a decision where there is
        dissent, the Chair is expected to be aware of which participants work for the same (or <a href="#MemberRelated">related</a>) Member
        organizations and weigh their input accordingly.</p>
      <h4 id="WGArchiveMinorityViews">3.3.2 Recording and Reporting Formal Objections</h4>
      <p>In the W3C process, an individual may register a Formal Objection to a decision. A <dfn id="FormalObjection">Formal Objection</dfn>
        to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g.,
        in response to a <a href="#rec-advance">request to advance</a> a technical report). <strong>Note:</strong> In this document, the
        term "Formal Objection" is used to emphasize this process implication: Formal Objections receive Director consideration. The word
        "objection" used alone has ordinary English connotations.</p>
      <p>An individual who registers a Formal Objection <em class="rfc2119">should</em> cite technical arguments and propose changes that
        would remove the Formal Objection; these proposals <em class="rfc2119">may</em> be vague or incomplete. Formal Objections that do
        not provide substantive arguments or rationale are unlikely to receive serious consideration by the Director.</p>
      <p>A record of each Formal Objection <em class="rfc2119">must</em> be <a href="#confidentiality-change">publicly available</a>. A
        Call for Review (of a document) to the Advisory Committee <em class="rfc2119">must</em> identify any Formal Objections.</p>
      <h4 id="formal-address">3.3.3 Formally Addressing an Issue</h4>
      <p>In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response to the
        reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation,
        a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C
        reviewer would generally consider to be technically sound. If a group believes that a reviewer's comments result from a
        misunderstanding, the group <em class="rfc2119">should</em> seek clarification before reaching a decision.</p>
      <p>As a courtesy, both Chairs and reviewers <em class="rfc2119">should</em> set expectations for the schedule of responses and
        acknowledgments. The group <em class="rfc2119">should</em> reply to a reviewer's initial comments in a timely manner. The group <em
          class="rfc2119">should</em>
        set a time limit for acknowledgment by a reviewer of the group's substantive response; a reviewer cannot block a group's progress.
        It is common for a reviewer to require a week or more to acknowledge and comment on a substantive response. The group's
        responsibility to respond to reviewers does not end once a reasonable amount of time has elapsed. However, reviewers <em class="rfc2119">should</em>
        realize that their comments will carry less weight if not sent to the group in a timely manner.</p>
      <p>Substantive responses <em class="rfc2119">should</em> be recorded. The group <em class="rfc2119">should</em> maintain an accurate
        summary of all substantive issues and responses to them (e.g., in the form of an issues list with links to mailing list archives).</p>
      <h4 id="WGChairReopen">3.3.4 Reopening a Decision When Presented With New Information</h4>
      <p>The Chair <em class="rfc2119">may</em> reopen a decision when presented with new information, including:</p>
      <ul>
        <li>additional technical information,</li>
        <li>comments by email from participants who were unable to attend a scheduled meeting,</li>
        <li>comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with
          colleagues or for cultural reasons).</li>
      </ul>
      <p>The Chair <em class="rfc2119">should</em> record that a decision has been reopened, and <em class="rfc2119">must</em> do so upon
        request from a group participant.</p>
      <h3 id="Votes">3.4 Votes</h3>
      <p>A group <em class="rfc2119">should</em> only conduct a vote to resolve a <em>substantive issue</em> after the Chair has
        determined that all available means of <a href="#Consensus">reaching consensus</a> through technical discussion and compromise have
        failed, and that a vote is necessary to break a deadlock. In this case the Chair <em class="rfc2119">must</em> record (e.g., in the
        minutes of the meeting or in an archived email message):</p>
      <ul>
        <li>an explanation of the issue being voted on;</li>
        <li>the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue;</li>
        <li>the outcome of the vote;</li>
        <li>any Formal Objections.</li>
      </ul>
      <p>In order to vote to resolve a substantive issue, an individual <em class="rfc2119">must</em> be a group <a href="#participant">participant</a>.
        Each organization represented in the group <em class="rfc2119">must</em> have at most one vote, even when the organization is
        represented by several participants in the group (including Invited Experts). For the purposes of voting:</p>
      <ul>
        <li>A Member or group of <a href="#MemberRelated">related Members</a> is considered a single organization.</li>
        <li>The <a href="#Team">Team</a> is considered an organization.</li>
      </ul>
      <p>Unless the charter states otherwise, <a href="#invited-expert-wg">Invited Experts</a> <em class="rfc2119">may</em> vote.</p>
      <p>If a participant is unable to attend a vote, that individual <em class="rfc2119">may</em> authorize anyone at the meeting to act
        as a <dfn id="proxy">proxy</dfn>. The absent participant <em class="rfc2119">must</em> inform the Chair in writing who is acting
        as proxy, with written instructions on the use of the proxy. For a Working Group or Interest Group, see the related requirements
        regarding an individual who attends a meeting as a <a href="#mtg-substitute">substitute</a> for a participant.</p>
      <p>A group <em class="rfc2119">may</em> vote for other purposes than to resolve a substantive issue. For instance, the Chair often
        conducts a "straw poll" vote as a means of determining whether there is consensus about a potential decision.</p>
      <p>A group <em class="rfc2119">may</em> also vote to make a process decision. For example, it is appropriate to decide by simple
        majority whether to hold a meeting in San Francisco or San Jose (there's not much difference geographically). When simple majority
        votes are used to decide minor issues, the minority are <em class="rfc2119">not required</em> to state the reasons for their
        dissent, and the group is <em class="rfc2119">not required</em> to record individual votes.</p>
      <p>A group charter <em class="rfc2119">should</em> include formal voting procedures (e.g., quorum or threshold requirements) for
        making decisions about substantive issues.</p>
      <p>Procedures for <a href="#ACVotes">Advisory Committee votes</a> are described separately.</p>
      <h3 id="WGAppeals">3.5 Appeal of a Chair's Decision</h3>
      <p>Groups resolve issues through dialog. Individuals who disagree strongly with a decision <em class="rfc2119">should</em> register
        with the Chair any <a href="#FormalObjection">Formal Objections</a> (e.g., to a decision made as the result of a <a href="#Votes">vote</a>).</p>
      <p>When group participants believe that their concerns are not being duly considered by the group, they <em class="rfc2119">may</em>
        ask the <a href="#def-Director">Director</a> (for representatives of a Member organization, via their Advisory Committee
        representative) to confirm or deny the decision. The participants <em class="rfc2119">should</em> also make their requests known to
        the <a href="#TeamContact">Team Contact</a>. The Team Contact <em class="rfc2119">must</em> inform the Director when a group
        participant has raised concerns about due process.</p>
      <p>Any requests to the Director to confirm a decision <em class="rfc2119">must</em> include a summary of the issue (whether technical
        or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions <em class="rfc2119">must</em>
        be recorded.</p>
      <p>Procedures for <a href="#ACAppeal">Advisory Committee appeals</a> are described separately.</p>
      <h3 id="resignation">3.6 Resignation from a Group</h3>
      <p>A W3C Member or Invited Expert <em class="rfc2119">may</em> resign from a group. The Team will establish administrative procedures
        for resignation. See section 4.2. of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]
        for information about obligations remaining after resignation from certain groups.</p>
      <section id="chapterDissemination">
        <h2 id="dissemination">4 Dissemination Policies</h2>
        <p>The Team is responsible for managing communication within W3C and with the general public (e.g., news services, press releases,
          managing the Web site and access privileges, and managing calendars). Members <em class="rfc2119">should</em> solicit review by
          the Team prior to issuing press releases about their work within W3C.</p>
        <p>The Team makes every effort to ensure the persistence and availability of the following public information:</p>
        <ul>
          <li><a href="#Reports">W3C technical reports</a> whose publication has been approved by the Director. Per the Membership
            Agreement, W3C technical reports (and software) are available free of charge to the general public; (refer to the <a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C
-              Document License</a> [<a href="#ref-doc-license">PUB18</a>]).</li>
          <li>A <a href="http://www.w3.org/Consortium/mission">mission statement</a> [<a href="#ref-mission">PUB15</a>] that explains the
            purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C.</li>
          <li>Legal documents, including the <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership Agreement</a> [<a
              href="#ref-member-agreement">PUB6</a>])
            and documentation of any legal commitments W3C has with other entities.</li>
          <li>The Process Document.</li>
          <li>Public results of W3C activities and <a href="#GAEvents">Workshops</a>.</li>
        </ul>
        <p>To keep the Members abreast of W3C meetings, Workshops, and review deadlines, the Team provides them with a regular (e.g.,
          weekly) news service and maintains a <a href="http://www.w3.org/Member/Eventscal">calendar</a> [<a href="#ref-calendar">MEM3</a>]
          of official W3C events. Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.</p>
        <h3 id"confidentiality-levels"="">4.1 Confidentiality Levels</h3>
        <p>There are three principal levels of access to W3C information (on the W3C Web site, in W3C meetings, etc.): public, Member-only,
          and Team-only.</p>
        <p>While much information made available by W3C is public, <dfn id="Member-only">"Member-only" information</dfn> is available to
          authorized parties only, including representatives of Member organizations, <a href="#invited-expert-wg">Invited Experts</a>, the
          Advisory Board, the TAG, and the Team. For example, the <a href="#WGCharter">charter</a> of some Working Groups may specify a
          Member-only confidentiality level for group proceedings.</p>
        <p id="Team-only">"Team-only" information is available to the Team and other authorized parties.</p>
        <p>Those authorized to access Member-only and Team-only information:</p>
        <ul>
          <li><em class="rfc2119">must</em> treat the information as confidential within W3C,</li>
          <li><em class="rfc2119">must</em> use reasonable efforts to maintain the proper level confidentiality, and</li>
          <li><em class="rfc2119">must not</em> release this information to the general public or press.</li>
        </ul>
        <p>The Team <em class="rfc2119">must</em> provide mechanisms to protect the confidentiality of Member-only information and ensure
          that authorized parties have proper access to this information. Documents <em class="rfc2119">should</em> clearly indicate
          whether they require Member-only confidentiality. Individuals uncertain of the confidentiality level of a piece of information <em
            class="rfc2119">should</em>
          contact the Team.</p>
        <p>Advisory Committee representatives <em class="rfc2119">may</em> authorize Member-only access to <a href="#member-rep">Member
            representatives</a> and other individuals employed by the Member who are considered appropriate recipients. For instance, it is
          the responsibility of the Advisory Committee representative and other employees and official representatives of the organization
          to ensure that Member-only news announcements are distributed for internal use only within their organization. Information about
          Member mailing lists is available in the <a href="http://www.w3.org/Member/Intro">New Member Orientation</a>.</p>
        <h4 id="confidentiality-change">4.1.1 Changing Confidentiality Level</h4>
        <p>As a benefit of membership, W3C provides some Team-only and Member-only channels for certain types of communication. For example,
          Advisory Committee representatives can send <a href="#ACReview">reviews</a> to a Team-only channel. However, for W3C processes
          with a significant public component, such as the technical report development process, it is also important for information that
          affects decision-making to be publicly available. The Team <em class="rfc2119">may</em> need to communicate Team-only information
          to a Working Group or the public. Similarly, a Working Group whose proceedings are Member-only <em class="rfc2119">must</em> make
          public information pertinent to the technical report development process.</p>
        <p>This document clearly indicates which information <em class="rfc2119">must</em> be available to Members or the public, even
          though that information was initially communicated on Team-only or Member-only channels. Only the Team and parties authorized by
          the Team change the level of confidentiality of this information. When doing so:</p>
        <ol>
          <li>The Team <em class="rfc2119">must</em> use a version of the information that was expressly provided by the author for the new
            confidentiality level. In Calls for Review and other similar messages, the Team <em class="rfc2119">should</em> remind
            recipients to provide such alternatives.</li>
          <li>The Team <em class="rfc2119">must not</em> attribute the version for the new confidentiality level to the author without the
            author's consent.</li>
          <li>If the author has not conveyed to the Team a version that is suitable for another confidentiality level, the Team <em class="rfc2119">may</em>
            make available a version that reasonably communicates what is required, while respecting the original level of confidentiality,
            and without attribution to the original author.</li>
        </ol>
      </section>
      <section id="ChapterGroups">
        <h2 id="GAGeneral">6 Working Groups and Interest Groups</h2>
        <p id="GAGroups">This document defines two types of groups:</p>
        <ol>
          <li><a href="#GroupsWG">Working Groups.</a> Working Groups typically produce deliverables (e.g., <a href="#rec-advance">Recommendation
-              Track technical reports</a>, software, test suites, and reviews of the deliverables of other groups). There are additional
            participation requirements described in the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</li>
          <li><a href="#GroupsIG">Interest Groups.</a> The primary goal of an Interest Group is to bring together people who wish to
            evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.</li>
        </ol>
        <p>Interest Groups do not publish <a href="#RecsW3C">Recommendation Track technical reports</a>; see information about <a href="#WGNote">maturity
-            levels for Interest Groups</a>.</p>
        <h3 id="ReqsAllGroups">6.1 Requirements for All Working and Interest Groups</h3>
        <p>Each group <em class="rfc2119">must</em> have a charter. Requirements for the charter depend on the group type. All group
          charters <em class="rfc2119">must</em> be public (even if other proceedings of the group are <a href="#Member-only">Member-only</a>).
-          Existing charters that are not yet public <em class="rfc2119">must</em> be made public when next revised or extended (with
          attention to <a href="#confidentiality-change">changing confidentiality level</a>).</p>
        <p>Each group <em class="rfc2119">must</em> have a <dfn id="GeneralChairs">Chair</dfn> (or co-Chairs) to coordinate the group's
          tasks. The Director appoints (and re-appoints) Chairs for all groups. The Chair is a <a href="#member-rep">Member representative</a>,
          a <a href="#Team">Team representative</a>, or an <a href="#invited-expert-wg">Invited Expert</a> (invited by the Director). The
          requirements of this document that apply to those types of participants apply to Chairs as well. The <a href="/Guide/chair-roles">role
            of the Chair [MEM14]</a> is described in the <a href="http://www.w3.org/Guide/">Member guide</a> [<a href="#ref-guide">MEM9</a>].</p>
        <p>Each group <em class="rfc2119">must</em> have a <dfn id="TeamContact">Team Contact</dfn>, who acts as the interface between the
          Chair, group participants, and the rest of the Team. The <a href="/Guide/staff-contact">role of the Team Contact</a> is described
          in the Member guide. The Chair and the Team Contact of a group <em class="rfc2119">should not</em> be the same individual.</p>
        <p>Each group <em class="rfc2119">must</em> have an archived mailing list for formal group communication (e.g., for meeting
          announcements and minutes, documentation of decisions, and <a href="#FormalObjection">Formal Objections</a> to decisions). It is
          the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists.
          Refer to the list of <a href="http://www.w3.org/Member/Mail/">group mailing lists</a> [<a href="#ref-mailing-lists">MEM2</a>].</p>
        <p>A Chair <em class="rfc2119">may</em> form task forces (composed of group participants) to carry out assignments for the group.
          The scope of these assignments <em class="rfc2119">must not</em> exceed the scope of the group's charter. A group <span class="rfc2119">SHOULD</span>
          document the process it uses to create task forces (e.g., each task force might have an informal "charter"). Task forces do not
          publish <a href="#Reports">technical reports</a>; the Working Group <em class="rfc2119">may</em> choose to publish their results
          as part of a technical report.</p>
        <h3>6.2 <dfn id="GroupsWG">Working Groups</dfn> and <dfn id="GroupsIG">Interest Groups</dfn></h3>
        <p>Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are defined together
          in the following sections.</p>
        <h4>6.2.1 <dfn id="group-participation">Working Group and Interest Group Participation Requirements</dfn></h4>
        <p>There are three types of individual <dfn id="wgparticipant">participants in a Working Group</dfn>: <a href="#member-rep">Member
            representatives</a>, <a href="#invited-expert-wg">Invited Experts</a>, and <a href="#Team">Team representatives</a> (including
          the <a href="#TeamContact">Team Contact</a>).</p>
        <p>There are four types of individual <dfn id="igparticipant">participants in an Interest Group</dfn>: the same three types as for
          Working Groups plus, for an Interest Group where the only <a href="#ig-mail-only">participation requirement is mailing list
            subscription</a>, <dfn id="public-participant-ig">public participants</dfn>.</p>
        <p>Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a
          group; see also the <a href="#ParticipationCriteria">individual participation criteria</a>.</p>
        <p>A participant <em class="rfc2119">must</em> represent at most one organization in a Working Group or Interest Group.</p>
        <p>An individual <em class="rfc2119">may</em> become a Working or Interest Group participant at any time during the group's
          existence. See also relevant requirements in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-join">section 4.3</a> of the
          <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
        <p>On an exceptional basis, a Working or Interest Group participant <em class="rfc2119">may</em> designate a <dfn id="mtg-substitute">substitute</dfn>
          to attend a <a href="#GeneralMeetings">meeting</a> and <em class="rfc2119">should</em> inform the Chair. The substitute <span class="rfc2119">MAY</span>
          act on behalf of the participant, including for <a href="#Votes">votes</a>. For the substitute to vote, the participant <em class="rfc2119">must</em>
          inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group's
          discussions, the regular participant <em class="rfc2119">should</em> authorize another participant to act as <a href="#proxy">proxy</a>
          for votes.</p>
        <p>To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of experts in the
          area defined by the charter. In principle, Interest Groups have no limit on the number of participants. When a Working Group grows
          too large to be effective, W3C <em class="rfc2119">may</em> split it into an Interest Group (a discussion forum) and a much
          smaller Working Group (a core group of highly dedicated participants).</p>
        <p>See also the licensing obligations on Working Group participants in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
+          of confidentiality</a> and other group requirements.</p>
+      <p>Meeting announcements <em class="rfc2119">should</em> be sent to all appropriate group mailing lists, i.e., those most relevant to
+        the anticipated meeting participants.</p>
+      <p>The following table lists requirements for organizing a meeting:</p>
+      <table border="1">
+        <tbody>
+          <tr>
+            <th><br>
+            </th>
+            <th>Face-to-face meetings</th>
+            <th>Distributed meetings</th>
+          </tr>
+          <tr>
+            <th>Meeting announcement (before)</th>
+            <td><span class="time-interval">eight weeks<sup>*</sup></span></td>
+            <td><span class="time-interval">one week<sup>*</sup></span></td>
+          </tr>
+          <tr>
+            <th>Agenda available (before)</th>
+            <td><span class="time-interval">two weeks</span></td>
+            <td><span class="time-interval">24 hours</span> (or longer if a meeting is scheduled after a weekend or holiday)</td>
+          </tr>
+          <tr>
+            <th>Participation confirmed (before)</th>
+            <td><span class="time-interval">three days</span></td>
+            <td><span class="time-interval">24 hours</span></td>
+          </tr>
+          <tr>
+            <th>Action items available (after)</th>
+            <td><span class="time-interval">three days</span></td>
+            <td><span class="time-interval">24 hours</span></td>
+          </tr>
+          <tr>
+            <th>Minutes available (after)</th>
+            <td><span class="time-interval">two weeks</span></td>
+            <td><span class="time-interval">48 hours</span></td>
+          </tr>
+        </tbody>
+      </table>
+      <p><sup>*</sup> To allow proper planning (e.g., travel arrangements), the Chair is responsible for giving sufficient advance notice
+        about the date and location of a meeting. Shorter notice for a meeting is allowed provided that there are no objections from group
+        participants.</p>
+      <h3 id="Consensus">3.3 Consensus</h3>
+      <p>Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all
+        legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active
+        participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public). Decisions
+        <em class="rfc2119">may</em> be made during meetings (<a href="#ftf-meeting">face-to-face</a> or <a href="#distributed-meeting">distributed</a>)
+        as well as through email. <strong>Note:</strong> The Director, CEO, and COO have the role of assessing consensus within the
+        Advisory Committee.</p>
+      <p>The following terms are used in this document to describe the level of support for a decision among a set of eligible individuals:</p>
+      <ol>
+        <li><dfn id="def-Consensus">Consensus</dfn>: A substantial number of individuals in the set support the decision and nobody in the
+          set registers a <a href="#FormalObjection">Formal Objection</a>. Individuals in the set may abstain. Abstention is either an
+          explicit expression of no opinion or silence by an individual in the set. <dfn id="def-Unanimity">Unanimity</dfn> is the
+          particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).</li>
+        <li><dfn id="def-Dissent">Dissent</dfn>: At least one individual in the set registers a <a href="#FormalObjection">Formal Objection</a>.</li>
+      </ol>
+      <p>By default, the set of individuals eligible to participate in a decision is the set of group participants. The Process Document
+        does not require a quorum for decisions (i.e., the minimal number of eligible participants required to be present before the Chair
+        can call a question). A charter <em class="rfc2119">may</em> include a quorum requirement for consensus decisions.</p>
+      <p>Where unanimity is not possible, a group <em class="rfc2119">should</em> strive to make consensus decisions where there is
+        significant support and few abstentions. The Process Document does not require a particular percentage of eligible participants to
+        agree to a motion in order for a decision to be made. To avoid decisions where there is widespread apathy, (i.e., little support and
+        many abstentions), groups <em class="rfc2119">should</em> set minimum thresholds of active support before a decision can be
+        recorded. The appropriate percentage <em class="rfc2119">may</em> vary depending on the size of the group and the nature of the
+        decision. A charter <em class="rfc2119">may</em> include threshold requirements for consensus decisions. For instance, a charter
+        might require a supermajority of eligible participants (i.e., some established percentage above 50%) to support certain types of
+        consensus decisions.</p>
+      <h4 id="managing-dissent">3.3.1 Managing Dissent</h4>
+      <p>In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The
+        Chair <em class="rfc2119">may</em> record a decision where there is dissent (i.e., there is at least one <a href="#FormalObjection">Formal
+          Objection</a>) so that the group may make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot
+        stop a group's work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly
+        considered the legitimate concerns of dissenters as far as is possible and reasonable, the group <em class="rfc2119">should</em>
+        move on.</p>
+      <p>Groups <em class="rfc2119">should</em> favor proposals that create the weakest objections. This is preferred over proposals that
+        are supported by a large majority but that cause strong objections from a few people. As part of making a decision where there is
+        dissent, the Chair is expected to be aware of which participants work for the same (or <a href="#MemberRelated">related</a>) Member
+        organizations and weigh their input accordingly.</p>
+      <h4 id="WGArchiveMinorityViews">3.3.2 Recording and Reporting Formal Objections</h4>
+      <p>In the W3C process, an individual may register a Formal Objection to a decision. A <dfn id="FormalObjection">Formal Objection</dfn>
+        to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g.,
+        in response to a <a href="#rec-advance">request to advance</a> a technical report). <strong>Note:</strong> In this document, the
+        term "Formal Objection" is used to emphasize this process implication: Formal Objections receive Director consideration. The word
+        "objection" used alone has ordinary English connotations.</p>
+      <p>An individual who registers a Formal Objection <em class="rfc2119">should</em> cite technical arguments and propose changes that
+        would remove the Formal Objection; these proposals <em class="rfc2119">may</em> be vague or incomplete. Formal Objections that do
+        not provide substantive arguments or rationale are unlikely to receive serious consideration by the Director.</p>
+      <p>A record of each Formal Objection <em class="rfc2119">must</em> be <a href="#confidentiality-change">publicly available</a>. A
+        Call for Review (of a document) to the Advisory Committee <em class="rfc2119">must</em> identify any Formal Objections.</p>
+      <h4 id="formal-address">3.3.3 Formally Addressing an Issue</h4>
+      <p>In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response to the
+        reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation,
+        a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C
+        reviewer would generally consider to be technically sound. If a group believes that a reviewer's comments result from a
+        misunderstanding, the group <em class="rfc2119">should</em> seek clarification before reaching a decision.</p>
+      <p>As a courtesy, both Chairs and reviewers <em class="rfc2119">should</em> set expectations for the schedule of responses and
+        acknowledgments. The group <em class="rfc2119">should</em> reply to a reviewer's initial comments in a timely manner. The group <em
+          class="rfc2119">should</em> set a time limit for acknowledgment by a reviewer of the group's substantive response; a reviewer
+        cannot block a group's progress. It is common for a reviewer to require a week or more to acknowledge and comment on a substantive
+        response. The group's responsibility to respond to reviewers does not end once a reasonable amount of time has elapsed. However,
+        reviewers <em class="rfc2119">should</em> realize that their comments will carry less weight if not sent to the group in a timely
+        manner.</p>
+      <p>Substantive responses <em class="rfc2119">should</em> be recorded. The group <em class="rfc2119">should</em> maintain an accurate
+        summary of all substantive issues and responses to them (e.g., in the form of an issues list with links to mailing list archives).</p>
+      <h4 id="WGChairReopen">3.3.4 Reopening a Decision When Presented With New Information</h4>
+      <p>The Chair <em class="rfc2119">may</em> reopen a decision when presented with new information, including:</p>
+      <ul>
+        <li>additional technical information,</li>
+        <li>comments by email from participants who were unable to attend a scheduled meeting,</li>
+        <li>comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with
+          colleagues or for cultural reasons).</li>
+      </ul>
+      <p>The Chair <em class="rfc2119">should</em> record that a decision has been reopened, and <em class="rfc2119">must</em> do so upon
+        request from a group participant.</p>
+      <h3 id="Votes">3.4 Votes</h3>
+      <p>A group <em class="rfc2119">should</em> only conduct a vote to resolve a <em>substantive issue</em> after the Chair has
+        determined that all available means of <a href="#Consensus">reaching consensus</a> through technical discussion and compromise have
+        failed, and that a vote is necessary to break a deadlock. In this case the Chair <em class="rfc2119">must</em> record (e.g., in the
+        minutes of the meeting or in an archived email message):</p>
+      <ul>
+        <li>an explanation of the issue being voted on;</li>
+        <li>the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue;</li>
+        <li>the outcome of the vote;</li>
+        <li>any Formal Objections.</li>
+      </ul>
+      <p>In order to vote to resolve a substantive issue, an individual <em class="rfc2119">must</em> be a group <a href="#participant">participant</a>.
+        Each organization represented in the group <em class="rfc2119">must</em> have at most one vote, even when the organization is
+        represented by several participants in the group (including Invited Experts). For the purposes of voting:</p>
+      <ul>
+        <li>A Member or group of <a href="#MemberRelated">related Members</a> is considered a single organization.</li>
+        <li>The <a href="#Team">Team</a> is considered an organization.</li>
+      </ul>
+      <p>Unless the charter states otherwise, <a href="#invited-expert-wg">Invited Experts</a> <em class="rfc2119">may</em> vote.</p>
+      <p>If a participant is unable to attend a vote, that individual <em class="rfc2119">may</em> authorize anyone at the meeting to act
+        as a <dfn id="proxy">proxy</dfn>. The absent participant <em class="rfc2119">must</em> inform the Chair in writing who is acting
+        as proxy, with written instructions on the use of the proxy. For a Working Group or Interest Group, see the related requirements
+        regarding an individual who attends a meeting as a <a href="#mtg-substitute">substitute</a> for a participant.</p>
+      <p>A group <em class="rfc2119">may</em> vote for other purposes than to resolve a substantive issue. For instance, the Chair often
+        conducts a "straw poll" vote as a means of determining whether there is consensus about a potential decision.</p>
+      <p>A group <em class="rfc2119">may</em> also vote to make a process decision. For example, it is appropriate to decide by simple
+        majority whether to hold a meeting in San Francisco or San Jose (there's not much difference geographically). When simple majority
+        votes are used to decide minor issues, the minority are <em class="rfc2119">not required</em> to state the reasons for their
+        dissent, and the group is <em class="rfc2119">not required</em> to record individual votes.</p>
+      <p>A group charter <em class="rfc2119">should</em> include formal voting procedures (e.g., quorum or threshold requirements) for
+        making decisions about substantive issues.</p>
+      <p>Procedures for <a href="#ACVotes">Advisory Committee votes</a> are described separately.</p>
+      <h3 id="WGAppeals">3.5 Appeal of a Chair's Decision</h3>
+      <p>Groups resolve issues through dialog. Individuals who disagree strongly with a decision <em class="rfc2119">should</em> register
+        with the Chair any <a href="#FormalObjection">Formal Objections</a> (e.g., to a decision made as the result of a <a href="#Votes">vote</a>).</p>
+      <p>When group participants believe that their concerns are not being duly considered by the group, they <em class="rfc2119">may</em>
+        ask the <a href="#def-Director">Director</a> (for representatives of a Member organization, via their Advisory Committee
+        representative) to confirm or deny the decision. The participants <em class="rfc2119">should</em> also make their requests known to
+        the <a href="#TeamContact">Team Contact</a>. The Team Contact <em class="rfc2119">must</em> inform the Director when a group
+        participant has raised concerns about due process.</p>
+      <p>Any requests to the Director to confirm a decision <em class="rfc2119">must</em> include a summary of the issue (whether technical
+        or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions <em class="rfc2119">must</em>
+        be recorded.</p>
+      <p>Procedures for <a href="#ACAppeal">Advisory Committee appeals</a> are described separately.</p>
+      <h3 id="resignation">3.6 Resignation from a Group</h3>
+      <p>A W3C Member or Invited Expert <em class="rfc2119">may</em> resign from a group. The Team will establish administrative procedures
+        for resignation. See section 4.2. of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]
+        for information about obligations remaining after resignation from certain groups.</p>
+      <section id="chapterDissemination">
+        <h2 id="dissemination">4 Dissemination Policies</h2>
+        <p>The Team is responsible for managing communication within W3C and with the general public (e.g., news services, press releases,
+          managing the Web site and access privileges, and managing calendars). Members <em class="rfc2119">should</em> solicit review by
+          the Team prior to issuing press releases about their work within W3C.</p>
+        <p>The Team makes every effort to ensure the persistence and availability of the following public information:</p>
+        <ul>
+          <li><a href="#Reports">W3C technical reports</a> whose publication has been approved by the Director. Per the Membership
+            Agreement, W3C technical reports (and software) are available free of charge to the general public; (refer to the
+            <a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C
+              Document License</a> [<a href="#ref-doc-license">PUB18</a>]).</li>
+          <li>A <a href="http://www.w3.org/Consortium/mission">mission statement</a> [<a href="#ref-mission">PUB15</a>] that explains the
+            purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C.</li>
+          <li>Legal documents, including the <a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership Agreement</a> [<a
+              href="#ref-member-agreement">PUB6</a>]) and documentation of any legal commitments W3C has with other entities.</li>
+          <li>The Process Document.</li>
+          <li>Public results of W3C activities and <a href="#GAEvents">Workshops</a>.</li>
+        </ul>
+        <p>To keep the Members abreast of W3C meetings, Workshops, and review deadlines, the Team provides them with a regular (e.g.,
+          weekly) news service and maintains a <a href="http://www.w3.org/Member/Eventscal">calendar</a> [<a href="#ref-calendar">MEM3</a>]
+          of official W3C events. Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.</p>
+        <h3 id"confidentiality-levels"="">4.1 Confidentiality Levels</h3>
+        <p>There are three principal levels of access to W3C information (on the W3C Web site, in W3C meetings, etc.): public, Member-only,
+          and Team-only.</p>
+        <p>While much information made available by W3C is public, <dfn id="Member-only">"Member-only" information</dfn> is available to
+          authorized parties only, including representatives of Member organizations, <a href="#invited-expert-wg">Invited Experts</a>, the
+          Advisory Board, the TAG, and the Team. For example, the <a href="#WGCharter">charter</a> of some Working Groups may specify a
+          Member-only confidentiality level for group proceedings.</p>
+        <p id="Team-only">"Team-only" information is available to the Team and other authorized parties.</p>
+        <p>Those authorized to access Member-only and Team-only information:</p>
+        <ul>
+          <li><em class="rfc2119">must</em> treat the information as confidential within W3C,</li>
+          <li><em class="rfc2119">must</em> use reasonable efforts to maintain the proper level confidentiality, and</li>
+          <li><em class="rfc2119">must not</em> release this information to the general public or press.</li>
+        </ul>
+        <p>The Team <em class="rfc2119">must</em> provide mechanisms to protect the confidentiality of Member-only information and ensure
+          that authorized parties have proper access to this information. Documents <em class="rfc2119">should</em> clearly indicate
+          whether they require Member-only confidentiality. Individuals uncertain of the confidentiality level of a piece of information <em
+            class="rfc2119">should</em> contact the Team.</p>
+        <p>Advisory Committee representatives <em class="rfc2119">may</em> authorize Member-only access to <a href="#member-rep">Member
+            representatives</a> and other individuals employed by the Member who are considered appropriate recipients. For instance, it is
+          the responsibility of the Advisory Committee representative and other employees and official representatives of the organization
+          to ensure that Member-only news announcements are distributed for internal use only within their organization. Information about
+          Member mailing lists is available in the <a href="http://www.w3.org/Member/Intro">New Member Orientation</a>.</p>
+        <h4 id="confidentiality-change">4.1.1 Changing Confidentiality Level</h4>
+        <p>As a benefit of membership, W3C provides some Team-only and Member-only channels for certain types of communication. For example,
+          Advisory Committee representatives can send <a href="#ACReview">reviews</a> to a Team-only channel. However, for W3C processes
+          with a significant public component, such as the technical report development process, it is also important for information that
+          affects decision-making to be publicly available. The Team <em class="rfc2119">may</em> need to communicate Team-only information
+          to a Working Group or the public. Similarly, a Working Group whose proceedings are Member-only <em class="rfc2119">must</em> make
+          public information pertinent to the technical report development process.</p>
+        <p>This document clearly indicates which information <em class="rfc2119">must</em> be available to Members or the public, even
+          though that information was initially communicated on Team-only or Member-only channels. Only the Team and parties authorized by
+          the Team change the level of confidentiality of this information. When doing so:</p>
+        <ol>
+          <li>The Team <em class="rfc2119">must</em> use a version of the information that was expressly provided by the author for the new
+            confidentiality level. In Calls for Review and other similar messages, the Team <em class="rfc2119">should</em> remind
+            recipients to provide such alternatives.</li>
+          <li>The Team <em class="rfc2119">must not</em> attribute the version for the new confidentiality level to the author without the
+            author's consent.</li>
+          <li>If the author has not conveyed to the Team a version that is suitable for another confidentiality level, the Team <em class="rfc2119">may</em>
+            make available a version that reasonably communicates what is required, while respecting the original level of confidentiality,
+            and without attribution to the original author.</li>
+        </ol>
+      </section>
+      <section id="ChapterGroups">
+        <h2 id="GAGeneral">6 Working Groups and Interest Groups</h2>
+        <p id="GAGroups">This document defines two types of groups:</p>
+        <ol>
+          <li><a href="#GroupsWG">Working Groups.</a> Working Groups typically produce deliverables (e.g., <a href="#rec-advance">Recommendation
+              Track technical reports</a>, software, test suites, and reviews of the deliverables of other groups). There are additional
+            participation requirements described in the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a>
+            [<a href="#ref-patentpolicy">PUB33</a>].</li>
+          <li><a href="#GroupsIG">Interest Groups.</a> The primary goal of an Interest Group is to bring together people who wish to
+            evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.</li>
+        </ol>
+        <p>Interest Groups do not publish <a href="#RecsW3C">Recommendation Track technical reports</a>; see information about <a href="#WGNote">maturity
+            levels for Interest Groups</a>.</p>
+        <h3 id="ReqsAllGroups">6.1 Requirements for All Working and Interest Groups</h3>
+        <p>Each group <em class="rfc2119">must</em> have a charter. Requirements for the charter depend on the group type. All group
+          charters <em class="rfc2119">must</em> be public (even if other proceedings of the group are <a href="#Member-only">Member-only</a>).
+          Existing charters that are not yet public <em class="rfc2119">must</em> be made public when next revised or extended (with
+          attention to <a href="#confidentiality-change">changing confidentiality level</a>).</p>
+        <p>Each group <em class="rfc2119">must</em> have a <dfn id="GeneralChairs">Chair</dfn> (or co-Chairs) to coordinate the group's
+          tasks. The Director appoints (and re-appoints) Chairs for all groups. The Chair is a <a href="#member-rep">Member representative</a>,
+          a <a href="#Team">Team representative</a>, or an <a href="#invited-expert-wg">Invited Expert</a> (invited by the Director). The
+          requirements of this document that apply to those types of participants apply to Chairs as well. The <a href="/Guide/chair-roles">role
+            of the Chair [MEM14]</a> is described in the <a href="http://www.w3.org/Guide/">Member guide</a> [<a href="#ref-guide">MEM9</a>].</p>
+        <p>Each group <em class="rfc2119">must</em> have a <dfn id="TeamContact">Team Contact</dfn>, who acts as the interface between the
+          Chair, group participants, and the rest of the Team. The <a href="/Guide/staff-contact">role of the Team Contact</a> is described
+          in the Member guide. The Chair and the Team Contact of a group <em class="rfc2119">should not</em> be the same individual.</p>
+        <p>Each group <em class="rfc2119">must</em> have an archived mailing list for formal group communication (e.g., for meeting
+          announcements and minutes, documentation of decisions, and <a href="#FormalObjection">Formal Objections</a> to decisions). It is
+          the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists.
+          Refer to the list of <a href="http://www.w3.org/Member/Mail/">group mailing lists</a> [<a href="#ref-mailing-lists">MEM2</a>].</p>
+        <p>A Chair <em class="rfc2119">may</em> form task forces (composed of group participants) to carry out assignments for the group.
+          The scope of these assignments <em class="rfc2119">must not</em> exceed the scope of the group's charter. A group <span class="rfc2119">SHOULD</span>
+          document the process it uses to create task forces (e.g., each task force might have an informal "charter"). Task forces do not
+          publish <a href="#Reports">technical reports</a>; the Working Group <em class="rfc2119">may</em> choose to publish their results
+          as part of a technical report.</p>
+        <h3>6.2 <dfn id="GroupsWG">Working Groups</dfn> and <dfn id="GroupsIG">Interest Groups</dfn></h3>
+        <p>Although Working Groups and Interest Groups have different purposes, they share some characteristics, and so are defined together
+          in the following sections.</p>
+        <h4>6.2.1 <dfn id="group-participation">Working Group and Interest Group Participation Requirements</dfn></h4>
+        <p>There are three types of individual <dfn id="wgparticipant">participants in a Working Group</dfn>: <a href="#member-rep">Member
+            representatives</a>, <a href="#invited-expert-wg">Invited Experts</a>, and <a href="#Team">Team representatives</a> (including
+          the <a href="#TeamContact">Team Contact</a>).</p>
+        <p>There are four types of individual <dfn id="igparticipant">participants in an Interest Group</dfn>: the same three types as for
+          Working Groups plus, for an Interest Group where the only <a href="#ig-mail-only">participation requirement is mailing list
+            subscription</a>, <dfn id="public-participant-ig">public participants</dfn>.</p>
+        <p>Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a
+          group; see also the <a href="#ParticipationCriteria">individual participation criteria</a>.</p>
+        <p>A participant <em class="rfc2119">must</em> represent at most one organization in a Working Group or Interest Group.</p>
+        <p>An individual <em class="rfc2119">may</em> become a Working or Interest Group participant at any time during the group's
+          existence. See also relevant requirements in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-join">section 4.3</a> of the
+          <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+        <p>On an exceptional basis, a Working or Interest Group participant <em class="rfc2119">may</em> designate a <dfn id="mtg-substitute">substitute</dfn>
+          to attend a <a href="#GeneralMeetings">meeting</a> and <em class="rfc2119">should</em> inform the Chair. The substitute <span class="rfc2119">MAY</span>
+          act on behalf of the participant, including for <a href="#Votes">votes</a>. For the substitute to vote, the participant <em class="rfc2119">must</em>
+          inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group's
+          discussions, the regular participant <em class="rfc2119">should</em> authorize another participant to act as <a href="#proxy">proxy</a>
+          for votes.</p>
+        <p>To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of experts in the
+          area defined by the charter. In principle, Interest Groups have no limit on the number of participants. When a Working Group grows
+          too large to be effective, W3C <em class="rfc2119">may</em> split it into an Interest Group (a discussion forum) and a much
+          smaller Working Group (a core group of highly dedicated participants).</p>
+        <p>See also the licensing obligations on Working Group participants in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
             3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>],
-          and the patent claim exclusion process of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">section 4</a>.</p>
        <h5>6.2.1.1 <dfn id="member-rep-wg">Member Representative</dfn> in a Working Group</h5>
        <p>An individual is a Member representative in a Working Group if all of the following conditions are satisfied:</p>
        <ul>
          <li>the Advisory Committee representative of the Member in question has designated the individual as a Working Group participant,
            and</li>
          <li>the individual qualifies for <a href="#member-rep">Member representation</a>.</li>
        </ul>
        <p><dfn id="member-rep-info">To designate an individual as a Member representative in a Working Group</dfn>, an Advisory Committee
          representative <em class="rfc2119">must</em> provide the Chair and Team Contact with all of the following information, in
          addition to any other information required by the <a href="#cfp">Call for Participation</a> and charter (including the
          participation requirements of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]):</p>
        <ol>
          <li>The name of the W3C Member the individual represents and whether the individual is an employee of that Member organization;</li>
          <li>A statement that the individual accepts the participation terms set forth in the charter (with an indication of charter date
            or version);</li>
          <li>A statement that the Member will provide the necessary financial support for participation (e.g., for travel, telephone calls,
            and conferences).</li>
        </ol>
        <p>A Member participates in a Working Group from the moment the first Member representative joins the group until either of the
          following occurs:</p>
        <ul>
          <li>the group closes, or</li>
          <li>the Member <a href="#resignation">resigns</a> from the Working Group; this is done through the Member's Advisory Committee
            representative.</li>
        </ul>
        <h5>6.2.1.2 <dfn id="member-rep-ig">Member Representative</dfn> in an Interest Group</h5>
        <p>When the participation requirements exceed <a href="#ig-mail-only">Interest Group mailing list subscription</a>, an individual
          is a Member representative in an Interest Group if all of the following conditions are satisfied:</p>
        <ul>
          <li>the Advisory Committee representative of the Member in question has designated the individual as an Interest Group
            participant, and</li>
          <li>the individual qualifies for <a href="#member-rep">Member representation</a>.</li>
        </ul>
        <p>To designate an individual as a Member representative in an Interest Group, the Advisory Committee representative <em class="rfc2119">must</em>
          follow the instructions in the <a href="#cfp">Call for Participation</a> and charter.</p>
        <p>Member participation in an Interest Group ceases under the same conditions as for a Working Group.</p>
        <h5>6.2.1.3 <dfn id="invited-expert-wg">Invited Expert in a Working Group</dfn></h5>
        <p>The Chair <em class="rfc2119">may</em> invite an individual with a particular expertise to participate in a Working Group. This
          individual <em class="rfc2119">may</em> represent an organization in the group (e.g., if acting as a liaison with another
          organization).</p>
        <p>An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:</p>
        <ul>
          <li>the Chair has designated the individual as a group participant,</li>
          <li>the Team Contact has agreed with the Chair's choice, and</li>
          <li>the individual has provided the <a href="#inv-expert-info">information required of an Invited Expert</a> to the Chair and
            Team Contact.</li>
        </ul>
        <p>To designate an individual as an Invited Expert in a Working Group, the Chair <em class="rfc2119">must</em> inform the Team
          Contact and provide rationale for the choice. When the Chair and the Team Contact disagree about a designation, the <a href="#def-Director">Director</a>
          determines whether the individual will be invited to participate in the Working Group.</p>
        <p><dfn id="inv-expert-info">To be able to participate in a Working Group as an Invited Expert</dfn>, an individual <em class="rfc2119">must</em>
          do all of the following:</p>
        <ul>
          <li>identify the organization, if any, the individual represents as a participant in this group,</li>
          <li>agree to the terms of the <a href="http://www.w3.org/Consortium/Legal/collaborators-agreement">invited expert and
              collaborators agreement</a> [<a href="#ref-invited-expert">PUB17</a>],</li>
          <li>accept the participation terms set forth in the charter (including the participation requirements of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
-              3</a> (especially 3.4) and <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">section 6</a> (especially
            6.10) of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]).
-            Indicate a specific charter date or version,</li>
          <li>disclose whether the individual is an employee of a W3C Member; see the <a href="#coi">conflict of interest policy</a>,</li>
          <li>provide a statement of who will provide the necessary financial support for the individual's participation (e.g., for travel,
            telephone calls, and conferences), and</li>
          <li>if the individual's employer (including a self-employed individual) or the organization the individual represents is not a W3C
            Member, indicate whether that organization intends to join W3C. If the organization does not intend to join W3C, indicate
            reasons the individual is aware of for this choice.</li>
        </ul>
        <p>The Chair <em class="rfc2119">should not</em> designate as an Invited Expert in a Working Group an individual who is an employee
          of a W3C Member. The Chair <em class="rfc2119">must not</em> use Invited Expert status to circumvent participation limits imposed
          by the <a href="#WGCharter">charter</a>.</p>
        <p>An Invited Expert participates in a Working Group from the moment the individual joins the group until any of the following
          occurs:</p>
        <ul>
          <li>the group closes, or</li>
          <li>the Chair or Director withdraws the invitation to participate, or</li>
          <li>the individual <a href="#resignation">resigns</a>.</li>
        </ul>
        <h5>6.2.1.4 <dfn id="invited-expert-ig">Invited Expert in an Interest Group</dfn></h5>
        <p>When the participation requirements exceed <a href="#ig-mail-only">Interest Group mailing list subscription</a>, the
          participation requirements for an Invited Expert in an Interest Group are the same as those for an <a href="#invited-expert-wg">Invited
-            Expert in a Working Group</a>.</p>
        <h5>6.2.1.5 <dfn id="team-rep-wg">Team Representative in a Working Group</dfn></h5>
        <p>An individual is a Team representative in a Working Group when so designated by W3C management.</p>
        <p>A Team representative participates in a Working Group from the moment the individual joins the group until any of the following
          occurs:</p>
        <ul>
          <li>the group closes, or</li>
          <li>W3C management changes Team representation by sending email to the Chair, cc'ing the group mailing list.</li>
        </ul>
        <p>The Team participates in a Working Group from the moment the Director announces the creation of the group until the group closes.</p>
        <h5>6.2.1.6 <dfn id="team-rep-ig">Team Representative in an Interest Group</dfn></h5>
        <p>When the participation requirements exceed <a href="#ig-mail-only">Interest Group mailing list subscription</a>, an individual
          is a Team representative in an Interest Group when so designated by W3C management.</p>
        <h4>6.2.2 <dfn id="WGCharterDevelopment">Working Group and Interest Group Charter Development</dfn></h4>
        <p>W3C creates a charter based on interest from the Members and Team. The Team <em class="rfc2119">must</em> notify the Advisory
          Committee when a charter for a new Working Group or Interest Group is in development. This is intended to raise awareness, even if
          no formal proposal is yet available. Advisory Committee representatives <em class="rfc2119">may</em> express their general
          support on the <a href="#ACCommunication">Advisory Committee discussion list</a>.</p>
        <p>W3C <em class="rfc2119">may</em> begin work on a Working Group or Interest Group charter at any time.</p>
        <h4>6.2.3 <dfn id="CharterReview">Advisory Committee Review of a Working Group or Interest Group Charter</dfn></h4>
        <p>The Director <em class="rfc2119">must</em> solicit <a href="#ReviewAppeal">Advisory Committee review</a> of every new or
          substantively modified Working Group or Interest Group charter. The Director is <em class="rfc2119">not required</em> to solicit
          Advisory Committee review prior to a charter extension or for minor changes. The review period <em class="rfc2119">must</em> be
          at least four weeks.</p>
        <p>The Director's Call for Review of a substantively modified charter <em class="rfc2119">must</em> highlight important changes
          (e.g., regarding deliverables or resource allocation) and include rationale for the changes.</p>
        <h4>6.2.4 <dfn id="cfp">Call for Participation in a Working Group or Interest Group</dfn></h4>
        <p>After Advisory Committee review of a Working Group or Interest Group charter, the Director <em class="rfc2119">may</em> issue a
          Call for Participation to the Advisory Committee. Charters <em class="rfc2119">may</em> be amended based on review comments
          before the Director issues a Call for Participation. </p>
        <p>For a new group, this announcement officially creates the group. The announcement <em class="rfc2119">must</em> include a
          reference to the <a href="#WGCharter">charter</a>, the name(s) of the group's <a href="#GeneralChairs">Chair(s)</a>, and the
          name of the <a href="#TeamContact">Team Contact</a>.</p>
        <p>After a Call for Participation, any <a href="#member-rep">Member representatives</a> and <a href="#invited-expert-wg">Invited
            Experts</a> <em class="rfc2119">must</em> be designated (or re-designated).</p>
        <p>Advisory Committee representatives <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a> creation or substantive
          modification of a Working Group or Interest Group charter.</p>
        <h4>6.2.5 <dfn id="charter-extension">Working Group and Interest Group Charter Extension</dfn></h4>
        <p>To extend a Working Group or Interest Group charter with no other substantive modifications, the Director announces the extension
          to the Advisory Committee. The announcement <em class="rfc2119">must</em> indicate the new duration. The announcement <span class="rfc2119">MUST</span>
          also include rationale for the extension, a reference to the <a href="#WGCharter">charter</a>, the name(s) of the group's <a href="#GeneralChairs">Chair(s)</a>,
          the name of the <a href="#TeamContact">Team Contact</a>, and instructions for joining the group.</p>
        <p>After a charter extension, Advisory Committee representatives and the Chair are <em class="rfc2119">not required</em> to
          re-designate <a href="#member-rep">Member representatives</a> and <a href="#invited-expert-wg">Invited Experts</a>.</p>
        <p>Advisory Committee representatives <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a> the extension of a Working Group
          or Interest Group charter.</p>
        <h4>6.2.6 <dfn id="WGCharter">Working Group and Interest Group Charters</dfn></h4>
        <p>A Working Group or Interest Group charter <em class="rfc2119">must</em> include all of the following information.</p>
        <ul>
          <li>The group's mission (e.g., develop a technology or process, review the work of other groups);</li>
          <li>The scope of the group's work and criteria for success;</li>
          <li>The duration of the group (typically from six months to two years);</li>
          <li>The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software), expected
            milestones, and the process for the group participants to approve the release of these deliverables (including public
            intermediate results). A charter is <em class="rfc2119">not required</em> to include the schedule for a review of another
            group's deliverables;</li>
          <li>Any dependencies by groups within or outside of W3C on the deliverables of this group. For any dependencies, the charter <span
              class="rfc2119">MUST</span>
            specify the mechanisms for communication about the deliverables;</li>
          <li>Any dependencies of this group on other groups within or outside of W3C. For example, one group's charter might specify that
            another group is expected to review a technical report before it can become a Recommendation. For any dependencies, the charter
            <em class="rfc2119">must</em> specify when required deliverables are expected from the other groups. The charter <em class="rfc2119">should</em>
            set expectations about how coordination with those groups will take place; see the section on <a href="#Liaisons">liaisons with
              other organizations</a>. Finally, the charter <em class="rfc2119">should</em> specify expected conformance to the
            deliverables of the other groups;</li>
          <li>The <a href="#confidentiality-levels">level of confidentiality</a> of the group's proceedings and deliverables;</li>
          <li>Meeting mechanisms and expected frequency;</li>
          <li>If known, the date of the first <a href="#ftf-meeting">face-to-face meeting</a>. The date of the first face-to-face meeting
            of a proposed group <em class="rfc2119">must not</em> be sooner than <span class="time-interval">eight weeks</span> after the
            date of the proposal.</li>
          <li>Communication mechanisms to be employed within the group, between the group and the rest of W3C, and with the general public;</li>
          <li>An estimate of the expected time commitment from participants;</li>
          <li>The expected time commitment and level of involvement by the Team (e.g., to track developments, write and edit technical
            reports, develop code, or organize pilot experiments).</li>
          <li>Intellectual property information. What are the intellectual property (including patents and copyright) considerations
            affecting the success of the Group? In particular, is there any reason to believe that it will be difficult to meet the
            Royalty-Free licensing goals of section 2 of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a
              href="#ref-patentpolicy">PUB33</a>]?</li>
        </ul>
        <p>See also the charter requirements of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Licensing">section 2</a> and <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
-            3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
        <p id="ig-charter-participation">An Interest Group charter <em class="rfc2119">may</em> include provisions regarding participation,
          including specifying that the <dfn id="ig-mail-only">only requirement for participation (by anyone) in the Interest Group is
            subscription to the Interest Group mailing list</dfn>. This type of Interest Group <em class="rfc2119">may</em> have <a href="#public-participant-ig">public
            participants</a>.</p>
        <p>A charter <em class="rfc2119">may</em> include additional voting procedures, but those procedures <em class="rfc2119">must not</em>
          conflict with the <a href="#Votes">voting requirements</a> of the Process Document.</p>
        <p>A charter <em class="rfc2119">may</em> include provisions other than those required by this document. The charter <em class="rfc2119">should</em>
          highlight whether additional provisions impose constraints beyond those of the W3C Process Document (e.g., limits on the number of
          individuals in a Working Group who represent the same Member organization or group of <a href="#MemberRelated">related Members</a>).</p>
        <h4>6.2.8 <dfn id="GeneralTermination">Working Group and Interest Group Closure</dfn></h4>
        <p>A Working Group or Interest Group charter specifies a duration for the group. The Director, subject to <a href="#ACAppeal">appeal</a>
          by Advisory Committee representatives, <em class="rfc2119">may</em> close a group prior to the date specified in the charter in
          any of the following circumstances:</p>
        <ul>
          <li>There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities
            established within W3C.</li>
          <li>The group produces chartered deliverables ahead of schedule.</li>
        </ul>
        <p>The Director closes a Working Group or Interest Group by announcement to the Advisory Committee.</p>
        <p>Closing a Working Group has implications with respect to the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent
            Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
      </section>
      <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="#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="#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="#ref-patentpolicy">PUB33</a>].
      </p>
      <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
        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="#revised-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="start" 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-levels">maturity
          level</a>. The Director <em class="rfc2119">must</em> inform the <a href="#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="#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 <em class="rfc2119">must</em> 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="#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> [<a href="#rdf-doc-list">PUB11</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="#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,</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> [<a href="#rdf-pubrules">PUB31</a>](e.g., for <span id="DocumentName">naming</span>, status information, style, and <span
          id="document-copyright">copyright
          requirements</span>). 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="#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="#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="#FormalObjection">Formal Objections</a>.</li>
        <li><em class="rfc2119">should</em> 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="#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 id="wide-review">7.2.3.1 Wide Review</h5>
      <p>The requirements for wide review 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 (for
        example through notices posted to <a href="mailto:public-review-announce@w3.org">public-review-announce@w3.org</a>) and were able
        to actually perform reviews of and provide comments on the specification. A second objective is to encourage groups to request
        reviews early enough that comments and suggested changes may still be reasonably incorporated in response to the review. 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 or identified as <a href="http://www.w3.org/2001/11/StdLiaison.html">liaisons</a> [<a href="#rdf-liaison-list">PUB29</a>],
-        and seek evidence of clear communication to the general public about appropriate times and which content to review and whether such
        reviews actually occurred. </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 <em class="rfc2119">should</em> 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 <em class="rfc2119">may</em> 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>
        <dd>Changes that add a new functionality, element, etc.</dd>
      </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> [<a href="#rdf-doc-list">PUB11</a>]
        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="#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. </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="#revised-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="#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>
      <h3 id="candidate-rec"><a 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="#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="#ref-patentpolicy">PUB33</a>].</p>
      <p>Possible next steps:</p>
      <ul>
        <li>Return to <a href="#revised-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="#def-Dissent" rel="glossary" title="Definition of Dissent"><span class="dfn-instance">dissent</span></a>
        to the Working Group decision to request advancement <a href="#AC">Advisory Committee</a> representatives <em class="rfc2119">may</em>
        <a href="#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="#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 <em class="rfc2119">must</em> announce the publication of a revised Candidate Recommendation to other W3C groups and
        the Public.</p>
      <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="#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="#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="#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 <em class="rfc2119">must not</em> include any substantive changes from the Proposed Recommendation it
        is based on, to make any substantive change to a Proposed Recommendation the Working Group <em class="rfc2119">must</em> return the
        specification to Candidate Recommendation or Working Draft.</p>
      <p>Possible Next Steps:</p>
      <ul>
        <li>Return to <a href="#revised-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>
      <h3 id="rec-publication">7.6 W3C Recommendation</h3>
      <p>The decision to advance a document to Recommendation is a <a href="#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="#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="#formal-address">formally address</a> the comment at least 14
          days before publication as a W3C Recommendation. In this case the <a href="#AC">Advisory Committee</a> <em class="rfc2119">may</em>
          <a href="#ACAppeal">appeal</a> the decision,</li>
        <li>The Director <em class="rfc2119">must</em> announce the publication of a W3C Recommendation to <a href="#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="#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="Modif-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="Modif-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="Modif-toCR" stroke="black" fill="black">
              <path d="M185,40h31"></path>
              <polygon points="211,36 221,40 211,44"></polygon> </g>
            <g id="Modif-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="Modif-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="Modif-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="Modif-ToPR" stroke="black" fill="black">
              <path d="M298,40h27"></path>
              <polygon points="324,36 334,40 324,44"></polygon> </g>
            <g id="Modif-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="Modif-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="Modif-ToRec" stroke="black" fill="black">
              <path d="M391,40h20"></path>
              <polygon points="404,36 414,40 404,44"></polygon> </g> </g>
          <g id="Modif-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="Modif-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="Modif-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="Modif-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 error that can be resolved by one or more changes in classes 1-3 of section <a href="#correction-classes">7.2.5
-          Classes of Changes</a>.</p>
      <p>Working Groups <em class="rfc2119">must</em> keep a record as errors are reported by readers and implementers. Such error reports
        <em class="rfc2119">should</em> be processed no less frequently than quarterly. Readers of the Recommendation <em class="rfc2119">should</em>
        be able easily to find and see the errata that apply to that specific Recommendation.</p>
      <p> Working groups may decide how to document errata. The best practice is a document that identifies itself as based on the
        Recommendation text and clearly identifies the errata and any proposed corrections; other approaches include various forms of an
        errata page, possibly auto-generated from a database.</p>
      <p>An erratum is resolved by an informative, "proposed" correction generated by the Working Group. A correction becomes part of the
        Recommendation by the process for Revising a Recommendation described in the next section.</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 <em class="rfc2119">may</em> request publication of a <a href="#rec-pr">Proposed Recommendation</a> or W3C <em class="rfc2119">may</em>
        publish a <a href="#rec-pr">Proposed Recommendation</a> to make this class of change without passing through earlier maturity
        levels. Such publications <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 <em class="rfc2119">may</em> 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 id="rec-edited">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>
      <p>For changes which introduces a new feature or features, W3C <em class="rfc2119">must</em> 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="#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="#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 id="proposed-rescinded-rec">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="#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="#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="#formal-address">formally address</a> the comment at least 14
        days before publication as a Rescinded Recommendation. In this case the <a href="#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
+          and the patent claim exclusion process of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Exclusion">section 4</a>.</p>
+        <h5>6.2.1.1 <dfn id="member-rep-wg">Member Representative</dfn> in a Working Group</h5>
+        <p>An individual is a Member representative in a Working Group if all of the following conditions are satisfied:</p>
+        <ul>
+          <li>the Advisory Committee representative of the Member in question has designated the individual as a Working Group participant,
+            and</li>
+          <li>the individual qualifies for <a href="#member-rep">Member representation</a>.</li>
+        </ul>
+        <p><dfn id="member-rep-info">To designate an individual as a Member representative in a Working Group</dfn>, an Advisory Committee
+          representative <em class="rfc2119">must</em> provide the Chair and Team Contact with all of the following information, in
+          addition to any other information required by the <a href="#cfp">Call for Participation</a> and charter (including the
+          participation requirements of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]):</p>
+        <ol>
+          <li>The name of the W3C Member the individual represents and whether the individual is an employee of that Member organization;</li>
+          <li>A statement that the individual accepts the participation terms set forth in the charter (with an indication of charter date
+            or version);</li>
+          <li>A statement that the Member will provide the necessary financial support for participation (e.g., for travel, telephone calls,
+            and conferences).</li>
+        </ol>
+        <p>A Member participates in a Working Group from the moment the first Member representative joins the group until either of the
+          following occurs:</p>
+        <ul>
+          <li>the group closes, or</li>
+          <li>the Member <a href="#resignation">resigns</a> from the Working Group; this is done through the Member's Advisory Committee
+            representative.</li>
+        </ul>
+        <h5>6.2.1.2 <dfn id="member-rep-ig">Member Representative</dfn> in an Interest Group</h5>
+        <p>When the participation requirements exceed <a href="#ig-mail-only">Interest Group mailing list subscription</a>, an individual
+          is a Member representative in an Interest Group if all of the following conditions are satisfied:</p>
+        <ul>
+          <li>the Advisory Committee representative of the Member in question has designated the individual as an Interest Group
+            participant, and</li>
+          <li>the individual qualifies for <a href="#member-rep">Member representation</a>.</li>
+        </ul>
+        <p>To designate an individual as a Member representative in an Interest Group, the Advisory Committee representative <em class="rfc2119">must</em>
+          follow the instructions in the <a href="#cfp">Call for Participation</a> and charter.</p>
+        <p>Member participation in an Interest Group ceases under the same conditions as for a Working Group.</p>
+        <h5>6.2.1.3 <dfn id="invited-expert-wg">Invited Expert in a Working Group</dfn></h5>
+        <p>The Chair <em class="rfc2119">may</em> invite an individual with a particular expertise to participate in a Working Group. This
+          individual <em class="rfc2119">may</em> represent an organization in the group (e.g., if acting as a liaison with another
+          organization).</p>
+        <p>An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:</p>
+        <ul>
+          <li>the Chair has designated the individual as a group participant,</li>
+          <li>the Team Contact has agreed with the Chair's choice, and</li>
+          <li>the individual has provided the <a href="#inv-expert-info">information required of an Invited Expert</a> to the Chair and
+            Team Contact.</li>
+        </ul>
+        <p>To designate an individual as an Invited Expert in a Working Group, the Chair <em class="rfc2119">must</em> inform the Team
+          Contact and provide rationale for the choice. When the Chair and the Team Contact disagree about a designation, the <a href="#def-Director">Director</a>
+          determines whether the individual will be invited to participate in the Working Group.</p>
+        <p><dfn id="inv-expert-info">To be able to participate in a Working Group as an Invited Expert</dfn>, an individual <em class="rfc2119">must</em>
+          do all of the following:</p>
+        <ul>
+          <li>identify the organization, if any, the individual represents as a participant in this group,</li>
+          <li>agree to the terms of the <a href="http://www.w3.org/Consortium/Legal/collaborators-agreement">invited expert and
+              collaborators agreement</a> [<a href="#ref-invited-expert">PUB17</a>],</li>
+          <li>accept the participation terms set forth in the charter (including the participation requirements of
+            <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
+              3</a> (especially 3.4) and <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Disclosure">section 6</a> (especially
+            6.10) of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>]).
+            Indicate a specific charter date or version,</li>
+          <li>disclose whether the individual is an employee of a W3C Member; see the <a href="#coi">conflict of interest policy</a>,</li>
+          <li>provide a statement of who will provide the necessary financial support for the individual's participation (e.g., for travel,
+            telephone calls, and conferences), and</li>
+          <li>if the individual's employer (including a self-employed individual) or the organization the individual represents is not a W3C
+            Member, indicate whether that organization intends to join W3C. If the organization does not intend to join W3C, indicate
+            reasons the individual is aware of for this choice.</li>
+        </ul>
+        <p>The Chair <em class="rfc2119">should not</em> designate as an Invited Expert in a Working Group an individual who is an employee
+          of a W3C Member. The Chair <em class="rfc2119">must not</em> use Invited Expert status to circumvent participation limits imposed
+          by the <a href="#WGCharter">charter</a>.</p>
+        <p>An Invited Expert participates in a Working Group from the moment the individual joins the group until any of the following
+          occurs:</p>
+        <ul>
+          <li>the group closes, or</li>
+          <li>the Chair or Director withdraws the invitation to participate, or</li>
+          <li>the individual <a href="#resignation">resigns</a>.</li>
+        </ul>
+        <h5>6.2.1.4 <dfn id="invited-expert-ig">Invited Expert in an Interest Group</dfn></h5>
+        <p>When the participation requirements exceed <a href="#ig-mail-only">Interest Group mailing list subscription</a>, the
+          participation requirements for an Invited Expert in an Interest Group are the same as those for an <a href="#invited-expert-wg">Invited
+            Expert in a Working Group</a>.</p>
+        <h5>6.2.1.5 <dfn id="team-rep-wg">Team Representative in a Working Group</dfn></h5>
+        <p>An individual is a Team representative in a Working Group when so designated by W3C management.</p>
+        <p>A Team representative participates in a Working Group from the moment the individual joins the group until any of the following
+          occurs:</p>
+        <ul>
+          <li>the group closes, or</li>
+          <li>W3C management changes Team representation by sending email to the Chair, cc'ing the group mailing list.</li>
+        </ul>
+        <p>The Team participates in a Working Group from the moment the Director announces the creation of the group until the group closes.</p>
+        <h5>6.2.1.6 <dfn id="team-rep-ig">Team Representative in an Interest Group</dfn></h5>
+        <p>When the participation requirements exceed <a href="#ig-mail-only">Interest Group mailing list subscription</a>, an individual
+          is a Team representative in an Interest Group when so designated by W3C management.</p>
+        <h4>6.2.2 <dfn id="WGCharterDevelopment">Working Group and Interest Group Charter Development</dfn></h4>
+        <p>W3C creates a charter based on interest from the Members and Team. The Team <em class="rfc2119">must</em> notify the Advisory
+          Committee when a charter for a new Working Group or Interest Group is in development. This is intended to raise awareness, even if
+          no formal proposal is yet available. Advisory Committee representatives <em class="rfc2119">may</em> express their general
+          support on the <a href="#ACCommunication">Advisory Committee discussion list</a>.</p>
+        <p>W3C <em class="rfc2119">may</em> begin work on a Working Group or Interest Group charter at any time.</p>
+        <h4>6.2.3 <dfn id="CharterReview">Advisory Committee Review of a Working Group or Interest Group Charter</dfn></h4>
+        <p>The Director <em class="rfc2119">must</em> solicit <a href="#ReviewAppeal">Advisory Committee review</a> of every new or
+          substantively modified Working Group or Interest Group charter. The Director is <em class="rfc2119">not required</em> to solicit
+          Advisory Committee review prior to a charter extension or for minor changes. The review period <em class="rfc2119">must</em> be
+          at least four weeks.</p>
+        <p>The Director's Call for Review of a substantively modified charter <em class="rfc2119">must</em> highlight important changes
+          (e.g., regarding deliverables or resource allocation) and include rationale for the changes.</p>
+        <h4>6.2.4 <dfn id="cfp">Call for Participation in a Working Group or Interest Group</dfn></h4>
+        <p>After Advisory Committee review of a Working Group or Interest Group charter, the Director <em class="rfc2119">may</em> issue a
+          Call for Participation to the Advisory Committee. Charters <em class="rfc2119">may</em> be amended based on review comments
+          before the Director issues a Call for Participation. </p>
+        <p>For a new group, this announcement officially creates the group. The announcement <em class="rfc2119">must</em> include a
+          reference to the <a href="#WGCharter">charter</a>, the name(s) of the group's <a href="#GeneralChairs">Chair(s)</a>, and the
+          name of the <a href="#TeamContact">Team Contact</a>.</p>
+        <p>After a Call for Participation, any <a href="#member-rep">Member representatives</a> and <a href="#invited-expert-wg">Invited
+            Experts</a> <em class="rfc2119">must</em> be designated (or re-designated).</p>
+        <p>Advisory Committee representatives <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a> creation or substantive
+          modification of a Working Group or Interest Group charter.</p>
+        <h4>6.2.5 <dfn id="charter-extension">Working Group and Interest Group Charter Extension</dfn></h4>
+        <p>To extend a Working Group or Interest Group charter with no other substantive modifications, the Director announces the extension
+          to the Advisory Committee. The announcement <em class="rfc2119">must</em> indicate the new duration. The announcement <span class="rfc2119">MUST</span>
+          also include rationale for the extension, a reference to the <a href="#WGCharter">charter</a>, the name(s) of the group's <a href="#GeneralChairs">Chair(s)</a>,
+          the name of the <a href="#TeamContact">Team Contact</a>, and instructions for joining the group.</p>
+        <p>After a charter extension, Advisory Committee representatives and the Chair are <em class="rfc2119">not required</em> to
+          re-designate <a href="#member-rep">Member representatives</a> and <a href="#invited-expert-wg">Invited Experts</a>.</p>
+        <p>Advisory Committee representatives <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a> the extension of a Working Group
+          or Interest Group charter.</p>
+        <h4>6.2.6 <dfn id="WGCharter">Working Group and Interest Group Charters</dfn></h4>
+        <p>A Working Group or Interest Group charter <em class="rfc2119">must</em> include all of the following information.</p>
+        <ul>
+          <li>The group's mission (e.g., develop a technology or process, review the work of other groups);</li>
+          <li>The scope of the group's work and criteria for success;</li>
+          <li>The duration of the group (typically from six months to two years);</li>
+          <li>The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software), expected
+            milestones, and the process for the group participants to approve the release of these deliverables (including public
+            intermediate results). A charter is <em class="rfc2119">not required</em> to include the schedule for a review of another
+            group's deliverables;</li>
+          <li>Any dependencies by groups within or outside of W3C on the deliverables of this group. For any dependencies, the charter <span
+              class="rfc2119">MUST</span> specify the mechanisms for communication about the deliverables;</li>
+          <li>Any dependencies of this group on other groups within or outside of W3C. For example, one group's charter might specify that
+            another group is expected to review a technical report before it can become a Recommendation. For any dependencies, the charter
+            <em class="rfc2119">must</em> specify when required deliverables are expected from the other groups. The charter <em class="rfc2119">should</em>
+            set expectations about how coordination with those groups will take place; see the section on <a href="#Liaisons">liaisons with
+              other organizations</a>. Finally, the charter <em class="rfc2119">should</em> specify expected conformance to the
+            deliverables of the other groups;</li>
+          <li>The <a href="#confidentiality-levels">level of confidentiality</a> of the group's proceedings and deliverables;</li>
+          <li>Meeting mechanisms and expected frequency;</li>
+          <li>If known, the date of the first <a href="#ftf-meeting">face-to-face meeting</a>. The date of the first face-to-face meeting
+            of a proposed group <em class="rfc2119">must not</em> be sooner than <span class="time-interval">eight weeks</span> after the
+            date of the proposal.</li>
+          <li>Communication mechanisms to be employed within the group, between the group and the rest of W3C, and with the general public;</li>
+          <li>An estimate of the expected time commitment from participants;</li>
+          <li>The expected time commitment and level of involvement by the Team (e.g., to track developments, write and edit technical
+            reports, develop code, or organize pilot experiments).</li>
+          <li>Intellectual property information. What are the intellectual property (including patents and copyright) considerations
+            affecting the success of the Group? In particular, is there any reason to believe that it will be difficult to meet the
+            Royalty-Free licensing goals of section 2 of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a
+              href="#ref-patentpolicy">PUB33</a>]?</li>
+        </ul>
+        <p>See also the charter requirements of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Licensing">section 2</a> and
+          <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Obligations">section
+            3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+        <p id="ig-charter-participation">An Interest Group charter <em class="rfc2119">may</em> include provisions regarding participation,
+          including specifying that the <dfn id="ig-mail-only">only requirement for participation (by anyone) in the Interest Group is
+            subscription to the Interest Group mailing list</dfn>. This type of Interest Group <em class="rfc2119">may</em> have
+          <a href="#public-participant-ig">public
+            participants</a>.</p>
+        <p>A charter <em class="rfc2119">may</em> include additional voting procedures, but those procedures <em class="rfc2119">must not</em>
+          conflict with the <a href="#Votes">voting requirements</a> of the Process Document.</p>
+        <p>A charter <em class="rfc2119">may</em> include provisions other than those required by this document. The charter <em class="rfc2119">should</em>
+          highlight whether additional provisions impose constraints beyond those of the W3C Process Document (e.g., limits on the number of
+          individuals in a Working Group who represent the same Member organization or group of <a href="#MemberRelated">related Members</a>).</p>
+        <h4>6.2.8 <dfn id="GeneralTermination">Working Group and Interest Group Closure</dfn></h4>
+        <p>A Working Group or Interest Group charter specifies a duration for the group. The Director, subject to <a href="#ACAppeal">appeal</a>
+          by Advisory Committee representatives, <em class="rfc2119">may</em> close a group prior to the date specified in the charter in
+          any of the following circumstances:</p>
+        <ul>
+          <li>There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities
+            established within W3C.</li>
+          <li>The group produces chartered deliverables ahead of schedule.</li>
+        </ul>
+        <p>The Director closes a Working Group or Interest Group by announcement to the Advisory Committee.</p>
+        <p>Closing a Working Group has implications with respect to the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent
+            Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+      </section>
+      <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="#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="#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="#ref-patentpolicy">PUB33</a>].
+      </p>
+      <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
+        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="#revised-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="start" 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-levels">maturity
+          level</a>. The Director <em class="rfc2119">must</em> inform the <a href="#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="#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 <em class="rfc2119">must</em> 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="#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> [<a href="#rdf-doc-list">PUB11</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="#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,</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> [<a href="#rdf-pubrules">PUB31</a>](e.g., for <span id="DocumentName">naming</span>, status information, style, and <span
+          id="document-copyright">copyright requirements</span>). 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="#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="#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="#FormalObjection">Formal Objections</a>.</li>
+        <li><em class="rfc2119">should</em> 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="#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 id="wide-review">7.2.3.1 Wide Review</h5>
+      <p>The requirements for wide review 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 (for
+        example through notices posted to <a href="mailto:public-review-announce@w3.org">public-review-announce@w3.org</a>) and were able
+        to actually perform reviews of and provide comments on the specification. A second objective is to encourage groups to request
+        reviews early enough that comments and suggested changes may still be reasonably incorporated in response to the review. 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 or identified as <a href="http://www.w3.org/2001/11/StdLiaison.html">liaisons</a> [<a href="#rdf-liaison-list">PUB29</a>],
+        and seek evidence of clear communication to the general public about appropriate times and which content to review and whether such
+        reviews actually occurred. </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 <em class="rfc2119">should</em> 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 <em class="rfc2119">may</em> 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>
+        <dd>Changes that add a new functionality, element, etc.</dd>
+      </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> [<a href="#rdf-doc-list">PUB11</a>]
+        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="#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. </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="#revised-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="#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>
+      <h3 id="candidate-rec"><a 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="#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="#ref-patentpolicy">PUB33</a>].</p>
+      <p>Possible next steps:</p>
+      <ul>
+        <li>Return to <a href="#revised-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="#def-Dissent" rel="glossary" title="Definition of Dissent"><span class="dfn-instance">dissent</span></a>
+        to the Working Group decision to request advancement <a href="#AC">Advisory Committee</a> representatives <em class="rfc2119">may</em>
+        <a href="#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="#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 <em class="rfc2119">must</em> announce the publication of a revised Candidate Recommendation to other W3C groups and
+        the Public.</p>
+      <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="#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="#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="#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 <em class="rfc2119">must not</em> include any substantive changes from the Proposed Recommendation it
+        is based on, to make any substantive change to a Proposed Recommendation the Working Group <em class="rfc2119">must</em> return the
+        specification to Candidate Recommendation or Working Draft.</p>
+      <p>Possible Next Steps:</p>
+      <ul>
+        <li>Return to <a href="#revised-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>
+      <h3 id="rec-publication">7.6 W3C Recommendation</h3>
+      <p>The decision to advance a document to Recommendation is a <a href="#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="#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="#formal-address">formally address</a> the comment at least 14
+          days before publication as a W3C Recommendation. In this case the <a href="#AC">Advisory Committee</a> <em class="rfc2119">may</em>
+          <a href="#ACAppeal">appeal</a> the decision,</li>
+        <li>The Director <em class="rfc2119">must</em> announce the publication of a W3C Recommendation to <a href="#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="#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="Modif-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="Modif-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="Modif-toCR" stroke="black" fill="black">
+              <path d="M185,40h31"></path>
+              <polygon points="211,36 221,40 211,44"></polygon> </g>
+            <g id="Modif-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="Modif-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="Modif-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="Modif-ToPR" stroke="black" fill="black">
+              <path d="M298,40h27"></path>
+              <polygon points="324,36 334,40 324,44"></polygon> </g>
+            <g id="Modif-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="Modif-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="Modif-ToRec" stroke="black" fill="black">
+              <path d="M391,40h20"></path>
+              <polygon points="404,36 414,40 404,44"></polygon> </g> </g>
+          <g id="Modif-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="Modif-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="Modif-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="Modif-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 error that can be resolved by one or more changes in classes 1-3 of section <a href="#correction-classes">7.2.5
+          Classes of Changes</a>.</p>
+      <p>Working Groups <em class="rfc2119">must</em> keep a record as errors are reported by readers and implementers. Such error reports
+        <em class="rfc2119">should</em> be processed no less frequently than quarterly. Readers of the Recommendation <em class="rfc2119">should</em>
+        be able easily to find and see the errata that apply to that specific Recommendation.</p>
+      <p> Working groups may decide how to document errata. The best practice is a document that identifies itself as based on the
+        Recommendation text and clearly identifies the errata and any proposed corrections; other approaches include various forms of an
+        errata page, possibly auto-generated from a database.</p>
+      <p>An erratum is resolved by an informative, "proposed" correction generated by the Working Group. A correction becomes part of the
+        Recommendation by the process for Revising a Recommendation described in the next section.</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 <em class="rfc2119">may</em> request publication of a <a href="#rec-pr">Proposed Recommendation</a> or W3C <em class="rfc2119">may</em>
+        publish a <a href="#rec-pr">Proposed Recommendation</a> to make this class of change without passing through earlier maturity
+        levels. Such publications <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 <em class="rfc2119">may</em> 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 id="rec-edited">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>
+      <p>For changes which introduces a new feature or features, W3C <em class="rfc2119">must</em> 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="#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="#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 id="proposed-rescinded-rec">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="#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="#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="#formal-address">formally address</a> the comment at least 14
+        days before publication as a Rescinded Recommendation. In this case the <a href="#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="#ref-rec-tips">PUB27</a>].</p>
      <h2 id="ReviewAppeal">8 Advisory Committee Reviews, Appeals, and Votes</h2>
      <p>This section describes how the Advisory Committee reviews proposals from the Director and how Advisory Committee representatives
        appeal W3C decisions and decisions by the Director. A <dfn id="def-w3c-decision">W3C decision</dfn> is one where the Director (or
        the Director's delegate) has exercised the role of assessing consensus after an <a href="#ACReview">Advisory Committee review</a>
        of an <a href="#CharterReview">Charter Proposal</a>, after a <a href="#cfr">Call for Review of a Proposed Recommendation</a>,
        after a <a href="#cfr-edited">Call for Review of a Proposed Recommendation</a>, after a <a href="#proposed-rescinded-rec">Proposal
          to Rescind a W3C Recommendation</a>, and after a <a href="#GAProcess">Proposed Process Document</a> review.</p>
      <h3 id="ACReview">8.1 Advisory Committee Reviews</h3>
      <p>The Advisory Committee reviews:</p>
      <ul>
        <li><a href="#CharterReview">new and modified Working and Interest Groups</a>,</li>
        <li><a href="#cfr">Proposed Recommendations</a>, <a href="#cfr-edited">Proposed Edited Recommendations</a>, <a href="#proposed-rescinded-rec">Proposal
-            to Rescind a Recommendation</a>, and</li>
        <li><a href="#GAProcess">Proposed changes to the W3C process</a>.</li>
      </ul>
      <h4 id="ACReviewStart">8.1.1 Start of a Review Period</h4>
      <p>Each Advisory Committee review period begins with a Call for Review from the Team to the Advisory Committee. The <dfn id="reviewform">review
-          form</dfn> describes the proposal, raises attention to deadlines, estimates when the decision will be available, and includes
        other practical information. Each Member organization <em class="rfc2119">may</em> send one review, which <em class="rfc2119">must</em>
        be returned by its Advisory Committee representative.</p>
      <p>The Team <em class="rfc2119">must</em> provide two channels for Advisory Committee review comments:</p>
      <ol>
        <li>an archived <a href="#Team-only">Team-only</a> channel; this is the default channel for reviews.</li>
        <li>an archived <a href="#Member-only">Member-only</a> channel.</li>
      </ol>
      <p>Reviewers <em class="rfc2119">may</em> send information to either or both channels. They <em class="rfc2119">may</em> also share
        their reviews with other Members on the <a href="#ACCommunication">Advisory Committee discussion list</a>.</p>
      <p>A Member organization <em class="rfc2119">may</em> modify its review during a review period (e.g., in light of comments from other
        Members).</p>
      <h4 id="ACReviewAfter">8.1.2 After the Review Period</h4>
      <p>After the review period, the Director <em class="rfc2119">must</em> announce to the Advisory Committee the level of support for
        the proposal (<a href="#def-Consensus">consensus</a> or <a href="#def-Dissent">dissent</a>). The Director <em class="rfc2119">must</em>
        also indicate whether there were any Formal Objections, with attention to <a href="#confidentiality-change">changing
          confidentiality level</a>. This <a href="#def-w3c-decision">W3C decision</a> is generally one of the following:</p>
      <ol>
        <li>The proposal is approved, possibly with minor changes integrated.</li>
        <li>The proposal is approved, possibly with <a href="#substantive-change">substantive changes</a> integrated. In this case the
          Director's announcement <em class="rfc2119">must</em> include rationale for the decision to advance the document despite the
          proposal for a substantive change.</li>
        <li>The proposal is returned for additional work, with a request to the initiator to <a href="#formal-address">formally address</a>
          certain issues.</li>
        <li>The proposal is rejected.</li>
      </ol>
      <p>This document does not specify time intervals between the end of an Advisory Committee review period and the <a href="#def-w3c-decision">W3C
-          decision</a>. This is to ensure that the Members and Team have sufficient time to consider comments gathered during the review.
        The Advisory Committee <em class="rfc2119">should not</em> expect an announcement sooner than <span class="time-interval">two
          weeks</span> after the end of a Proposed Recommendation review period. If, after <span class="time-interval">three weeks</span>,
        the Director has not announced the outcome, the Director <em class="rfc2119">should</em> provide the Advisory Committee with an
        update.</p>
      <h3 id="ACAppeal">8.2 Appeal by Advisory Committee Representatives</h3>
      <p>Advisory Committee representatives <em class="rfc2119">may</em> appeal certain decisions, though appeals are only expected to
        occur in extraordinary circumstances.</p>
      <p>When Advisory Committee review immediately precedes a decision, Advisory Committee representatives <em class="rfc2119">may</em>
        only appeal when there is <a href="#def-Dissent">dissent</a>. These decisions are:</p>
      <ul>
        <li><a href="#rec-publication">Publication of a Recommendation</a> or <a href="#proposed-rescinded-rec">Publication of a Rescinded
            Recommendation</a>,</li>
        <li><a href="#cfp">Working or Interest Group creation</a>, substantive <a href="#CharterReview">modification</a> or <a href="#charter-extension">extension</a>,</li>
        <li>Changes to the <a href="#GAProcess">W3C process</a>.</li>
      </ul>
      <p>Advisory Committee representatives <em class="rfc2119">may</em> always appeal the following decisions:</p>
      <ul>
        <li><a href="#charter-extension">Working or Interest Group extension</a> or <a href="#GeneralTermination">closure</a>,</li>
        <li><a href="#candidate-rec">Call for Implementations</a>, <a href="#cfr">Call for Review of a Proposed Recommendation</a>, <a href="#cfr-edited">Call
-            for Review of an Edited Recommendation</a>, or <a href="#proposed-rescinded-rec">Proposal to Rescind a Recommendation</a></li>
        <li>the Director's intention to sign a <a href="#mou">Memorandum of Understanding</a> with another organization.</li>
      </ul>
      <p>In all cases, an appeal <em class="rfc2119">must</em> be initiated within <span class="time-interval">three weeks</span> of the
        decision.</p>
      <p>An Advisory Committee representative initiates an appeal by sending a request to the Team (explained in detail in the <a href="http://www.w3.org/Member/Intro">New
-          Member Orientation</a>). The Team <em class="rfc2119">must</em> announce the appeal process to the Advisory Committee and provide
        an address for comments from Advisory Committee representatives. The archive of these comments <em class="rfc2119">must</em> be
        Member-visible. If, within <span class="time-interval">one week</span> of the Team's announcement, 5% or more of the Advisory
        Committee support the appeal request, the Team <em class="rfc2119">must</em> organize an appeal vote asking the Advisory Committee
        to approve or reject the decision.
        <!-- Voting procedure to be determined --></p>
      <h3 id="ACVotes">8.3Advisory Committee Votes</h3>
      <p>The Advisory Committee votes in <a href="#AB-TAG-elections">elections for seats on the TAG or Advisory Board</a>, and in the event
        of a formal appeal of a <a href="#def-w3c-decision">W3C decision</a>. Whenever the Advisory Committee votes, each Member or group
        of <a href="#MemberRelated">related Members</a> has one vote. In the case of <a href="#AB-TAG-elections">Advisory Board and TAG
          elections</a>, "one vote" means "one vote per available seat".</p>
      <h2 id="GAEvents">9 Workshops and Symposia</h2>
      <p>The Team organizes <dfn id="EventsW">Workshops</dfn> and <dfn id="EventsS">Symposia</dfn> to promote early involvement in the
        development of W3C activities from Members and the public.</p>
      <p>The goal of a Workshop is usually either to convene experts and other interested parties for an exchange of ideas about a
        technology or policy, or to address the pressing concerns of W3C Members. Organizers of the first type of Workshop <em class="rfc2119">may</em>
        solicit position papers for the Workshop program and <em class="rfc2119">may</em> use those papers to choose attendees and/or
        presenters.</p>
      <p>The goal of a Symposium is usually to educate interested parties about a particular subject.</p>
      <p>The Call for Participation in a Workshop or Symposium <em class="rfc2119">may</em> indicate participation requirements or limits,
        and expected deliverables (e.g., reports and minutes). Organization of an event does not guarantee further investment by W3C in a
        particular topic, but <em class="rfc2119">may</em> lead to proposals for new activities or groups.</p>
      <p>Workshops and Symposia generally last one to three days. If a Workshop is being organized to address the pressing concerns of
        Members, the Team <em class="rfc2119">must</em> issue the Call for Participation no later than <span class="time-interval">six
          weeks</span> prior to the Workshop's scheduled start date. For other Workshops and Symposia, the Team <em class="rfc2119">must</em>
        issue a Call for Participation no later than <span class="time-interval">eight weeks</span> prior to the meeting's scheduled start
        date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks.</p>
      <p><strong>Note:</strong> In general, W3C does not organize <dfn id="EventsC">conferences</dfn>. Currently, W3C presents its work to
        the public at the annual World Wide Web Conference, which is coordinated by the <a href="http://www.iw3c2.org/">International World
          Wide Web Conference Committee</a> (<abbr>IW3C2</abbr>).</p>
      <h2 id="Liaisons">10 Liaisons</h2>
      <p>W3C uses the term "liaison" to refer to coordination of activities with a variety of organizations, through a number of mechanisms
        ranging from very informal (e.g., an individual from another organization participates in a W3C Working Group, or just follows its
        work) to mutual membership, to even more formal agreements. Liaisons are not meant to substitute for W3C membership.</p>
      <p>All liaisons <em class="rfc2119">must</em> be coordinated by the Team due to requirements for public communication; patent,
        copyright, and other IPR policies; confidentiality agreements; and mutual membership agreements.</p>
      <p>The W3C Director <em class="rfc2119">may</em> negotiate and sign a <dfn id="mou">Memorandum of Understanding (<abbr>MoU</abbr>)</dfn>
        with another organization. Before signing the MoU, the Team <em class="rfc2119">must</em> inform the Advisory Committee of the
        intent to sign and make the MoU available for Advisory Committee review; the Advisory Committee <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a>.
        Once approved, a Memorandum of Understanding <em class="rfc2119">should</em> be made public.</p>
      <p>Information about <a href="http://www.w3.org/2001/11/StdLiaison">W3C liaisons with other organizations</a> and the guidelines W3C
        follows when creating a liaison [<a href="#ref-liaison-list">PUB28</a>] is available on the Web.</p>
      <h2 id="Submission">11 Member Submission Process</h2>
      <p>The Member Submission process allows Members to propose technology or other ideas for consideration by the Team. After review, the
        Team <em class="rfc2119">may</em> publish the material at the W3C Web site. The formal process affords Members a record of their
        contribution and gives them a mechanism for disclosing the details of the transaction with the Team (including IPR claims). The Team
        also publishes review comments on the Submitted materials for W3C Members, the public, and the media.</p>
      <p>A <dfn id="MemberSubmission">Member Submission</dfn> consists of:</p>
      <ul>
        <li>One or more documents developed outside of the W3C process, and</li>
        <li>Information about the documents, provided by the Submitter.</li>
      </ul>
      <p>One or more Members (called the "Submitter(s)") <em class="rfc2119">may</em> participate in a Member Submission. Only W3C Members
        <em class="rfc2119">may</em> be listed as Submitter(s).</p>
      <p>The Submission process consists of the following steps:</p>
      <ol>
        <li>One of the Submitter(s) sends a request to the Team to acknowledge the Submission request. The Team and Submitter(s) communicate
          to ensure that the Member Submission is complete.</li>
        <li>After Team review, the Director <em class="rfc2119">must</em> either acknowledge or reject the Submission request.
          <ul>
            <li>If <a href="#SubmissionYes">acknowledged</a>, the Team <em class="rfc2119">must</em> publish the Member Submission at the
              public W3C Web site, in addition to Team comments about the Member Submission.</li>
            <li>If <a href="#SubmissionNo">rejected</a>, the Submitter(s) <em class="rfc2119">may</em> appeal to either the <a href="#TAG">TAG</a>
              or the <a href="#AB">Advisory Board</a>.</li>
          </ul>
        </li>
      </ol>
      <p><strong>Note:</strong> To avoid confusion about the Member Submission process, please note that:</p>
      <ul>
        <li>Documents in a Member Submission are developed outside of W3C. These documents are <strong>not</strong> part of the <a href="#Reports">technical
-            report development process</a> (and therefore are not included in the <a href="http://www.w3.org/TR/">index of W3C technical
            reports</a>). Members wishing to have documents developed outside of W3C published by W3C <em class="rfc2119">must</em> follow
          the Member Submission process.</li>
        <li>The Submission process is <strong>not</strong> a means by which Members ask for "ratification" of these documents as <a href="#RecsW3C">W3C
-            Recommendations</a>.</li>
        <li>There is no requirement or guarantee that technology which is part of an acknowledged Submission request will receive further
          consideration by W3C (e.g., by a W3C Working Group).</li>
      </ul>
      <p>Publication of a Member Submission by W3C does not imply endorsement by W3C, including the W3C Team or Members. The acknowledgment
        of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request
        has been made by the Submitter. A Member Submission published by W3C <em class="rfc2119">must not</em> be referred to as "work in
        progress" of the W3C.</p>
      <p>The list of <a href="http://www.w3.org/Submission/">acknowledged Member Submissions</a> [<a href="#ref-submission-list">PUB10</a>]
        is available at the W3C Web site.</p>
      <h3 id="SubmissionRights">11.1 Submitter Rights and Obligations</h3>
      <p>When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member
        <em class="rfc2119">must</em> copy each of the Advisory Committee representatives of the other participating Members, and each of
        those Advisory Committee representatives <em class="rfc2119">must</em> confirm (by email to the Team) their participation in the
        Submission request.</p>
      <p>At any time prior to acknowledgment, any Submitter <em class="rfc2119">may</em> withdraw support for a Submission request
        (described in "<a href="http://www.w3.org/2000/09/submission">How to send a Submission request</a>"). A Submission request is
        "withdrawn" when no Submitter(s) support it. The Team <em class="rfc2119">must not</em> make statements about withdrawn Submission
        requests.</p>
      <p>Prior to acknowledgment, the Submitter(s) <em class="rfc2119">must not</em>, <strong>under any circumstances</strong>, refer to a
        document as "submitted to the World Wide Web Consortium" or "under consideration by W3C" or any similar phrase either in public or
        Member communication. The Submitter(s) <em class="rfc2119">must not</em> imply in public or Member communication that W3C is
        working (with the Submitter(s)) on the material in the Member Submission. The Submitter(s) <em class="rfc2119">may</em> publish the
        documents in the Member Submission prior to acknowledgment (without reference to the Submission request).</p>
      <p>After acknowledgment, the Submitter(s) <em class="rfc2119">must not</em>, <strong>under any circumstances</strong>, imply W3C
        investment in the Member Submission until, and unless, the material has been adopted as a deliverable of a W3C Working Group</p>
      <h4 id="SubmissionScope">11.1.1 Scope of Member Submissions</h4>
      <p>When a technology overlaps in scope with the work of a chartered Working Group, Members <em class="rfc2119">should</em> <a href="#group-participation">participate
-          in the Working Group</a> and contribute the technology to the group's process rather than seek publication through the Member
        Submission process. The Working Group <em class="rfc2119">may</em> incorporate the contributed technology into its deliverables. If
        the Working Group does not incorporate the technology, it <em class="rfc2119">should not</em> publish the contributed documents as
        Working Group Notes since Working Group Notes represent group output, not input to the group.</p>
      <p>On the other hand, while W3C is in the early stages of developing a charter, Members <em class="rfc2119">should</em> use the
        Submission process to build consensus around concrete proposals for new work.</p>
      <p>Members <em class="rfc2119">should not</em> submit materials covering topics well outside the scope of <a href="http://www.w3.org/Consortium/mission">W3C's
-          mission</a> [<a href="#ref-mission">PUB15</a>].</p>
      <h4 id="SubmissionReqs">11.1.2Information Required in a Submission Request</h4>
      <p>The Submitter(s) and any other authors of the submitted material <em class="rfc2119">must</em> agree that, if the request is
        acknowledged, the documents in the Member Submission will be subject to the <a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C
-          Document License</a> [<a href="#ref-doc-license">PUB18</a>] and will include a reference to it. The Submitter(s) <em class="rfc2119">may</em>
        hold the copyright for the documents in a Member Submission.</p>
      <p>The request must satisfy the Member Submission licensing commitments of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-submissions">section
-          3.3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
      <p>The Submitter(s) <em class="rfc2119">must</em> include the following information:</p>
      <ul>
        <li>The list of all submitting Members.</li>
        <li>Position statements from all submitting Members (gathered by the Submitter). All position statements must appear in a separate
          document.</li>
        <li>Complete electronic copies of any documents submitted for consideration (e.g., a technical specification, a position paper,
          etc.) If the Submission request is acknowledged, these documents will be published by W3C and therefore must satisfy the
          Communication Team's <a href="http://www.w3.org/Guide/pubrules">Publication Rules</a> [<a href="#ref-pubrules">PUB31</a>].
          Submitters may hold the copyright for the material contained in these documents, but when published by W3C, these documents <span
            class="rfc2119">MUST</span>
          be subject to the provisions of the <a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C Document License</a> [<a
            href="#ref-doc-license">PUB18</a>].</li>
      </ul>
      <p>The request <em class="rfc2119">must</em> also answer the following questions.</p>
      <ul>
        <li>What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its
          use? Again, many answers are possible, but the specific answer will affect the Team's decision.</li>
        <li>What resources, if any, does the Submitter intend to make available if the W3C acknowledges the Submission request and takes
          action on it?</li>
        <li>What action would the Submitter like W3C to take if the Submission request is acknowledged?</li>
        <li>What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating
          where change control will reside if the request is acknowledged.</li>
      </ul>
      <p>For other administrative requirements related to Submission requests, see "<a href="http://www.w3.org/2000/09/submission">How to
          send a Submission request</a>" [<a href="#ref-member-sub">MEM8</a>].</p>
      <h3 id="TeamSubmissionRights">11.2 Team Rights and Obligations</h3>
      <p>Although they are not technical reports, the documents in a Member Submission <em class="rfc2119">must</em> fulfill the
        requirements established by the Team, including the Team's <a href="http://www.w3.org/Guide/pubrules">Publication Rules</a>.</p>
      <p>The Team sends a <a id="validation-notice">validation notice</a> to the Submitter(s) once the Team has reviewed a Submission
        request and judged it complete and correct.</p>
      <p>Prior to a decision to <a href="#SubmissionYes">acknowledge</a> or <a href="#SubmissionNo">reject</a> the request, the request is
        <a href="#Team-only">Team-only</a>, and the Team <em class="rfc2119">must</em> hold it in the strictest confidentiality. In
        particular, the Team <em class="rfc2119">must not</em> comment to the media about the Submission request.</p>
      <h3 id="SubmissionYes">11.3 Acknowledgment of a Submission Request</h3>
      <p>The Director <a href="#SubmissionYes">acknowledges</a> a Submission request by sending an announcement to the Advisory Committee.
        Though the announcement <em class="rfc2119">may</em> be made at any time, the Submitter(s) can expect an announcement between <span
          class="time-interval">four
          to six weeks</span> after the <a href="#validation-notice">validation notice</a>. The Team <em class="rfc2119">must</em> keep
        the Submitter(s) informed of when an announcement is likely to be made.</p>
      <p>Once a Submission request has been acknowledged, the Team <em class="rfc2119">must</em>:</p>
      <ul>
        <li>Publish the Member Submission.</li>
        <li>Publish Team comments about the Submission request.</li>
      </ul>
      <p>If the Submitter(s) wishes to modify a document published as the result of acknowledgment, the Submitter(s) <em class="rfc2119">must</em>
        start the Submission process from the beginning, even just to correct editorial changes.</p>
      <h3 id="SubmissionNo">11.4 Rejection of a Submission Request</h3>
      <p>The Director <em class="rfc2119">may</em> reject a Submission request for a variety of reasons, including any of the following:</p>
      <ul>
        <li>The ideas expressed in the request overlap in scope with the work of a chartered Working Group, and acknowledgment might
          jeopardize the progress of the group.</li>
        <li>The IPR statement made by the Submitter(s) is inconsistent with the W3C's <a href="http://www.w3.org/Consortium/Patent-Policy">Patent
-            Policy</a> [<a href="#ref-patentpolicy">PUB33</a>], <a href="http://www.w3.org/Consortium/Legal/copyright-documents">Document
            License</a> [<a href="#ref-doc-license">PUB18</a>], or other IPR policies.</li>
        <li>The ideas expressed in the request are poor, might harm the Web, or run counter to <a href="http://www.w3.org/Consortium/mission">W3C's
-            mission</a>.</li>
        <li>The ideas expressed in the request lie well outside the scope of W3C's mission.</li>
      </ul>
      <p>In case of a rejection, the Team <em class="rfc2119">must</em> inform the Advisory Committee representative(s) of the
        Submitter(s). If requested by the Submitter(s), the Team <em class="rfc2119">must</em> provide rationale to the Submitter(s) about
        the rejection. Other than to the Submitter(s), the Team <em class="rfc2119">must not</em> make statements about why a Submission
        request was rejected.</p>
      <p>The Advisory Committee representative(s) of the Submitters(s) <em class="rfc2119">may</em> appeal the rejection to the <a href="#TAG">TAG</a>
        if the reasons are related to Web architecture, or to the <a href="#AB">Advisory Board</a> if the request is rejected for other
        reasons. In this case the Team <em class="rfc2119">should</em> make available its rationale for the rejection to the appropriate
        body. The Team will establish a process for such appeals that ensures the appropriate <a href="#confidentiality-levels">level of
          confidentiality</a>.</p>
      <h2 id="GAProcess">12 Process Evolution</h2>
      <p>The <span id="ProcessDoc">W3C Process Document</span> undergoes similar consensus-building processes as technical reports, with
        the <a href="#AB">Advisory Board</a> acting as the sponsoring Working Group.</p>
      <p>The Advisory Board initiates review of a Process Document as follows:</p>
      <ol>
        <li>The Team sends a Call for Review to the Advisory Committee and other W3C groups.</li>
        <li>After comments have been <a href="#formal-address">formally addressed</a> and the document possibly modified, the Team seeks
          endorsement from the Members by initiating an <a href="#ACReview">Advisory Committee review</a> of a Proposed Process Document.
          The review period <em class="rfc2119">must</em> last at least <span class="time-interval">four weeks</span>.</li>
        <li><a href="#ACReviewAfter">After the Advisory Committee review</a>, if there is consensus, the Team enacts the new process
          officially by announcing the <a href="#def-w3c-decision">W3C decision</a> to the Advisory Committee. If there was <a href="#def-Dissent">dissent</a>,
          Advisory Committee representatives <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a> the decision.</li>
      </ol>
      <p>W3C <em class="rfc2119">may</em> also modify a Process Document by following the processes for <a href="#rec-modify">modifying a
          Recommendation</a>.</p>
      <p>Reviews of the Process Document are not public reviews.</p>
      <h2 id="references">13 References</h2>
      <h3 id="public-refs">13.1 Public Resources</h3>
      <p>The following public information is available at the <a href="http://www.w3.org/">W3C Web site</a>.</p>
      <dl>
        <dt id="ref-join-w3c">[PUB5]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/join">How to Join W3C</a></cite></dd>
        <dt id="ref-member-agreement">[PUB6]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership Agreement</a></cite></dd>
        <dt id="ref-current-mem">[PUB8]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Member/List">The list of current W3C Members</a></cite></dd>
        <dt id="ref-activity-list">[PUB9]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/activities">The list of W3C Activities</a></cite></dd>
        <dt id="rdf-submission-list">[PUB10]</dt>
        <dd><cite><a href="http://www.w3.org/Submission/">The list of acknowledged Member Submissions</a></cite></dd>
        <dt id="rdf-doc-list">[PUB11]</dt>
        <dd><cite><a href="http://www.w3.org/TR/">The W3C technical reports index</a></cite></dd>
        <dt id="rdf-submission-overview">[PUB13]</dt>
        <dd><cite><a href="http://www.w3.org/Submission/1996/Template/">Submission request overview</a></cite></dd>
        <dt id="rdf-people">[PUB14]</dt>
        <dd><cite><a href="http://www.w3.org/People/">The W3C Team</a></cite></dd>
        <dt id="rdf-mission">[PUB15]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/">About the World Wide Web Consortium</a></cite></dd>
        <dt id="rdf-team-submission-list">[PUB16]</dt>
        <dd><cite><a href="http://www.w3.org/TeamSubmission/">The list of published Team Submissions</a></cite></dd>
        <dt id="rdf-invited-expert">[PUB17]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Legal/collaborators-agreement">Invited expert and collaborators agreement</a></cite></dd>
        <dt id="rdf-doc-license">[PUB18]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C Document License</a></cite></dd>
        <dt id="rdf-software-license">[PUB19]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Legal/copyright-software">W3C Software Notice and License</a></cite></dd>
        <dt id="rdf-translations">[PUB20]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Translation/">Translations of W3C technical reports</a></cite></dd>
        <dt id="rdf-pub-mailing-lists">[PUB21]</dt>
        <dd><cite><a href="http://www.w3.org/Mail/">Public W3C mailing lists</a></cite></dd>
        <dt id="rdf-coi">[PUB23]</dt>
        <dd><cite><a href="http://www.w3.org/2000/09/06-conflictpolicy">Conflict of Interest Policy for W3C Team Members Engaged in Outside
              Professional Activities</a></cite></dd>
        <dt id="rdf-tag-charter">[PUB25]</dt>
        <dd><cite><a href="http://www.w3.org/2001/07/19-tag">Technical Architecture Group (TAG) Charter</a></cite></dd>
        <dt id="rdf-tag-home">[PUB26]</dt>
        <dd><cite><a href="http://www.w3.org/2001/tag/">The TAG home page</a></cite></dd>
        <dt id="rdf-rec-tips">[PUB27]</dt>
        <dd><cite><a href="http://www.w3.org/2002/05/rec-tips">Tips for Getting to Recommendation Faster</a></cite></dd>
        <dt id="rdf-liaison-list">[PUB28]</dt>
        <dd><cite><a href="http://www.w3.org/2001/11/StdLiaison">W3C liaisons with other organizations</a></cite></dd>
        <dt id="rdf-ab-home">[PUB30]</dt>
        <dd><cite><a href="http://www.w3.org/2002/ab/">The Advisory Board home page</a></cite></dd>
        <dt id="rdf-pubrules">[PUB31]</dt>
        <dd><cite><a href="http://www.w3.org/Guide/pubrules">Publication Rules</a></cite></dd>
        <dt id="rdf-fellows">[PUB32]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Recruitment/Fellows">W3C Fellows Program</a></cite></dd>
        <dt id="rdf-patentpolicy">[PUB33]</dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 Feb 2004 version of the W3C Patent Policy</a></cite>. The
          <a href="http://www.w3.org/Consortium/Patent-Policy/">latest version of the W3C Patent Policy</a> is available at
          http://www.w3.org/Consortium/Patent-Policy/.</dd>
        <dt id="in-place-tr-mod">[PUB35]</dt>
        <dd><cite><a href="http://www.w3.org/2003/01/republishing/">In-place modification of W3C Technical Reports</a></cite></dd>
      </dl>
      <h3>13.2 <a id="member-refs">Member-only Resources</a></h3>
      <p>The following <a href="#Member-only">Member-only</a> information is available at the <a href="http://www.w3.org/">W3C Web site</a>.</p>
      <dl>
        <dt id="rdf-current-ac">[MEM1]</dt>
        <dd><cite><a href="http://www.w3.org/Member/ACList">Current Advisory Committee representatives</a></cite></dd>
        <dt id="rdf-mailing-lists">[MEM2]</dt>
        <dd><cite><a href="http://www.w3.org/Member/Mail/">Group mailing lists</a></cite></dd>
        <dt id="rdf-calendar">[MEM3]</dt>
        <dd>The <cite><a href="http://www.w3.org/Member/Eventscal">calendar of all scheduled official W3C events</a></cite></dd>
        <dt id="rdf-new-member">[MEM4]</dt>
        <dd>The <cite><a href="http://www.w3.org/Member/Intro">New Member Orientation</a></cite>, which includes an introduction to W3C
          processes from a practical standpoint, including relevant email addresses.</dd>
        <dt id="rdf-ac-meetings">[MEM5]</dt>
        <dd><cite><a href="http://www.w3.org/Member/Meeting/">Advisory Committee meetings</a></cite></dd>
        <dt id="rdf-member-web">[MEM6]</dt>
        <dd><cite><a href="http://www.w3.org/Member/">Member Web site</a></cite></dd>
        <dt id="rdf-member-sub">[MEM8]</dt>
        <dd><cite><a href="http://www.w3.org/2000/09/submission">How to send a Submission request</a></cite></dd>
        <dt id="rdf-guide">[MEM9]</dt>
        <dd><cite><a href="http://www.w3.org/Guide/">The Art of Consensus</a></cite>, a guidebook for W3C Working Group Chairs and other
          collaborators</dd>
        <dt id="rdf-discipline-gl">[MEM14]</dt>
        <dd><cite><a href="http://www.w3.org/2002/09/discipline">Guidelines for Disciplinary Action</a></cite></dd>
        <dt id="rdf-election-howto">[MEM15]</dt>
        <dd><cite><a href="http://www.w3.org/2002/10/election-howto">How to Organize an Advisory Board or TAG election</a></cite></dd>
      </dl>
      <h3 id="other-refs">13.3 Other References</h3>
      <dl>
        <dt id="rdf-RFC2119">[RFC2119]</dt>
        <dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">"Key words for use in RFCs to Indicate Requirement Levels"</a></cite>, S.
          Bradner, March 1997.</dd>
        <dt id="ref-RFC2777">[RFC2777]</dt>
        <dd><cite><a href="http://www.ietf.org/rfc/rfc2777.txt">"Publicly Verifiable Nomcom Random Selection"</a></cite>, D. Eastlake 3rd,
          February 2000.</dd>
      </dl>
      <h2 id="acks">14 Acknowledgments</h2>
      <p>The following individuals have contributed to this proposal for a revised Process: Daniel Appelquist (Telefonica), Art Barstow
        (Nokia), Robin Berjon (W3C), Judy Brewer (W3C), Marcos Cáceres (Mozilla), Wayne Carr (Intel), Michael Champion (W3C), Mark Crawford
        (SAP), Karl Dubost (Mozilla), Fantasai (unaffiliated), Virginie Galindo (Gemalto), Daniel Glazman (Disruptive Innovations), Eduardo
        Gutentag (unaffiiliated), Brad Hill (Facebook), Jeff Jaffe (W3C), Cullen Jennings (Cisco), Brain Kardell (JQuery), Peter Linss (HP),
        Nigel Megitt (BBC), Olle Olsson (SICS), Natasha Rooney (GSMA), Sam Ruby (IBM), David Singer (Apple), Henri Sivonen (Mozilla), Josh
        Soref (BlackBerry), Anne van Kesteren (Mozilla), Léonie Watson (The Paciello Group), Mike West (Google), Chris Wilson (Google),
        Steve Zilles (Adobe).</p>
      <p>The following individuals contributed to the development of earlier versions of the Process: Jean-François Abramatic (IBM, and
        previously ILOG and W3C), Dan Appelquist (Telefonica), Art Barstow (Nokia), Ann Bassetti (The Boeing Company), Jim Bell (HP), Robin
        Berjon (W3C), Tim Berners-Lee (W3C), Klaus Birkenbihl (Fraunhofer Gesellschaft), Don Brutzman (Web3D), Carl Cargill (Netscape, Sun
        Microsystems), Wayne Carr (Intel), Marcos Cáceres (Mozilla), Michael Champion (Microsoft), Paul Cotton (Microsoft), Mark Crawford
        (SAP), Tantek Çelik (Mozilla), Don Deutsch (Oracle), David Fallside (IBM), Fantasai (Mozilla), Wendy Fong (Hewlett-Packard),
        Virginie Galindo (Gemalto), Daniel Glazman (Disruptive Innovations), Paul Grosso (Arbortext), Eduardo Gutentag (Sun Microsystems),
        Joe Hall (CDT), Ivan Herman (W3C), Ian Hickson (Google), Steve Holbrook (IBM), Renato Iannella (IPR Systems), Ian Jacobs (W3C), Jeff
        Jaffe (W3C), Cullen Jennings (Cisco), Sally Khudairi (W3C), John Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen (Ericsson),
        Ken Laskey (MITRE), Ora Lassila (Nokia), Håkon Wium Lie (Opera Software), Chris Lilley (W3C), Bede McCall (MITRE), Giri Mandyam
        (Qualcomm), Larry Masinter (Adobe Systems), Qiuling Pan (Huawei), TV Raman (Google), Thomas Reardon (Microsoft), Claus von Riegen
        (SAP AG), David Singer (Apple), David Singer (IBM), Ralph Swick (W3C), Anne van Kesteren, Jean-Charles Verdié (MStar), Chris Wilson
        (Google), Lauren Wood (unaffiliated), and Steve Zilles (Adobe Systems).</p>
      <h2 id="changes">15 Changes</h2>
      <p>This document is based on 1 August 2014 Process. <a href="https://dvcs.w3.org/hg/AB/">Detailed change logs</a> are available.</p>
      <p>The notable changes include:</p>
      <h3>Current Editor's draft</h3>
      <ul>
        <li>Editorial corrections - typos and markup errors</li>
      </ul>
      <h3>Previous Editor's drafts</h3>
      <ul>
        <li>Editorial cleanups to <a href="#wide-review">7.2.3.1 Wide Review</a></li>
        <li>Editorial Changes to <a href="#errata">7.7.1 Errata Management</a> - <a href="https://www.w3.org/community/w3process/track/issues/141">ISSUE-141</a></li>
        <li>Remove <a id="GCGCreation" name="CGCreation"></a><a id="GroupsCG" name="GroupsCG"></a> <a id="CGParticipation" name="CGParticipation"></a><a
            id="cgparticipant"
            name="cgparticipant"></a>
          <a id="CGCharter" name="CGCharter"></a>Coordination groups - <a href="https://www.w3.org/community/w3process/track/issues/129">ISSUE-129</a></li>
        <li>Remove vestigial traces of Good Standing throughout</li>
        <li>Loosen constraints on multiple employees of a single member being on TAG - <a href="#AB-TAG-constraints">section 2.5.1</a></li>
        <li>Replace "W3C Chair" with "CEO" throughout</li>
        <li>Editorial tweaks to what is requested in <a href="file:///Users/chaals/Documents/w3c/AB/cover.html#wide-review">7.2.3.1 Wide
            Review</a></li>
        <li>Remove section <span id="three-month-rule">6.2.7 "Heartbeat" publishing requirement, redundant with the first requirement of <a
              href="#revised-wd">section
              7.3.2</a><br>
          </span></li>
      </ul>
      <h3>30 September "AC intermediate review" draft</h3>
      <p>Provided to the Advisory Committee to review the following changes made compared to the 1 August 2014 Operative Process document</p>
      <ul>
        <li>Remove <a id="ActivityProposal">Activities</a> from the Process (as resolved multiple times since 2007)</li>
        <li>Remove <a id="good-standing">6.2.1.7</a> Good Standing in a Working Group</li>
      </ul>
    </main>
    <em class="rfc2119"><em class="rfc2119"> </em></em>
  </body>
</html>
\ No newline at end of file
+          on getting to Recommendation faster</a> [<a href="#ref-rec-tips">PUB27</a>].</p>
+      <h2 id="ReviewAppeal">8 Advisory Committee Reviews, Appeals, and Votes</h2>
+      <p>This section describes how the Advisory Committee reviews proposals from the Director and how Advisory Committee representatives
+        appeal W3C decisions and decisions by the Director. A <dfn id="def-w3c-decision">W3C decision</dfn> is one where the Director (or
+        the Director's delegate) has exercised the role of assessing consensus after an <a href="#ACReview">Advisory Committee review</a>
+        of an <a href="#CharterReview">Charter Proposal</a>, after a <a href="#cfr">Call for Review of a Proposed Recommendation</a>,
+        after a <a href="#cfr-edited">Call for Review of a Proposed Recommendation</a>, after a <a href="#proposed-rescinded-rec">Proposal
+          to Rescind a W3C Recommendation</a>, and after a <a href="#GAProcess">Proposed Process Document</a> review.</p>
+      <h3 id="ACReview">8.1 Advisory Committee Reviews</h3>
+      <p>The Advisory Committee reviews:</p>
+      <ul>
+        <li><a href="#CharterReview">new and modified Working and Interest Groups</a>,</li>
+        <li><a href="#cfr">Proposed Recommendations</a>, <a href="#cfr-edited">Proposed Edited Recommendations</a>, <a href="#proposed-rescinded-rec">Proposal
+            to Rescind a Recommendation</a>, and</li>
+        <li><a href="#GAProcess">Proposed changes to the W3C process</a>.</li>
+      </ul>
+      <h4 id="ACReviewStart">8.1.1 Start of a Review Period</h4>
+      <p>Each Advisory Committee review period begins with a Call for Review from the Team to the Advisory Committee. The <dfn id="reviewform">review
+          form</dfn> describes the proposal, raises attention to deadlines, estimates when the decision will be available, and includes
+        other practical information. Each Member organization <em class="rfc2119">may</em> send one review, which <em class="rfc2119">must</em>
+        be returned by its Advisory Committee representative.</p>
+      <p>The Team <em class="rfc2119">must</em> provide two channels for Advisory Committee review comments:</p>
+      <ol>
+        <li>an archived <a href="#Team-only">Team-only</a> channel; this is the default channel for reviews.</li>
+        <li>an archived <a href="#Member-only">Member-only</a> channel.</li>
+      </ol>
+      <p>Reviewers <em class="rfc2119">may</em> send information to either or both channels. They <em class="rfc2119">may</em> also share
+        their reviews with other Members on the <a href="#ACCommunication">Advisory Committee discussion list</a>.</p>
+      <p>A Member organization <em class="rfc2119">may</em> modify its review during a review period (e.g., in light of comments from other
+        Members).</p>
+      <h4 id="ACReviewAfter">8.1.2 After the Review Period</h4>
+      <p>After the review period, the Director <em class="rfc2119">must</em> announce to the Advisory Committee the level of support for
+        the proposal (<a href="#def-Consensus">consensus</a> or <a href="#def-Dissent">dissent</a>). The Director <em class="rfc2119">must</em>
+        also indicate whether there were any Formal Objections, with attention to <a href="#confidentiality-change">changing
+          confidentiality level</a>. This <a href="#def-w3c-decision">W3C decision</a> is generally one of the following:</p>
+      <ol>
+        <li>The proposal is approved, possibly with minor changes integrated.</li>
+        <li>The proposal is approved, possibly with <a href="#substantive-change">substantive changes</a> integrated. In this case the
+          Director's announcement <em class="rfc2119">must</em> include rationale for the decision to advance the document despite the
+          proposal for a substantive change.</li>
+        <li>The proposal is returned for additional work, with a request to the initiator to <a href="#formal-address">formally address</a>
+          certain issues.</li>
+        <li>The proposal is rejected.</li>
+      </ol>
+      <p>This document does not specify time intervals between the end of an Advisory Committee review period and the <a href="#def-w3c-decision">W3C
+          decision</a>. This is to ensure that the Members and Team have sufficient time to consider comments gathered during the review.
+        The Advisory Committee <em class="rfc2119">should not</em> expect an announcement sooner than <span class="time-interval">two
+          weeks</span> after the end of a Proposed Recommendation review period. If, after <span class="time-interval">three weeks</span>,
+        the Director has not announced the outcome, the Director <em class="rfc2119">should</em> provide the Advisory Committee with an
+        update.</p>
+      <h3 id="ACAppeal">8.2 Appeal by Advisory Committee Representatives</h3>
+      <p>Advisory Committee representatives <em class="rfc2119">may</em> appeal certain decisions, though appeals are only expected to
+        occur in extraordinary circumstances.</p>
+      <p>When Advisory Committee review immediately precedes a decision, Advisory Committee representatives <em class="rfc2119">may</em>
+        only appeal when there is <a href="#def-Dissent">dissent</a>. These decisions are:</p>
+      <ul>
+        <li><a href="#rec-publication">Publication of a Recommendation</a> or <a href="#proposed-rescinded-rec">Publication of a Rescinded
+            Recommendation</a>,</li>
+        <li><a href="#cfp">Working or Interest Group creation</a>, substantive <a href="#CharterReview">modification</a> or 
+          <a href="#charter-extension">extension</a>,</li>
+        <li>Changes to the <a href="#GAProcess">W3C process</a>.</li>
+      </ul>
+      <p>Advisory Committee representatives <em class="rfc2119">may</em> always appeal the following decisions:</p>
+      <ul>
+        <li><a href="#charter-extension">Working or Interest Group extension</a> or <a href="#GeneralTermination">closure</a>,</li>
+        <li><a href="#candidate-rec">Call for Implementations</a>, <a href="#cfr">Call for Review of a Proposed Recommendation</a>, <a href="#cfr-edited">Call
+            for Review of an Edited Recommendation</a>, or <a href="#proposed-rescinded-rec">Proposal to Rescind a Recommendation</a></li>
+        <li>the Director's intention to sign a <a href="#mou">Memorandum of Understanding</a> with another organization.</li>
+      </ul>
+      <p>In all cases, an appeal <em class="rfc2119">must</em> be initiated within <span class="time-interval">three weeks</span> of the
+        decision.</p>
+      <p>An Advisory Committee representative initiates an appeal by sending a request to the Team (explained in detail in the 
+        <a href="http://www.w3.org/Member/Intro">New
+          Member Orientation</a>). The Team <em class="rfc2119">must</em> announce the appeal process to the Advisory Committee and provide
+        an address for comments from Advisory Committee representatives. The archive of these comments <em class="rfc2119">must</em> be
+        Member-visible. If, within <span class="time-interval">one week</span> of the Team's announcement, 5% or more of the Advisory
+        Committee support the appeal request, the Team <em class="rfc2119">must</em> organize an appeal vote asking the Advisory Committee
+        to approve or reject the decision.
+        <!-- Voting procedure to be determined --></p>
+      <h3 id="ACVotes">8.3Advisory Committee Votes</h3>
+      <p>The Advisory Committee votes in <a href="#AB-TAG-elections">elections for seats on the TAG or Advisory Board</a>, and in the event
+        of a formal appeal of a <a href="#def-w3c-decision">W3C decision</a>. Whenever the Advisory Committee votes, each Member or group
+        of <a href="#MemberRelated">related Members</a> has one vote. In the case of <a href="#AB-TAG-elections">Advisory Board and TAG
+          elections</a>, "one vote" means "one vote per available seat".</p>
+      <h2 id="GAEvents">9 Workshops and Symposia</h2>
+      <p>The Team organizes <dfn id="EventsW">Workshops</dfn> and <dfn id="EventsS">Symposia</dfn> to promote early involvement in the
+        development of W3C activities from Members and the public.</p>
+      <p>The goal of a Workshop is usually either to convene experts and other interested parties for an exchange of ideas about a
+        technology or policy, or to address the pressing concerns of W3C Members. Organizers of the first type of Workshop <em class="rfc2119">may</em>
+        solicit position papers for the Workshop program and <em class="rfc2119">may</em> use those papers to choose attendees and/or
+        presenters.</p>
+      <p>The goal of a Symposium is usually to educate interested parties about a particular subject.</p>
+      <p>The Call for Participation in a Workshop or Symposium <em class="rfc2119">may</em> indicate participation requirements or limits,
+        and expected deliverables (e.g., reports and minutes). Organization of an event does not guarantee further investment by W3C in a
+        particular topic, but <em class="rfc2119">may</em> lead to proposals for new activities or groups.</p>
+      <p>Workshops and Symposia generally last one to three days. If a Workshop is being organized to address the pressing concerns of
+        Members, the Team <em class="rfc2119">must</em> issue the Call for Participation no later than <span class="time-interval">six
+          weeks</span> prior to the Workshop's scheduled start date. For other Workshops and Symposia, the Team <em class="rfc2119">must</em>
+        issue a Call for Participation no later than <span class="time-interval">eight weeks</span> prior to the meeting's scheduled start
+        date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks.</p>
+      <p><strong>Note:</strong> In general, W3C does not organize <dfn id="EventsC">conferences</dfn>. Currently, W3C presents its work to
+        the public at the annual World Wide Web Conference, which is coordinated by the <a href="http://www.iw3c2.org/">International World
+          Wide Web Conference Committee</a> (<abbr>IW3C2</abbr>).</p>
+      <h2 id="Liaisons">10 Liaisons</h2>
+      <p>W3C uses the term "liaison" to refer to coordination of activities with a variety of organizations, through a number of mechanisms
+        ranging from very informal (e.g., an individual from another organization participates in a W3C Working Group, or just follows its
+        work) to mutual membership, to even more formal agreements. Liaisons are not meant to substitute for W3C membership.</p>
+      <p>All liaisons <em class="rfc2119">must</em> be coordinated by the Team due to requirements for public communication; patent,
+        copyright, and other IPR policies; confidentiality agreements; and mutual membership agreements.</p>
+      <p>The W3C Director <em class="rfc2119">may</em> negotiate and sign a <dfn id="mou">Memorandum of Understanding (<abbr>MoU</abbr>)</dfn>
+        with another organization. Before signing the MoU, the Team <em class="rfc2119">must</em> inform the Advisory Committee of the
+        intent to sign and make the MoU available for Advisory Committee review; the Advisory Committee <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a>.
+        Once approved, a Memorandum of Understanding <em class="rfc2119">should</em> be made public.</p>
+      <p>Information about <a href="http://www.w3.org/2001/11/StdLiaison">W3C liaisons with other organizations</a> and the guidelines W3C
+        follows when creating a liaison [<a href="#ref-liaison-list">PUB28</a>] is available on the Web.</p>
+      <h2 id="Submission">11 Member Submission Process</h2>
+      <p>The Member Submission process allows Members to propose technology or other ideas for consideration by the Team. After review, the
+        Team <em class="rfc2119">may</em> publish the material at the W3C Web site. The formal process affords Members a record of their
+        contribution and gives them a mechanism for disclosing the details of the transaction with the Team (including IPR claims). The Team
+        also publishes review comments on the Submitted materials for W3C Members, the public, and the media.</p>
+      <p>A <dfn id="MemberSubmission">Member Submission</dfn> consists of:</p>
+      <ul>
+        <li>One or more documents developed outside of the W3C process, and</li>
+        <li>Information about the documents, provided by the Submitter.</li>
+      </ul>
+      <p>One or more Members (called the "Submitter(s)") <em class="rfc2119">may</em> participate in a Member Submission. Only W3C Members
+        <em class="rfc2119">may</em> be listed as Submitter(s).</p>
+      <p>The Submission process consists of the following steps:</p>
+      <ol>
+        <li>One of the Submitter(s) sends a request to the Team to acknowledge the Submission request. The Team and Submitter(s) communicate
+          to ensure that the Member Submission is complete.</li>
+        <li>After Team review, the Director <em class="rfc2119">must</em> either acknowledge or reject the Submission request.
+          <ul>
+            <li>If <a href="#SubmissionYes">acknowledged</a>, the Team <em class="rfc2119">must</em> publish the Member Submission at the
+              public W3C Web site, in addition to Team comments about the Member Submission.</li>
+            <li>If <a href="#SubmissionNo">rejected</a>, the Submitter(s) <em class="rfc2119">may</em> appeal to either the <a href="#TAG">TAG</a>
+              or the <a href="#AB">Advisory Board</a>.</li>
+          </ul>
+        </li>
+      </ol>
+      <p><strong>Note:</strong> To avoid confusion about the Member Submission process, please note that:</p>
+      <ul>
+        <li>Documents in a Member Submission are developed outside of W3C. These documents are <strong>not</strong> part of the <a href="#Reports">technical
+            report development process</a> (and therefore are not included in the <a href="http://www.w3.org/TR/">index of W3C technical
+            reports</a>). Members wishing to have documents developed outside of W3C published by W3C <em class="rfc2119">must</em> follow
+          the Member Submission process.</li>
+        <li>The Submission process is <strong>not</strong> a means by which Members ask for "ratification" of these documents as <a href="#RecsW3C">W3C
+            Recommendations</a>.</li>
+        <li>There is no requirement or guarantee that technology which is part of an acknowledged Submission request will receive further
+          consideration by W3C (e.g., by a W3C Working Group).</li>
+      </ul>
+      <p>Publication of a Member Submission by W3C does not imply endorsement by W3C, including the W3C Team or Members. The acknowledgment
+        of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request
+        has been made by the Submitter. A Member Submission published by W3C <em class="rfc2119">must not</em> be referred to as "work in
+        progress" of the W3C.</p>
+      <p>The list of <a href="http://www.w3.org/Submission/">acknowledged Member Submissions</a> [<a href="#ref-submission-list">PUB10</a>]
+        is available at the W3C Web site.</p>
+      <h3 id="SubmissionRights">11.1 Submitter Rights and Obligations</h3>
+      <p>When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member
+        <em class="rfc2119">must</em> copy each of the Advisory Committee representatives of the other participating Members, and each of
+        those Advisory Committee representatives <em class="rfc2119">must</em> confirm (by email to the Team) their participation in the
+        Submission request.</p>
+      <p>At any time prior to acknowledgment, any Submitter <em class="rfc2119">may</em> withdraw support for a Submission request
+        (described in "<a href="http://www.w3.org/2000/09/submission">How to send a Submission request</a>"). A Submission request is
+        "withdrawn" when no Submitter(s) support it. The Team <em class="rfc2119">must not</em> make statements about withdrawn Submission
+        requests.</p>
+      <p>Prior to acknowledgment, the Submitter(s) <em class="rfc2119">must not</em>, <strong>under any circumstances</strong>, refer to a
+        document as "submitted to the World Wide Web Consortium" or "under consideration by W3C" or any similar phrase either in public or
+        Member communication. The Submitter(s) <em class="rfc2119">must not</em> imply in public or Member communication that W3C is
+        working (with the Submitter(s)) on the material in the Member Submission. The Submitter(s) <em class="rfc2119">may</em> publish the
+        documents in the Member Submission prior to acknowledgment (without reference to the Submission request).</p>
+      <p>After acknowledgment, the Submitter(s) <em class="rfc2119">must not</em>, <strong>under any circumstances</strong>, imply W3C
+        investment in the Member Submission until, and unless, the material has been adopted as a deliverable of a W3C Working Group</p>
+      <h4 id="SubmissionScope">11.1.1 Scope of Member Submissions</h4>
+      <p>When a technology overlaps in scope with the work of a chartered Working Group, Members <em class="rfc2119">should</em> <a href="#group-participation">participate
+          in the Working Group</a> and contribute the technology to the group's process rather than seek publication through the Member
+        Submission process. The Working Group <em class="rfc2119">may</em> incorporate the contributed technology into its deliverables. If
+        the Working Group does not incorporate the technology, it <em class="rfc2119">should not</em> publish the contributed documents as
+        Working Group Notes since Working Group Notes represent group output, not input to the group.</p>
+      <p>On the other hand, while W3C is in the early stages of developing a charter, Members <em class="rfc2119">should</em> use the
+        Submission process to build consensus around concrete proposals for new work.</p>
+      <p>Members <em class="rfc2119">should not</em> submit materials covering topics well outside the scope of <a href="http://www.w3.org/Consortium/mission">W3C's
+          mission</a> [<a href="#ref-mission">PUB15</a>].</p>
+      <h4 id="SubmissionReqs">11.1.2Information Required in a Submission Request</h4>
+      <p>The Submitter(s) and any other authors of the submitted material <em class="rfc2119">must</em> agree that, if the request is
+        acknowledged, the documents in the Member Submission will be subject to the <a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C
+          Document License</a> [<a href="#ref-doc-license">PUB18</a>] and will include a reference to it. The Submitter(s) <em class="rfc2119">may</em>
+        hold the copyright for the documents in a Member Submission.</p>
+      <p>The request must satisfy the Member Submission licensing commitments of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-submissions">section
+          3.3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
+      <p>The Submitter(s) <em class="rfc2119">must</em> include the following information:</p>
+      <ul>
+        <li>The list of all submitting Members.</li>
+        <li>Position statements from all submitting Members (gathered by the Submitter). All position statements must appear in a separate
+          document.</li>
+        <li>Complete electronic copies of any documents submitted for consideration (e.g., a technical specification, a position paper,
+          etc.) If the Submission request is acknowledged, these documents will be published by W3C and therefore must satisfy the
+          Communication Team's <a href="http://www.w3.org/Guide/pubrules">Publication Rules</a> [<a href="#ref-pubrules">PUB31</a>].
+          Submitters may hold the copyright for the material contained in these documents, but when published by W3C, these documents <span
+            class="rfc2119">MUST</span> be subject to the provisions of the <a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C
+            Document License</a> [<a href="#ref-doc-license">PUB18</a>].</li>
+      </ul>
+      <p>The request <em class="rfc2119">must</em> also answer the following questions.</p>
+      <ul>
+        <li>What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its
+          use? Again, many answers are possible, but the specific answer will affect the Team's decision.</li>
+        <li>What resources, if any, does the Submitter intend to make available if the W3C acknowledges the Submission request and takes
+          action on it?</li>
+        <li>What action would the Submitter like W3C to take if the Submission request is acknowledged?</li>
+        <li>What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating
+          where change control will reside if the request is acknowledged.</li>
+      </ul>
+      <p>For other administrative requirements related to Submission requests, see "<a href="http://www.w3.org/2000/09/submission">How to
+          send a Submission request</a>" [<a href="#ref-member-sub">MEM8</a>].</p>
+      <h3 id="TeamSubmissionRights">11.2 Team Rights and Obligations</h3>
+      <p>Although they are not technical reports, the documents in a Member Submission <em class="rfc2119">must</em> fulfill the
+        requirements established by the Team, including the Team's <a href="http://www.w3.org/Guide/pubrules">Publication Rules</a>.</p>
+      <p>The Team sends a <a id="validation-notice">validation notice</a> to the Submitter(s) once the Team has reviewed a Submission
+        request and judged it complete and correct.</p>
+      <p>Prior to a decision to <a href="#SubmissionYes">acknowledge</a> or <a href="#SubmissionNo">reject</a> the request, the request is
+        <a href="#Team-only">Team-only</a>, and the Team <em class="rfc2119">must</em> hold it in the strictest confidentiality. In
+        particular, the Team <em class="rfc2119">must not</em> comment to the media about the Submission request.</p>
+      <h3 id="SubmissionYes">11.3 Acknowledgment of a Submission Request</h3>
+      <p>The Director <a href="#SubmissionYes">acknowledges</a> a Submission request by sending an announcement to the Advisory Committee.
+        Though the announcement <em class="rfc2119">may</em> be made at any time, the Submitter(s) can expect an announcement between <span
+          class="time-interval">four to six weeks</span> after the <a href="#validation-notice">validation notice</a>. The Team <em class="rfc2119">must</em>
+        keep the Submitter(s) informed of when an announcement is likely to be made.</p>
+      <p>Once a Submission request has been acknowledged, the Team <em class="rfc2119">must</em>:</p>
+      <ul>
+        <li>Publish the Member Submission.</li>
+        <li>Publish Team comments about the Submission request.</li>
+      </ul>
+      <p>If the Submitter(s) wishes to modify a document published as the result of acknowledgment, the Submitter(s) <em class="rfc2119">must</em>
+        start the Submission process from the beginning, even just to correct editorial changes.</p>
+      <h3 id="SubmissionNo">11.4 Rejection of a Submission Request</h3>
+      <p>The Director <em class="rfc2119">may</em> reject a Submission request for a variety of reasons, including any of the following:</p>
+      <ul>
+        <li>The ideas expressed in the request overlap in scope with the work of a chartered Working Group, and acknowledgment might
+          jeopardize the progress of the group.</li>
+        <li>The IPR statement made by the Submitter(s) is inconsistent with the W3C's <a href="http://www.w3.org/Consortium/Patent-Policy">Patent
+            Policy</a> [<a href="#ref-patentpolicy">PUB33</a>], <a href="http://www.w3.org/Consortium/Legal/copyright-documents">Document
+            License</a> [<a href="#ref-doc-license">PUB18</a>], or other IPR policies.</li>
+        <li>The ideas expressed in the request are poor, might harm the Web, or run counter to <a href="http://www.w3.org/Consortium/mission">W3C's
+            mission</a>.</li>
+        <li>The ideas expressed in the request lie well outside the scope of W3C's mission.</li>
+      </ul>
+      <p>In case of a rejection, the Team <em class="rfc2119">must</em> inform the Advisory Committee representative(s) of the
+        Submitter(s). If requested by the Submitter(s), the Team <em class="rfc2119">must</em> provide rationale to the Submitter(s) about
+        the rejection. Other than to the Submitter(s), the Team <em class="rfc2119">must not</em> make statements about why a Submission
+        request was rejected.</p>
+      <p>The Advisory Committee representative(s) of the Submitters(s) <em class="rfc2119">may</em> appeal the rejection to the <a href="#TAG">TAG</a>
+        if the reasons are related to Web architecture, or to the <a href="#AB">Advisory Board</a> if the request is rejected for other
+        reasons. In this case the Team <em class="rfc2119">should</em> make available its rationale for the rejection to the appropriate
+        body. The Team will establish a process for such appeals that ensures the appropriate <a href="#confidentiality-levels">level of
+          confidentiality</a>.</p>
+      <h2 id="GAProcess">12 Process Evolution</h2>
+      <p>The <span id="ProcessDoc">W3C Process Document</span> undergoes similar consensus-building processes as technical reports, with
+        the <a href="#AB">Advisory Board</a> acting as the sponsoring Working Group.</p>
+      <p>The Advisory Board initiates review of a Process Document as follows:</p>
+      <ol>
+        <li>The Team sends a Call for Review to the Advisory Committee and other W3C groups.</li>
+        <li>After comments have been <a href="#formal-address">formally addressed</a> and the document possibly modified, the Team seeks
+          endorsement from the Members by initiating an <a href="#ACReview">Advisory Committee review</a> of a Proposed Process Document.
+          The review period <em class="rfc2119">must</em> last at least <span class="time-interval">four weeks</span>.</li>
+        <li><a href="#ACReviewAfter">After the Advisory Committee review</a>, if there is consensus, the Team enacts the new process
+          officially by announcing the <a href="#def-w3c-decision">W3C decision</a> to the Advisory Committee. If there was <a href="#def-Dissent">dissent</a>,
+          Advisory Committee representatives <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a> the decision.</li>
+      </ol>
+      <p>W3C <em class="rfc2119">may</em> also modify a Process Document by following the processes for <a href="#rec-modify">modifying a
+          Recommendation</a>.</p>
+      <p>Reviews of the Process Document are not public reviews.</p>
+      <h2 id="references">13 References</h2>
+      <h3 id="public-refs">13.1 Public Resources</h3>
+      <p>The following public information is available at the <a href="http://www.w3.org/">W3C Web site</a>.</p>
+      <dl>
+        <dt id="ref-join-w3c">[PUB5]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/join">How to Join W3C</a></cite></dd>
+        <dt id="ref-member-agreement">[PUB6]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership Agreement</a></cite></dd>
+        <dt id="ref-current-mem">[PUB8]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/Member/List">The list of current W3C Members</a></cite></dd>
+        <dt id="ref-activity-list">[PUB9]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/activities">The list of W3C Activities</a></cite></dd>
+        <dt id="rdf-submission-list">[PUB10]</dt>
+        <dd><cite><a href="http://www.w3.org/Submission/">The list of acknowledged Member Submissions</a></cite></dd>
+        <dt id="rdf-doc-list">[PUB11]</dt>
+        <dd><cite><a href="http://www.w3.org/TR/">The W3C technical reports index</a></cite></dd>
+        <dt id="rdf-submission-overview">[PUB13]</dt>
+        <dd><cite><a href="http://www.w3.org/Submission/1996/Template/">Submission request overview</a></cite></dd>
+        <dt id="rdf-people">[PUB14]</dt>
+        <dd><cite><a href="http://www.w3.org/People/">The W3C Team</a></cite></dd>
+        <dt id="rdf-mission">[PUB15]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/">About the World Wide Web Consortium</a></cite></dd>
+        <dt id="rdf-team-submission-list">[PUB16]</dt>
+        <dd><cite><a href="http://www.w3.org/TeamSubmission/">The list of published Team Submissions</a></cite></dd>
+        <dt id="rdf-invited-expert">[PUB17]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/Legal/collaborators-agreement">Invited expert and collaborators agreement</a></cite></dd>
+        <dt id="rdf-doc-license">[PUB18]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C Document License</a></cite></dd>
+        <dt id="rdf-software-license">[PUB19]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/Legal/copyright-software">W3C Software Notice and License</a></cite></dd>
+        <dt id="rdf-translations">[PUB20]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/Translation/">Translations of W3C technical reports</a></cite></dd>
+        <dt id="rdf-pub-mailing-lists">[PUB21]</dt>
+        <dd><cite><a href="http://www.w3.org/Mail/">Public W3C mailing lists</a></cite></dd>
+        <dt id="rdf-coi">[PUB23]</dt>
+        <dd><cite><a href="http://www.w3.org/2000/09/06-conflictpolicy">Conflict of Interest Policy for W3C Team Members Engaged in Outside
+              Professional Activities</a></cite></dd>
+        <dt id="rdf-tag-charter">[PUB25]</dt>
+        <dd><cite><a href="http://www.w3.org/2001/07/19-tag">Technical Architecture Group (TAG) Charter</a></cite></dd>
+        <dt id="rdf-tag-home">[PUB26]</dt>
+        <dd><cite><a href="http://www.w3.org/2001/tag/">The TAG home page</a></cite></dd>
+        <dt id="rdf-rec-tips">[PUB27]</dt>
+        <dd><cite><a href="http://www.w3.org/2002/05/rec-tips">Tips for Getting to Recommendation Faster</a></cite></dd>
+        <dt id="rdf-liaison-list">[PUB28]</dt>
+        <dd><cite><a href="http://www.w3.org/2001/11/StdLiaison">W3C liaisons with other organizations</a></cite></dd>
+        <dt id="rdf-ab-home">[PUB30]</dt>
+        <dd><cite><a href="http://www.w3.org/2002/ab/">The Advisory Board home page</a></cite></dd>
+        <dt id="rdf-pubrules">[PUB31]</dt>
+        <dd><cite><a href="http://www.w3.org/Guide/pubrules">Publication Rules</a></cite></dd>
+        <dt id="rdf-fellows">[PUB32]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/Recruitment/Fellows">W3C Fellows Program</a></cite></dd>
+        <dt id="rdf-patentpolicy">[PUB33]</dt>
+        <dd><cite><a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 Feb 2004 version of the W3C Patent Policy</a></cite>. The
+          <a href="http://www.w3.org/Consortium/Patent-Policy/">latest version of the W3C Patent Policy</a> is available at
+          http://www.w3.org/Consortium/Patent-Policy/.</dd>
+        <dt id="in-place-tr-mod">[PUB35]</dt>
+        <dd><cite><a href="http://www.w3.org/2003/01/republishing/">In-place modification of W3C Technical Reports</a></cite></dd>
+      </dl>
+      <h3>13.2 <a id="member-refs">Member-only Resources</a></h3>
+      <p>The following <a href="#Member-only">Member-only</a> information is available at the <a href="http://www.w3.org/">W3C Web site</a>.</p>
+      <dl>
+        <dt id="rdf-current-ac">[MEM1]</dt>
+        <dd><cite><a href="http://www.w3.org/Member/ACList">Current Advisory Committee representatives</a></cite></dd>
+        <dt id="rdf-mailing-lists">[MEM2]</dt>
+        <dd><cite><a href="http://www.w3.org/Member/Mail/">Group mailing lists</a></cite></dd>
+        <dt id="rdf-calendar">[MEM3]</dt>
+        <dd>The <cite><a href="http://www.w3.org/Member/Eventscal">calendar of all scheduled official W3C events</a></cite></dd>
+        <dt id="rdf-new-member">[MEM4]</dt>
+        <dd>The <cite><a href="http://www.w3.org/Member/Intro">New Member Orientation</a></cite>, which includes an introduction to W3C
+          processes from a practical standpoint, including relevant email addresses.</dd>
+        <dt id="rdf-ac-meetings">[MEM5]</dt>
+        <dd><cite><a href="http://www.w3.org/Member/Meeting/">Advisory Committee meetings</a></cite></dd>
+        <dt id="rdf-member-web">[MEM6]</dt>
+        <dd><cite><a href="http://www.w3.org/Member/">Member Web site</a></cite></dd>
+        <dt id="rdf-member-sub">[MEM8]</dt>
+        <dd><cite><a href="http://www.w3.org/2000/09/submission">How to send a Submission request</a></cite></dd>
+        <dt id="rdf-guide">[MEM9]</dt>
+        <dd><cite><a href="http://www.w3.org/Guide/">The Art of Consensus</a></cite>, a guidebook for W3C Working Group Chairs and other
+          collaborators</dd>
+        <dt id="rdf-discipline-gl">[MEM14]</dt>
+        <dd><cite><a href="http://www.w3.org/2002/09/discipline">Guidelines for Disciplinary Action</a></cite></dd>
+        <dt id="rdf-election-howto">[MEM15]</dt>
+        <dd><cite><a href="http://www.w3.org/2002/10/election-howto">How to Organize an Advisory Board or TAG election</a></cite></dd>
+      </dl>
+      <h3 id="other-refs">13.3 Other References</h3>
+      <dl>
+        <dt id="rdf-RFC2119">[RFC2119]</dt>
+        <dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">"Key words for use in RFCs to Indicate Requirement Levels"</a></cite>, S.
+          Bradner, March 1997.</dd>
+        <dt id="ref-RFC2777">[RFC2777]</dt>
+        <dd><cite><a href="http://www.ietf.org/rfc/rfc2777.txt">"Publicly Verifiable Nomcom Random Selection"</a></cite>, D. Eastlake 3rd,
+          February 2000.</dd>
+      </dl>
+      <h2 id="acks">14 Acknowledgments</h2>
+      <p>The following individuals have contributed to this proposal for a revised Process: Daniel Appelquist (Telefonica), Art Barstow
+        (Nokia), Robin Berjon (W3C), Judy Brewer (W3C), Marcos Cáceres (Mozilla), Wayne Carr (Intel), Michael Champion (W3C), Mark Crawford
+        (SAP), Karl Dubost (Mozilla), Fantasai (unaffiliated), Virginie Galindo (Gemalto), Daniel Glazman (Disruptive Innovations), Eduardo
+        Gutentag (unaffiiliated), Brad Hill (Facebook), Jeff Jaffe (W3C), Cullen Jennings (Cisco), Brain Kardell (JQuery), Peter Linss (HP),
+        Nigel Megitt (BBC), Olle Olsson (SICS), Natasha Rooney (GSMA), Sam Ruby (IBM), David Singer (Apple), Henri Sivonen (Mozilla), Josh
+        Soref (BlackBerry), Anne van Kesteren (Mozilla), Léonie Watson (The Paciello Group), Mike West (Google), Chris Wilson (Google),
+        Steve Zilles (Adobe).</p>
+      <p>The following individuals contributed to the development of earlier versions of the Process: Jean-François Abramatic (IBM, and
+        previously ILOG and W3C), Dan Appelquist (Telefonica), Art Barstow (Nokia), Ann Bassetti (The Boeing Company), Jim Bell (HP), Robin
+        Berjon (W3C), Tim Berners-Lee (W3C), Klaus Birkenbihl (Fraunhofer Gesellschaft), Don Brutzman (Web3D), Carl Cargill (Netscape, Sun
+        Microsystems), Wayne Carr (Intel), Marcos Cáceres (Mozilla), Michael Champion (Microsoft), Paul Cotton (Microsoft), Mark Crawford
+        (SAP), Tantek Çelik (Mozilla), Don Deutsch (Oracle), David Fallside (IBM), Fantasai (Mozilla), Wendy Fong (Hewlett-Packard),
+        Virginie Galindo (Gemalto), Daniel Glazman (Disruptive Innovations), Paul Grosso (Arbortext), Eduardo Gutentag (Sun Microsystems),
+        Joe Hall (CDT), Ivan Herman (W3C), Ian Hickson (Google), Steve Holbrook (IBM), Renato Iannella (IPR Systems), Ian Jacobs (W3C), Jeff
+        Jaffe (W3C), Cullen Jennings (Cisco), Sally Khudairi (W3C), John Klensin (MCI), Tim Krauskopf (Spyglass), Kari Laihonen (Ericsson),
+        Ken Laskey (MITRE), Ora Lassila (Nokia), Håkon Wium Lie (Opera Software), Chris Lilley (W3C), Bede McCall (MITRE), Giri Mandyam
+        (Qualcomm), Larry Masinter (Adobe Systems), Qiuling Pan (Huawei), TV Raman (Google), Thomas Reardon (Microsoft), Claus von Riegen
+        (SAP AG), David Singer (Apple), David Singer (IBM), Ralph Swick (W3C), Anne van Kesteren, Jean-Charles Verdié (MStar), Chris Wilson
+        (Google), Lauren Wood (unaffiliated), and Steve Zilles (Adobe Systems).</p>
+      <h2 id="changes">15 Changes</h2>
+      <p>This document is based on 1 August 2014 Process. <a href="https://dvcs.w3.org/hg/AB/">Detailed change logs</a> are available.</p>
+      <p>The notable changes include:</p>
+      <h3>Current Editor's draft</h3>
+      <ul>
+        <li>Editorial corrections - typos and markup errors</li>
+      </ul>
+      <h3>Previous Editor's drafts</h3>
+      <ul>
+        <li>Editorial cleanups to <a href="#wide-review">7.2.3.1 Wide Review</a></li>
+        <li>Editorial Changes to <a href="#errata">7.7.1 Errata Management</a> - <a href="https://www.w3.org/community/w3process/track/issues/141">ISSUE-141</a></li>
+        <li>Remove <a id="GCGCreation" name="CGCreation"></a><a id="GroupsCG" name="GroupsCG"></a> <a id="CGParticipation" name="CGParticipation"></a><a
+            id="cgparticipant" name="cgparticipant"></a> <a id="CGCharter" name="CGCharter"></a>Coordination groups - 
+          <a href="https://www.w3.org/community/w3process/track/issues/129">ISSUE-129</a></li>
+        <li>Remove vestigial traces of Good Standing throughout</li>
+        <li>Loosen constraints on multiple employees of a single member being on TAG - <a href="#AB-TAG-constraints">section 2.5.1</a></li>
+        <li>Replace "W3C Chair" with "CEO" throughout</li>
+        <li>Editorial tweaks to what is requested in <a href="file:///Users/chaals/Documents/w3c/AB/cover.html#wide-review">7.2.3.1 Wide
+            Review</a></li>
+        <li>Remove section <span id="three-month-rule">6.2.7 "Heartbeat" publishing requirement, redundant with the first requirement of <a
+              href="#revised-wd">section 7.3.2</a><br>
+          </span></li>
+      </ul>
+      <h3>30 September "AC intermediate review" draft</h3>
+      <p>Provided to the Advisory Committee to review the following changes made compared to the 1 August 2014 Operative Process document</p>
+      <ul>
+        <li>Remove <a id="ActivityProposal">Activities</a> from the Process (as resolved multiple times since 2007)</li>
+        <li>Remove <a id="good-standing">6.2.1.7</a> Good Standing in a Working Group</li>
+      </ul>
+    </main>
+    <em class="rfc2119"><em class="rfc2119"> </em></em>
+  </body>
+</html>