Removed coordination groups - issue 129.
authorcharles
Sun, 21 Dec 2014 22:27:47 +0300
changeset 132 c42095c2375d
parent 131 13d93c5ec375
child 133 3c4bc56ce16b
Removed coordination groups - issue 129.
cover.html
--- a/cover.html	Tue Dec 16 15:23:12 2014 +0300
+++ b/cover.html	Sun Dec 21 22:27:47 2014 +0300
@@ -1,3284 +1,219 @@
-<!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">16 December 2014 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>Previous operative version:</dt>
-        <dd><a href="http://www.w3.org/2005/10/Process-20051014/">14 October
-            2005 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-2014 <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
+<!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">20 December 2014 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>Previous operative version:</dt>
        <dd><a href="http://www.w3.org/2005/10/Process-20051014/">14 October
            2005 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-2014 <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"><a id="status">Status of this Document</a></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 is the 16 December 2014 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>In <em>this draft</em>, there is a loosening of restrictions on TAG
-      membership, and the "W3C Chair" has been changed to "CEO" (to match the
-      reality of the last dozen years). A <a href="#changes">change history</a>
-      (compared to the 2014 Process Document) forms part of the draft.</p>
-    <p>During the rest of 2014 the document will be developed in preparation for
-      adopting a revised process in 2015.</p>
-    <p>Public comment is invited on the draft. Please send comments about this
-      document to the <a href="http://www.w3.org/community/w3process/">Revising
-        W3C Process Community Group</a> (<a href="http://lists.w3.org/Archives/Public/public-w3process/">Mailing
+          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"><a id="status">Status of this Document</a></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 is the 16 December 2014 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>In <em>this draft</em>, A <a href="#changes">change history</a>
      (compared to the 2014 Process Document) forms part of the draft.</p>
    <p>During the rest of 2014 the document will be developed in preparation for
      adopting a revised process in 2015.</p>
    <p>Public comment is invited on the draft. Please send comments about this
      document to the <a href="http://www.w3.org/community/w3process/">Revising
        W3C Process Community Group</a> (<a href="http://lists.w3.org/Archives/Public/public-w3process/">Mailing
         list archive</a>, publicly available) or to [email protected] (<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"><a id="pp">Relation of Process Document to Patent Policy</a></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
+        Issue Tracker</a> and <a href="https://dvcs.w3.org/hg/AB/">detailed
        changelogs</a> are available online. </p>
    <h2 class="notoc"><a id="pp">Relation of Process Document to Patent Policy</a></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.&nbsp;</p>
-    <div class="toc" role="navigation">
-      <h2 class="notoc"><a id="toc">Table of Contents</a></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, Interest Groups, and Coordination 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"><a id="fulltoc">Expanded table of contents</a></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, Interest
-            Groups, and Coordination Groups</a>
-          <ul class="toc">
-            <li class="tocline3"><a href="#ReqsAllGroups">6.1 Requirements for
-                All Working, Interest, and Coordination 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"><s>6.2.7 Working Group "Heartbeat"
-                    Requirement</s></li>
-                <li class="tocline4"><a href="#GeneralTermination">6.2.8 Working
-                    Group and Interest Group Closure</a></li>
-              </ul>
-            </li>
-            <li class="tocline3"><a href="#GroupsCG">6.3 Coordination Groups</a>
-              <ul class="toc">
-                <li class="tocline4"><a href="#CGParticipation">6.3.1
-                    Coordination Group Participation Requirements</a></li>
-                <li class="tocline4"><a href="#CGCreation">6.3.2 Coordination
-                    Group Creation and Closure</a></li>
-                <li class="tocline4"><a href="#CGCharter">6.3.3 Coordination
-                    Group Charters</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>
-    <div role="main">
-      <h2>1 <a id="Intro">Introduction</a></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
+          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.&nbsp;</p>
    <div class="toc" role="navigation">
      <h2 class="notoc"><a id="toc">Table of Contents</a></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"><a id="fulltoc">Expanded table of contents</a></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>
    <div role="main">
      <h2>1 <a id="Intro">Introduction</a></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
+            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>2 <a id="Organization">Members, Advisory Committee, Team, Advisory
-          Board, Technical Architecture Group</a></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>2.1 <a id="Members">Members</a></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, Interest Groups, and Coordination Groups</a> and author and
-          review <a href="#Reports">technical reports</a>.</li>
-      </ol>
-      <p><a id="MemberSubscription">W3C membership</a> 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>
-        <span class="rfc2119">MUST</span> ensure that Member participation
-        agreements remain <a href="#Team-only">Team-only</a> and that no Member
-        receives preferential treatment within W3C.</p>
-      <p><a id="IndividualParticipation">W3C does not have a class of membership
-          tailored to, or priced for individuals</a>. However, an individual <span
-          class="rfc2119">MAY</span> 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>2.1.1 <a id="MemberBenefits">Rights of Members</a></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
+          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>2 <a id="Organization">Members, Advisory Committee, Team, Advisory
          Board, Technical Architecture Group</a></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>2.1 <a id="Members">Members</a></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><a id="MemberSubscription">W3C membership</a> 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>
        <span class="rfc2119">MUST</span> ensure that Member participation
        agreements remain <a href="#Team-only">Team-only</a> and that no Member
        receives preferential treatment within W3C.</p>
      <p><a id="IndividualParticipation">W3C does not have a class of membership
          tailored to, or priced for individuals</a>. However, an individual <span
          class="rfc2119">MAY</span>
        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>2.1.1 <a id="MemberBenefits">Rights of Members</a></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, Interest Groups, and
-            Coordination 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 <span class="rfc2119">MAY</span> designate up to four
-        (or more at the Team's discretion) individuals who, though not employed
-        by the organization, <span class="rfc2119">MAY</span> exercise the
-        rights of <a href="#member-rep">Member representatives</a>. These
-        individuals <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span>
-        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>2.1.2 <a id="MemberRelated">Related Members</a></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 <span class="rfc2119">MUST</span> 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>2.1.3 <a id="AC">Advisory Committee (AC)</a></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 <span class="rfc2119">MUST</span>
-        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 <span class="rfc2119">MUST</span>
-        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>2.1.3.1 <a id="ACCommunication">Advisory Committee Mailing Lists</a></h5>
-      <p>The Team <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> monitor discussion and <span
-            class="rfc2119">SHOULD</span> participate in discussion when
-          appropriate. Ongoing detailed discussions <span class="rfc2119">SHOULD</span>
-          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 <span class="rfc2119">MAY</span>
-        request that additional individuals from their organization be
-        subscribed to these lists. Failure to contain distribution internally <span
-          class="rfc2119">MAY</span> result in suspension of additional email
-        addresses, at the discretion of the Team.</p>
-      <h5>2.1.3.2 <a id="ACMeetings">Advisory Committee Meetings</a></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 <span class="rfc2119">SHOULD</span>
-        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 <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">MAY</span> allow a Member organization to
-        send two representatives to a meeting.</p>
-      <p>The Team <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span>
-        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
+            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 <span class="rfc2119">MAY</span> designate up to four
        (or more at the Team's discretion) individuals who, though not employed
        by the organization, <span class="rfc2119">MAY</span> exercise the
        rights of <a href="#member-rep">Member representatives</a>. These
        individuals <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span>
        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>2.1.2 <a id="MemberRelated">Related Members</a></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 <span class="rfc2119">MUST</span> 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>2.1.3 <a id="AC">Advisory Committee (AC)</a></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 <span class="rfc2119">MUST</span>
        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 <span class="rfc2119">MUST</span>
        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>2.1.3.1 <a id="ACCommunication">Advisory Committee Mailing Lists</a></h5>
      <p>The Team <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> monitor discussion and <span
            class="rfc2119">SHOULD</span>
          participate in discussion when appropriate. Ongoing detailed
          discussions <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">MAY</span>
        request that additional individuals from their organization be
        subscribed to these lists. Failure to contain distribution internally <span
          class="rfc2119">MAY</span>
        result in suspension of additional email addresses, at the discretion of
        the Team.</p>
      <h5>2.1.3.2 <a id="ACMeetings">Advisory Committee Meetings</a></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 <span class="rfc2119">SHOULD</span>
        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 <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">MAY</span> allow a Member organization to
        send two representatives to a meeting.</p>
      <p>The Team <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span>
        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>2.2 <a id="Team">The W3C Team</a></h3>
-      <p>The Team consists of the <a id="def-Director">Director</a>, <a id="def-W3CChair">CEO</a>,
-        W3C paid staff, unpaid interns, and W3C Fellows. <a id="fellows">W3C
-          Fellows</a> 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 <span class="rfc2119">MAY</span> delegate
-        responsibility (generally to other individuals in the Team) for any of
-        their roles described in this document.</p>
-      <p>The&nbsp; is the lead technical architect at W3C and as such, is
-        responsible for 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. The Director appoints group <a href="#GeneralChairs">Chairs</a>
-        and has the role of "tie-breaker" for questions of <a href="#good-standing">Good
-          Standing</a> in a Working Group or <a href="#WGAppeals">appeal of a
-          Working Group decision</a>. The Director is generally Chair of the <a
-          href="#TAG">TAG</a>.</p>
-      <p>The&nbsp; leads Member relations, and <a href="#Liaisons">liaisons</a>
-        with other organizations, governments, and the public.</p>
-      <p>The <a id="def-COO">Chief Operating Officer</a> (<abbr>COO</abbr>)
-        leads the operation of W3C as an organization: a collection of people, <a
-          href="#hosts">Host institutions</a>, and processes.</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 three <a id="hosts">"Host"
-          institutions</a>: 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 joint sponsorship contracts; the Hosts
-        themselves are not W3C Members.</p>
-      <h4>2.2.1 <a id="TeamSubmission">Team Submissions</a></h4>
-      <p>Team members <span class="rfc2119">MAY</span> 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>2.3 <a id="AB">Advisory Board (AB)</a></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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">SHOULD</span> send a summary
-        of each of its meetings to the Advisory Committee and other group
-        Chairs. The Advisory Board <span class="rfc2119">SHOULD</span> 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
+          meetings</a> [<a href="#ref-ac-meetings">MEM5</a>] is available at the
        Member Web site.</p>
      <h3>2.2 <a id="Team">The W3C Team</a></h3>
      <p>The Team consists of the <a id="def-Director">Director</a>, <a id="def-W3CChair">CEO</a>,
        W3C paid staff, unpaid interns, and W3C Fellows. <a id="fellows">W3C
          Fellows</a> 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 <span class="rfc2119">MAY</span> delegate
        responsibility (generally to other individuals in the Team) for any of
        their roles described in this document.</p>
      <p>The Director is the lead technical architect at W3C. His
        responsibilities are identified throughout this document in relevant
        places, but 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. The Director appoints group <a href="#GeneralChairs">Chairs</a>
        and has the role of "tie-breaker" for questions of <a href="#good-standing">Good
+          Standing</a> in a Working Group or <a href="#WGAppeals">appeal of a
          Working Group decision</a>. The Director is generally Chair of the <a
          href="#TAG">TAG</a>.</p>
      <p>The CEO leads Member relations, and <a href="#Liaisons">liaisons</a>
        with other organizations, governments, and the public.</p>
      <p>The <a id="def-COO">Chief Operating Officer</a> (<abbr>COO</abbr>)
        leads the operation of W3C as an organization: a collection of people, <a
          href="#hosts">Host
+          institutions</a>, and processes.</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 three <a id="hosts">"Host"
          institutions</a>: 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 joint sponsorship contracts; the Hosts
        themselves are not W3C Members.</p>
      <h4>2.2.1 <a id="TeamSubmission">Team Submissions</a></h4>
      <p>Team members <span class="rfc2119">MAY</span> 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>2.3 <a id="AB">Advisory Board (AB)</a></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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">SHOULD</span> send a summary
        of each of its meetings to the Advisory Committee and other group
        Chairs. The Advisory Board <span class="rfc2119">SHOULD</span> 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>2.3.1 <a id="ABParticipation">Advisory Board Participation</a></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>2.4 <a id="TAG">Technical Architecture Group (TAG)</a></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 <span class="rfc2119">SHOULD NOT</span> 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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MAY</span>
-        use a list that will be <a href="#Member-only">Member-only</a>.</p>
-      <p>The TAG <span class="rfc2119">SHOULD</span> send a summary of each of
-        its <a href="#GeneralMeetings">meetings</a> to the Advisory Committee
-        and other group Chairs. The TAG <span class="rfc2119">SHOULD</span>
-        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>2.4.1 <a id="tag-participation">Technical Architecture Group
-          Participation</a></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 <span
-          class="rfc2119">NOT REQUIRED</span> to be on the W3C Team. The
-        Director <span class="rfc2119">MAY</span> 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>2.5 <a id="AB-TAG-participation">Advisory Board and Technical
-          Architecture Group Participation</a></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. <a href="#good-standing">Good Standing</a>
-        rules as defined for Working Group participants also apply to Advisory
-        Board and TAG participants. Advisory Board and TAG participants <span class="rfc2119">SHOULD</span>
-        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>).
+          home page</a> [<a href="#ref-ab-home">PUB30</a>].</p>
      <h4>2.3.1 <a id="ABParticipation">Advisory Board Participation</a></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>2.4 <a id="TAG">Technical Architecture Group (TAG)</a></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 <span class="rfc2119">SHOULD NOT</span> 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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MAY</span>
        use a list that will be <a href="#Member-only">Member-only</a>.</p>
      <p>The TAG <span class="rfc2119">SHOULD</span> send a summary of each of
        its <a href="#GeneralMeetings">meetings</a> to the Advisory Committee
        and other group Chairs. The TAG <span class="rfc2119">SHOULD</span>
        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>2.4.1 <a id="tag-participation">Technical Architecture Group
          Participation</a></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 <span
          class="rfc2119">NOT
+          REQUIRED</span> to be on the W3C Team. The Director <span class="rfc2119">MAY</span>
        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>2.5 <a id="AB-TAG-participation">Advisory Board and Technical
          Architecture Group Participation</a></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. <a href="#good-standing">Good Standing</a>
        rules as defined for Working Group participants also apply to Advisory
        Board and TAG participants. Advisory Board and TAG participants <span class="rfc2119">SHOULD</span>
        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>2.5.1 <a id="AB-TAG-constraints">Advisory Board and Technical
-          Architecture Group Participation Constraints</a></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 <span class="rfc2119">MUST NOT</span> 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>2.5.2 <a id="AB-TAG-elections">Advisory Board and Technical
-          Architecture Group Elections</a></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 <span
-          class="rfc2119">SHOULD</span> 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>)
-        <span class="rfc2119">MAY</span> nominate one individual. A nomination <span
-          class="rfc2119">MUST</span> be made with the consent of the nominee.
-        In order for an individual to be nominated as a Member representative,
-        the individual <span class="rfc2119">MUST</span> qualify for <a href="#member-rep">Member
-          representation</a> and the Member's Advisory Committee representative
-        <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span>
-        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 <span class="rfc2119">MUST</span> include that
-        information in the nomination. In order for an individual to be
-        nominated as a Team representative, the nominating Advisory Committee
-        representative <span class="rfc2119">MUST</span> first secure approval
-        from Team management. A nominee is <span class="rfc2119">NOT REQUIRED</span>
-        to be an employee of a Member organization, and <span class="rfc2119">MAY</span>
-        be a <a href="#fellows">W3C Fellow</a>. Each nomination <span class="rfc2119">SHOULD</span>
-        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>) <span class="rfc2119">MAY</span> 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>2.5.2.1 <a id="random">Verifiable Random Selection Procedure</a></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>2.5.3 <a id="AB-TAG-vacated">Advisory Board and Technical
-          Architecture Group Vacated Seats</a></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>,
-          for example because the participant has failed to remain in <a href="#good-standing">Good
-            Standing</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 <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">MAY</span>
-          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 <span class="rfc2119">SHOULD
-            NOT</span> request an exceptional election if the next regularly
-          scheduled election is fewer than three months away.</li>
-      </ul>
-      <h2>3 <a id="Policies">General Policies for W3C Groups</a></h2>
-      <p>This section describes general policies for W3C groups regarding
-        participation, meeting requirements, and decision-making. These policies
-        apply to <a id="participant">participants</a> in the following groups:
-        <a href="#AC">Advisory Committee</a>, <a href="#ABParticipation">Advisory
+          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>2.5.1 <a id="AB-TAG-constraints">Advisory Board and Technical
          Architecture Group Participation Constraints</a></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 <span class="rfc2119">MUST NOT</span> 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>2.5.2 <a id="AB-TAG-elections">Advisory Board and Technical
          Architecture Group Elections</a></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 <span
          class="rfc2119">SHOULD</span>
        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>)
        <span class="rfc2119">MAY</span> nominate one individual. A nomination <span
          class="rfc2119">MUST</span>
        be made with the consent of the nominee. In order for an individual to
        be nominated as a Member representative, the individual <span class="rfc2119">MUST</span>
        qualify for <a href="#member-rep">Member representation</a> and the
        Member's Advisory Committee representative <span class="rfc2119">MUST</span>
        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 <span
          class="rfc2119">MUST</span>
        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 <span class="rfc2119">MUST</span> include that
        information in the nomination. In order for an individual to be
        nominated as a Team representative, the nominating Advisory Committee
        representative <span class="rfc2119">MUST</span> first secure approval
        from Team management. A nominee is <span class="rfc2119">NOT REQUIRED</span>
        to be an employee of a Member organization, and <span class="rfc2119">MAY</span>
        be a <a href="#fellows">W3C Fellow</a>. Each nomination <span class="rfc2119">SHOULD</span>
        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>) <span class="rfc2119">MAY</span> 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>2.5.2.1 <a id="random">Verifiable Random Selection Procedure</a></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>2.5.3 <a id="AB-TAG-vacated">Advisory Board and Technical
          Architecture Group Vacated Seats</a></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>,
          for example because the participant has failed to remain in <a href="#good-standing">Good
+            Standing</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 <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">MAY</span>
          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 <span class="rfc2119">SHOULD
+            NOT</span> request an exceptional election if the next regularly
          scheduled election is fewer than three months away.</li>
      </ul>
      <h2>3 <a id="Policies">General Policies for W3C Groups</a></h2>
      <p>This section describes general policies for W3C groups regarding
        participation, meeting requirements, and decision-making. These policies
        apply to <a id="participant">participants</a> 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>, <a href="#igparticipant">Interest Groups</a>, and <a href="#cgparticipant">Coordination
-          Groups</a>.</p>
-      <h3>3.1 <a id="ParticipationCriteria">Individual Participation Criteria</a></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>3.1.1 <a id="coi">Conflict of Interest Policy</a></h4>
-      <p>Individuals participating materially in W3C work <span class="rfc2119">MUST</span>
-        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 <span class="rfc2119">MUST</span>
-        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 <span class="rfc2119">MUST</span> be evaluated.
-        The role <span class="rfc2119">MAY</span> be reassigned according to
-        the appropriate process. For instance, the Director <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">SHOULD</span>
-        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>3.1.2 <a id="member-rep">Individuals Representing a Member
-          Organization</a></h4>
-      <p>Generally, individuals representing a Member in an official capacity
-        within W3C are employees of the Member organization. However, an
-        Advisory Committee representative <span class="rfc2119">MAY</span>
-        designate a non-employee to represent the Member. Non-employee Member
-        representatives <span class="rfc2119">MUST</span> 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> <span class="rfc2119">MAY</span>
-        decline to allow an individual designated by an Advisory Committee
-        representative to participate in a group.</p>
-      <p>A group charter <span class="rfc2119">MAY</span> limit the number of
-        individuals representing a W3C Member (or group of <a href="#MemberRelated">related
-          Members</a>).</p>
-      <h3>3.2 <a id="GeneralMeetings">Meetings</a></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>) <span class="rfc2119">SHOULD</span> observe the meeting
-        requirements in this section.</p>
-      <p>W3C distinguishes two types of meetings:</p>
-      <ol>
-        <li>A <a id="ftf-meeting">face-to-face meeting</a> is one where most of
-          the attendees are expected to participate in the same physical
-          location.</li>
-        <li>A <a id="distributed-meeting">distributed meeting</a> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">SHOULD</span> 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>3.3 <a id="Consensus">Consensus</a></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 <span class="rfc2119">MAY</span> 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><a id="def-Consensus">Consensus</a>: 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. <a id="def-Unanimity">Unanimity</a>
-          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><a id="def-Dissent">Dissent</a>: 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 in <a href="#good-standing">Good
-          Standing</a>. 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 <span class="rfc2119">MAY</span>
-        include a quorum requirement for consensus decisions.</p>
-      <p>Where unanimity is not possible, a group <span class="rfc2119">SHOULD</span>
-        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 <span class="rfc2119">SHOULD</span>
-        set minimum thresholds of active support before a decision can be
-        recorded. The appropriate percentage <span class="rfc2119">MAY</span>
-        vary depending on the size of the group and the nature of the decision.
-        A charter <span class="rfc2119">MAY</span> 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>3.3.1 <a id="managing-dissent">Managing Dissent</a></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 <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">SHOULD</span>
-        move on.</p>
-      <p>Groups <span class="rfc2119">SHOULD</span> 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>3.3.2 <a id="WGArchiveMinorityViews">Recording and Reporting Formal
-          Objections</a></h4>
-      <p>In the W3C process, an individual may register a Formal Objection to a
-        decision. A <a id="FormalObjection">Formal Objection</a> 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 <span class="rfc2119">SHOULD</span>
-        cite technical arguments and propose changes that would remove the
-        Formal Objection; these proposals <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MUST</span> be
-        <a href="#confidentiality-change">publicly available</a>. A Call for
-        Review (of a document) to the Advisory Committee <span class="rfc2119">MUST</span>
-        identify any Formal Objections.</p>
-      <h4>3.3.3 <a id="formal-address">Formally Addressing an Issue</a></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 <span class="rfc2119">SHOULD</span>
-        seek clarification before reaching a decision.</p>
-      <p>As a courtesy, both Chairs and reviewers <span class="rfc2119">SHOULD</span>
-        set expectations for the schedule of responses and acknowledgments. The
-        group <span class="rfc2119">SHOULD</span> reply to a reviewer's initial
-        comments in a timely manner. The group <span class="rfc2119">SHOULD</span>
-        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 <span class="rfc2119">SHOULD</span> realize that
-        their comments will carry less weight if not sent to the group in a
-        timely manner.</p>
-      <p>Substantive responses <span class="rfc2119">SHOULD</span> be recorded.
-        The group <span class="rfc2119">SHOULD</span> 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>3.3.4 <a id="WGChairReopen">Reopening a Decision When Presented With
-          New Information</a></h4>
-      <p>The Chair <span class="rfc2119">MAY</span> 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 <span class="rfc2119">SHOULD</span> record that a decision
-        has been reopened, and <span class="rfc2119">MUST</span> do so upon
-        request from a group participant.</p>
-      <h3>3.4 <a id="Votes">Votes</a></h3>
-      <p>A group <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">MUST</span>
-        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 <span class="rfc2119">MUST</span>
-        be a group <a href="#participant">participant</a> in <a href="#good-standing">Good
-          Standing</a>. Each organization represented in the group <span class="rfc2119">MUST</span>
-        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> <span class="rfc2119">MAY</span> vote.</p>
-      <p>If a participant is unable to attend a vote, that individual <span class="rfc2119">MAY</span>
-        authorize anyone at the meeting to act as a <a id="proxy">proxy</a>.
-        The absent participant <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">NOT
-          REQUIRED</span> to state the reasons for their dissent, and the group
-        is <span class="rfc2119">NOT REQUIRED</span> to record individual
-        votes.</p>
-      <p>A group charter <span class="rfc2119">SHOULD</span> 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>3.5 <a id="WGAppeals">Appeal of a Chair's Decision</a></h3>
-      <p>Groups resolve issues through dialog. Individuals who disagree strongly
-        with a decision <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">SHOULD</span>
-        also make their requests known to the <a href="#TeamContact">Team
-          Contact</a>. The Team Contact <span class="rfc2119">MUST</span>
-        inform the Director when a group participant has raised concerns about
-        due process.</p>
-      <p>Any requests to the Director to confirm a decision <span class="rfc2119">MUST</span>
-        include a summary of the issue (whether technical or procedural),
-        decision, and rationale for the objection. All counter-arguments,
-        rationales, and decisions <span class="rfc2119">MUST</span> be
-        recorded.</p>
-      <p>Procedures for <a href="#ACAppeal">Advisory Committee appeals</a> are
-        described separately.</p>
-      <h3>3.6 <a id="resignation">Resignation from a Group</a></h3>
-      <p>A W3C Member or Invited Expert <span class="rfc2119">MAY</span> 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
+          Groups</a>, and <a href="#igparticipant">Interest Groups</a>.</p>
      <h3>3.1 <a id="ParticipationCriteria">Individual Participation Criteria</a></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>3.1.1 <a id="coi">Conflict of Interest Policy</a></h4>
      <p>Individuals participating materially in W3C work <span class="rfc2119">MUST</span>
        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 <span class="rfc2119">MUST</span>
        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 <span class="rfc2119">MUST</span> be evaluated.
        The role <span class="rfc2119">MAY</span> be reassigned according to
        the appropriate process. For instance, the Director <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">SHOULD</span>
        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>3.1.2 <a id="member-rep">Individuals Representing a Member
          Organization</a></h4>
      <p>Generally, individuals representing a Member in an official capacity
        within W3C are employees of the Member organization. However, an
        Advisory Committee representative <span class="rfc2119">MAY</span>
        designate a non-employee to represent the Member. Non-employee Member
        representatives <span class="rfc2119">MUST</span> 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> <span class="rfc2119">MAY</span>
        decline to allow an individual designated by an Advisory Committee
        representative to participate in a group.</p>
      <p>A group charter <span class="rfc2119">MAY</span> limit the number of
        individuals representing a W3C Member (or group of <a href="#MemberRelated">related
+          Members</a>).</p>
      <h3>3.2 <a id="GeneralMeetings">Meetings</a></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>) <span class="rfc2119">SHOULD</span> observe the meeting
        requirements in this section.</p>
      <p>W3C distinguishes two types of meetings:</p>
      <ol>
        <li>A <a id="ftf-meeting">face-to-face meeting</a> is one where most of
          the attendees are expected to participate in the same physical
          location.</li>
        <li>A <a id="distributed-meeting">distributed meeting</a> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">SHOULD</span> 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>3.3 <a id="Consensus">Consensus</a></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 <span class="rfc2119">MAY</span> 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><a id="def-Consensus">Consensus</a>: 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. <a id="def-Unanimity">Unanimity</a>
          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><a id="def-Dissent">Dissent</a>: 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 in <a href="#good-standing">Good
+          Standing</a>. 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 <span class="rfc2119">MAY</span>
        include a quorum requirement for consensus decisions.</p>
      <p>Where unanimity is not possible, a group <span class="rfc2119">SHOULD</span>
        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 <span class="rfc2119">SHOULD</span>
        set minimum thresholds of active support before a decision can be
        recorded. The appropriate percentage <span class="rfc2119">MAY</span>
        vary depending on the size of the group and the nature of the decision.
        A charter <span class="rfc2119">MAY</span> 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>3.3.1 <a id="managing-dissent">Managing Dissent</a></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 <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">SHOULD</span> move on.</p>
      <p>Groups <span class="rfc2119">SHOULD</span> 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>3.3.2 <a id="WGArchiveMinorityViews">Recording and Reporting Formal
          Objections</a></h4>
      <p>In the W3C process, an individual may register a Formal Objection to a
        decision. A <a id="FormalObjection">Formal Objection</a> 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 <span class="rfc2119">SHOULD</span>
        cite technical arguments and propose changes that would remove the
        Formal Objection; these proposals <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MUST</span> be
        <a href="#confidentiality-change">publicly available</a>. A Call for
        Review (of a document) to the Advisory Committee <span class="rfc2119">MUST</span>
        identify any Formal Objections.</p>
      <h4>3.3.3 <a id="formal-address">Formally Addressing an Issue</a></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 <span class="rfc2119">SHOULD</span>
        seek clarification before reaching a decision.</p>
      <p>As a courtesy, both Chairs and reviewers <span class="rfc2119">SHOULD</span>
        set expectations for the schedule of responses and acknowledgments. The
        group <span class="rfc2119">SHOULD</span> reply to a reviewer's initial
        comments in a timely manner. The group <span class="rfc2119">SHOULD</span>
        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 <span class="rfc2119">SHOULD</span> realize that
        their comments will carry less weight if not sent to the group in a
        timely manner.</p>
      <p>Substantive responses <span class="rfc2119">SHOULD</span> be recorded.
        The group <span class="rfc2119">SHOULD</span> 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>3.3.4 <a id="WGChairReopen">Reopening a Decision When Presented With
          New Information</a></h4>
      <p>The Chair <span class="rfc2119">MAY</span> 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 <span class="rfc2119">SHOULD</span> record that a decision
        has been reopened, and <span class="rfc2119">MUST</span> do so upon
        request from a group participant.</p>
      <h3>3.4 <a id="Votes">Votes</a></h3>
      <p>A group <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">MUST</span>
        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 <span class="rfc2119">MUST</span>
        be a group <a href="#participant">participant</a> in <a href="#good-standing">Good
+          Standing</a>. Each organization represented in the group <span class="rfc2119">MUST</span>
        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> <span class="rfc2119">MAY</span> vote.</p>
      <p>If a participant is unable to attend a vote, that individual <span class="rfc2119">MAY</span>
        authorize anyone at the meeting to act as a <a id="proxy">proxy</a>.
        The absent participant <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">NOT
          REQUIRED</span> to state the reasons for their dissent, and the group
        is <span class="rfc2119">NOT REQUIRED</span> to record individual
        votes.</p>
      <p>A group charter <span class="rfc2119">SHOULD</span> 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>3.5 <a id="WGAppeals">Appeal of a Chair's Decision</a></h3>
      <p>Groups resolve issues through dialog. Individuals who disagree strongly
        with a decision <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">MAY</span> 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 <span class="rfc2119">SHOULD</span>
        also make their requests known to the <a href="#TeamContact">Team
          Contact</a>. The Team Contact <span class="rfc2119">MUST</span>
        inform the Director when a group participant has raised concerns about
        due process.</p>
      <p>Any requests to the Director to confirm a decision <span class="rfc2119">MUST</span>
        include a summary of the issue (whether technical or procedural),
        decision, and rationale for the objection. All counter-arguments,
        rationales, and decisions <span class="rfc2119">MUST</span> be
        recorded.</p>
      <p>Procedures for <a href="#ACAppeal">Advisory Committee appeals</a> are
        described separately.</p>
      <h3>3.6 <a id="resignation">Resignation from a Group</a></h3>
      <p>A W3C Member or Invited Expert <span class="rfc2119">MAY</span> 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>4 <a id="dissemination">Dissemination Policies</a></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 <span
-            class="rfc2119">SHOULD</span> 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>4.1 <a id="confidentiality-levels">Confidentiality Levels</a></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, <a id="Member-only">"Member-only"
-            information</a> 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><a id="Team-only">"Team-only" information</a> is available to the
-          Team and other authorized parties.</p>
-        <p>Those authorized to access Member-only and Team-only information:</p>
-        <ul>
-          <li><span class="rfc2119">MUST</span> treat the information as
-            confidential within W3C,</li>
-          <li><span class="rfc2119">MUST</span> use reasonable efforts to
-            maintain the proper level confidentiality, and</li>
-          <li><span class="rfc2119">MUST NOT</span> release this information to
-            the general public or press.</li>
-        </ul>
-        <p>The Team <span class="rfc2119">MUST</span> provide mechanisms to
-          protect the confidentiality of Member-only information and ensure that
-          authorized parties have proper access to this information. Documents <span
-            class="rfc2119">SHOULD</span> clearly indicate whether they require
-          Member-only confidentiality. Individuals uncertain of the
-          confidentiality level of a piece of information <span class="rfc2119">SHOULD</span>
-          contact the Team.</p>
-        <p>Advisory Committee representatives <span class="rfc2119">MAY</span>
-          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>4.1.1 <a id="confidentiality-change">Changing Confidentiality Level</a></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 <span class="rfc2119">MAY</span> need to
-          communicate Team-only information to a Working Group or the public.
-          Similarly, a Working Group whose proceedings are Member-only <span class="rfc2119">MUST</span>
-          make public information pertinent to the technical report development
-          process.</p>
-        <p>This document clearly indicates which information <span class="rfc2119">MUST</span>
-          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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">SHOULD</span> remind
-            recipients to provide such alternatives.</li>
-          <li>The Team <span class="rfc2119">MUST NOT</span> 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 <span class="rfc2119">MAY</span>
-            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>6 <a id="GAGeneral">Working Groups, Interest Groups, and
-            Coordination Groups</a></h2>
-        <p><a id="GAGroups">This document defines three types of groups:</a></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 <a href="#good-standing">Good
-              Standing</a> requirements for Working Group participation as well
-            as 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>
-          <li><a href="#GroupsCG">Coordination Groups.</a> A Coordination Group
-            manages dependencies and facilitates communication with other
-            groups, within or outside of W3C.</li>
-        </ol>
-        <p>Neither Interest Groups nor Coordination Groups publish <a href="#RecsW3C">Recommendation
-            Track technical reports</a>; see information about <a href="#WGNote">maturity
-            levels for Interest Groups and Coordination Groups</a>.</p>
-        <h3>6.1 <a id="ReqsAllGroups">Requirements for All Working, Interest,
-            and Coordination Groups</a></h3>
-        <p>Each group <span class="rfc2119">MUST</span> have a charter.
-          Requirements for the charter depend on the group type. All group
-          charters <span class="rfc2119">MUST</span> be public (even if other
-          proceedings of the group are <a href="#Member-only">Member-only</a>).
-          Existing charters that are not yet public <span class="rfc2119">MUST</span>
-          be made public when next revised or extended (with attention to <a href="#confidentiality-change">changing
-            confidentiality level</a>).</p>
-        <p>Each group <span class="rfc2119">MUST</span> have a <a id="GeneralChairs">Chair</a>
-          (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
+          Policy</a> [<a href="#ref-patentpolicy">PUB33</a>] for information
        about obligations remaining after resignation from certain groups.</p>
      <section id="chapterDissemination">
        <h2>4 <a id="dissemination">Dissemination Policies</a></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 <span
            class="rfc2119">SHOULD</span>
          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>4.1 <a id="confidentiality-levels">Confidentiality Levels</a></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, <a id="Member-only">"Member-only"
+            information</a> 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><a id="Team-only">"Team-only" information</a> is available to the
          Team and other authorized parties.</p>
        <p>Those authorized to access Member-only and Team-only information:</p>
        <ul>
          <li><span class="rfc2119">MUST</span> treat the information as
            confidential within W3C,</li>
          <li><span class="rfc2119">MUST</span> use reasonable efforts to
            maintain the proper level confidentiality, and</li>
          <li><span class="rfc2119">MUST NOT</span> release this information to
            the general public or press.</li>
        </ul>
        <p>The Team <span class="rfc2119">MUST</span> provide mechanisms to
          protect the confidentiality of Member-only information and ensure that
          authorized parties have proper access to this information. Documents <span
            class="rfc2119">SHOULD</span>
          clearly indicate whether they require Member-only confidentiality.
          Individuals uncertain of the confidentiality level of a piece of
          information <span class="rfc2119">SHOULD</span> contact the Team.</p>
        <p>Advisory Committee representatives <span class="rfc2119">MAY</span>
          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>4.1.1 <a id="confidentiality-change">Changing Confidentiality Level</a></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 <span class="rfc2119">MAY</span> need to
          communicate Team-only information to a Working Group or the public.
          Similarly, a Working Group whose proceedings are Member-only <span class="rfc2119">MUST</span>
          make public information pertinent to the technical report development
          process.</p>
        <p>This document clearly indicates which information <span class="rfc2119">MUST</span>
          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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">SHOULD</span> remind
            recipients to provide such alternatives.</li>
          <li>The Team <span class="rfc2119">MUST NOT</span> 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 <span class="rfc2119">MAY</span>
            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>6 <a id="GAGeneral">Working Groups and Interest Groups</a></h2>
        <p><a id="GAGroups">This document defines three types of groups:</a></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 <a href="#good-standing">Good
+              Standing</a> requirements for Working Group participation as well
            as 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>6.1 <a id="ReqsAllGroups">Requirements for All Working and Interest
            Groups</a></h3>
        <p>Each group <span class="rfc2119">MUST</span> have a charter.
          Requirements for the charter depend on the group type. All group
          charters <span class="rfc2119">MUST</span> be public (even if other
          proceedings of the group are <a href="#Member-only">Member-only</a>).
          Existing charters that are not yet public <span class="rfc2119">MUST</span>
          be made public when next revised or extended (with attention to <a href="#confidentiality-change">changing
+            confidentiality level</a>).</p>
        <p>Each group <span class="rfc2119">MUST</span> have a <a id="GeneralChairs">Chair</a>
          (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 <span class="rfc2119">MUST</span> have a <a id="TeamContact">Team
-            Contact</a>, 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 <span class="rfc2119">SHOULD NOT</span>
-          be the same individual.</p>
-        <p>Each group <span class="rfc2119">MUST</span> 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
+            guide</a> [<a href="#ref-guide">MEM9</a>].</p>
        <p>Each group <span class="rfc2119">MUST</span> have a <a id="TeamContact">Team
+            Contact</a>, 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 <span class="rfc2119">SHOULD NOT</span>
          be the same individual.</p>
        <p>Each group <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> form task forces (composed
-          of group participants) to carry out assignments for the group. The
-          scope of these assignments <span class="rfc2119">MUST NOT</span>
-          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 <span class="rfc2119">MAY</span>
-          choose to publish their results as part of a technical report.</p>
-        <h3>6.2 <a id="GroupsWG">Working Groups</a> and <a id="GroupsIG">Interest
-            Groups</a></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 <a id="group-participation">Working Group and Interest Group
-            Participation Requirements</a></h4>
-        <p>There are three types of individual <a id="wgparticipant">participants
-            in a Working Group</a>: <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 <a id="igparticipant">participants
-            in an Interest Group</a>: the same three types as for Working Groups
-          plus, for an Interest Group where the only <a href="#ig-mail-only">participation
+            lists</a> [<a href="#ref-mailing-lists">MEM2</a>].</p>
        <p>A Chair <span class="rfc2119">MAY</span> form task forces (composed
          of group participants) to carry out assignments for the group. The
          scope of these assignments <span class="rfc2119">MUST NOT</span>
          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 <span class="rfc2119">MAY</span>
          choose to publish their results as part of a technical report.</p>
        <h3>6.2 <a id="GroupsWG">Working Groups</a> and <a id="GroupsIG">Interest
+            Groups</a></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 <a id="group-participation">Working Group and Interest Group
            Participation Requirements</a></h4>
        <p>There are three types of individual <a id="wgparticipant">participants
+            in a Working Group</a>: <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 <a id="igparticipant">participants
+            in an Interest Group</a>: 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>, <a id="public-participant-ig">public
-            participants</a>.</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 <span class="rfc2119">MUST</span> represent at most
-          one organization in a Working Group or Interest Group.</p>
-        <p>An individual <span class="rfc2119">MAY</span> 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
+            participants</a>.</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 <span class="rfc2119">MUST</span> represent at most
          one organization in a Working Group or Interest Group.</p>
        <p>An individual <span class="rfc2119">MAY</span> 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 <span
-            class="rfc2119">MAY</span> designate a <a id="mtg-substitute">substitute</a>
-          to attend a <a href="#GeneralMeetings">meeting</a> and <span class="rfc2119">SHOULD</span>
-          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 <span class="rfc2119">MUST</span>
-          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 <span class="rfc2119">SHOULD</span> authorize
-          another participant to act as <a href="#proxy">proxy</a> for votes.
-          For the purposes of <a href="#good-standing">Good Standing</a>, the
-          regular representative and the substitute are considered the same
-          participant.</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 <span class="rfc2119">MAY</span> 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
+            Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
        <p>On an exceptional basis, a Working or Interest Group participant <span
            class="rfc2119">MAY</span>
          designate a <a id="mtg-substitute">substitute</a> to attend a <a href="#GeneralMeetings">meeting</a>
          and <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">MUST</span>
          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 <span class="rfc2119">SHOULD</span> authorize
          another participant to act as <a href="#proxy">proxy</a> for votes.
          For the purposes of <a href="#good-standing">Good Standing</a>, the
          regular representative and the substitute are considered the same
          participant.</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 <span class="rfc2119">MAY</span> 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 <a id="member-rep-wg">Member Representative</a> 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><a id="member-rep-info">To designate an individual as a Member
-            representative in a Working Group</a>, an Advisory Committee
-          representative <span class="rfc2119">MUST</span> 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 <a id="member-rep-ig">Member Representative</a> in an
-          Interest Group</h5>
-        <p>When the participation requirements exceed <a href="#ig-mail-only">Interest
+            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 <a id="member-rep-wg">Member Representative</a> 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><a id="member-rep-info">To designate an individual as a Member
            representative in a Working Group</a>, an Advisory Committee
          representative <span class="rfc2119">MUST</span> 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 <a id="member-rep-ig">Member Representative</a> 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 <span class="rfc2119">MUST</span>
-          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 <a id="invited-expert-wg">Invited Expert</a> in a Working
-          Group</h5>
-        <p>The Chair <span class="rfc2119">MAY</span> invite an individual with
-          a particular expertise to participate in a Working Group. This
-          individual <span class="rfc2119">MAY</span> 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
+            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 <span class="rfc2119">MUST</span>
          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 <a id="invited-expert-wg">Invited Expert</a> in a Working
          Group</h5>
        <p>The Chair <span class="rfc2119">MAY</span> invite an individual with
          a particular expertise to participate in a Working Group. This
          individual <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MUST</span> 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><a id="inv-expert-info">To be able to participate in a Working Group
-            as an Invited Expert</a>, an individual <span class="rfc2119">MUST</span>
-          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
+              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 <span class="rfc2119">MUST</span> 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><a id="inv-expert-info">To be able to participate in a Working Group
            as an Invited Expert</a>, an individual <span class="rfc2119">MUST</span>
          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 <span class="rfc2119">SHOULD NOT</span> designate as an
-          Invited Expert in a Working Group an individual who is an employee of
-          a W3C Member. The Chair <span class="rfc2119">MUST NOT</span> 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 <a id="invited-expert-ig">Invited Expert</a> in an Interest
-          Group</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 <a id="team-rep-wg">Team Representative in a Working Group</a></h5>
-        <p>An individual is a Team representative in a Working Group when so
-          designated by W3C management.</p>
-        <p>An 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 <a id="team-rep-ig">Team Representative in an Interest
-            Group</a></h5>
-        <p>When the participation requirements exceed <a href="#ig-mail-only">Interest
+              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 <span class="rfc2119">SHOULD NOT</span> designate as an
          Invited Expert in a Working Group an individual who is an employee of
          a W3C Member. The Chair <span class="rfc2119">MUST NOT</span> 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 <a id="invited-expert-ig">Invited Expert</a> 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 Team
-          representative in an Interest Group when so designated by W3C
-          management.</p>
-        <h4>6.2.2 <a id="WGCharterDevelopment">Working Group and Interest Group
-            Charter Development</a></h4>
-        <p>W3C creates a charter based on interest from the Members and Team.
-          The Team <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span>
-          express their general support on the <a href="#ACCommunication">Advisory
-            Committee discussion list</a>.</p>
-        <p>W3C <span class="rfc2119">MAY</span> begin work on a Working Group
-          or Interest Group charter at any time.</p>
-        <h4>6.2.3 <a id="CharterReview">Advisory Committee Review</a> of a
-          Working Group or Interest Group Charter</h4>
-        <p>The Director <span class="rfc2119">MUST</span> solicit <a href="#ReviewAppeal">Advisory
-            Committee review</a> of every new or substantively modified Working
-          Group or Interest Group charter. The Director is <span class="rfc2119">NOT
-            REQUIRED</span> 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 <span
-            class="rfc2119">MUST</span> highlight important changes (e.g.,
-          regarding deliverables or resource allocation) and include rationale
-          for the changes.</p>
-        <h4>6.2.4 <a id="cfp">Call for Participation in a Working Group or
-            Interest Group</a></h4>
-        <p>After Advisory Committee review of a Working Group or Interest Group
-          charter, the Director <span class="rfc2119">MAY</span> issue a Call
-          for Participation to the Advisory Committee. Charters <span class="rfc2119">MAY</span>
-          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 <span class="rfc2119">MUST</span> 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> <span class="rfc2119">MUST</span> be designated (or
-          re-designated).</p>
-        <p>Advisory Committee representatives <span class="rfc2119">MAY</span>
-          <a href="#ACAppeal">appeal</a> creation or substantive modification of
-          a Working Group or Interest Group charter.&nbsp;</p>
-        <h4>6.2.5 <a id="charter-extension">Working Group and Interest Group
-            Charter Extension</a></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 <span class="rfc2119">MUST</span>
-          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 <span class="rfc2119">NOT REQUIRED</span> to re-designate <a
-            href="#member-rep">Member representatives</a> and <a href="#invited-expert-wg">Invited
-            Experts</a>.</p>
-        <p>Advisory Committee representatives <span class="rfc2119">MAY</span>
-          <a href="#ACAppeal">appeal</a> the extension of a Working Group or
-          Interest Group charter.&nbsp;</p>
-        <h4>6.2.6 <a id="WGCharter">Working Group and Interest Group Charters</a></h4>
-        <p>A Working Group or Interest Group charter <span class="rfc2119">MUST</span>
-          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 <span class="rfc2119">NOT REQUIRED</span> 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 <span class="rfc2119">MUST</span>
-            specify when required deliverables are expected from the other
-            groups. The charter <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">SHOULD</span>
-            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 <span class="rfc2119">MUST NOT</span> be sooner than
-            <span class="time-interval">eight weeks</span> after the date of the
-            proposal.&nbsp;</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>]?&nbsp;</li>
-        </ul>
-        <p>See also the charter requirements of <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Licensing">section
+            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 <a id="team-rep-wg">Team Representative in a Working Group</a></h5>
        <p>An individual is a Team representative in a Working Group when so
          designated by W3C management.</p>
        <p>An 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 <a id="team-rep-ig">Team Representative in an Interest
            Group</a></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 <a id="WGCharterDevelopment">Working Group and Interest Group
            Charter Development</a></h4>
        <p>W3C creates a charter based on interest from the Members and Team.
          The Team <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span>
          express their general support on the <a href="#ACCommunication">Advisory
+            Committee discussion list</a>.</p>
        <p>W3C <span class="rfc2119">MAY</span> begin work on a Working Group
          or Interest Group charter at any time.</p>
        <h4>6.2.3 <a id="CharterReview">Advisory Committee Review</a> of a
          Working Group or Interest Group Charter</h4>
        <p>The Director <span class="rfc2119">MUST</span> solicit <a href="#ReviewAppeal">Advisory
+            Committee review</a> of every new or substantively modified Working
          Group or Interest Group charter. The Director is <span class="rfc2119">NOT
+            REQUIRED</span> 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 <span
            class="rfc2119">MUST</span>
          highlight important changes (e.g., regarding deliverables or resource
          allocation) and include rationale for the changes.</p>
        <h4>6.2.4 <a id="cfp">Call for Participation in a Working Group or
            Interest Group</a></h4>
        <p>After Advisory Committee review of a Working Group or Interest Group
          charter, the Director <span class="rfc2119">MAY</span> issue a Call
          for Participation to the Advisory Committee. Charters <span class="rfc2119">MAY</span>
          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 <span class="rfc2119">MUST</span> 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> <span class="rfc2119">MUST</span> be designated (or
          re-designated).</p>
        <p>Advisory Committee representatives <span class="rfc2119">MAY</span>
          <a href="#ACAppeal">appeal</a> creation or substantive modification of
          a Working Group or Interest Group charter.&nbsp;</p>
        <h4>6.2.5 <a id="charter-extension">Working Group and Interest Group
            Charter Extension</a></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 <span class="rfc2119">MUST</span>
          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 <span class="rfc2119">NOT REQUIRED</span> to re-designate <a
            href="#member-rep">Member
+            representatives</a> and <a href="#invited-expert-wg">Invited
            Experts</a>.</p>
        <p>Advisory Committee representatives <span class="rfc2119">MAY</span>
          <a href="#ACAppeal">appeal</a> the extension of a Working Group or
          Interest Group charter.&nbsp;</p>
        <h4>6.2.6 <a id="WGCharter">Working Group and Interest Group Charters</a></h4>
        <p>A Working Group or Interest Group charter <span class="rfc2119">MUST</span>
          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 <span class="rfc2119">NOT REQUIRED</span> 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 <span class="rfc2119">MUST</span>
            specify when required deliverables are expected from the other
            groups. The charter <span class="rfc2119">SHOULD</span> 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 <span class="rfc2119">SHOULD</span>
            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 <span class="rfc2119">MUST NOT</span> be sooner than
            <span class="time-interval">eight weeks</span> after the date of the
            proposal.&nbsp;</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>]?&nbsp;</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 <span class="rfc2119">MAY</span>
-          include provisions regarding participation, including specifying that
-          the <a id="ig-mail-only">only requirement for participation (by
-            anyone) in the Interest Group</a> is subscription to the Interest
-          Group mailing list. This type of Interest Group <span class="rfc2119">MAY</span>
-          have <a href="#public-participant-ig">public participants</a>.</p>
-        <p>A charter <span class="rfc2119">MAY</span> include additional voting
-          procedures, but those procedures <span class="rfc2119">MUST NOT</span>
-          conflict with the <a href="#Votes">voting requirements</a> of the
-          Process Document.</p>
-        <p>A charter <span class="rfc2119">MAY</span> include provisions other
-          than those required by this document. The charter <span class="rfc2119">SHOULD</span>
-          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 <a id="GeneralTermination">Working Group and Interest Group
-            Closure</a></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, <span class="rfc2119">MAY</span>
-          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>
-        <h3>6.3 <a id="GroupsCG">Coordination Groups&nbsp;<span class="issue">
-            </span></a><a href="https://www.w3.org/community/w3process/track/issues/129">ISSUE-129</a>
-          proposes to remove the separate definition of Coordination Groups.</h3>
-        <p>W3C activities interact in many ways. There are dependencies between
-          groups within the same area, in different areas, and between W3C
-          activities and the activities of other organizations. Examples of
-          dependencies include the use by one technology of another being
-          developed elsewhere, scheduling constraints between groups, and the
-          synchronization of publicity for the announcement of deliverables.
-          Coordination Groups are created to manage dependencies so that issues
-          are resolved fairly and the solutions are consistent with W3C's
-          mission and results.</p>
-        <p>Where a Coordination Group's scope covers two groups with unresolved
-          disputes or tensions, it is the first locus of resolution of these
-          disputes.</p>
-        <h4>6.3.1 <a id="CGParticipation">Coordination Group Participation
-            Requirements</a></h4>
-        <p>There are four types <a id="cgparticipant">participants in a
-            Coordination Group</a>: the <a href="#GeneralChairs">Chair</a>, the
-          Chair of each coordinated group (to promote effective communication
-          among the groups), Invited Experts (e.g., liaisons to groups inside or
-          outside W3C), and Team representatives (including the <a href="#TeamContact">Team
-            Contact</a>). The requirements for Invited Expert participation are
-          the same as for an <a href="#invited-expert-wg">Invited Expert in a
-            Working Group</a>.</p>
-        <p>Coordination Group participants <span class="rfc2119">MUST</span>
-          follow the <a href="#coi">conflict of interest policy</a> by
-          disclosing information to the rest of the group.</p>
-        <p>There are no Good Standing requirements for Coordination Group
-          participation; regular participation in a relevant Coordination Group
-          is one of the <a href="/Guide/chair-roles">roles of a group Chair
-            [MEM14]</a>.</p>
-        <h4>6.3.2 <a id="CGCreation">Coordination Group Creation and Closure</a></h4>
-        <p>The Director creates or modifies a Coordination Group by sending the
-          <a href="#CGCharter">Coordination Group charter</a> to the Advisory
-          Committee.&nbsp;</p>
-        <p>A Coordination Group <span class="rfc2119">SHOULD</span> close when
-          there is no longer a perceived need for coordination.</p>
-        <h4>6.3.3 <a id="CGCharter">Coordination Group Charters</a></h4>
-        <p>A Coordination Group charter <span class="rfc2119">MUST</span>
-          include all of the following information:</p>
-        <ul>
-          <li>The group's mission;</li>
-          <li>The scope of the group's work, including the names of coordinated
-            groups and contact information for those groups;</li>
-          <li>Any dependencies by groups within or outside of W3C on this group;</li>
-          <li>Any dependencies of this group on other groups within or outside
-            of W3C; see the section on <a href="#Liaisons">liaisons with other
-              organizations</a>.</li>
-          <li>The <a href="#confidentiality-levels">level of confidentiality</a>
-            of the group's proceedings;</li>
-          <li>Meeting mechanisms and expected frequency;</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 level of involvement by the Team.</li>
-        </ul>
-        <p>A charter <span class="rfc2119">MAY</span> include additional voting
-          procedures, but those procedures <span class="rfc2119">MUST NOT</span>
-          conflict with the <a href="#Votes">voting requirements</a> of the
-          Process Document.</p>
-        <p>A charter <span class="rfc2119">MAY</span> include provisions other
-          than those required by this document. The charter <span class="rfc2119">SHOULD</span>
-          highlight whether additional provisions impose constraints beyond
-          those of the W3C Process Document.</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&nbsp; implementation experience to
-        demonstrate that the specification works in practice. The next phase is
-        a Proposed Recommendation, to finalize the review of W3C Members. If the
-        Director determines that W3C member review supports a specification
-        becoming a standard, W3C publishes it as a Recommendation.</p>
-      <p>Groups may also publish documents as W3C Notes, typically either to
-        document information other than technical specifications, such as use
-        cases motivating a specification and best practices for its use, or to
-        clarify the status of work that is abandoned. </p>
-      <p>Some W3C Notes are developed through successive Working Drafts, with an
-        expectation that they will become Notes, while others are simply
-        published. There are few formal requirements to publish a document as a
-        W3C Note, and they have no standing as a recommendation of W3C but are
-        simply documents preserved for historical reference.</p>
-      <p>Individual Working Groups and Interest Groups may adopt additional
-        processes for developing publications, so long as they do not conflict
-        with the requirements in this chapter.</p>
-      <h4 id="recs-and-notes">7.1.1 Recommendations and Notes</h4>
-      <p>W3C follows these steps when advancing a technical report to
-        Recommendation.</p>
-      <ol>
-        <li>Publication of the <a href="#first-wd">First Public Working Draft</a>,</li>
-        <li>Publication of zero or more revised <a href="#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 <span class="rfc2119">must</span> not be made to
-          a Proposed Recommendation except by publishing a new Working Draft or
-          Candidate Recommendation.</dd>
-        <dt id="RecsW3C">W3C Recommendation (REC)</dt>
-        <dd>A W3C Recommendation is a specification or set of guidelines or
-          requirements that, after extensive consensus-building, has received
-          the endorsement of W3C Members and the Director. W3C recommends the
-          wide deployment of its Recommendations as standards for the Web. The
-          W3C Royalty-Free IPR licenses granted under the Patent Policy apply to
-          W3C Recommendations.</dd>
-        <dt id="WGNote">Working Group Note, Interest Group Note (NOTE) </dt>
-        <dd>A Working Group Note or Interest Group Note is published by a
-          chartered Working Group or Interest Group to provide a stable
-          reference for a useful document that is not intended to be a formal
-          standard, or to document work that was abandoned without producing a
-          Recommendation.</dd>
-        <dt id="RescindedRec">Rescinded Recommendation</dt>
-        <dd>A Rescinded Recommendation is an entire Recommendation that W3C no
-          longer endorses. See also clause 10 of the licensing requirements for
-          W3C Recommendations in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Requirements">section
+            Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
        <p id="ig-charter-participation">An Interest Group charter <span class="rfc2119">MAY</span>
          include provisions regarding participation, including specifying that
          the <a id="ig-mail-only">only requirement for participation (by
            anyone) in the Interest Group</a> is subscription to the Interest
          Group mailing list. This type of Interest Group <span class="rfc2119">MAY</span>
          have <a href="#public-participant-ig">public participants</a>.</p>
        <p>A charter <span class="rfc2119">MAY</span> include additional voting
          procedures, but those procedures <span class="rfc2119">MUST NOT</span>
          conflict with the <a href="#Votes">voting requirements</a> of the
          Process Document.</p>
        <p>A charter <span class="rfc2119">MAY</span> include provisions other
          than those required by this document. The charter <span class="rfc2119">SHOULD</span>
          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 <a id="GeneralTermination">Working Group and Interest Group
            Closure</a></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, <span class="rfc2119">MAY</span>
          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&nbsp; implementation experience to
        demonstrate that the specification works in practice. The next phase is
        a Proposed Recommendation, to finalize the review of W3C Members. If the
        Director determines that W3C member review supports a specification
        becoming a standard, W3C publishes it as a Recommendation.</p>
      <p>Groups may also publish documents as W3C Notes, typically either to
        document information other than technical specifications, such as use
        cases motivating a specification and best practices for its use, or to
        clarify the status of work that is abandoned. </p>
      <p>Some W3C Notes are developed through successive Working Drafts, with an
        expectation that they will become Notes, while others are simply
        published. There are few formal requirements to publish a document as a
        W3C Note, and they have no standing as a recommendation of W3C but are
        simply documents preserved for historical reference.</p>
      <p>Individual Working Groups and Interest Groups may adopt additional
        processes for developing publications, so long as they do not conflict
        with the requirements in this chapter.</p>
      <h4 id="recs-and-notes">7.1.1 Recommendations and Notes</h4>
      <p>W3C follows these steps when advancing a technical report to
        Recommendation.</p>
      <ol>
        <li>Publication of the <a href="#first-wd">First Public Working Draft</a>,</li>
        <li>Publication of zero or more revised <a href="#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 <span class="rfc2119">must</span> not be made to
          a Proposed Recommendation except by publishing a new Working Draft or
          Candidate Recommendation.</dd>
        <dt id="RecsW3C">W3C Recommendation (REC)</dt>
        <dd>A W3C Recommendation is a specification or set of guidelines or
          requirements that, after extensive consensus-building, has received
          the endorsement of W3C Members and the Director. W3C recommends the
          wide deployment of its Recommendations as standards for the Web. The
          W3C Royalty-Free IPR licenses granted under the Patent Policy apply to
          W3C Recommendations.</dd>
        <dt id="WGNote">Working Group Note, Interest Group Note (NOTE) </dt>
        <dd>A Working Group Note or Interest Group Note is published by a
          chartered Working Group or Interest Group to provide a stable
          reference for a useful document that is not intended to be a formal
          standard, or to document work that was abandoned without producing a
          Recommendation.</dd>
        <dt id="RescindedRec">Rescinded Recommendation</dt>
        <dd>A Rescinded Recommendation is an entire Recommendation that W3C no
          longer endorses. See also clause 10 of the licensing requirements for
          W3C Recommendations in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Requirements">section
             5</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
-            Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</dd>
-      </dl>
-      <p>Working Groups and Interest Groups <em class="rfc2119">may</em> make
-        available "Editor's drafts". Editor's drafts have no official standing
-        whatsoever, and do not necessarily imply consensus of a Working Group or
-        Interest Group, nor are their contents endorsed in any way by W3C.</p>
-      <h3 id="requirements-and-definitions">7.2 General requirements and
-        definitions</h3>
-      <p>Please note that <dfn>publishing</dfn> as used in this document refers
-        to producing a version which is listed as a W3C Technical Report on its
-        <a href="http://www.w3.org/TR/">Technical Reports page
-          http://www.w3.org/TR</a>.</p>
-      <h4 id="general-requirements">7.2.1 General requirements for Technical
-        Reports</h4>
-      <p>Every document published as part of the technical report development
-        process <em class="rfc2119 old">must</em> be a public document. The <a
-          href="http://www.w3.org/TR/">index of W3C technical reports</a> [<a href="#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> (e.g., for <a id="DocumentName">naming</a>, status
-        information, style, and <a id="document-copyright">copyright
-          requirements</a>). These rules are subject to change by the Team from
-        time to time. The Team <em class="rfc2119">must</em> inform group
-        Chairs and the Advisory Committee of any changes to these rules.</p>
-      <p>The primary language for W3C Technical Reports is English. W3C
-        encourages the translation of its Technical Reports. <a href="http://www.w3.org/Consortium/Translation/">Information
-          about translations of W3C technical reports</a> [<a href="#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><span class="rfc2119">should</span> provide public documentation of
-          changes that are not substantive.</li>
-        <li><em class="rfc2119">should</em> report which, if any, of the Working
-          Group's requirements for this document have changed since the previous
-          step.</li>
-        <li><em class="rfc2119">should</em> report any changes in dependencies
-          with other groups.</li>
-        <li><em class="rfc2119">should</em> provide information about
-          implementations known to the Working Group.</li>
-      </ul>
-      <p>For a First Public Working Draft there is no "previous maturity level",
-        so many requirements do not apply, and approval is normally fairly
-        automatic. For later stages, especially transition to Candidate or
-        Proposed Recommendation, there is generally a formal review meeting to
-        ensure the requirements have been met before Director's approval is
-        given.</p>
-      <h4 id="doc-reviews">7.2.3 Reviews and Review Responsibilities</h4>
-      <p>A document is available for review from the moment it is first
-        published. Working Groups <em class="rfc2119">should</em> <a href="#formal-address">formally
-          address</a> <em>any</em> substantive review comment about a technical
-        report in a timely manner. </p>
-      Reviewers <em class="rfc2119">should</em> send substantive technical
-      reviews as early as possible. Working Groups are often reluctant to make <a
-        href="#substantive-change">substantive changes</a> to a mature document,
-      particularly if this would cause significant compatibility problems due to
-      existing implementation. Working Groups <em class="rfc2119">should</em>
-      record substantive or interesting proposals raised by reviews but not
-      incorporated into a current specification.
-      <h5>7.2.3.1 <a id="wide-review">Wide Review</a></h5>
-      <p>The requirements for <dfn>wide review</dfn> are not precisely defined
-        by the W3C Process. The objective is to ensure that the entire set of
-        stakeholders of the Web community, including the general public, have
-        had adequate notice of the progress of the Working Group (for example
-        through notices posted to <a href="mailto:[email protected]">[email protected]</a>)
-        and thereby an opportunity to comment on the specification. Before
-        approving transitions, the Director will consider who has been
-        explicitly offered a reasonable opportunity to review the document, who
-        has provided comments, the record of requests to and responses from
-        reviewers, especially groups identified as dependencies in the charter,
-        and seek evidence of clear communication to the general public about
-        appropriate times and which content to review. </p>
-      <p>For example, inviting review of new or significantly revised sections
-        published in Working Drafts, and tracking those comments and the Working
-        Group's responses, is generally a good practice which would often be
-        considered positive evidence of wide review. Working Groups <span class="rfc2119">should</span>
-        announce to other W3C Working Groups as well as the general public,
-        especially those affected by this specification, a proposal to enter
-        Candidate Recommendation (for example in approximately four weeks). By
-        contrast a generic statement in a document requesting review at any time
-        is likely not to be considered as sufficient evidence that the group has
-        solicited wide review. </p>
-      <p>A Working Group could present evidence that wide review has been
-        received, irrespective of solicitation. But it is important to note that
-        receiving many detailed reviews is not necessarily the same as wide
-        review, since they may only represent comment from a small segment of
-        the relevant stakeholder community.</p>
-      <h4 id="implementation-experience">7.2.4 Implementation Experience</h4>
-      <p>Implementation experience is required to show that a specification is
-        sufficiently clear, complete, and relevant to market needs, to ensure
-        that independent interoperable implementations of each feature of the
-        specification will be realized. While no exhaustive list of requirements
-        is provided here, when assessing that there is <dfn>adequate
-          implementation experience</dfn> the Director will consider (though not
-        be limited to):</p>
-      <ul>
-        <li>is each feature of the current specification implemented, and how is
-          this demonstrated?</li>
-        <li>are there independent interoperable implementations of the current
-          specification?</li>
-        <li>are there implementations created by people other than the authors
-          of the specification?</li>
-        <li>are implementations publicly deployed?</li>
-        <li>is there implementation experience at all levels of the
-          specification's ecosystem (authoring, consuming, publishing…)?</li>
-        <li>are there reports of difficulties or problems with implementation?</li>
-      </ul>
-      <p>Planning and accomplishing a demonstration of (interoperable)
-        implementations can be very time consuming. Groups are often able to
-        work more effectively if they plan how they will demonstrate
-        interoperable implementations early in the development process; for
-        example, they may wish to develop tests in concert with implementation
-        efforts.</p>
-      <h4 id="correction-classes">7.2.5 Classes of Changes</h4>
-      <p>This document distinguishes the following 4 classes of changes to a
-        specification. The first two classes of change are considered <dfn id="editorial-change">editorial
+            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>.</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> (e.g., for <a id="DocumentName">naming</a>, status
        information, style, and <a id="document-copyright">copyright
          requirements</a>). These rules are subject to change by the Team from
        time to time. The Team <em class="rfc2119">must</em> inform group
        Chairs and the Advisory Committee of any changes to these rules.</p>
      <p>The primary language for W3C Technical Reports is English. W3C
        encourages the translation of its Technical Reports. <a href="http://www.w3.org/Consortium/Translation/">Information
+          about translations of W3C technical reports</a> [<a href="#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><span class="rfc2119">should</span> provide public documentation of
          changes that are not substantive.</li>
        <li><em class="rfc2119">should</em> report which, if any, of the Working
          Group's requirements for this document have changed since the previous
          step.</li>
        <li><em class="rfc2119">should</em> report any changes in dependencies
          with other groups.</li>
        <li><em class="rfc2119">should</em> provide information about
          implementations known to the Working Group.</li>
      </ul>
      <p>For a First Public Working Draft there is no "previous maturity level",
        so many requirements do not apply, and approval is normally fairly
        automatic. For later stages, especially transition to Candidate or
        Proposed Recommendation, there is generally a formal review meeting to
        ensure the requirements have been met before Director's approval is
        given.</p>
      <h4 id="doc-reviews">7.2.3 Reviews and Review Responsibilities</h4>
      <p>A document is available for review from the moment it is first
        published. Working Groups <em class="rfc2119">should</em> <a href="#formal-address">formally
+          address</a> <em>any</em> substantive review comment about a technical
        report in a timely manner. </p>
      Reviewers <em class="rfc2119">should</em> send substantive technical
      reviews as early as possible. Working Groups are often reluctant to make <a
        href="#substantive-change">substantive
+        changes</a> to a mature document, particularly if this would cause
      significant compatibility problems due to existing implementation. Working
      Groups <em class="rfc2119">should</em> record substantive or interesting
      proposals raised by reviews but not incorporated into a current
      specification.
      <h5>7.2.3.1 <a id="wide-review">Wide Review</a></h5>
      <p>The requirements for <dfn>wide review</dfn> are not precisely defined
        by the W3C Process. The objective is to ensure that the entire set of
        stakeholders of the Web community, including the general public, have
        had adequate notice of the progress of the Working Group (for example
        through notices posted to <a href="mailto:[email protected]">[email protected]</a>)
        and thereby an opportunity to comment on the specification. Before
        approving transitions, the Director will consider who has been
        explicitly offered a reasonable opportunity to review the document, who
        has provided comments, the record of requests to and responses from
        reviewers, especially groups identified as dependencies in the charter,
        and seek evidence of clear communication to the general public about
        appropriate times and which content to review. </p>
      <p>For example, inviting review of new or significantly revised sections
        published in Working Drafts, and tracking those comments and the Working
        Group's responses, is generally a good practice which would often be
        considered positive evidence of wide review. Working Groups <span class="rfc2119">should</span>
        announce to other W3C Working Groups as well as the general public,
        especially those affected by this specification, a proposal to enter
        Candidate Recommendation (for example in approximately four weeks). By
        contrast a generic statement in a document requesting review at any time
        is likely not to be considered as sufficient evidence that the group has
        solicited wide review. </p>
      <p>A Working Group could present evidence that wide review has been
        received, irrespective of solicitation. But it is important to note that
        receiving many detailed reviews is not necessarily the same as wide
        review, since they may only represent comment from a small segment of
        the relevant stakeholder community.</p>
      <h4 id="implementation-experience">7.2.4 Implementation Experience</h4>
      <p>Implementation experience is required to show that a specification is
        sufficiently clear, complete, and relevant to market needs, to ensure
        that independent interoperable implementations of each feature of the
        specification will be realized. While no exhaustive list of requirements
        is provided here, when assessing that there is <dfn>adequate
          implementation experience</dfn> the Director will consider (though not
        be limited to):</p>
      <ul>
        <li>is each feature of the current specification implemented, and how is
          this demonstrated?</li>
        <li>are there independent interoperable implementations of the current
          specification?</li>
        <li>are there implementations created by people other than the authors
          of the specification?</li>
        <li>are implementations publicly deployed?</li>
        <li>is there implementation experience at all levels of the
          specification's ecosystem (authoring, consuming, publishing…)?</li>
        <li>are there reports of difficulties or problems with implementation?</li>
      </ul>
      <p>Planning and accomplishing a demonstration of (interoperable)
        implementations can be very time consuming. Groups are often able to
        work more effectively if they plan how they will demonstrate
        interoperable implementations early in the development process; for
        example, they may wish to develop tests in concert with implementation
        efforts.</p>
      <h4 id="correction-classes">7.2.5 Classes of Changes</h4>
      <p>This document distinguishes the following 4 classes of changes to a
        specification. The first two classes of change are considered <dfn id="editorial-change">editorial
           changes</dfn>, the latter two <dfn id="substantive-change">substantive
-          changes</dfn>.</p>
-      <dl>
-        <dt>1. No changes to text content</dt>
-        <dd>These changes include fixing broken links, style sheets or invalid
-          markup.</dd>
-        <dt>2. Corrections that do not affect conformance</dt>
-        <dd>Editorial changes or clarifications that do not change the technical
-          content of the specification.</dd>
-        <dt>3. Corrections that do not add new features</dt>
-        <dd>These changes <span class="rfc2119">may</span> affect conformance
-          to the specification. A change that affects conformance is one that:
-          <ul>
-            <li>makes conforming data, processors, or other conforming agents
-              become non-conforming according to the new version, or</li>
-            <li>makes non-conforming data, processors, or other agents become
-              conforming, or</li>
-            <li>clears up an ambiguity or under-specified part of the
-              specification in such a way that data, a processor, or an agent
-              whose conformance was once unclear becomes clearly either
-              conforming or non-conforming.</li>
-          </ul>
-        </dd>
-        <dt>4. New features</dt>
-        <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> [TR] for review, and for simple historical
-        reference. For all Public Working Drafts a Working Group</p>
-      <ul>
-        <li> <em class="rfc2119">should</em> document outstanding issues, and
-          parts of the document on which the Working Group does not have
-          consensus, and</li>
-        <li> <em class="rfc2119">may</em> request publication of a Working
-          Draft even if its content is considered unstable and does not meet all
-          Working Group requirements.</li>
-      </ul>
-      <h4 id="first-wd">7.3.1 First Public Working Draft</h4>
-      <p>To publish the First Public Working Draft of a document, a Working
-        Group must meet the applicable <a href="#transition-reqs">general
-          requirements for advancement</a>.</p>
-      <p>The Director <em class="rfc2119">must</em> announce the publication of
-        a First Public Working Draft publication to other W3C groups and to the
-        public. </p>
-      <p>Publishing the First Public Working Draft triggers a Call for
-        Exclusions, per <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
-          4</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
-          Patent Policy</a> [<a href="#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>&nbsp;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 <span class="rfc2119">must</span> 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
+          changes</dfn>.</p>
      <dl>
        <dt>1. No changes to text content</dt>
        <dd>These changes include fixing broken links, style sheets or invalid
          markup.</dd>
        <dt>2. Corrections that do not affect conformance</dt>
        <dd>Editorial changes or clarifications that do not change the technical
          content of the specification.</dd>
        <dt>3. Corrections that do not add new features</dt>
        <dd>These changes <span class="rfc2119">may</span> affect conformance
          to the specification. A change that affects conformance is one that:
          <ul>
            <li>makes conforming data, processors, or other conforming agents
              become non-conforming according to the new version, or</li>
            <li>makes non-conforming data, processors, or other agents become
              conforming, or</li>
            <li>clears up an ambiguity or under-specified part of the
              specification in such a way that data, a processor, or an agent
              whose conformance was once unclear becomes clearly either
              conforming or non-conforming.</li>
          </ul>
        </dd>
        <dt>4. New features</dt>
        <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> [TR] for review, and for simple historical
        reference. For all Public Working Drafts a Working Group</p>
      <ul>
        <li> <em class="rfc2119">should</em> document outstanding issues, and
          parts of the document on which the Working Group does not have
          consensus, and</li>
        <li> <em class="rfc2119">may</em> request publication of a Working
          Draft even if its content is considered unstable and does not meet all
          Working Group requirements.</li>
      </ul>
      <h4 id="first-wd">7.3.1 First Public Working Draft</h4>
      <p>To publish the First Public Working Draft of a document, a Working
        Group must meet the applicable <a href="#transition-reqs">general
          requirements for advancement</a>.</p>
      <p>The Director <em class="rfc2119">must</em> announce the publication of
        a First Public Working Draft publication to other W3C groups and to the
        public. </p>
      <p>Publishing the First Public Working Draft triggers a Call for
        Exclusions, per <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion">section
+          4</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
          Patent Policy</a> [<a href="#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>&nbsp;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 <span class="rfc2119">must</span> 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 <span class="rfc2119">must not</span>
-        include any substantive changes from the Proposed Recommendation it is
-        based on, to make any substantive change to a Proposed Recommendation
-        the Working Group <span class="rfc2119">must</span> return the
-        specification to Candidate Recommendation or Working Draft.</p>
-      <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)
+            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 <span class="rfc2119">must not</span>
        include any substantive changes from the Proposed Recommendation it is
        based on, to make any substantive change to a Proposed Recommendation
        the Working Group <span class="rfc2119">must</span> return the
        specification to Candidate Recommendation or Working Draft.</p>
      <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 class of mistake, from mere editorial to a
-        serious error that may affect the conformance with the Recommendation by
-        software or content (e.g., content validity).</p>
-      <p>Working Groups <em class="rfc2119">must</em> track errata on an
-        "errata page." An errata page is a list of enumerated errors, possibly
-        accompanied by corrections. Each Recommendation links to an errata page;
-        see the Team's <a href="http://www.w3.org/Guide/pubrules">Publication
-          Rules</a>.</p>
-      <p>A correction is first "proposed" by the Working Group. A correction
-        becomes part of the Recommendation by the process for Revising a
-        Recommendation described in the next section.</p>
-      <p>A Working Group <em class="rfc2119">should</em> keep their errata
-        pages up-to-date, as errors are reported by readers and implementers. A
-        Working Group <em class="rfc2119">must</em> report errata page changes
-        to interested parties, notably when corrections are proposed or
-        incorporated into an Edited Recommendation, according to the Team's
-        requirements.</p>
-      <h4 id="revised-rec">7.7.2 Revising a Recommendation</h4>
-      <p>A Working group <em class="rfc2119">may</em> request republication of
-        a Recommendation, or W3C <em class="rfc2119">may</em> republish a
-        Recommendation, to make corrections that do not result in any changes to
-        the text of the specification.</p>
-      <p><a href="#editorial-change">Editorial changes</a> to a Recommendation
-        require no technical review of the proposed changes. A Working Group <span
-          class="rfc2119">may</span> request publication of a <a href="#rec-pr">Proposed
-          Recommendation</a>&nbsp; or W3C <span class="rfc2119">may</span>
-        publish a <a href="#rec-pr">Proposed Recommendation</a> to make this
-        class of change without passing through earlier maturity levels. Such
-        publications are <em class="rfc2119">may</em> be called a <dfn>Proposed
-          Edited Recommendation</dfn>.</p>
-      <p>To make corrections to a Recommendation that produce <a href="#substantive-change">substantive
-          changes</a> but do not add new features, a Working Group <span class="rfc2119">may</span>
-        request publication of a <a href="#last-call">Candidate Recommendation</a>,
-        without passing through earlier maturity levels.</p>
-      <p>In the latter two cases, the resulting Recommendation <em class="rfc2119">may</em>
-        be called an <dfn 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 <span class="rfc2119">must</span>
-        follow the full process of <a href="#rec-advance">advancing a technical
-          report to Recommendation</a> beginning with a new First Public Working
-        Draft.</p>
-      <h3 id="Note">7.8 Publishing a Working Group or Interest Group Note</h3>
-      <p>Working Groups and Interest Groups publish material that is not a
-        formal specification as Notes. This includes supporting documentation
-        for a specification such as explanations of design principles or use
-        cases and requirements, non-normative guides to good practices, as well
-        as specifications where work has been stopped and there is no longer
-        consensus for making them a new standard.</p>
-      <p>In order to publish a Note, a Working Group or Interest Group: </p>
-      <ul>
-        <li> <em class="rfc2119">may</em> publish a Note with or without its
-          prior publication as a Working Draft.</li>
-        <li><em class="rfc2119">must</em> record the group's decision to request
-          publication as a Note, and</li>
-        <li><em class="rfc2119">should</em> publish documentation of significant
-          changes to the technical report since any previous publication.</li>
-      </ul>
-      <p>Possible next steps:</p>
-      <ul>
-        <li>End state: A technical report <em class="rfc2119">may</em> remain a
-          Working Group Note indefinitely</li>
-        <li>A Working Group <em class="rfc2119">may</em> resume work on
-          technical report within the scope of its charter at any time, at the
-          maturity level the specification had before publication as a Note</li>
-      </ul>
-      <p>The <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent
-          Policy</a> [<a href="#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
+            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 class of mistake, from mere editorial to a
        serious error that may affect the conformance with the Recommendation by
        software or content (e.g., content validity).</p>
      <p>Working Groups <em class="rfc2119">must</em> track errata on an
        "errata page." An errata page is a list of enumerated errors, possibly
        accompanied by corrections. Each Recommendation links to an errata page;
        see the Team's <a href="http://www.w3.org/Guide/pubrules">Publication
          Rules</a>.</p>
      <p>A correction is first "proposed" by the Working Group. A correction
        becomes part of the Recommendation by the process for Revising a
        Recommendation described in the next section.</p>
      <p>A Working Group <em class="rfc2119">should</em> keep their errata
        pages up-to-date, as errors are reported by readers and implementers. A
        Working Group <em class="rfc2119">must</em> report errata page changes
        to interested parties, notably when corrections are proposed or
        incorporated into an Edited Recommendation, according to the Team's
        requirements.</p>
      <h4 id="revised-rec">7.7.2 Revising a Recommendation</h4>
      <p>A Working group <em class="rfc2119">may</em> request republication of
        a Recommendation, or W3C <em class="rfc2119">may</em> republish a
        Recommendation, to make corrections that do not result in any changes to
        the text of the specification.</p>
      <p><a href="#editorial-change">Editorial changes</a> to a Recommendation
        require no technical review of the proposed changes. A Working Group <span
          class="rfc2119">may</span>
        request publication of a <a href="#rec-pr">Proposed Recommendation</a>&nbsp;
+        or W3C <span class="rfc2119">may</span> publish a <a href="#rec-pr">Proposed
+          Recommendation</a> to make this class of change without passing
        through earlier maturity levels. Such publications are <em class="rfc2119">may</em>
        be called a <dfn>Proposed Edited Recommendation</dfn>.</p>
      <p>To make corrections to a Recommendation that produce <a href="#substantive-change">substantive
+          changes</a> but do not add new features, a Working Group <span class="rfc2119">may</span>
        request publication of a <a href="#last-call">Candidate Recommendation</a>,
        without passing through earlier maturity levels.</p>
      <p>In the latter two cases, the resulting Recommendation <em class="rfc2119">may</em>
        be called an <dfn 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 <span class="rfc2119">must</span>
        follow the full process of <a href="#rec-advance">advancing a technical
          report to Recommendation</a> beginning with a new First Public Working
        Draft.</p>
      <h3 id="Note">7.8 Publishing a Working Group or Interest Group Note</h3>
      <p>Working Groups and Interest Groups publish material that is not a
        formal specification as Notes. This includes supporting documentation
        for a specification such as explanations of design principles or use
        cases and requirements, non-normative guides to good practices, as well
        as specifications where work has been stopped and there is no longer
        consensus for making them a new standard.</p>
      <p>In order to publish a Note, a Working Group or Interest Group: </p>
      <ul>
        <li> <em class="rfc2119">may</em> publish a Note with or without its
          prior publication as a Working Draft.</li>
        <li><em class="rfc2119">must</em> record the group's decision to request
          publication as a Note, and</li>
        <li><em class="rfc2119">should</em> publish documentation of significant
          changes to the technical report since any previous publication.</li>
      </ul>
      <p>Possible next steps:</p>
      <ul>
        <li>End state: A technical report <em class="rfc2119">may</em> remain a
          Working Group Note indefinitely</li>
        <li>A Working Group <em class="rfc2119">may</em> resume work on
          technical report within the scope of its charter at any time, at the
          maturity level the specification had before publication as a Note</li>
      </ul>
      <p>The <a href="http://www.w3.org/Consortium/Patent-Policy">W3C Patent
          Policy</a> [<a href="#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>8 <a id="ReviewAppeal">Advisory Committee Reviews, Appeals, and Votes</a></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 <a id="def-w3c-decision">W3C
-          decision</a> 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
+          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>8 <a id="ReviewAppeal">Advisory Committee Reviews, Appeals, and Votes</a></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 <a id="def-w3c-decision">W3C
          decision</a> 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>8.1 <a id="ACReview">Advisory Committee Reviews</a></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
+          Document</a> review.</p>
      <h3>8.1 <a id="ACReview">Advisory Committee Reviews</a></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>8.1.1 <a id="ACReviewStart">Start of a Review Period</a></h4>
-      <p>Each Advisory Committee review period begins with a Call for Review
-        from the Team to the Advisory Committee. The <a id="reviewform">review
-          form</a> describes the proposal, raises attention to deadlines,
-        estimates when the decision will be available, and includes other
-        practical information. Each Member organization <span class="rfc2119">MAY</span>
-        send one review, which <span class="rfc2119">MUST</span> be returned by
-        its Advisory Committee representative.</p>
-      <p>The Team <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> send information to either
-        or both channels. They <span class="rfc2119">MAY</span> also share
-        their reviews with other Members on the <a href="#ACCommunication">Advisory
-          Committee discussion list</a>.</p>
-      <p>A Member organization <span class="rfc2119">MAY</span> modify its
-        review during a review period (e.g., in light of comments from other
-        Members).</p>
-      <h4>8.1.2 <a id="ACReviewAfter">After the Review Period</a></h4>
-      <p>After the review period, the Director <span class="rfc2119">MUST</span>
-        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 <span class="rfc2119">MUST</span> 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 <span
-            class="rfc2119">MUST</span> 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 <span class="rfc2119">SHOULD NOT</span> 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 <span class="rfc2119">SHOULD</span>
-        provide the Advisory Committee with an update.</p>
-      <h3>8.2 <a id="ACAppeal">Appeal by Advisory Committee Representatives</a></h3>
-      <p>Advisory Committee representatives <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">MAY</span>
-        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
+            to Rescind a Recommendation</a>, and</li>
        <li><a href="#GAProcess">Proposed changes to the W3C process</a>.</li>
      </ul>
      <h4>8.1.1 <a id="ACReviewStart">Start of a Review Period</a></h4>
      <p>Each Advisory Committee review period begins with a Call for Review
        from the Team to the Advisory Committee. The <a id="reviewform">review
          form</a> describes the proposal, raises attention to deadlines,
        estimates when the decision will be available, and includes other
        practical information. Each Member organization <span class="rfc2119">MAY</span>
        send one review, which <span class="rfc2119">MUST</span> be returned by
        its Advisory Committee representative.</p>
      <p>The Team <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> send information to either
        or both channels. They <span class="rfc2119">MAY</span> also share
        their reviews with other Members on the <a href="#ACCommunication">Advisory
+          Committee discussion list</a>.</p>
      <p>A Member organization <span class="rfc2119">MAY</span> modify its
        review during a review period (e.g., in light of comments from other
        Members).</p>
      <h4>8.1.2 <a id="ACReviewAfter">After the Review Period</a></h4>
      <p>After the review period, the Director <span class="rfc2119">MUST</span>
        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 <span class="rfc2119">MUST</span> 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 <span
            class="rfc2119">MUST</span>
          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 <span class="rfc2119">SHOULD NOT</span> 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
        <span class="rfc2119">SHOULD</span> provide the Advisory Committee with
        an update.</p>
      <h3>8.2 <a id="ACAppeal">Appeal by Advisory Committee Representatives</a></h3>
      <p>Advisory Committee representatives <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span>
-        announce the appeal process to the Advisory Committee and provide an
-        address for comments from Advisory Committee representatives. The
-        archive of these comments <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> organize
-        an appeal vote asking the Advisory Committee to approve or reject the
-        decision.
-        <!-- Voting procedure to be determined --></p>
-      <h3>8.3 <a id="ACVotes">Advisory Committee Votes</a></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
+            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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span>
        announce the appeal process to the Advisory Committee and provide an
        address for comments from Advisory Committee representatives. The
        archive of these comments <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> organize
        an appeal vote asking the Advisory Committee to approve or reject the
        decision.
        <!-- Voting procedure to be determined --></p>
      <h3>8.3 <a id="ACVotes">Advisory Committee Votes</a></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>9 <a id="GAEvents">Workshops and Symposia</a></h2>
-      <p>The Team organizes <a id="EventsW">Workshops</a> and <a id="EventsS">Symposia</a>
-        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 <span class="rfc2119">MAY</span> solicit
-        position papers for the Workshop program and <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">MAY</span>
-        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
-        <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> 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 <a id="EventsC">conferences</a>.
-        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>10 <a id="Liaisons">Liaisons</a></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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> negotiate and sign a
-        <a id="mou">Memorandum of Understanding (<abbr>MoU</abbr>)</a> with
-        another organization. Before signing the MoU, the Team <span class="rfc2119">MUST</span>
-        inform the Advisory Committee of the intent to sign and make the MoU
-        available for Advisory Committee review; the Advisory Committee <span class="rfc2119">MAY</span>
-        <a href="#ACAppeal">appeal</a>. Once approved, a Memorandum of
-        Understanding <span class="rfc2119">SHOULD</span> 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>11 <a id="Submission">Member Submission Process</a></h2>
-      <p>The Member Submission process allows Members to propose technology or
-        other ideas for consideration by the Team. After review, the Team <span
-          class="rfc2119">MAY</span> 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 <a id="MemberSubmission">Member Submission</a> 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)") <span class="rfc2119">MAY</span>
-        participate in a Member Submission. Only W3C Members <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">MUST</span>
-          either acknowledge or reject the Submission request.
-          <ul>
-            <li>If <a href="#SubmissionYes">acknowledged</a>, the Team <span class="rfc2119">MUST</span>
-              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) <span
-                class="rfc2119">MAY</span> 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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST
-          NOT</span> 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>11.1 <a id="SubmissionRights">Submitter Rights and Obligations</a></h3>
-      <p>When more than one Member jointly participates in a Submission request,
-        only one Member formally sends in the request. That Member <span class="rfc2119">MUST</span>
-        copy each of the Advisory Committee representatives of the other
-        participating Members, and each of those Advisory Committee
-        representatives <span class="rfc2119">MUST</span> confirm (by email to
-        the Team) their participation in the Submission request.</p>
-      <p>At any time prior to acknowledgment, any Submitter <span class="rfc2119">MAY</span>
-        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 <span class="rfc2119">MUST
-          NOT</span> make statements about withdrawn Submission requests.</p>
-      <p>Prior to acknowledgment, the Submitter(s) <span class="rfc2119">MUST
-          NOT</span>, <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) <span class="rfc2119">MUST NOT</span>
-        imply in public or Member communication that W3C is working (with the
-        Submitter(s)) on the material in the Member Submission. The Submitter(s)
-        <span class="rfc2119">MAY</span> publish the documents in the Member
-        Submission prior to acknowledgment (without reference to the Submission
-        request).</p>
-      <p>After acknowledgment, the Submitter(s) <span class="rfc2119">MUST NOT</span>,
-        <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>11.1.1 <a id="SubmissionScope">Scope of Member Submissions</a></h4>
-      <p>When a technology overlaps in scope with the work of a chartered
-        Working Group, Members <span class="rfc2119">SHOULD</span> <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 <span class="rfc2119">MAY</span> incorporate
-        the contributed technology into its deliverables. If the Working Group
-        does not incorporate the technology, it <span class="rfc2119">SHOULD
-          NOT</span> 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 <span class="rfc2119">SHOULD</span> use the Submission
-        process to build consensus around concrete proposals for new work.</p>
-      <p>Members <span class="rfc2119">SHOULD NOT</span> 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>11.1.2 <a id="SubmissionReqs">Information Required in a Submission
-          Request</a></h4>
-      <p>The Submitter(s) and any other authors of the submitted material <span
-          class="rfc2119">MUST</span> 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) <span class="rfc2119">MAY</span>
-        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
+          Board and TAG elections</a>, "one vote" means "one vote per available
        seat".</p>
      <h2>9 <a id="GAEvents">Workshops and Symposia</a></h2>
      <p>The Team organizes <a id="EventsW">Workshops</a> and <a id="EventsS">Symposia</a>
        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 <span class="rfc2119">MAY</span> solicit
        position papers for the Workshop program and <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">MAY</span>
        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
        <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> 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 <a id="EventsC">conferences</a>.
        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>10 <a id="Liaisons">Liaisons</a></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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> negotiate and sign a
        <a id="mou">Memorandum of Understanding (<abbr>MoU</abbr>)</a> with
        another organization. Before signing the MoU, the Team <span class="rfc2119">MUST</span>
        inform the Advisory Committee of the intent to sign and make the MoU
        available for Advisory Committee review; the Advisory Committee <span class="rfc2119">MAY</span>
        <a href="#ACAppeal">appeal</a>. Once approved, a Memorandum of
        Understanding <span class="rfc2119">SHOULD</span> 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>11 <a id="Submission">Member Submission Process</a></h2>
      <p>The Member Submission process allows Members to propose technology or
        other ideas for consideration by the Team. After review, the Team <span
          class="rfc2119">MAY</span>
        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 <a id="MemberSubmission">Member Submission</a> 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)") <span class="rfc2119">MAY</span>
        participate in a Member Submission. Only W3C Members <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">MUST</span>
          either acknowledge or reject the Submission request.
          <ul>
            <li>If <a href="#SubmissionYes">acknowledged</a>, the Team <span class="rfc2119">MUST</span>
              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) <span
                class="rfc2119">MAY</span>
              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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST
+          NOT</span> 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>11.1 <a id="SubmissionRights">Submitter Rights and Obligations</a></h3>
      <p>When more than one Member jointly participates in a Submission request,
        only one Member formally sends in the request. That Member <span class="rfc2119">MUST</span>
        copy each of the Advisory Committee representatives of the other
        participating Members, and each of those Advisory Committee
        representatives <span class="rfc2119">MUST</span> confirm (by email to
        the Team) their participation in the Submission request.</p>
      <p>At any time prior to acknowledgment, any Submitter <span class="rfc2119">MAY</span>
        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 <span class="rfc2119">MUST
+          NOT</span> make statements about withdrawn Submission requests.</p>
      <p>Prior to acknowledgment, the Submitter(s) <span class="rfc2119">MUST
          NOT</span>, <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) <span class="rfc2119">MUST NOT</span>
        imply in public or Member communication that W3C is working (with the
        Submitter(s)) on the material in the Member Submission. The Submitter(s)
        <span class="rfc2119">MAY</span> publish the documents in the Member
        Submission prior to acknowledgment (without reference to the Submission
        request).</p>
      <p>After acknowledgment, the Submitter(s) <span class="rfc2119">MUST NOT</span>,
        <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>11.1.1 <a id="SubmissionScope">Scope of Member Submissions</a></h4>
      <p>When a technology overlaps in scope with the work of a chartered
        Working Group, Members <span class="rfc2119">SHOULD</span> <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 <span class="rfc2119">MAY</span> incorporate
        the contributed technology into its deliverables. If the Working Group
        does not incorporate the technology, it <span class="rfc2119">SHOULD
          NOT</span> 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 <span class="rfc2119">SHOULD</span> use the Submission
        process to build consensus around concrete proposals for new work.</p>
      <p>Members <span class="rfc2119">SHOULD NOT</span> 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>11.1.2 <a id="SubmissionReqs">Information Required in a Submission
          Request</a></h4>
      <p>The Submitter(s) and any other authors of the submitted material <span
          class="rfc2119">MUST</span>
        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) <span class="rfc2119">MAY</span>
        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) <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> 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>11.2 <a id="TeamSubmissionRights">Team Rights and Obligations</a></h3>
-      <p>Although they are not technical reports, the documents in a Member
-        Submission <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> hold it in the strictest
-        confidentiality. In particular, the Team <span class="rfc2119">MUST NOT</span>
-        comment to the media about the Submission request.</p>
-      <h3>11.3 <a id="SubmissionYes">Acknowledgment of a Submission Request</a></h3>
-      <p>The Director <a href="#SubmissionYes">acknowledges</a> a Submission
-        request by sending an announcement to the Advisory Committee. Though the
-        announcement <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span>:</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) <span class="rfc2119">MUST</span>
-        start the Submission process from the beginning, even just to correct
-        editorial changes.</p>
-      <h3>11.4 <a id="SubmissionNo">Rejection of a Submission Request</a></h3>
-      <p>The Director <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MUST</span>
-        inform the Advisory Committee representative(s) of the Submitter(s). If
-        requested by the Submitter(s), the Team <span class="rfc2119">MUST</span>
-        provide rationale to the Submitter(s) about the rejection. Other than to
-        the Submitter(s), the Team <span class="rfc2119">MUST NOT</span> make
-        statements about why a Submission request was rejected.</p>
-      <p>The Advisory Committee representative(s) of the Submitters(s) <span class="rfc2119">MAY</span>
-        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 <span
-          class="rfc2119">SHOULD</span> 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>12 <a id="GAProcess">Process Evolution</a></h2>
-      <p>The <a id="ProcessDoc">W3C Process Document</a> 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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> <a
-            href="#ACAppeal">appeal</a> the decision.</li>
-      </ol>
-      <p>W3C <span class="rfc2119">MAY</span> 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>13 <a id="references">References</a></h2>
-      <h3>13.1 <a id="public-refs">Public Resources</a></h3>
-      <p>The following public information is available at the <a href="http://www.w3.org/">W3C
-          Web site</a>.</p>
-      <dl>
-        <dt><a id="ref-join-w3c"><b>[PUB5]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/join">How to Join W3C</a></cite></dd>
-        <dt><a id="ref-member-agreement"><b>[PUB6]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
-              Agreement</a></cite></dd>
-        <dt><a id="ref-current-mem"><b>[PUB8]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/Member/List">The list of
-              current W3C Members</a></cite></dd>
-        <dt><a id="ref-activity-list"><b>[PUB9]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/activities">The list of
-              W3C Activities</a></cite></dd>
-        <dt><a id="ref-submission-list"><b>[PUB10]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Submission/">The list of
-              acknowledged Member Submissions</a></cite></dd>
-        <dt><a id="ref-doc-list"><b>[PUB11]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/TR/">The W3C technical reports
-              index</a></cite></dd>
-        <dt><a id="ref-submission-overview"><b>[PUB13]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Submission/1996/Template/">Submission
-              request overview</a></cite></dd>
-        <dt><a id="ref-people"><b>[PUB14]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/People/">The W3C Team</a></cite></dd>
-        <dt><a id="ref-mission"><b>[PUB15]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/">About the World Wide
-              Web Consortium</a></cite></dd>
-        <dt><a id="ref-team-submission-list"><b>[PUB16]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/TeamSubmission/">The list of
-              published Team Submissions</a></cite></dd>
-        <dt><a id="ref-invited-expert"><b>[PUB17]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/Legal/collaborators-agreement">Invited
-              expert and collaborators agreement</a></cite></dd>
-        <dt><a id="ref-doc-license"><b>[PUB18]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C
+          Patent Policy</a> [<a href="#ref-patentpolicy">PUB33</a>].</p>
      <p>The Submitter(s) <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> 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>11.2 <a id="TeamSubmissionRights">Team Rights and Obligations</a></h3>
      <p>Although they are not technical reports, the documents in a Member
        Submission <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span> hold it in the strictest
        confidentiality. In particular, the Team <span class="rfc2119">MUST NOT</span>
        comment to the media about the Submission request.</p>
      <h3>11.3 <a id="SubmissionYes">Acknowledgment of a Submission Request</a></h3>
      <p>The Director <a href="#SubmissionYes">acknowledges</a> a Submission
        request by sending an announcement to the Advisory Committee. Though the
        announcement <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MUST</span>:</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) <span class="rfc2119">MUST</span>
        start the Submission process from the beginning, even just to correct
        editorial changes.</p>
      <h3>11.4 <a id="SubmissionNo">Rejection of a Submission Request</a></h3>
      <p>The Director <span class="rfc2119">MAY</span> 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 <span class="rfc2119">MUST</span>
        inform the Advisory Committee representative(s) of the Submitter(s). If
        requested by the Submitter(s), the Team <span class="rfc2119">MUST</span>
        provide rationale to the Submitter(s) about the rejection. Other than to
        the Submitter(s), the Team <span class="rfc2119">MUST NOT</span> make
        statements about why a Submission request was rejected.</p>
      <p>The Advisory Committee representative(s) of the Submitters(s) <span class="rfc2119">MAY</span>
        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 <span
          class="rfc2119">SHOULD</span>
        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>12 <a id="GAProcess">Process Evolution</a></h2>
      <p>The <a id="ProcessDoc">W3C Process Document</a> 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 <span class="rfc2119">MUST</span> 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 <span class="rfc2119">MAY</span> <a
            href="#ACAppeal">appeal</a>
          the decision.</li>
      </ol>
      <p>W3C <span class="rfc2119">MAY</span> 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>13 <a id="references">References</a></h2>
      <h3>13.1 <a id="public-refs">Public Resources</a></h3>
      <p>The following public information is available at the <a href="http://www.w3.org/">W3C
+          Web site</a>.</p>
      <dl>
        <dt><a id="ref-join-w3c"><b>[PUB5]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/join">How to Join W3C</a></cite></dd>
        <dt><a id="ref-member-agreement"><b>[PUB6]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Agreement/Member-Agreement">Membership
+              Agreement</a></cite></dd>
        <dt><a id="ref-current-mem"><b>[PUB8]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Member/List">The list of
              current W3C Members</a></cite></dd>
        <dt><a id="ref-activity-list"><b>[PUB9]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/activities">The list of
              W3C Activities</a></cite></dd>
        <dt><a id="ref-submission-list"><b>[PUB10]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Submission/">The list of
              acknowledged Member Submissions</a></cite></dd>
        <dt><a id="ref-doc-list"><b>[PUB11]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/TR/">The W3C technical reports
              index</a></cite></dd>
        <dt><a id="ref-submission-overview"><b>[PUB13]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Submission/1996/Template/">Submission
+              request overview</a></cite></dd>
        <dt><a id="ref-people"><b>[PUB14]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/People/">The W3C Team</a></cite></dd>
        <dt><a id="ref-mission"><b>[PUB15]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/">About the World Wide
              Web Consortium</a></cite></dd>
        <dt><a id="ref-team-submission-list"><b>[PUB16]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/TeamSubmission/">The list of
              published Team Submissions</a></cite></dd>
        <dt><a id="ref-invited-expert"><b>[PUB17]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Legal/collaborators-agreement">Invited
+              expert and collaborators agreement</a></cite></dd>
        <dt><a id="ref-doc-license"><b>[PUB18]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Legal/copyright-documents">W3C
 Document
-              License</a></cite></dd>
-        <dt><a id="ref-software-license"><b>[PUB19]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/Legal/copyright-software">W3C
+              License</a></cite></dd>
        <dt><a id="ref-software-license"><b>[PUB19]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Legal/copyright-software">W3C
 Software
-              Notice and License</a></cite></dd>
-        <dt><a id="ref-translations"><b>[PUB20]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/Translation/">Translations
-              of W3C technical reports</a></cite></dd>
-        <dt><a id="ref-pub-mailing-lists"><b>[PUB21]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Mail/">Public W3C mailing lists</a></cite></dd>
-        <dt><a id="ref-coi"><b>[PUB23]</b></a></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><a id="ref-tag-charter"><b>[PUB25]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/2001/07/19-tag">Technical
-              Architecture Group (TAG) Charter</a></cite></dd>
-        <dt><a id="ref-tag-home"><b>[PUB26]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/2001/tag/">The TAG home page</a></cite></dd>
-        <dt><a id="ref-rec-tips"><b>[PUB27]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/2002/05/rec-tips">Tips for Getting
-              to Recommendation Faster</a></cite></dd>
-        <dt><a id="ref-liaison-list"><b>[PUB28]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/2001/11/StdLiaison">W3C liaisons
-              with other organizations</a></cite></dd>
-        <dt><a id="ref-ab-home"><b>[PUB30]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/2002/ab/">The Advisory Board home
-              page</a></cite></dd>
-        <dt><a id="ref-pubrules"><b>[PUB31]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Guide/pubrules">Publication Rules</a></cite></dd>
-        <dt><a id="ref-fellows"><b>[PUB32]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Consortium/Recruitment/Fellows">W3C
-              Fellows Program</a></cite></dd>
-        <dt><a id="ref-patentpolicy"><b>[PUB33]</b></a></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><a id="in-place-tr-mod">[PUB35]</a></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><a id="ref-current-ac"><b>[MEM1]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Member/ACList">Current Advisory
-              Committee representatives</a></cite></dd>
-        <dt><a id="ref-mailing-lists"><b>[MEM2]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Member/Mail/">Group mailing lists</a></cite></dd>
-        <dt><a id="ref-calendar"><b>[MEM3]</b></a></dt>
-        <dd>The <cite><a href="http://www.w3.org/Member/Eventscal">calendar of
-              all scheduled official W3C events</a></cite></dd>
-        <dt><a id="ref-new-member"><b>[MEM4]</b></a></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><a id="ref-ac-meetings"><b>[MEM5]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Member/Meeting/">Advisory Committee
-              meetings</a></cite></dd>
-        <dt><a id="ref-member-web"><b>[MEM6]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/Member/">Member Web site</a></cite></dd>
-        <dt><a id="ref-member-sub"><b>[MEM8]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/2000/09/submission">How to send a
-              Submission request</a></cite></dd>
-        <dt><a id="ref-guide"><b>[MEM9]</b></a></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><a id="ref-discipline-gl"><b>[MEM14]</b></a></dt>
-        <dd><cite><a href="http://www.w3.org/2002/09/discipline">Guidelines for
-              Disciplinary Action</a></cite></dd>
-        <dt><a id="ref-election-howto"><b>[MEM15]</b></a></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>13.3 <a id="other-refs">Other References</a></h3>
-      <dl>
-        <dt><a id="ref-RFC2119"><b>[RFC2119]</b></a></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><a id="ref-RFC2777"><b>[RFC2777]</b></a></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>14 <a id="acks">Acknowledgments</a></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 Caceres (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), Cullen Jennings (Cisco), Jeff Jaffe (W3C), 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>Loosen requirement on multiple employees of one member on TAG -
-          section 2.5.1</li>
-        <li>Replace "W3C Chair" with "CEO"</li>
-        <li>Editorial tweaks to what is requested for review</li>
-      </ul>
-      <h3>Previous Editor's drafts</h3>
-      <ul>
-        <li>Remove section <span id="three-month-rule">6.2.7 "Heartbeat"
-            publishing requirement</span></li>
-      </ul>
-      <h3><span style="color: black;">30 September "AC intermediate review"</span></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="def-Activity">A</a><a id="ActivityStatement">c</a><a
-            id="ActivityDevelopment">t</a><a id="ActivityCreation">i</a><a id="ActivityModification">v</a><a
-            id="ActivityExtension">i</a><a id="ActivityTermination">t</a><a id="ActivityProposal">ies</a>
-          <a id="Activities">f</a>rom the Process (as resolved multiple times
-          since 2007)</li>
-        <li>Remove 6.2.1.7 <a id="good-standing">Good Standing in a Working
-            Group</a></li>
-      </ul>
-    </div>
-  </body>
-</html>
+              Notice and License</a></cite></dd>
        <dt><a id="ref-translations"><b>[PUB20]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Translation/">Translations
+              of W3C technical reports</a></cite></dd>
        <dt><a id="ref-pub-mailing-lists"><b>[PUB21]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Mail/">Public W3C mailing lists</a></cite></dd>
        <dt><a id="ref-coi"><b>[PUB23]</b></a></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><a id="ref-tag-charter"><b>[PUB25]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/2001/07/19-tag">Technical
              Architecture Group (TAG) Charter</a></cite></dd>
        <dt><a id="ref-tag-home"><b>[PUB26]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/2001/tag/">The TAG home page</a></cite></dd>
        <dt><a id="ref-rec-tips"><b>[PUB27]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/2002/05/rec-tips">Tips for Getting
              to Recommendation Faster</a></cite></dd>
        <dt><a id="ref-liaison-list"><b>[PUB28]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/2001/11/StdLiaison">W3C liaisons
              with other organizations</a></cite></dd>
        <dt><a id="ref-ab-home"><b>[PUB30]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/2002/ab/">The Advisory Board home
              page</a></cite></dd>
        <dt><a id="ref-pubrules"><b>[PUB31]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Guide/pubrules">Publication Rules</a></cite></dd>
        <dt><a id="ref-fellows"><b>[PUB32]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Consortium/Recruitment/Fellows">W3C
              Fellows Program</a></cite></dd>
        <dt><a id="ref-patentpolicy"><b>[PUB33]</b></a></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><a id="in-place-tr-mod">[PUB35]</a></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><a id="ref-current-ac"><b>[MEM1]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Member/ACList">Current Advisory
              Committee representatives</a></cite></dd>
        <dt><a id="ref-mailing-lists"><b>[MEM2]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Member/Mail/">Group mailing lists</a></cite></dd>
        <dt><a id="ref-calendar"><b>[MEM3]</b></a></dt>
        <dd>The <cite><a href="http://www.w3.org/Member/Eventscal">calendar of
              all scheduled official W3C events</a></cite></dd>
        <dt><a id="ref-new-member"><b>[MEM4]</b></a></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><a id="ref-ac-meetings"><b>[MEM5]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Member/Meeting/">Advisory Committee
              meetings</a></cite></dd>
        <dt><a id="ref-member-web"><b>[MEM6]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/Member/">Member Web site</a></cite></dd>
        <dt><a id="ref-member-sub"><b>[MEM8]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/2000/09/submission">How to send a
              Submission request</a></cite></dd>
        <dt><a id="ref-guide"><b>[MEM9]</b></a></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><a id="ref-discipline-gl"><b>[MEM14]</b></a></dt>
        <dd><cite><a href="http://www.w3.org/2002/09/discipline">Guidelines for
              Disciplinary Action</a></cite></dd>
        <dt><a id="ref-election-howto"><b>[MEM15]</b></a></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>13.3 <a id="other-refs">Other References</a></h3>
      <dl>
        <dt><a id="ref-RFC2119"><b>[RFC2119]</b></a></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><a id="ref-RFC2777"><b>[RFC2777]</b></a></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>14 <a id="acks">Acknowledgments</a></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 Caceres (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), Cullen Jennings (Cisco), Jeff Jaffe (W3C), 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>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>
      </ul>
      <h3>Previous Editor's drafts</h3>
      <ul>
        <li>Loosen requirement on multiple employees of one member on TAG -
          section 2.5.1</li>
        <li>Replace "W3C Chair" with "CEO"</li>
        <li>Editorial tweaks to what is requested for review</li>
        <li>Remove section <span id="three-month-rule">6.2.7 "Heartbeat"
            publishing requirement</span></li>
      </ul>
      <h3><span style="color: black;">30 September "AC intermediate review"</span></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="def-Activity">A</a><a id="ActivityStatement">c</a><a
            id="ActivityDevelopment">t</a><a
            id="ActivityCreation">i</a><a
            id="ActivityModification">v</a><a
            id="ActivityExtension">i</a><a
            id="ActivityTermination">t</a><a
            id="ActivityProposal">ies</a>
          <a id="Activities">f</a>rom the Process (as resolved multiple times
          since 2007)</li>
        <li>Remove 6.2.1.7 <a id="good-standing">Good Standing in a Working
            Group</a></li>
      </ul>
    </div>
  </body>
</html>
\ No newline at end of file