https://www.w3.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=Roessler
W3C Wiki - User contributions [en]
2024-03-28T16:21:54Z
User contributions
MediaWiki 1.41.0
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=68887
Privacy/TPWG
2013-10-03T17:51:31Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]] and an ongoing list of [[Privacy/TPWG/Editorial corrections|editorial corrections]], collected on the wiki.<br />
<br />
<br />
----<br />
<br />
<div style="float: left; width: 45%; font-size: 22px;"><br />
'''Important links'''<br />
<br />
* [https://www.w3.org/2002/09/wbs/49311/tpwg-poll/ Poll on how best to continue]<br />
* [http://www.w3.org/2011/tracking-protection/1309-plan.html Proposed plan]<br />
* [[Privacy/TPWG/How to|How to (add a change proposal)]]<br />
* [http://www.w3.org/2011/tracking-protection/decision-policy.html Getting to Closed (Calls for Objections)]<br />
</div><br />
<div style="float: left; width: 45%;"><br />
; Important dates<br />
<br />
; by October 6th (extended from Oct 2nd) : All ISSUEs to be considered have been raised; Phase 2 will start for ISSUES-25, -24, -5, -10, and -170 that are sufficiently documented.<br />
; by October 16 : All ISSUEs are properly documented; Phase 2 starts for all issues.<br />
; by October 9th : Respond to the poll on how best to continue<br />
; December 03 : Publication of our next working draft (frozen for review on Nov 22)<br />
</div><br />
<br style="clear: both;"><br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]] [https://www.w3.org/2011/tracking-protection/track/issues/25 ISSUE-25]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]] [http://www.w3.org/2011/tracking-protection/track/issues/24 ISSUE-24]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/170 ISSUE-170]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]] [https://www.w3.org/2011/tracking-protection/track/issues/202 ISSUE-202]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]] [https://www.w3.org/2011/tracking-protection/track/issues/188 ISSUE-188]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/203 ISSUE-203]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]] [https://www.w3.org/2011/tracking-protection/track/issues/204 ISSUE-204] [https://www.w3.org/2011/tracking-protection/track/issues/16 ISSUE-16]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/205 ISSUE-205]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] [https://www.w3.org/2011/tracking-protection/track/issues/134 ISSUE-134]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]] [https://www.w3.org/2011/tracking-protection/track/issues/10 ISSUE-10]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]] [https://www.w3.org/2011/tracking-protection/track/issues/206 ISSUE-206]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]] [https://www.w3.org/2011/tracking-protection/track/issues/207 ISSUE-207]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]] [https://www.w3.org/2011/tracking-protection/track/issues/119 ISSUE-119]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]] [https://www.w3.org/2011/tracking-protection/track/issues/5 ISSUE-5]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]] [https://www.w3.org/2011/tracking-protection/track/issues/208 ISSUE-208]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]] [https://www.w3.org/2011/tracking-protection/track/issues/209 ISSUE-209]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]] [https://www.w3.org/2011/tracking-protection/track/issues/210 ISSUE-210]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]] [https://www.w3.org/2011/tracking-protection/track/issues/199 ISSUE-199]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]] [https://www.w3.org/2011/tracking-protection/track/issues/211 ISSUE-211]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/213 ISSUE-213]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]] [http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Principles_for_Permitted_Uses ISSUE-231]<br />
* [[Privacy/TPWG/Change Proposal DNT 0|Change Proposal DNT: 0]] [https://www.w3.org/2011/tracking-protection/track/issues/148 ISSUE-148]<br />
* [[Privacy/TPWG/Change Proposal Add to Last Working Draft|Change Proposal Add to Last Working Draft]] [https://www.w3.org/2011/tracking-protection/track/issues/214 ISSUE-214]<br />
<br />
== Resolved change proposals ==<br />
<br />
* [[Privacy/TPWG/Change Proposal Data Hygiene Tracking of URL Data|Change Proposal Data Hygiene Tracking of URL Data]] [https://www.w3.org/2011/tracking-protection/track/issues/215 ISSUE-215]<br />
** [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/att-0466/NAI-DAA-DMA_June_26_draft_compared_to_June_22_Tracking_Compliance_and_Scope_copy.pdf DAA proposal]<br />
** [[Privacy/TPWG/Questions re DAA proposal|Questions re DAA proposal]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Principles_for_Permitted_Uses&diff=68886
Privacy/TPWG/Change Proposal Principles for Permitted Uses
2013-10-03T17:50:54Z
<p>Roessler: </p>
<hr />
<div>== Strictly Necessary ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0347.html Proposal from Mayer]; [http://www.w3.org/2011/tracking-protection/track/issues/231 ISSUE-231]<br />
<br />
=== New Text ===<br />
<br />
5.1.2 Data Minimization, Retention and Transparency<br />
<br />
Data retained by a party for permitted uses must be limited to the data strictly necessary for such permitted uses. Such data must not be retained any longer than is proporationate and strictly necessary for such permitted uses.<br />
<br />
Third parties must provide public transparency of the time periods for which data collected for permitted uses are retained. The third party may enumerate different retention periods for different permitted uses. Data must not be used for a permitted use once the data retention period for that permitted use has expired. After there are no remaining permitted uses for given data, the data must be deleted or de-identified.<br />
<br />
Third parties must make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained, and must not rely on unique identifiers for users or devices if alternative solutions are reasonably available.<br />
<br />
Allowed Example: A third-party advertising network uses a minimal set of deidentified data to frequency cap advertisements.<br />
<br />
Disallowed Example: A third-party analytics service generates public reports about aggregate page impressions. It retains full protocol logs for two weeks, even though it has no need for them.<br />
<br />
== Technically feasible ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0388.html Proposal from Colando]<br />
<br />
=== New Text ===<br />
<br />
''End of section 5.1.2:''<br />
<br />
Third parties MUST make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained, and MUST NOT rely on unique identifiers for users or devices if alternative solutions are reasonably available and technically feasible.<br />
<br />
== Internally verifiable ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0388.html Proposal from Colando]<br />
<br />
=== New Text ===<br />
<br />
''End of section 5.1.4:''<br />
<br />
Third parties must use reasonable technical and organizational safeguards to prevent further processing of data retained for permitted uses. While physical separation of data maintained for permitted uses is not required, best practices should be in place to ensure technical controls ensure access limitations and information security. Third parties should ensure that the access and use of data retained for permitted uses is internally verifiable.<br />
<br />
== Editor's Draft ==<br />
<br />
5.1.2 Data Minimization, Retention and Transparency<br />
<br />
Data retained by a party for permitted uses must be limited to the data reasonably necessary for such permitted uses. Such data must not be retained any longer than is proporationate and reasonably necessary for such permitted uses.<br />
<br />
Third parties must provide public transparency of the time periods for which data collected for permitted uses are retained. The third party may enumerate different retention periods for different permitted uses. Data must not be used for a permitted use once the data retention period for that permitted use has expired. After there are no remaining permitted uses for given data, the data must be deleted or de-identified.<br />
<br />
Third parties must make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained, and must not rely on unique identifiers for users or devices if alternative solutions are reasonably available.<br />
<br />
5.1.4 Reasonable Security<br />
<br />
Third parties must use reasonable technical and organizational safeguards to prevent further processing of data retained for permitted uses. While physical separation of data maintained for permitted uses is not required, best practices should be in place to ensure technical controls ensure access limitations and information security. Third parties should ensure that the access and use of data retained for permitted uses is auditable.<br />
<br />
<br />
== New general principle for permitted uses ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jul/0477.html Proposal from Rob van Eijk]<br />
<br />
=== New Text ===<br />
<br />
5.2.5 no matching/syncing between permitted uses<br />
<br />
Data collected or retained by a party for a specific permitted use must not be matched or synced with data from other permitted uses. <br />
<br />
Disallowed Example: cookie syncing between permitted uses.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=68285
Privacy/TPWG
2013-09-11T17:09:16Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]] [https://www.w3.org/2011/tracking-protection/track/issues/25 ISSUE-25]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]] [http://www.w3.org/2011/tracking-protection/track/issues/24 ISSUE-24]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/170 ISSUE-170]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]] [https://www.w3.org/2011/tracking-protection/track/issues/202 ISSUE-202]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]] [https://www.w3.org/2011/tracking-protection/track/issues/188 ISSUE-188]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/203 ISSUE-203]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]] [https://www.w3.org/2011/tracking-protection/track/issues/204 ISSUE-204] [https://www.w3.org/2011/tracking-protection/track/issues/16 ISSUE-16]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/205 ISSUE-205]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] [https://www.w3.org/2011/tracking-protection/track/issues/134 ISSUE-134]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]] [https://www.w3.org/2011/tracking-protection/track/issues/10 ISSUE-10]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]] [https://www.w3.org/2011/tracking-protection/track/issues/206 ISSUE-206]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]] [https://www.w3.org/2011/tracking-protection/track/issues/207 ISSUE-207]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]] [https://www.w3.org/2011/tracking-protection/track/issues/119 ISSUE-119]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]] [https://www.w3.org/2011/tracking-protection/track/issues/5 ISSUE-5]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]] [https://www.w3.org/2011/tracking-protection/track/issues/208 ISSUE-208]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]] [https://www.w3.org/2011/tracking-protection/track/issues/209 ISSUE-209]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]] [https://www.w3.org/2011/tracking-protection/track/issues/210 ISSUE-210]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]] [https://www.w3.org/2011/tracking-protection/track/issues/199 ISSUE-199]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]] [https://www.w3.org/2011/tracking-protection/track/issues/211 ISSUE-211]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/213 ISSUE-213]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]] issue missing?<br />
* [[Privacy/TPWG/Change Proposal DNT 0|Change Proposal DNT: 0]] [https://www.w3.org/2011/tracking-protection/track/issues/148 ISSUE-148]<br />
* [[Privacy/TPWG/Change Proposal Add to Last Working Draft|Change Proposal Add to Last Working Draft]] [https://www.w3.org/2011/tracking-protection/track/issues/214 ISSUE-214]<br />
<br />
== DAA proposal and open questions ==<br />
<br />
* [[Privacy/TPWG/Change Proposal Data Hygiene Tracking of URL Data|Change Proposal Data Hygiene Tracking of URL Data]] [https://www.w3.org/2011/tracking-protection/track/issues/215 ISSUE-215]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/att-0466/NAI-DAA-DMA_June_26_draft_compared_to_June_22_Tracking_Compliance_and_Scope_copy.pdf DAA proposal]<br />
* [[Privacy/TPWG/Questions re DAA proposal|Questions re DAA proposal]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=68284
Privacy/TPWG
2013-09-11T17:07:50Z
<p>Roessler: /* DAA proposal and open questions */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]] [https://www.w3.org/2011/tracking-protection/track/issues/25 ISSUE-25]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]] [http://www.w3.org/2011/tracking-protection/track/issues/24 ISSUE-24]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/170 ISSUE-170]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]] [https://www.w3.org/2011/tracking-protection/track/issues/202 ISSUE-202]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]] [https://www.w3.org/2011/tracking-protection/track/issues/188 ISSUE-188]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/203 ISSUE-203]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]] [https://www.w3.org/2011/tracking-protection/track/issues/204 ISSUE-204] [https://www.w3.org/2011/tracking-protection/track/issues/16 ISSUE-16]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/205 ISSUE-205]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] [https://www.w3.org/2011/tracking-protection/track/issues/134 ISSUE-134]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]] [https://www.w3.org/2011/tracking-protection/track/issues/10 ISSUE-10]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]] [https://www.w3.org/2011/tracking-protection/track/issues/206 ISSUE-206]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]] [https://www.w3.org/2011/tracking-protection/track/issues/207 ISSUE-207]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]] [https://www.w3.org/2011/tracking-protection/track/issues/119 ISSUE-119]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]] [https://www.w3.org/2011/tracking-protection/track/issues/5 ISSUE-5]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]] [https://www.w3.org/2011/tracking-protection/track/issues/208 ISSUE-208]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]] [https://www.w3.org/2011/tracking-protection/track/issues/209 ISSUE-209]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]] [https://www.w3.org/2011/tracking-protection/track/issues/210 ISSUE-210]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]] [https://www.w3.org/2011/tracking-protection/track/issues/199 ISSUE-199]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]] [https://www.w3.org/2011/tracking-protection/track/issues/211 ISSUE-211]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/213 ISSUE-213]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]] <br />
* [[Privacy/TPWG/Change Proposal DNT 0|Change Proposal DNT: 0]] [https://www.w3.org/2011/tracking-protection/track/issues/148 ISSUE-148]<br />
* [[Privacy/TPWG/Change Proposal Add to Last Working Draft|Change Proposal Add to Last Working Draft]] [https://www.w3.org/2011/tracking-protection/track/issues/214 ISSUE-214]<br />
<br />
== DAA proposal and open questions ==<br />
<br />
* [[Privacy/TPWG/Change Proposal Data Hygiene Tracking of URL Data|Change Proposal Data Hygiene Tracking of URL Data]] [https://www.w3.org/2011/tracking-protection/track/issues/215 ISSUE-215]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/att-0466/NAI-DAA-DMA_June_26_draft_compared_to_June_22_Tracking_Compliance_and_Scope_copy.pdf DAA proposal]<br />
* [[Privacy/TPWG/Questions re DAA proposal|Questions re DAA proposal]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=68283
Privacy/TPWG
2013-09-11T17:07:34Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]] [https://www.w3.org/2011/tracking-protection/track/issues/25 ISSUE-25]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]] [http://www.w3.org/2011/tracking-protection/track/issues/24 ISSUE-24]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/170 ISSUE-170]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]] [https://www.w3.org/2011/tracking-protection/track/issues/202 ISSUE-202]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]] [https://www.w3.org/2011/tracking-protection/track/issues/188 ISSUE-188]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/203 ISSUE-203]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]] [https://www.w3.org/2011/tracking-protection/track/issues/204 ISSUE-204] [https://www.w3.org/2011/tracking-protection/track/issues/16 ISSUE-16]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/205 ISSUE-205]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] [https://www.w3.org/2011/tracking-protection/track/issues/134 ISSUE-134]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]] [https://www.w3.org/2011/tracking-protection/track/issues/10 ISSUE-10]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]] [https://www.w3.org/2011/tracking-protection/track/issues/206 ISSUE-206]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]] [https://www.w3.org/2011/tracking-protection/track/issues/207 ISSUE-207]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]] [https://www.w3.org/2011/tracking-protection/track/issues/119 ISSUE-119]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]] [https://www.w3.org/2011/tracking-protection/track/issues/5 ISSUE-5]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]] [https://www.w3.org/2011/tracking-protection/track/issues/208 ISSUE-208]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]] [https://www.w3.org/2011/tracking-protection/track/issues/209 ISSUE-209]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]] [https://www.w3.org/2011/tracking-protection/track/issues/210 ISSUE-210]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]] [https://www.w3.org/2011/tracking-protection/track/issues/199 ISSUE-199]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]] [https://www.w3.org/2011/tracking-protection/track/issues/211 ISSUE-211]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/213 ISSUE-213]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]] <br />
* [[Privacy/TPWG/Change Proposal DNT 0|Change Proposal DNT: 0]] [https://www.w3.org/2011/tracking-protection/track/issues/148 ISSUE-148]<br />
* [[Privacy/TPWG/Change Proposal Add to Last Working Draft|Change Proposal Add to Last Working Draft]] [https://www.w3.org/2011/tracking-protection/track/issues/214 ISSUE-214]<br />
<br />
== DAA proposal and open questions ==<br />
<br />
* [[Privacy/TPWG/Change Proposal Data Hygiene Tracking of URL Data|Change Proposal Data Hygiene Tracking of URL Data]] [[https://www.w3.org/2011/tracking-protection/track/issues/215|ISSUE-215]]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/att-0466/NAI-DAA-DMA_June_26_draft_compared_to_June_22_Tracking_Compliance_and_Scope_copy.pdf DAA proposal]<br />
* [[Privacy/TPWG/Questions re DAA proposal|Questions re DAA proposal]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=68282
Privacy/TPWG
2013-09-11T16:56:39Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]] [https://www.w3.org/2011/tracking-protection/track/issues/25|ISSUE-25]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]] [http://www.w3.org/2011/tracking-protection/track/issues/24|ISSUE-24]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/170|ISSUE-170]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]] [https://www.w3.org/2011/tracking-protection/track/issues/202|ISSUE-202]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]] [https://www.w3.org/2011/tracking-protection/track/issues/188|ISSUE-188]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/203|ISSUE-203]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]] [https://www.w3.org/2011/tracking-protection/track/issues/204|ISSUE-204]] [[https://www.w3.org/2011/tracking-protection/track/issues/16|ISSUE-16]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/205|ISSUE-205]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] [https://www.w3.org/2011/tracking-protection/track/issues/134|ISSUE-134]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]] [https://www.w3.org/2011/tracking-protection/track/issues/10|ISSUE-10]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]] [https://www.w3.org/2011/tracking-protection/track/issues/206|ISSUE-206]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]] [https://www.w3.org/2011/tracking-protection/track/issues/207|ISSUE-207]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]] [https://www.w3.org/2011/tracking-protection/track/issues/119|ISSUE-119]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]] [https://www.w3.org/2011/tracking-protection/track/issues/5|ISSUE-5]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]] [https://www.w3.org/2011/tracking-protection/track/issues/208|ISSUE-208]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]] [https://www.w3.org/2011/tracking-protection/track/issues/209|ISSUE-209]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]] [https://www.w3.org/2011/tracking-protection/track/issues/210|ISSUE-210]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]] [https://www.w3.org/2011/tracking-protection/track/issues/199|ISSUE-199]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]] [https://www.w3.org/2011/tracking-protection/track/issues/211|ISSUE-211]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]] [https://www.w3.org/2011/tracking-protection/track/issues/213|ISSUE-213]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]] <br />
* [[Privacy/TPWG/Change Proposal DNT 0|Change Proposal DNT: 0]] [https://www.w3.org/2011/tracking-protection/track/issues/148|ISSUE-148]<br />
* [[Privacy/TPWG/Change Proposal Add to Last Working Draft|Change Proposal Add to Last Working Draft]] [https://www.w3.org/2011/tracking-protection/track/issues/214|ISSUE-214]<br />
<br />
== DAA proposal and open questions ==<br />
<br />
* [[Privacy/TPWG/Change Proposal Data Hygiene Tracking of URL Data|Change Proposal Data Hygiene Tracking of URL Data]] [[https://www.w3.org/2011/tracking-protection/track/issues/215|ISSUE-215]]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/att-0466/NAI-DAA-DMA_June_26_draft_compared_to_June_22_Tracking_Compliance_and_Scope_copy.pdf DAA proposal]<br />
* [[Privacy/TPWG/Questions re DAA proposal|Questions re DAA proposal]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=68281
Privacy/TPWG
2013-09-11T16:52:48Z
<p>Roessler: </p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]] [[https://www.w3.org/2011/tracking-protection/track/issues/25|ISSUE-25]]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]] [[http://www.w3.org/2011/tracking-protection/track/issues/24|ISSUE-24]]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]] [[https://www.w3.org/2011/tracking-protection/track/issues/170|ISSUE-170]]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]] [[https://www.w3.org/2011/tracking-protection/track/issues/202|ISSUE-202]]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]] [[https://www.w3.org/2011/tracking-protection/track/issues/188|ISSUE-188]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]] [[https://www.w3.org/2011/tracking-protection/track/issues/203|ISSUE-203]]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]] [[https://www.w3.org/2011/tracking-protection/track/issues/204|ISSUE-204]] [[https://www.w3.org/2011/tracking-protection/track/issues/16|ISSUE-16]]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]] [[https://www.w3.org/2011/tracking-protection/track/issues/205|ISSUE-205]]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] [[https://www.w3.org/2011/tracking-protection/track/issues/134|ISSUE-134]]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]] [[https://www.w3.org/2011/tracking-protection/track/issues/10|ISSUE-10]]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]] [[https://www.w3.org/2011/tracking-protection/track/issues/206|ISSUE-206]]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]] [[https://www.w3.org/2011/tracking-protection/track/issues/207|ISSUE-207]]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]] [[https://www.w3.org/2011/tracking-protection/track/issues/119|ISSUE-119]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]] [[https://www.w3.org/2011/tracking-protection/track/issues/5|ISSUE-5]]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]] [[https://www.w3.org/2011/tracking-protection/track/issues/208|ISSUE-208]]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]] [[https://www.w3.org/2011/tracking-protection/track/issues/209|ISSUE-209]]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]] [[https://www.w3.org/2011/tracking-protection/track/issues/210|ISSUE-210]]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]] [[https://www.w3.org/2011/tracking-protection/track/issues/199|ISSUE-199]]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]] [[https://www.w3.org/2011/tracking-protection/track/issues/211|ISSUE-211]]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]] [[https://www.w3.org/2011/tracking-protection/track/issues/213|ISSUE-213]]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]] <br />
* [[Privacy/TPWG/Change Proposal DNT 0|Change Proposal DNT: 0]] [[https://www.w3.org/2011/tracking-protection/track/issues/148|ISSUE-148]] (@@ issue number TBD @@)<br />
* [[Privacy/TPWG/Change Proposal Add to Last Working Draft|Change Proposal Add to Last Working Draft]] [[https://www.w3.org/2011/tracking-protection/track/issues/214|ISSUE-214]]<br />
<br />
== DAA proposal and open questions ==<br />
<br />
* [[Privacy/TPWG/Change Proposal Data Hygiene Tracking of URL Data|Change Proposal Data Hygiene Tracking of URL Data]] [[https://www.w3.org/2011/tracking-protection/track/issues/215|ISSUE-215]]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/att-0466/NAI-DAA-DMA_June_26_draft_compared_to_June_22_Tracking_Compliance_and_Scope_copy.pdf DAA proposal]<br />
* [[Privacy/TPWG/Questions re DAA proposal|Questions re DAA proposal]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Main_Page&diff=68129
Main Page
2013-09-04T12:13:37Z
<p>Roessler: spam!</p>
<hr />
<div>This wiki is for connecting the W3C communities (Web developers, implementers, people who make the W3C specifications).<br />
The [http://www.w3.org/ W3C] has a formal track for making [http://www.w3.org/TR/ standards specifications]. The specs answer a lot of questions, but not all of them. The wiki is used by many communities such as the [[Open Web Platform]] and the [[Semantic Web]]. You might want [[How To Contribute|to contribute to W3C work]]<br />
<br />
Pages here have no formal status but may have [[WikiConsensus]]. Questions & answers here may be misleading, or just plain wrong. Or, they may be useful. You are welcome to add, fix, develop and rearrange topics. <br />
<br />
__NOTOC__<br />
{| cellpadding="5" cellspacing="5" style="width:100%; border:1px solid #ddcef2; margin-bottom:0.5em; vertical-align:top; background-color:#fefede;padding:1em;"<br />
| W3C invites the public to edit this wiki. W3C Membership is not required but you must have an account. Request a [http://www.w3.org/Help/Account/Request/Public Public W3C Account] to get started. Note that you must log in with your account in order to edit the wiki.<br />
|}<br />
<br />
== CSS ==<br />
See [[CSS]].<br />
<br />
== [[Open Web Platform]] ==<br />
* You might be interesting by [[HTML/Training|learning HTML]] or have a reference about [[HTML/Elements|HTML elements]]<br />
* The W3C [[Quality Assurance]] was a dedicated W3C activity from 2001 to 2005. It included work on the [[MarkupValidator|Markup validator]], but also touched upon topics such as [[TrackingIssues|tracking issues]] and [[UriTesting|URI testing]] among others. The W3C maintains a [[IetfW3cLiaison|liaison with IETF]] to coordinate on technologies and specification related to the [[Open Web Platform]]<br />
<br />
==Specifications==<br />
See http://w3.org/TR for current specs. Wrk being done to improve specs in general:<br />
* [[SpecProd]] - an effort to [[restyle]] spec content design.<br />
* [[Spec Advancement]] - proposals for accelerating spec advancement.<br />
<br />
== [[Evolution]] ==<br />
An attempt to round up discussions about extensibility, versioning, naming, identifiers, registries, standards process.<br />
<br />
== [[SocialWeb]] ==<br />
* [[SocialWebHeadlightsTaskForce]]<br />
<br />
== [[SemanticWeb|Semantic Web]] ==<br />
* [[GoodURIs]], [[OpenFormats]], [[HCLSIG BioRDF Subgroup/Tasks/URI Best Practices]]<br />
* [[Semantic Web FAQs]], [[SemanticWebTools]], [[SPARQL]], [[:Category:Grddl]], [[OwlAuthoringTools]]<br />
** Emerging topics: [[LinkedData]], [[RdfAndSql]], [[EmbeddingRDFinHTML]], [[RDFa]]<br />
** RESTful thoughts: [[Semantic Annotations for RESTful Services]], [[WoDo|Web of Data Objects]], [[SemanticInbox]], [[foaf+ssl]]<br />
* [http://esw.w3.org/topic/SweoIG Semantic Web Education and Outreach Interest Group]<br />
* [[Semantic Bioinformatics]]<br />
* [[Semantic Web Job Mart]] - looking for work in the field? Looking for employees?<br />
<br />
== Security and Privacy ==<br />
* [[Security]], starting around March 2006, for discussion on W3C Security-related specifications and enhancements to [[XML-Dsig]]<br />
* Using Web technologies implies traceability, logs, identification, therefore [[Privacy]] is becoming a growing concern from the community and need to be addressed at the technical level. [http://www.profi-fachuebersetzung.de Übersetzungsbüro Düsseldorf] [http://www.proweb365.com Minneapolis Web Design]<br />
<br />
== Identity ==<br />
* [[IdentityBrowser]], a wiki page for notes relating to the [http://www.w3.org/2011/identity-ws/ W3C Identity in the Browser Workshop]<br />
* [[IdentityCharter]], a wiki page for the draft charter which may include Crypto API and Identity API<br />
<br />
== XML ==<br />
* [[SchemaComposition]] and topics related to [[XML Schema]], prompted by the [http://www.w3.org/2005/03/xml-schema-user-cfp W3C Workshop on XML Schema 1.0 User Experiences] [http://goodessays.net/ good essays]<br />
* [[XprocVnext]] for candidate requirements discussion by the XML Processing Model WG<br />
<br />
== W3C Organization ==<br />
* [[MailingLists]], [[InternetRelayChat]], [[JabberChickenEgg]], [[ConnectingAudiences]], [[ScheduledTopicChat]], [[AdvancedDevelopment]], [[StaffBooks]]<br />
* '''Local communities''' See: [[:Category:Gatherings|Category Gatherings]]<br />
<br />
Traditional Wiki starting points:<br />
* [[Special:Recentchanges|RecentChanges]]: see where people are currently working (see also [[MailingLists]])<br />
* [http://www.mediawiki.org/wiki/Help:Contents Help pages]: to get you going<br />
* [[WikiSandBox]]: feel free to change this page and experiment with editing<br />
* [[Special:Search|FindPage]]: search or browse the database in various ways<br />
<br />
We also keep notes [[AboutThisService]], like [[WikiUpgrade]].<br />
<br />
== To be classified ==<br />
stuff to move to [[SemanticWebTools]]:<br />
* '''Semantic Web Tools''' [[SemanticWebTools]], [http://www-sop.inria.fr/acacia/soft/corese/ Corese] (RDF, RDFS, SPARQL), [http://jena.sourceforge.net/ Jena] (RDF, RDFS, OWL), [http://www.bestessays.com Writing services], [http://www.termpaperscorner.com term papers], [http://www.openrdf.org/ Sesame], [http://tap.stanford.edu/ TAP], [http://librdf.org/ Redland], [http://www.1980.hk/javadoc/ hk1980.rdf (interface only)] [http://www.cerebra.com/products/cerebra_it.html Cerebra Server] (RDF, RDFS, OWL) [http://www.ontotext.com/owlim/ OWLIM] (RDF, RDFS, OWL), [http://lsdis.cs.uga.edu/projects/semdis/brahms/ LSDIS_Lab's BRAHMS main-memory RDF/S storage] (NL to RDF, SeRQL) . See the [[SemanticWebTools|separate page]] for a more comprehensive listing<br />
* '''Semantic Web Authoring Tools''' [[IdeaGraph]], [[IsaViz]] (RDF editing GUIs), [[Morla]], [http://www.cerebra.com/products/repos_bench_it.html Cerebra Workbench]<br />
* '''Converters to and from RDF''' [[ConverterToRdf]] [[ConverterFromRdf]]<br />
<br />
another clump, perhaps for RDFApplicationsAndProjects: ''or two separate clumps: [[RDFApplications]], [[RDFProjects]]?''<br />
<br />
* '''Semantic Web Applications''' [[SeedApplications]], [[SemanticWebUseCases]], [[VocabularyMarket]], [[GeoInfo]], [[ServiceDescription]], [[RestaurantRecommendation]], [[RdfThesaurus]], [[MultiLingual]], [[MozillaRdf]], [[DmozRdf]], [[RdfCalendar]], [[ImageDescription]], [[ConceptualApplications]], [[SkosDev]], [http://www.portedeurope.org http://www.portedeurope.org] [http://lsdis.cs.uga.edu/projects/asdoc/ LSDIS_Lab's ActiveSemanticElectronicMedicalRecord deployed and in use at Athens_Heart_Center], [[SPARQL Box]]<br />
* '''Project Incubators''': [[HCLSIG/Terminology/PathRadCorrelation|Path-Rad Correlation]]<br />
* '''Usability and HCI''': [[SemanticWebUsability]] state of the art in HCI/Usability<br />
* '''RDF vocabularies'''<br />
** [[RdfSchema]]<br />
** [[VocabularyMarket]]<br />
** [[Ontology Dowsing]] (or how I exhumed the old topic of ontology discovery);<br />
* '''Design Patterns''': [[PartWhole]], [[InterpretationProperties]], [[DeltaView]], [[RdfSmushing]], [[SemanticWebArchitecture]], , [[SocialMeaning]], [[NaturalLanguageInterfaces]], [[GermanTranslations]], [[TextValues]] and [[RdfCoreXmlLiteral]], [[ConfigurationManagement]], [[LargeTripleStores]] [http://www.profischnell.com Juristische Übersetzung] (and [[RdfStoreBenchmarking]]), [[Contexts]], [[RoleNoun]], [http://esw.w3.org/topic/RDFa RDFa]<br />
* '''FAQs''' , [[:Category:Faq]], [http://planetrdf.com/guide/ Dave Beckett's Resource Description Framework (RDF) Resource Guide] (is this an FAQ?), [http://www.semanticwebfaq.com/ Semantic Web FAQ], [[FaqIdeas]] (desperately needs refactoring!)<br />
* '''[[RdfSyntax|Serializations of RDF]]''' [[NotationThree]], [[SpotOfDrama]] (Atom/SOAP/RDF), [[ExtensibilityFramework]] or [http://www.intertwingly.net/wiki/pie/ExtensibilityFramework here], [[PieNt]] (an alternative serialization of RDF to [[RdfTriples]] ), [http://www.cerebra.com/products/repos_bench_it.html Cerebra Repository] (RDF, RDFS, OWL), [[SimpleRdfXml]]<br />
* '''Recent Experiments''' [http://en.wikibooks.org/wiki/ASQ ASQ], SWAD-Europe work packages: [[EswWp2]], [[EswWp7]] and [[EswWp10]], [[SemWebSpain]], [[WikiPedia]]:Massachusetts_Institute_of_Technology 's [[SIMILE]] (Semantic Interoperability of Metadata and Information in unLike Environments), [[SemanticWebEnablingConferences]], [[EdmProofing]] [https://lookboard.com Lookboard]<br />
<br />
* [[:Category:Breadcrumbs]]<br />
----<br />
Issues for HTML Working Group:<br />
<br />
* [http://www.w3.org/html/wg/wiki/ HTML]<br />
<br />
----<br />
<br />
* [[Open Media Web: Standardization Roadmap]]<br />
----<br />
* [[Xsl-fo]]<br />
<br />
----<br />
* [[ebook-Workshop]]<br />
* [[ebook-Workshop-slides]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Questions_re_DAA_proposal&diff=67091
Privacy/TPWG/Questions re DAA proposal
2013-07-03T19:52:31Z
<p>Roessler: /* Questions on the DAA proposal */</p>
<hr />
<div>== Questions on the DAA proposal ==<br />
<br />
* [http://www.w3.org/mid/4210CA43-6160-4A75-BD18-2A0833D32198@consumerwatchdog.org Simpson, who is making the proposal]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0505.html Simpson, on relationship with Wiley's slides]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jul/0005.html Roessler, clarifying questions]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0513.html Felten, delinked vs. de-identified]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0434.html Singer, request for explanations]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Questions_re_DAA_proposal&diff=67090
Privacy/TPWG/Questions re DAA proposal
2013-07-03T19:40:04Z
<p>Roessler: /* Questions on the DAA proposal */</p>
<hr />
<div>== Questions on the DAA proposal ==<br />
<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0505.html Simpson, on relationship with Wiley's slides]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jul/0005.html Roessler, clarifying questions]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0513.html Felten, delinked vs. de-identified]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0434.html Singer, request for explanations]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Questions_re_DAA_proposal&diff=67089
Privacy/TPWG/Questions re DAA proposal
2013-07-03T19:37:21Z
<p>Roessler: Created page with "== Questions on the DAA proposal == * [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0505.html Simpson, on relationship with Wiley's slides] * [http://lists.w3.org…"</p>
<hr />
<div>== Questions on the DAA proposal ==<br />
<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0505.html Simpson, on relationship with Wiley's slides]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jul/0005.html Roessler, clarifying questions]<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0513.html Felten, delinked vs. de-identified]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=67088
Privacy/TPWG
2013-07-03T19:34:15Z
<p>Roessler: </p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal DNT 0|Change Proposal DNT: 0]]<br />
* [[Privacy/TPWG/Change Proposal Add to Last Working Draft|Change Proposal Add to Last Working Draft]]<br />
<br />
== DAA proposal and open questions ==<br />
<br />
* [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/att-0466/NAI-DAA-DMA_June_26_draft_compared_to_June_22_Tracking_Compliance_and_Scope_copy.pdf DAA proposal]<br />
* [[Privacy/TPWG/Questions re DAA proposal|Questions re DAA proposal]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_DNT_0&diff=67007
Privacy/TPWG/Change Proposal DNT 0
2013-06-30T22:35:33Z
<p>Roessler: </p>
<hr />
<div>== DNT: 0 equal consent ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0392.html Change proposal Mayer]; [https://www.w3.org/2011/tracking-protection/track/issues/148 ISSUE-148]<br />
<br />
=== New Text ===<br />
<br />
DNT: 0 means whatever a user agrees to in providing consent.<br />
<br />
== No Change proposal ==<br />
<br />
[http://www.w3.org/mid/1470752.pNfFhMB0uY@hegel.sophia.w3.org No-change proposal Wenning]<br />
<br />
== Existing Text ==<br />
<br />
When a user sends a DNT: 0 signal, the user is expressing a preference for a personalized experience. This signal indicates explicit consent for data collection, retention, processing, disclosure, and use by the recipient of this signal to provide a personalized experience for the user. This recommendation places no restrictions on data collected from requests received with DNT: 0.<br />
<br />
''The change proposal aims to replace this existing text.''</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_DNT_0&diff=67006
Privacy/TPWG/Change Proposal DNT 0
2013-06-30T22:33:41Z
<p>Roessler: Created page with "== DNT: 0 equal consent == [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0392.html Change proposal Mayer]; [https://www.w3.org/2011/tracking-protection/track/issu…"</p>
<hr />
<div>== DNT: 0 equal consent ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0392.html Change proposal Mayer]; [https://www.w3.org/2011/tracking-protection/track/issues/148 ISSUE-148]<br />
<br />
=== New Text ===<br />
<br />
DNT: 0 means whatever a user agrees to in providing consent.<br />
<br />
== Existing Text ==<br />
<br />
When a user sends a DNT: 0 signal, the user is expressing a preference for a personalized experience. This signal indicates explicit consent for data collection, retention, processing, disclosure, and use by the recipient of this signal to provide a personalized experience for the user. This recommendation places no restrictions on data collected from requests received with DNT: 0.<br />
<br />
''The change proposal aims to replace this existing text.''</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=67005
Privacy/TPWG
2013-06-30T22:32:17Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal DNT 0|Change Proposal DNT: 0]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_First_Party_Compliance&diff=67004
Privacy/TPWG/Change Proposal First Party Compliance
2013-06-30T22:28:21Z
<p>Roessler: /* More restrictive */</p>
<hr />
<div>== Prohibit Append and Use in Third Party Context == <br />
<br />
Proposal from John Simpson: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0243.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/170 issue-170]<br />
<br />
=== New text ===<br />
<br />
When DNT:1 is received:<br />
<br />
* A 1st Party MUST NOT combine or otherwise use identifiable data<br />
received from another party with data it has collected while a 1st Party.<br />
<br />
* A 1st Party MUST NOT share identifiable data with another party unless<br />
the data was provided voluntarily by the user and is necessary to complete<br />
a business transaction with the user.<br />
<br />
* A Party MUST NOT use data gathered while a 1st Party when operating as<br />
a 3rd Party.<br />
<br />
''This text would be in addition to existing First Party Compliance requirements in the editors' draft.''<br />
<br />
== Third party compliance for use outside first party context ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0394.html Proposal from Alan Chapell]<br />
<br />
=== New text ===<br />
<br />
Use of this information [information collected in the first party context] outside the first party context is tracking and subject to third party rules for tracking as outlined in Section 5 below.<br />
<br />
''This text would be in addition to existing First Party Compliance requirements in the editors' draft.''<br />
<br />
== First party electing third party compliance ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0326.html Proposal from Susan Israel]<br />
<br />
''Strike:'' First parties may elect to follow third party practices.<br />
<br />
== Elect more restrictive ==<br />
<br />
[http://www.w3.org/mid/2986273.lhovrIYgx2@hegel.sophia.w3.org Proposal Wenning]<br />
<br />
=== New Text ===<br />
<br />
First parties may elect to be more restrictive in their data collection <br />
practices than proscribed in this Specification. If first parties only <br />
collect data as permitted for third parties when receiving a DNT:1 <br />
header, they can indicate this according to the tracking status message <br />
as set forth in the Tracking Preference Expression Specification. This <br />
also allows them to use DNT:0 as a permission mechanism for regulated <br />
environments. <br />
<br />
<br />
''This text would replace "First parties may elect to follow third party practices."''<br />
<br />
== Editor's draft ==<br />
<br />
If a first party receives a DNT:1 signal the first party may engage in its normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience.<br />
<br />
The first party must not pass information about this network interaction to third parties who could not collect the data themselves under this standard. Information about the transaction may be passed on to service providers acting on behalf of the first party<br />
<br />
First parties may elect to follow third party practices.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_First_Party_Compliance&diff=67003
Privacy/TPWG/Change Proposal First Party Compliance
2013-06-30T22:28:05Z
<p>Roessler: </p>
<hr />
<div>== Prohibit Append and Use in Third Party Context == <br />
<br />
Proposal from John Simpson: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0243.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/170 issue-170]<br />
<br />
=== New text ===<br />
<br />
When DNT:1 is received:<br />
<br />
* A 1st Party MUST NOT combine or otherwise use identifiable data<br />
received from another party with data it has collected while a 1st Party.<br />
<br />
* A 1st Party MUST NOT share identifiable data with another party unless<br />
the data was provided voluntarily by the user and is necessary to complete<br />
a business transaction with the user.<br />
<br />
* A Party MUST NOT use data gathered while a 1st Party when operating as<br />
a 3rd Party.<br />
<br />
''This text would be in addition to existing First Party Compliance requirements in the editors' draft.''<br />
<br />
== Third party compliance for use outside first party context ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0394.html Proposal from Alan Chapell]<br />
<br />
=== New text ===<br />
<br />
Use of this information [information collected in the first party context] outside the first party context is tracking and subject to third party rules for tracking as outlined in Section 5 below.<br />
<br />
''This text would be in addition to existing First Party Compliance requirements in the editors' draft.''<br />
<br />
== First party electing third party compliance ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0326.html Proposal from Susan Israel]<br />
<br />
''Strike:'' First parties may elect to follow third party practices.<br />
<br />
== More restrictive ==<br />
<br />
[http://www.w3.org/mid/2986273.lhovrIYgx2@hegel.sophia.w3.org Proposal Wenning]<br />
<br />
=== New Text ===<br />
<br />
First parties may elect to be more restrictive in their data collection <br />
practices than proscribed in this Specification. If first parties only <br />
collect data as permitted for third parties when receiving a DNT:1 <br />
header, they can indicate this according to the tracking status message <br />
as set forth in the Tracking Preference Expression Specification. This <br />
also allows them to use DNT:0 as a permission mechanism for regulated <br />
environments. <br />
<br />
<br />
''This text would replace "First parties may elect to follow third party practices."''<br />
<br />
== Editor's draft ==<br />
<br />
If a first party receives a DNT:1 signal the first party may engage in its normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience.<br />
<br />
The first party must not pass information about this network interaction to third parties who could not collect the data themselves under this standard. Information about the transaction may be passed on to service providers acting on behalf of the first party<br />
<br />
First parties may elect to follow third party practices.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_First_Party_Compliance&diff=67002
Privacy/TPWG/Change Proposal First Party Compliance
2013-06-30T22:25:57Z
<p>Roessler: </p>
<hr />
<div>== Prohibit Append and Use in Third Party Context == <br />
<br />
Proposal from John Simpson: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0243.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/170 issue-170]<br />
<br />
=== New text ===<br />
<br />
When DNT:1 is received:<br />
<br />
* A 1st Party MUST NOT combine or otherwise use identifiable data<br />
received from another party with data it has collected while a 1st Party.<br />
<br />
* A 1st Party MUST NOT share identifiable data with another party unless<br />
the data was provided voluntarily by the user and is necessary to complete<br />
a business transaction with the user.<br />
<br />
* A Party MUST NOT use data gathered while a 1st Party when operating as<br />
a 3rd Party.<br />
<br />
''This text would be in addition to existing First Party Compliance requirements in the editors' draft.''<br />
<br />
== Third party compliance for use outside first party context ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0394.html Proposal from Alan Chapell]<br />
<br />
=== New text ===<br />
<br />
Use of this information [information collected in the first party context] outside the first party context is tracking and subject to third party rules for tracking as outlined in Section 5 below.<br />
<br />
''This text would be in addition to existing First Party Compliance requirements in the editors' draft.''<br />
<br />
== First party electing third party compliance ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0326.html Proposal from Susan Israel]<br />
<br />
''Strike:'' First parties may elect to follow third party practices.<br />
<br />
== Editor's draft ==<br />
<br />
If a first party receives a DNT:1 signal the first party may engage in its normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience.<br />
<br />
The first party must not pass information about this network interaction to third parties who could not collect the data themselves under this standard. Information about the transaction may be passed on to service providers acting on behalf of the first party<br />
<br />
First parties may elect to follow third party practices.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_First_Party_Compliance&diff=67001
Privacy/TPWG/Change Proposal First Party Compliance
2013-06-30T22:25:05Z
<p>Roessler: </p>
<hr />
<div>== Prohibit Append and Use in Third Party Context == <br />
<br />
Proposal from John Simpson: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0243.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/170 issue-170]<br />
<br />
=== New text ===<br />
<br />
When DNT:1 is received:<br />
<br />
* A 1st Party MUST NOT combine or otherwise use identifiable data<br />
received from another party with data it has collected while a 1st Party.<br />
<br />
* A 1st Party MUST NOT share identifiable data with another party unless<br />
the data was provided voluntarily by the user and is necessary to complete<br />
a business transaction with the user.<br />
<br />
* A Party MUST NOT use data gathered while a 1st Party when operating as<br />
a 3rd Party.<br />
<br />
''This text would be in addition to existing First Party Compliance requirements in the editors' draft.''<br />
<br />
== Third party compliance for use outside first party context ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0394.html Proposal from Alan Chapell]<br />
<br />
=== New text ===<br />
<br />
Use of this information [information collected in the first party context] outside the first party context is tracking and subject to third party rules for tracking as outlined in Section 5 below.<br />
<br />
''This text would be in addition to existing First Party Compliance requirements in the editors' draft.''<br />
<br />
== First party electing third party compliance ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0326.html Proposal from Susan Israel]<br />
<br />
''Strike:'' First parties may elect to follow third party practices.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Party_Definitions&diff=67000
Privacy/TPWG/Change Proposal Party Definitions
2013-06-30T22:21:27Z
<p>Roessler: </p>
<hr />
<div>== Proposal: Infer with high probability, knowing and intentional communication ==<br />
<br />
Proposal from Lee Tien: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0323.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/10 issue-10]<br />
<br />
=== New text ===<br />
A '''party''' is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person.<br />
<br />
A '''first party''' is any party, in a specific network interaction, that can infer with high probability that the user knowingly and intentionally communicated with it. Otherwise, a party is a third party.<br />
<br />
A '''third party''' is any party, in a specific network interaction, that cannot infer with high probability that the user knowingly and intentionally communicated with it.<br />
<br />
== Proposal: Remove/modify list of affiliates ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0370.html Proposal from Amy Colando].<br />
<br />
=== Remove text ===<br />
<br />
''Remove the sentence:'' A list of affiliates MUST be available through a single user interaction from each page, for example, by following a single link, or through a single click.<br />
<br />
''Alternately, replace with:'' For example, a list of affiliates that is available via a link from a resource where a party describes DNT practices would be considered easily discoverable.<br />
<br />
== Proposal: Transparency about affiliates, with example ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0390.html Proposal from Chris Pedigo].<br />
<br />
=== New text ===<br />
<br />
''Replace requirement about single user interaction with:'' Parties MUST provide transparency about what affiliates are considered part of the same party. Examples of ways to provide this transparency are through common branding or by disclosing affiliates and affiliate data sharing practices in a long form privacy policy.<br />
<br />
== Proposal: no change ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0363.html No-change proposal from Justin Brookman]<br />
<br />
== Editors' Draft Text ==<br />
''The above proposal would replace the existing text below from the editors' draft.''<br />
<br />
A '''party''' is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person. For unique corporate entities to qualify as a common party with respect to this document, those entities MUST be commonly owned and commonly controlled and MUST provide easy discoverability of affiliate organizations. A list of affiliates MUST be available through a single user interaction from each page, for example, by following a single link, or through a single click.<br />
<br />
In the context of a specific network interaction, the '''first party''' is the party with which the user intentionally interacts. In most cases on a traditional web browser, the first party will be the party that owns and operates the domain visible in the address bar.<br />
<br />
The party that owns and operates or has control over a branded or labeled embedded widget, search box, or similar service with which a user intentionally interacts is also considered a first party. If a user merely mouses over, closes, or mutes such content, that is not sufficient interaction to render the party a first party. <br />
<br />
A '''third party''' is any party other than a first party, service provider, or the user.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Principles_for_Permitted_Uses&diff=66999
Privacy/TPWG/Change Proposal Principles for Permitted Uses
2013-06-30T22:18:25Z
<p>Roessler: Created page with "== Strictly Necessary == [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0347.html Proposal from Mayer] === New Text === 5.1.2 Data Minimization, Retention and Tr…"</p>
<hr />
<div>== Strictly Necessary ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0347.html Proposal from Mayer]<br />
<br />
=== New Text ===<br />
<br />
5.1.2 Data Minimization, Retention and Transparency<br />
<br />
Data retained by a party for permitted uses must be limited to the data strictly necessary for such permitted uses. Such data must not be retained any longer than is proporationate and strictly necessary for such permitted uses.<br />
<br />
Third parties must provide public transparency of the time periods for which data collected for permitted uses are retained. The third party may enumerate different retention periods for different permitted uses. Data must not be used for a permitted use once the data retention period for that permitted use has expired. After there are no remaining permitted uses for given data, the data must be deleted or de-identified.<br />
<br />
Third parties must make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained, and must not rely on unique identifiers for users or devices if alternative solutions are reasonably available.<br />
<br />
Allowed Example: A third-party advertising network uses a minimal set of deidentified data to frequency cap advertisements.<br />
<br />
Disallowed Example: A third-party analytics service generates public reports about aggregate page impressions. It retains full protocol logs for two weeks, even though it has no need for them.<br />
<br />
== Technically feasible ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0388.html Proposal from Colando]<br />
<br />
=== New Text ===<br />
<br />
''End of section 5.1.2:''<br />
<br />
Third parties MUST make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained, and MUST NOT rely on unique identifiers for users or devices if alternative solutions are reasonably available and technically feasible.<br />
<br />
== Internally verifiable ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0388.html Proposal from Colando]<br />
<br />
=== New Text ===<br />
<br />
''End of section 5.1.4:''<br />
<br />
Third parties must use reasonable technical and organizational safeguards to prevent further processing of data retained for permitted uses. While physical separation of data maintained for permitted uses is not required, best practices should be in place to ensure technical controls ensure access limitations and information security. Third parties should ensure that the access and use of data retained for permitted uses is internally verifiable.<br />
<br />
== Editor's Draft ==<br />
<br />
5.1.2 Data Minimization, Retention and Transparency<br />
<br />
Data retained by a party for permitted uses must be limited to the data reasonably necessary for such permitted uses. Such data must not be retained any longer than is proporationate and reasonably necessary for such permitted uses.<br />
<br />
Third parties must provide public transparency of the time periods for which data collected for permitted uses are retained. The third party may enumerate different retention periods for different permitted uses. Data must not be used for a permitted use once the data retention period for that permitted use has expired. After there are no remaining permitted uses for given data, the data must be deleted or de-identified.<br />
<br />
Third parties must make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained, and must not rely on unique identifiers for users or devices if alternative solutions are reasonably available.<br />
<br />
5.1.4 Reasonable Security<br />
<br />
Third parties must use reasonable technical and organizational safeguards to prevent further processing of data retained for permitted uses. While physical separation of data maintained for permitted uses is not required, best practices should be in place to ensure technical controls ensure access limitations and information security. Third parties should ensure that the access and use of data retained for permitted uses is auditable.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=66998
Privacy/TPWG
2013-06-30T22:13:15Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Principles for Permitted Uses|Change Proposals Principles for Permitted Uses]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=66997
Privacy/TPWG
2013-06-30T22:12:56Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Permitted Uses|Change Proposals Permitted Uses]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=66996
Privacy/TPWG
2013-06-30T22:11:36Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=66995
Privacy/TPWG
2013-06-30T22:08:46Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Reasonably Necessary|Change Proposal Reasonably Necessary]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Partial_Compliance&diff=66994
Privacy/TPWG/Change Proposal Partial Compliance
2013-06-30T22:04:23Z
<p>Roessler: /* Partial Compliance */</p>
<hr />
<div>== Partial Compliance ==<br />
<br />
[http://www.w3.org/mid/B8AD71B8D9BB415B82AFB6749AE945CD@gmail.com Change proposal from Jonathan Mayer]; [https://www.w3.org/2011/tracking-protection/track/issues/213 ISSUE-213]<br />
<br />
=== New Text ===<br />
<br />
A website MUST NOT be in partial compliance with the TPE or TCS documents.<br />
<br />
Example: A website is testing support for the TPE protocol by connecting it to a proprietary compliance standard. It must not represent compliance with "Do Not Track" unless it adheres to the requirements of both TPE and TCS.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Partial_Compliance&diff=66993
Privacy/TPWG/Change Proposal Partial Compliance
2013-06-30T22:02:00Z
<p>Roessler: Created page with "== Partial Compliance == [http://www.w3.org/mid/B8AD71B8D9BB415B82AFB6749AE945CD@gmail.com Change proposal from Jonathan Mayer] === New Text === A website MUST NOT be in parti…"</p>
<hr />
<div>== Partial Compliance ==<br />
<br />
[http://www.w3.org/mid/B8AD71B8D9BB415B82AFB6749AE945CD@gmail.com Change proposal from Jonathan Mayer]<br />
<br />
=== New Text ===<br />
<br />
A website MUST NOT be in partial compliance with the TPE or TCS documents.<br />
<br />
Example: A website is testing support for the TPE protocol by connecting it to a proprietary compliance standard. It must not represent compliance with "Do Not Track" unless it adheres to the requirements of both TPE and TCS.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG&diff=66992
Privacy/TPWG
2013-06-30T22:00:41Z
<p>Roessler: /* Change proposals */</p>
<hr />
<div>= Tracking Protection Working Group =<br />
<br />
Info on the [http://www.w3.org/2011/tracking-protection/ Tracking Protection Working Group] is maintained on the group home page. The group uses this wiki for collecting certain quickly-changing resources; participants should feel free to make changes to help the group as a whole.<br />
<br />
You can also see a list of past [[Privacy/TPWG/Background Memos|background memos]], collected on the wiki.<br />
<br />
== Change proposals ==<br />
* [[Privacy/TPWG/Change Proposal Audience Measurement|Change Proposal Audience Measurement]]<br />
* [[Privacy/TPWG/Change Proposal Security|Change Proposal Security]]<br />
* [[Privacy/TPWG/Change Proposal First Party Compliance|Change Proposal First Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Geolocation|Change Proposal Geolocation]]<br />
* [[Privacy/TPWG/Change Proposal Deidentification|Change Proposal Deidentification]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Third Party Compliance|Change Proposal Tracking Third Party Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Transience Collection|Change Proposal Transience & Collect/Retain/Use/Share]]<br />
* [[Privacy/TPWG/Change Proposal User Agent Compliance|Change Proposal User Agent Compliance]]<br />
* [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]]<br />
* [[Privacy/TPWG/Change Proposal Party Definitions|Change Proposal Party Definitions]]<br />
* [[Privacy/TPWG/Change Proposal Service Provider|Change Proposal Service Provider]]<br />
* [[Privacy/TPWG/Change Proposal Disregarding|Change Proposal Disregarding]]<br />
* [[Privacy/TPWG/Change Proposal No Tracking|Change Proposal No Tracking]]<br />
* [[Privacy/TPWG/Change Proposal Tracking Definition|Change Proposal Tracking Definition]]<br />
* [[Privacy/TPWG/Change Proposal Unknowing|Change Proposal Unknowing]]<br />
* [[Privacy/TPWG/Change Proposal Scope|Change Proposal Scope]]<br />
* [[Privacy/TPWG/Change Proposal Existing Controls|Change Proposal Existing Controls]]<br />
* [[Privacy/TPWG/Change Proposal Unique Identifiers|Change Proposal Unique Identifiers]]<br />
* [[Privacy/TPWG/Change Proposal Retention Permitted Uses|Change Proposal Retention Permitted Uses]]<br />
* [[Privacy/TPWG/Change Proposal Partial Compliance|Change Proposal Partial Compliance]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Short_Term&diff=66989
Privacy/TPWG/Change Proposal Short Term
2013-06-30T11:08:10Z
<p>Roessler: </p>
<hr />
<div>== Proposal: Protocol information, two weeks, any purpose ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0322.html Proposal from Lee Tien] [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0373.html and Jonathan Mayer (1)] [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0334.html (2)]; [https://www.w3.org/2011/tracking-protection/track/issues/134 issue-134]<br />
<br />
=== New text ===<br />
A third party may collect and use protocol information for any purpose, subject to a two-week retention period.<br />
<br />
Protocol information includes:<br />
* any information that a user agent necessarily shares with a web server when it communicates with the web server (e.g. IP address and User-Agent), and<br />
* the URL of the top-level page, communicated via a Referer header or other means, unless the URL contains information that is not unlinkable (e.g. a username or user ID).<br />
<br />
Protocol information does not include:<br />
* any information that a web server could cause to not be sent but still communicate with the user agent (e.g. a cookie or a Request-URI parameter generated by the user agent), except the URL of the top-level page, and<br />
* any data added by a network intermediary that the operator of a web server has actual knowledge of (e.g. a unique device identifier HTTP header).<br />
<br />
Under the general rule on protocol information a third party may temporarily use a top-level page URL for the purpose of contextually personalizing content.<br />
<br />
== Proposal: Protocol information, one week, any purpose ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0338.html Proposal from Dan Auerbach] [https://www.w3.org/2011/tracking-protection/track/issues/134 issue-134]<br />
<br />
=== New text ===<br />
<br />
A third party MAY also use protocol information (e.g. HTTP header information and IP information) for any purpose, subject to a one week retention period.<br />
<br />
== Proposal: Permitted use. ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0425.html Proposal from David Singer]<br />
<br />
# Make it a "permitted use"<br />
# define it as ''Raw data may be collected and retained solely for the purpose of processing that data into data allowed by other claimed permitted uses.''<br />
# Retain a short paragraph in the out-of-scope section that says ''The use of data present in the transaction, as part of the processing of that transaction, is out of scope: for example, the contextual customization of ads shown as part of the same network interaction is not restricted by DNT: 1.''<br />
<br />
=== New text ===<br />
<br />
====Out of scope====<br />
<br />
The use of data present in the transaction, as part of the processing of that transaction, is out of scope: for example, the contextual customization of ads shown as part of the same network interaction is not restricted by DNT: 1.<br />
<br />
====Permitted Use====<br />
<br />
Raw data may be collected and retained solely for the purposes of processing that data into one of:<br />
# Data that is not tracking data, and is thus out of scope;<br />
# Data that is tracking data, but for which consent was in effect at the time of collection;<br />
# Data that is tracking data, but which is being retained under another permitted use that was claimed at the time of collection.<br />
<br />
All other data MUST BE discarded at the time of processing.<br />
<br />
== Editors' Draft Text ==<br />
''The above proposals would replace the existing text below from the editors' draft.''<br />
<br />
It is outside the scope of this specification to control short-term, transient collection and use of data, so long as the information is not transmitted to a third party and is not used to build a profile about a user or otherwise alter an individual user’s user experience outside the current network interaction. For example, the contextual customization of ads shown as part of the same network interaction is not restricted by DNT: 1.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_User_Agent_Compliance&diff=66988
Privacy/TPWG/Change Proposal User Agent Compliance
2013-06-30T09:57:32Z
<p>Roessler: /* No tracking by UA */</p>
<hr />
<div>== Mirror TPE language == <br />
<br />
Proposal from Justin Brookman: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0306.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/205 issue-205] (See also: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0230.html proposal from Mike O'Neill])<br />
<br />
=== New text ===<br />
<br />
''Proposal is to mirror the language on user agent compliance for setting a preference currently in the TPE draft. Summary of differences: explanatory text about the user's preference rather than institution; choice implied by the decision to use the agent; remove requirement to make available neutral explanation to user.''<br />
<br />
The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they communicate with via HTTP, thereby allowing each service to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy all parties.<br />
<br />
Key to that notion of expression is that the signal sent must reflect the user's preference, not the choice of some vendor, institution, site, or any network-imposed mechanism outside the user's control; this applies equally to both the general preference and exceptions. The basic principle is that a tracking preference expression is only transmitted when it reflects a deliberate choice by the user. In the absence of user choice, there is no tracking preference expressed.<br />
<br />
A user agent must offer users a minimum of two alternative choices for a Do Not Track preference: unset or DNT:1. A user agent may offer a third alternative choice: DNT:0.<br />
<br />
If the user's choice is DNT:1 or DNT:0, the tracking preference is enabled; otherwise, the tracking preference is not enabled.<br />
<br />
A user agent must have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent, or another default preference is required to comply with applicable laws, regulations or judicial processes. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as SuperFred, but might imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred. Likewise, a user agent extension or add-on must not alter the tracking preference unless the act of installing and enabling that extension or add-on is an explicit choice by the user for that tracking preference.<br />
<br />
A user agent extension or add-on must not alter the user's tracking preference setting unless it complies with the requirements in this document, including but not limited to this section (Determining a User Preference). Software outside of the user agent that causes a DNT header to be sent (or causes existing headers to be modified) must not do so without ensuring that the requirements of this section are met; such software also must ensure the transmitted preference reflects the individual user's preference.<br />
<br />
We do not specify how tracking preference choices are offered to the user or how the preference is enabled: each implementation is responsible for determining the user experience by which a tracking preference is enabled. For example, a user might select a check-box in their user agent's configuration, install an extension or add-on that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., Privacy settings: high). The user-agent might ask the user for their preference during startup, perhaps on first use or after an update adds the tracking protection feature. Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.<br />
<br />
Although some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled, the user is at least able to choose whether to make use of those user agents. In contrast, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment, aside from blanket limitations on what resources can or cannot be accessed through that network. Implementations of HTTP that are not under control of the user must not generate or modify a tracking preference.<br />
<br />
==No tracking by UA==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0399.html proposal from Alan Chapell]<br />
<br />
===New text===<br />
<br />
A user agent MUST NOT track information related to the network interaction outside of the [Permitted Uses] and any explicitly-granted exceptions without consent.<br />
<br />
== UA Compliance Example ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0372.html Proposal from Jonathan Mayer] and [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0380.html Dan Auerbach].<br />
<br />
=== New text (jmayer) ===<br />
<br />
''Suggests adding a non-normative example only:''<br />
<br />
Example: A browser which presents a preselected first-run or install-time DNT option is compliant, as DNT signals would reflect the user's affirmative DNT choice.<br />
<br />
=== New text (danA) ===<br />
<br />
''Suggests adding a non-normative example only:''<br />
<br />
Example: A browser which has a first-run option that forces a user to choose between DNT: 1, DNT: 0, or keeping DNT unset, would be considered compliant with the DNT standard, as signals sent out based on this implementation reflect the user's affirmative DNT choice.<br />
<br />
== Editors' draft ==<br />
<br />
A user agent MUST offer users a minimum of two alternative choices for a Do Not Track preference: unset or DNT: 1. A user agent MAY offer a third alternative choice: DNT: 0.<br />
<br />
If the user's choice is DNT:1 or DNT:0, the tracking preference is enabled; otherwise, the tracking preference is not enabled.<br />
<br />
A user agent MUST have a default tracking preference of unset (not enabled).<br />
<br />
User agents and web sites are responsible for determining the user experience by which a tracking preference is controlled. User agents and web sites MUST ensure that tracking preference choices are communicated to users clearly and accurately and shown at the time and place the tracking preference choice is made available to a user. User agents and web sites MUST ensure that the tracking preference choices describe the parties to whom DNT applies and MUST make available brief and neutral explanatory text to provide more detailed information about DNT functionality.<br />
<br />
That text MUST indicate that:<br />
* if the tracking preference is communicated, it limits collection and use of web viewing data for certain advertising and other purposes;<br />
* when DNT is enabled, some data may still be collected and used for certain purposes, and a description of such purposes; and<br />
* if a user affirmatively allows a particular party to collect and use information about web viewing activities, enabling DNT will not limit collection and use from that party.<br />
<br />
User agents and web sites MUST obtain an explicit choice made by a user when setting controls that affect the tracking preference expression.<br />
<br />
A user agent MUST transmit the tracking preference according to the [TRACKING-DNT] specification.<br />
<br />
Implementations of HTTP that are not under control of the user MUST NOT generate or modify a tracking preference.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Deidentification&diff=66945
Privacy/TPWG/Change Proposal Deidentification
2013-06-28T13:07:08Z
<p>Roessler: </p>
<hr />
<div>== De-identification ==<br />
<br />
Proposal from Dan Auerbach: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0271.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/188 issue-188]<br />
<br />
=== New text ===<br />
Data can be considered de-identified if it has been deleted, modified, aggregated, anonymized or otherwise manipulated in order to achieve a reasonable level of justified confidence that the data cannot reasonably be used to infer information about, or otherwise be linked to, a particular user, user agent, or device.<br />
<br />
==== Non-normative text ====<br />
<br />
Example 1. Hashing a pseudonym such as a cookie string does NOT provide sufficient de-identification for an otherwise rich data set such as a browsing history, since there are many ways to re-identify individuals based on pseudonymous data.<br />
<br />
Example 2. In many cases, keeping only high-level aggregate data, such as the total number of visitors of a website each day broken down by country (discarding data from countries without many visitors) would be considered sufficiently de-identified.<br />
<br />
Example 3. Deleting data is always a safe and easy way to achieve de-identification.<br />
<br />
Remark 1. De-identification is a property of data. If data can be considered de-identified according to the “reasonable level of justified confidence” clause of (1), then no data manipulation process needs to take place in order to satisfy the requirements of (1).<br />
<br />
Remark 2. There are a diversity of techniques being researched and developed to de-identify data sets, and companies are encouraged to explore and innovate new approaches to fit their needs.<br />
<br />
Remark 3. It is a best practice for companies to perform “penetration testing” by having an expert with access to the data attempt to re-identify individuals or disclose attributes about them. The expert need not actually identify or disclose the attribute of an individual, but if the expert demonstrates how this could plausibly be achieved by joining the data set against other public data sets or private data sets accessible to the company, then the data set in question should no longer be considered sufficiently de-identified and changes should be made to provide stronger anonymization for the data set.<br />
<br />
== use of "tracking" / level of confidence ==<br />
<br />
Proposal from David Singer: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0234.html email]<br />
<br />
=== New text ===<br />
''In particular, changes to use "tracking data", "generally accepted high level of confidence", remove "downstream".''<br />
<br />
Data is deidentified when a party:<br />
* has achieved ''a generally accepted high level of confidence'' that the data is not, and cannot be made into, tracking data;<br />
* commits to try not to reidentify the data; and<br />
* contractually prohibits recipients from trying to re-identify the data.<br />
<br />
== -commitment, -contract ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0352.html Proposal from Roy Fielding].<br />
<br />
=== New text ===<br />
<br />
A data set is considered de-identified when there exists a reasonable level of justified confidence that the data within it cannot be used to infer information about, or otherwise be linked to, a particular user.<br />
<br />
== European/German-style ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0404.html proposal from Thomas Schauf].<br />
<br />
=== New text ===<br />
Data is considered de-identified when data that has been collected is altered or otherwise processed so that it cannot be attributed to a data subject without the use of additional data which is subject to separate and distinct technical and organisational controls to ensure such non attribution, or when such attribution would require a disproportionate amount of time, expense and effort.<br />
<br />
== Three-state proposal ==<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/att-0466/NAI-DAA-DMA_June_26_draft_compared_to_June_22_Tracking_Compliance_and_Scope_copy.pdf NAI/DAA proposal]<br />
<br />
=== New text ===<br />
<br />
Data is deidentified when a party:<br />
<br />
# has taken reasonable steps to ensure that the data cannot reasonably be re-associated or connected to a specific user, computer, or device;<br />
# has taken reasonable steps to protect the non-identifiable nature of data if it is distributed to non- affiliates and obtain satisfactory written assurance that such entities will not attempt to reconstruct the data in a way such that an individual may be re-identified and will use or disclose the de- identified data only for uses as specified by the entity.<br />
# has taken reasonable steps to ensure that any non-affiliate that receives de-identified data will itself ensure that any further non-affiliate entities to which such data is disclosed agree to the same restrictions and conditions.<br />
# will commit to not purposely sharing this data publicly. <br />
<br />
Data is delinked when a party:<br />
# has achieved a reasonable level of justified confidence that data has been de-identified and cannot be internally linked to a specific user, computer, or other device within a reasonable timeframe;<br />
# has taken reasonable steps to ensure that data cannot be reverse engineered back to identifiable data without the need for operational or administrative controls.<br />
<br />
Non-Normative: Delinked data could still have some level of internal linkage within a discrete dataset if the process to delink data occurs on a set time interval, for example, hourly or daily. Implementers should consider only exercising the market research and product development permitted uses in the de-identified but still internally linkable state.<br />
<br />
== Pending proposals ==<br />
<br />
''This page still needs to integrate [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0279.html Rob van Eijk's proposal].''<br />
<br />
== Editors' Draft Text ==<br />
''The above proposals would replace the existing text below from the editors' draft.''<br />
<br />
Data is deidentified when a party:<br />
* has achieved a reasonable level of justified confidence that the data cannot be used to infer information about, or otherwise be linked to, a particular consumer, computer, or other device;<br />
* commits to try not to reidentify the data; and<br />
* contractually prohibits downstream recipients from trying to re-identify the data.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_User_Agent_Compliance&diff=66936
Privacy/TPWG/Change Proposal User Agent Compliance
2013-06-28T11:10:10Z
<p>Roessler: </p>
<hr />
<div>== Mirror TPE language == <br />
<br />
Proposal from Justin Brookman: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0306.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/205 issue-205]<br />
<br />
=== New text ===<br />
<br />
''Proposal is to mirror the language on user agent compliance for setting a preference currently in the TPE draft. Summary of differences: explanatory text about the user's preference rather than institution; choice implied by the decision to use the agent; remove requirement to make available neutral explanation to user.''<br />
<br />
The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they communicate with via HTTP, thereby allowing each service to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy all parties.<br />
<br />
Key to that notion of expression is that the signal sent must reflect the user's preference, not the choice of some vendor, institution, site, or any network-imposed mechanism outside the user's control; this applies equally to both the general preference and exceptions. The basic principle is that a tracking preference expression is only transmitted when it reflects a deliberate choice by the user. In the absence of user choice, there is no tracking preference expressed.<br />
<br />
A user agent must offer users a minimum of two alternative choices for a Do Not Track preference: unset or DNT:1. A user agent may offer a third alternative choice: DNT:0.<br />
<br />
If the user's choice is DNT:1 or DNT:0, the tracking preference is enabled; otherwise, the tracking preference is not enabled.<br />
<br />
A user agent must have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as SuperFred, but might imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred. Likewise, a user agent extension or add-on must not alter the tracking preference unless the act of installing and enabling that extension or add-on is an explicit choice by the user for that tracking preference.<br />
<br />
A user agent extension or add-on must not alter the user's tracking preference setting unless it complies with the requirements in this document, including but not limited to this section (Determining a User Preference). Software outside of the user agent that causes a DNT header to be sent (or causes existing headers to be modified) must not do so without ensuring that the requirements of this section are met; such software also must ensure the transmitted preference reflects the individual user's preference.<br />
<br />
We do not specify how tracking preference choices are offered to the user or how the preference is enabled: each implementation is responsible for determining the user experience by which a tracking preference is enabled. For example, a user might select a check-box in their user agent's configuration, install an extension or add-on that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., Privacy settings: high). The user-agent might ask the user for their preference during startup, perhaps on first use or after an update adds the tracking protection feature. Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.<br />
<br />
Although some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled, the user is at least able to choose whether to make use of those user agents. In contrast, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment, aside from blanket limitations on what resources can or cannot be accessed through that network. Implementations of HTTP that are not under control of the user must not generate or modify a tracking preference.<br />
<br />
==No tracking by UA==<br />
<br />
[http://www.w3.org/mid/CDF069BC.34317%25achapell@chapellassociates.com proposal from Alan Chapell]<br />
<br />
===New text===<br />
<br />
A user agent MUST NOT track information related to the network interaction outside of the [Permitted Uses] and any explicitly-granted exceptions without consent.<br />
<br />
<br />
== UA Compliance Example ==<br />
<br />
[http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0372.html Proposal from Jonathan Mayer] and [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0380.html Dan Auerbach].<br />
<br />
=== New text (jmayer) ===<br />
<br />
''Suggests adding a non-normative example only:''<br />
<br />
Example: A browser which presents a preselected first-run or install-time DNT option is compliant, as DNT signals would reflect the user's affirmative DNT choice.<br />
<br />
=== New text (danA) ===<br />
<br />
''Suggests adding a non-normative example only:''<br />
<br />
Example: A browser which has a first-run option that forces a user to choose between DNT: 1, DNT: 0, or keeping DNT unset, would be considered compliant with the DNT standard, as signals sent out based on this implementation reflect the user's affirmative DNT choice.<br />
<br />
== Editors' draft ==<br />
<br />
A user agent MUST offer users a minimum of two alternative choices for a Do Not Track preference: unset or DNT: 1. A user agent MAY offer a third alternative choice: DNT: 0.<br />
<br />
If the user's choice is DNT:1 or DNT:0, the tracking preference is enabled; otherwise, the tracking preference is not enabled.<br />
<br />
A user agent MUST have a default tracking preference of unset (not enabled).<br />
<br />
User agents and web sites are responsible for determining the user experience by which a tracking preference is controlled. User agents and web sites MUST ensure that tracking preference choices are communicated to users clearly and accurately and shown at the time and place the tracking preference choice is made available to a user. User agents and web sites MUST ensure that the tracking preference choices describe the parties to whom DNT applies and MUST make available brief and neutral explanatory text to provide more detailed information about DNT functionality.<br />
<br />
That text MUST indicate that:<br />
* if the tracking preference is communicated, it limits collection and use of web viewing data for certain advertising and other purposes;<br />
* when DNT is enabled, some data may still be collected and used for certain purposes, and a description of such purposes; and<br />
* if a user affirmatively allows a particular party to collect and use information about web viewing activities, enabling DNT will not limit collection and use from that party.<br />
<br />
User agents and web sites MUST obtain an explicit choice made by a user when setting controls that affect the tracking preference expression.<br />
<br />
A user agent MUST transmit the tracking preference according to the [TRACKING-DNT] specification.<br />
<br />
Implementations of HTTP that are not under control of the user MUST NOT generate or modify a tracking preference.</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Audience_Measurement&diff=66921
Privacy/TPWG/Change Proposal Audience Measurement
2013-06-28T10:18:47Z
<p>Roessler: </p>
<hr />
<div>== Audience Measurement Permitted Use ==<br />
<br />
Proposal from Kathy Joe: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0245.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/25 issue-25]<br />
<br />
=== New text ===<br />
Aggregated data collection and use for audience measurement research<br />
<br />
Information may be collected, retained and used by a third party for audience measurement research where the information is used to calibrate, validate or calculate through data collected from opted-in panels, which in part contains information collected across sites and over time from user agents.<br />
<br />
A third party eligible for an audience measurement research permitted use MUST adhere to the following restrictions. The data collected by the third party:<br />
<br />
* Must be pseudonymised before statistical analysis begins, and<br />
* Must not be shared with any other party unless the data are de-identified prior to sharing, and<br />
* Must be deleted or de-identified as early as possible after the purpose of collection is met and in no case shall such retention, prior to de-identification, exceed 53 weeks and<br />
* Must not be used for any other independent purpose including changing an individual’s user experience or building a profile for ad targeting purposes. <br />
* In addition, the third party must be subject to an independent certification process under the oversight of a generally-accepted market research industry organization that maintains a web platform providing user information about audience measurement research. This web platform lists the parties eligible to collect information under DNT standards and the audience measurement research permitted use and it provides users with an opportunity to exclude their data contribution.<br />
<br />
====Non-normative: collection and use for audience measurement research====<br />
Audience measurement research creates statistical measures of the reach in relation to the total online population, and frequency of exposure of the content to the online audience, including paid components of web pages.<br />
<br />
Audience measurement research for DNT purposes originates with opt-in panel output that is calibrated by counting actual hits on tagged content on websites. The panel output is re-adjusted using data collected from a broader online audience in order to ensure data produced from the panel accurately represents the whole online audience. Aggregate results from the panel can also be applied to the hits counted for specific content to describe the general character of the audience for that content<br />
<br />
This online data is collected on a first party and third party basis. Audience measurement is centered around specific content, not around a user.<br />
<br />
The collected data is retained for a given period for purposes of sample quality control, and auditing. During this retention period contractual measures must be in place to limit access to, and protect the data, as well as restrict the data from other uses. This retention period is set by auditing bodies, after which the data must be de-identified. <br />
<br />
The purposes of audience measurement research must be limited to:<br />
<br />
* Facilitating online media valuation, planning and buying via accurate and reliable audience measurement.<br />
* Optimizing content and placement on an individual site.<br />
<br />
The term “audience measurement research” does not include sales, promotional, or marketing activities directed at a specific computer or device. Audience measurement data must be reported as aggregated information such that no recipient is able to build commercial profiles about particular individuals or devices.<br />
<br />
''This text would replace the audience measurement placeholder note in the editors' draft.''<br />
<br />
== Audience Measurement with large buckets ==<br />
<br />
Proposal form Rigo Wenning: [http://www.w3.org/mid/1455409.O2aSxzv7j6@hegel.sophia.w3.org email]<br />
<br />
Add the following bullet to the list of normative clauses in Kathy Joe's proposal:<br />
<br />
===New Text===<br />
<br />
* MUST NOT be aggregated into categories and buckets with less than 812 <br />
Members<br />
<br />
== Audience Measurement with Deidentified and Protocol Data ==<br />
<br />
Proposal from Lee Tien: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0320.html email]<br />
<br />
=== New text ===<br />
<br />
A third party MAY use deidentified data for audience measurement. A third party MAY also use protocol information for audience measurement, subject to a two-week retention period.<br />
<br />
''This text would replace the audience measurement placeholder note in the editors' draft. See [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] for definition of protocol information.''<br />
<br />
==No Change Proposal==</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Audience_Measurement&diff=66920
Privacy/TPWG/Change Proposal Audience Measurement
2013-06-28T09:43:37Z
<p>Roessler: /* Audience Measurement with large buckets */</p>
<hr />
<div>== Audience Measurement Permitted Use ==<br />
<br />
Proposal from Kathy Joe: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0245.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/25 issue-25]<br />
<br />
=== New text ===<br />
Aggregated data collection and use for audience measurement research<br />
<br />
Information may be collected, retained and used by a third party for audience measurement research where the information is used to calibrate, validate or calculate through data collected from opted-in panels, which in part contains information collected across sites and over time from user agents.<br />
<br />
A third party eligible for an audience measurement research permitted use MUST adhere to the following restrictions. The data collected by the third party:<br />
<br />
* Must be pseudonymised before statistical analysis begins, and<br />
* Must not be shared with any other party unless the data are de-identified prior to sharing, and<br />
* Must be deleted or de-identified as early as possible after the purpose of collection is met and in no case shall such retention, prior to de-identification, exceed 53 weeks and<br />
* Must not be used for any other independent purpose including changing an individual’s user experience or building a profile for ad targeting purposes. <br />
* In addition, the third party must be subject to an independent certification process under the oversight of a generally-accepted market research industry organization that maintains a web platform providing user information about audience measurement research. This web platform lists the parties eligible to collect information under DNT standards and the audience measurement research permitted use and it provides users with an opportunity to exclude their data contribution.<br />
<br />
====Non-normative: collection and use for audience measurement research====<br />
Audience measurement research creates statistical measures of the reach in relation to the total online population, and frequency of exposure of the content to the online audience, including paid components of web pages.<br />
<br />
Audience measurement research for DNT purposes originates with opt-in panel output that is calibrated by counting actual hits on tagged content on websites. The panel output is re-adjusted using data collected from a broader online audience in order to ensure data produced from the panel accurately represents the whole online audience. Aggregate results from the panel can also be applied to the hits counted for specific content to describe the general character of the audience for that content<br />
<br />
This online data is collected on a first party and third party basis. Audience measurement is centered around specific content, not around a user.<br />
<br />
The collected data is retained for a given period for purposes of sample quality control, and auditing. During this retention period contractual measures must be in place to limit access to, and protect the data, as well as restrict the data from other uses. This retention period is set by auditing bodies, after which the data must be de-identified. <br />
<br />
The purposes of audience measurement research must be limited to:<br />
<br />
* Facilitating online media valuation, planning and buying via accurate and reliable audience measurement.<br />
* Optimizing content and placement on an individual site.<br />
<br />
The term “audience measurement research” does not include sales, promotional, or marketing activities directed at a specific computer or device. Audience measurement data must be reported as aggregated information such that no recipient is able to build commercial profiles about particular individuals or devices.<br />
<br />
''This text would replace the audience measurement placeholder note in the editors' draft.''<br />
<br />
== Audience Measurement with large buckets ==<br />
<br />
Proposal form Rigo Wenning: [http://www.w3.org/mid/1455409.O2aSxzv7j6@hegel.sophia.w3.org email]<br />
<br />
Add the following bullet to the list of normative clauses in Kathy Joe's proposal:<br />
<br />
===New Text===<br />
<br />
* MUST NOT be aggregated into categories and buckets with less than 812 <br />
Members<br />
<br />
== Audience Measurement with Deidentified and Protocol Data ==<br />
<br />
Proposal from Lee Tien: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0320.html email]<br />
<br />
=== New text ===<br />
<br />
A third party MAY use deidentified data for audience measurement. A third party MAY also use protocol information for audience measurement, subject to a two-week retention period.<br />
<br />
''This text would replace the audience measurement placeholder note in the editors' draft. See [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] for definition of protocol information.''</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Change_Proposal_Audience_Measurement&diff=66919
Privacy/TPWG/Change Proposal Audience Measurement
2013-06-28T09:43:16Z
<p>Roessler: </p>
<hr />
<div>== Audience Measurement Permitted Use ==<br />
<br />
Proposal from Kathy Joe: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0245.html email]; [https://www.w3.org/2011/tracking-protection/track/issues/25 issue-25]<br />
<br />
=== New text ===<br />
Aggregated data collection and use for audience measurement research<br />
<br />
Information may be collected, retained and used by a third party for audience measurement research where the information is used to calibrate, validate or calculate through data collected from opted-in panels, which in part contains information collected across sites and over time from user agents.<br />
<br />
A third party eligible for an audience measurement research permitted use MUST adhere to the following restrictions. The data collected by the third party:<br />
<br />
* Must be pseudonymised before statistical analysis begins, and<br />
* Must not be shared with any other party unless the data are de-identified prior to sharing, and<br />
* Must be deleted or de-identified as early as possible after the purpose of collection is met and in no case shall such retention, prior to de-identification, exceed 53 weeks and<br />
* Must not be used for any other independent purpose including changing an individual’s user experience or building a profile for ad targeting purposes. <br />
* In addition, the third party must be subject to an independent certification process under the oversight of a generally-accepted market research industry organization that maintains a web platform providing user information about audience measurement research. This web platform lists the parties eligible to collect information under DNT standards and the audience measurement research permitted use and it provides users with an opportunity to exclude their data contribution.<br />
<br />
====Non-normative: collection and use for audience measurement research====<br />
Audience measurement research creates statistical measures of the reach in relation to the total online population, and frequency of exposure of the content to the online audience, including paid components of web pages.<br />
<br />
Audience measurement research for DNT purposes originates with opt-in panel output that is calibrated by counting actual hits on tagged content on websites. The panel output is re-adjusted using data collected from a broader online audience in order to ensure data produced from the panel accurately represents the whole online audience. Aggregate results from the panel can also be applied to the hits counted for specific content to describe the general character of the audience for that content<br />
<br />
This online data is collected on a first party and third party basis. Audience measurement is centered around specific content, not around a user.<br />
<br />
The collected data is retained for a given period for purposes of sample quality control, and auditing. During this retention period contractual measures must be in place to limit access to, and protect the data, as well as restrict the data from other uses. This retention period is set by auditing bodies, after which the data must be de-identified. <br />
<br />
The purposes of audience measurement research must be limited to:<br />
<br />
* Facilitating online media valuation, planning and buying via accurate and reliable audience measurement.<br />
* Optimizing content and placement on an individual site.<br />
<br />
The term “audience measurement research” does not include sales, promotional, or marketing activities directed at a specific computer or device. Audience measurement data must be reported as aggregated information such that no recipient is able to build commercial profiles about particular individuals or devices.<br />
<br />
''This text would replace the audience measurement placeholder note in the editors' draft.''<br />
<br />
== Audience Measurement with large buckets ==<br />
<br />
Proposal form Rigo Wenning: [http://www.w3.org/mid/1455409.O2aSxzv7j6@hegel.sophia.w3.org email]<br />
<br />
Add the following bullet to the list of normative clauses in Kathy Joe's proposal:<br />
<br />
* MUST NOT be aggregated into categories and buckets with less than 812 <br />
Members<br />
<br />
<br />
== Audience Measurement with Deidentified and Protocol Data ==<br />
<br />
Proposal from Lee Tien: [http://lists.w3.org/Archives/Public/public-tracking/2013Jun/0320.html email]<br />
<br />
=== New text ===<br />
<br />
A third party MAY use deidentified data for audience measurement. A third party MAY also use protocol information for audience measurement, subject to a two-week retention period.<br />
<br />
''This text would replace the audience measurement placeholder note in the editors' draft. See [[Privacy/TPWG/Change Proposal Short Term|Change Proposal Short Term]] for definition of protocol information.''</div>
Roessler
https://www.w3.org/wiki/index.php?title=Security&diff=65698
Security
2013-04-25T20:22:08Z
<p>Roessler: </p>
<hr />
<div>This is not [http://www.w3.org/Security/wiki the wiki you are looking for].</div>
Roessler
https://www.w3.org/wiki/index.php?title=HTML/wg/2013-04-Agenda&diff=65593
HTML/wg/2013-04-Agenda
2013-04-23T16:31:32Z
<p>Roessler: Fixing IRC channel</p>
<hr />
<div>{{stub}}<br />
<br />
= HTML Working Group 2013 April Meeting =<br />
<br />
This page is for the [[HTML/wg|HTML WG]] f2f: 23-24 April (Tuesday-Wednesday).<br />
<br />
<span style="color:#ff0000">'''Participants MUST [https://www.w3.org/2002/09/wbs/40318/html-april-2013/ register] for this meeting by 5-Apr-2012.'''</span><br />
<br />
<span style="color:#ff0000">'''This Meeting Page, in particular the Agenda, is a WorkInProgress and Will Change!'''</span><br />
<br />
<br />
== Working Group Meetings schedule ==<br />
<br />
{| style="background-color:#ffffcc;" border="1" cellpadding="10" cellspacing="0"<br />
!+ colspan="4"|April 2013<br />
|-<br />
!Tuesday 23<br />
!Wednesday 24<br />
!Thursday 25<br />
!Friday 26<br />
|-<br />
!+ colspan="2" style="background-color:rgba(0,255,0,0.3);"|HTML<br />
!+ colspan="2" style="background-color:rgba(255,255,0,0.3);"|[http://www.w3.org/wiki/Webapps/April2013Meeting Web Applications] (*)<br />
|-<br />
!+ colspan="2" style="background-color:rgba(0,0,255,0.3);"|[http://www.w3.org/2012/webcrypto/wiki/F2F_April2013 Web Cryptography]<br />
!+ colspan="2" style="background-color:rgba(255,0,0,0.3);"|[https://www.w3.org/2002/09/wbs/49309/webappsecsvapr2013/ Web Application Security]<br />
|-<br />
!+ style="background-color:#ccc;"|<br />
!+ colspan="2" style="background-color:rgba(255,0,255,0.3);"|[http://www.w3.org/WAI/PF/meetings/2013-04-ftf Protocols and Formats]<br />
!+ style="background-color:#ccc;"|<br />
|}<br />
<br />
(*) The Web Applications Working Group ends at noon on Friday 26.<br />
<br />
NOTE: Paypal is hosting a reception at 4-6pm on Wed Apr 24 at the meeting location.<br />
<br />
== Specifications, Documents and References ==<br />
<br />
See<br />
<br />
* [http://www.w3.org/html/wg/ Group homepage]<br />
* [http://www.w3.org/wiki/HTML/Publications Publications]<br />
<br />
== Potential Topics ==<br />
<br />
[add your agenda topic request here]<br />
<br />
<br />
** Current open bugs<br />
** Settling the question of normativity<br />
* Assigning a transcript to audio or video (ISSUE-194)(A11Y TF)<br />
* Web Performance WG issues related to HTML5 (Daniel)<br />
* Extension specs status<br />
** Moving Image Description Extension to Last Call and plans for re-integration with HTML 5.1 (A11Y TF)<br />
** Status check on other extensions specs<br />
<br />
== Logistics ==<br />
<br />
* Meeting Host = eBay<br />
* IRC channel = #html-wg; irc.w3.org (available ports are 6667, 6665, or 21)<br />
* Dates = April 23-24 2013<br />
* Time = See below; all times are US West Coast time zone<br />
* Location = eBay, 2211 north 1st street, San Jose, CA, 95131<br />
* Meeting Room = Building 12, Second floor, Roundtable room<br />
* Everyone will be required to check in at the front desk in building 10 and obtain a guest badge.<br />
* Guest Wireless access - the ssid is "eBayGuest" and the password is "BuyItNow!"<br />
* Zakim Bridge +1.617.761.6200, conference 4865 ("HTML"). [http://www.w3.org/2006/tools/wiki/Zakim-SIP SIP access] is available via a gateway.<br />
<br />
For nearby hotels, see the [http://www.w3.org/WAI/PF/meetings/2013-04-ftf Protocols and Formats page]<br />
<br />
== Agenda April 23 ==<br />
<br />
* 09:00 - 09:45 Tweak agenda à la an [http://en.wikipedia.org/wiki/Unconference unconference style meeting]<br />
* 09:45 - 12:00 TBD<br />
* 9:30 - 10:15 Candidate Recommendation status part 1 (Robin)<br />
** HTML Test Suite coverage, gaps and status<br />
** Usage of Github and branching (Kris)<br />
** Review of which parts of HTML5 pass the "passive exit criteria"<br />
** Status of HTML 5.1 and Canvas open bugs<br />
** Status of Features at Risk (more, less?)<br />
** Getting Microdata to CR (Editorial team)<br />
* 10:30 - 12:00 Candidate Recommendation status (part 2)<br />
* 12:00 - 13:00 Lunch<br />
* 13:00 - 14:00 Media Source Extensions (MSE) (Media TF) (90 mins)<br />
** Current open bugs <br />
** Getting MSE to Last Call <br />
** Note: Media Task Force would like to request a slot on the morning of April 23 PM because some members will be unavailable on April 24 <br />
* 14:00 - 15:30 Encrypted Media Extensions (EME) (Media TF) (90 mins)<br />
** Current open bugs and issues<br />
** Encouraging alternate media to be in the clear when primary media is encrypted (A11Y TF)<br />
** First Public Working Draft status <br />
** Note: Media Task Force would like to request a slot on the morning of April 23 PM because some members will be unavailable on April 24 <br />
* 15:30 - 17:00 TBD<br />
<br />
== Agenda April 24 ==<br />
<br />
* 09:00 - 10:15 Miscellaneous topics (including polyglot)<br />
** Moving the Polyglot spec forward (Eliott)<br />
** Plans for heartbeat publications (Editorial team)<br />
* 10:15 - 17:00 TBD</div>
Roessler
https://www.w3.org/wiki/index.php?title=ChairTraining&diff=65001
ChairTraining
2013-04-04T16:11:27Z
<p>Roessler: Created page with "= Chair Training Curriculum = == W3C Values == “W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission.” -- W3C Process, 1 Introduction…"</p>
<hr />
<div>= Chair Training Curriculum =<br />
<br />
== W3C Values ==<br />
<br />
“W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission.” -- W3C Process, 1 Introduction<br />
<br />
* Respect<br />
* Overall goal of pushing the Web forward<br />
* Neutral<br />
* Fairness<br />
<br />
== Rules around groups: Process, IP, Anti-trust ==<br />
<br />
* participation policy and expectations<br />
* PWET training<br />
* process basics: issue tracking and reopening<br />
* decision processes<br />
* editing policies - commit then review, review then commit<br />
<br />
<br />
* Anti-trust<br />
* Conflict of Interest<br />
* Conflict of Interest as a Chair<br />
<br />
<br />
* Document license<br />
* Patent policy<br />
* External contributions<br />
<br />
* Horizontal reviews<br />
* Coordination with other Groups<br />
* Coordination with other standard bodies<br />
<br />
== Mechanics ==<br />
<br />
* Minutes taking<br />
* How to use archives<br />
* Getting action items done<br />
* Creating subgroup, task forces<br />
* Editorial Teams<br />
* Staying on schedule<br />
<br />
<br />
* Press Releases<br />
* How to work with Comm team<br />
* How to manage press and outside communications while you’re working<br />
<br />
* How to manage a Last Call, How to come up with CR exit criteria<br />
* Structuring outside comments and reviews<br />
<br />
* How to manage testing<br />
<br />
== Soft factors: values, and the art of chairing ==<br />
<br />
"art of consensus"<br />
<br />
<br />
* how to run effective meetings / build agendas<br />
* how to frame an issue, how to frame a question<br />
* roles in WG: team contact, Chair, editor, test suite leader, domain lead, Director<br />
<br />
* How to manage disruptive participants<br />
* How to manage factions (case studies?)<br />
<br />
* "leading by example"<br />
* How to connect out-of-band/private discussion with the rest of the group<br />
* When not to make a decision (due to lack of agreement)<br />
<br />
* Managing scope, extensions, rechartering, V vs V.next (the mythical version 2 trick :)<br />
* Using CR phase to start work on V.next<br />
* Use Cases and Requirements<br />
<br />
== Tooling ==<br />
<br />
* respec, anolis, etc.<br />
* WG homepage<br />
* IRC, Zakim, RRSAgent<br />
* CVS/HG/GIT<br />
* WBS<br />
* Doodle<br />
* /QA/<br />
* Event calendar<br />
* Tracker, bugzilla<br />
* etherpad, google doc, etc.<br />
<br />
= Methods of training delivery =<br />
<br />
* TPAC annual session<br />
* Separate training day<br />
* case based study session -- using experienced chairs to introduce a case that is then discussed in the group</div>
Roessler
https://www.w3.org/wiki/index.php?title=Privacy/DNT-Breakouts&diff=64029
Privacy/DNT-Breakouts
2013-02-11T19:02:51Z
<p>Roessler: </p>
<hr />
<div>== Main room ==<br />
<br />
Star Conference Room, [http://www.csail.mit.edu/resources/maps/4D/D463.gif D463]<br />
<br />
IRC: [http://irc.w3.org/?channels=dnt #dnt]<br />
<br />
Phone: +1.617.761.6200, conference code 87225<br />
<br />
== Breakout rooms ==<br />
<br />
=== Group A ===<br />
<br />
IRC: [http://irc.w3.org/?channels=dnta #dnta]<br />
<br />
Phone: +1.617.761.6200, conference code 26631<br />
<br />
Meeting room: [http://www.csail.mit.edu/resources/maps/4G/G451.gif G451]<br />
<br />
Last Names: A-D<br />
<br />
Section Leader: Justin Brookman<br />
<br />
=== Group B ===<br />
<br />
IRC: [http://irc.w3.org/?channels=dntb #dntb]<br />
<br />
Phone: +1.617.761.6200, conference code 26632<br />
<br />
Meeting room: [http://www.csail.mit.edu/resources/maps/6G/G631.gif G631]<br />
<br />
Last Names: E-L<br />
<br />
Section Leader: Nick Doty<br />
<br />
=== Group C ===<br />
<br />
IRC: [http://irc.w3.org/?channels=dntc #dntc]<br />
<br />
Phone: +1.617.761.6200, conference code 26633<br />
<br />
Meeting room: [http://www.csail.mit.edu/resources/maps/7G/G725.gif G725]<br />
<br />
Last Names: M-R<br />
<br />
Section Leader: David Singer<br />
<br />
=== Group D ===<br />
<br />
IRC: [http://irc.w3.org/?channels=dntd #dntd]<br />
<br />
Phone: +1.617.761.6200, conference code 26634<br />
<br />
Meeting room: [http://www.csail.mit.edu/resources/maps/4D/D407.gif D407]<br />
<br />
Last Names: S-V<br />
<br />
Section Leaders: Dan Auerbach / Wendy Seltzer<br />
<br />
=== Group E ===<br />
<br />
IRC: [http://irc.w3.org/?channels=dnte #dnte]<br />
<br />
Phone: +1.617.761.6200, conference code 87225<br />
<br />
Meeting room: Star Conference Room, [http://www.csail.mit.edu/resources/maps/4D/D463.gif D463]<br />
<br />
Last Names: W-Z<br />
<br />
Section Leaders: Heather West / Thomas Roessler<br />
<br />
= Monday break-out session =<br />
<br />
High-level questions for group leaders:<br />
<br />
1. “Lifetime browsing history” is a phrase that is often used, but never defined clearly. What would LBH mean as a technical matter?<br />
<br />
2. In light of this definition, what technical measures would suppress or delete LBH?<br />
<br />
3. Tying LBH to the previous group discussions of “buckets” or “low-entropy cookies,” how can the latter continue while suppressing or deleting LBH?<br />
<br />
4. Are there any compelling use cases for retaining detailed browsing history beyond a general time limit on retention? <br />
<br />
5. If so, how would you limit those use cases consistent with the goals of: (1) limiting LBH; while (2) enabling “buckets” or “low-entropy cookies”?<br />
<br />
<br />
<br />
Background and more detailed set of questions for group leaders to consider:<br />
<br />
1. Describing the task: what would it mean to say that a standard means that a user will have “no lifetime browsing history” (“LBH”) or “no long-term browsing history” (also “LBH”) across multiple sites?<br />
Roughly speaking: (a) limit on specific content in refers (such as search terms); (b) limit on specific story title on a newspaper site (“newspaper.com” is not suppressed, but “newspaper.com.specific story on a government leader’s personal life” is suppressed); (c) also suppress “newspaper.com”?, or (d) anything else?<br />
<br />
[Note: Today we are focusing on this task; not taking a position in this exercise about what other mechanisms, inside or outside of DNT, may address user choice about target marketing.]<br />
<br />
2. Given that task definition, what measures exist that could address or achieve suppression of LBH?<br />
Deletion? Of what?<br />
Delinking or de-identification? (Note – the group session on Tuesday will be on specific techniques of de-identification/delinking, after Ed Felten’s presentation on that subject.)<br />
Other ways so that the detailed URIs do not go past a certain time?<br />
<br />
3. There is interest in “low-entropy cookies” or “buckets” continuing along with the limits on LBH. What would it mean, technically, to continue these while suppressing LBH?<br />
Where use buckets/low-entropy cookie, how define minimum bucket size? Any other dimensions relevant to designing what would qualify as a bucket or low-entropy cookie?<br />
<br />
4. Any other big-picture things to consider if DNT standard leads to suppression of LBH, while permitting low-entropy cookies?<br />
<br />
5. What role for retention of IP addresses, for what purposes, in suppressing LBH?<br />
<br />
6. Here is one option for “short term use”: “Operators may collect and retain data related to a communication in a third-party context for up to N weeks. During this time, operators may render data deidentified or perform processing of the data for any of the other permitted uses.”<br />
To what extent would this approach fit with the goal of suppressing LBH? If this approach to short term use is in the standard, are there any uses where details about the browsing history would be retained longer? What are those, and why?<br />
Length of time – how would you think about a possible time limit for “short term use”?<br />
<br />
7. Moving to specific uses, we had the recent presentation from Media Rating Council about a general one-year retention, but with exceptions allowed where companies have cited privacy concerns. <br />
A different but similar audit function concerns financial payments – did a site deliver the promised advertisements? <br />
Query – many audit functions are based on sampling rather than having every transaction audited. To what extent has sampling been considered in the DNT process, and to what extent would retention of samples be consistent with suppressing LBH?<br />
<br />
8. The MRC speaker said that most campaigns tested by his group are short-term, such as a few weeks or less. What about a presumption that campaigns are that length, but with an exceptions process if a campaign is, of its nature, longer-term?<br />
<br />
9. What about cybersecurity, and keeping the detailed URIs? When asked about a one year limit, one person mentioned Black Friday (the day after Thanksgiving), as an example where annual events are important for telling a denial of service attack from heavy shopping traffic. What is the relevance of highly detailed content of this sort over the long term? Suggestions for mitigating the risks that these security databases become the target for subpoenas or other requests that show LBH?<br />
<br />
10. How would other possible permitted uses interact with a limit on LBH? [Leader – you can refer to bare bones text for the current list.] If there is a market research permitted use (and some have objected to that), any reason to have the level of detail of the specific URI for more than the length of the short term use?<br />
<br />
11. Wrapping up. In light of the discussion, is the goal of suppressing LBH a useful task to address in DNT process? Do you have a coherent way to do that? What are the pros and cons of working on this goal?</div>
Roessler
https://www.w3.org/wiki/index.php?title=MutualReviewExpectations&diff=56010
MutualReviewExpectations
2011-12-23T15:05:18Z
<p>Roessler: /* Goals and Scope */</p>
<hr />
<div>= W3C/IETF mutual review expectations =<br />
<br />
Mark Nottingham <mnot@mnot.net>, Thomas Roessler <tlr@w3.org><br />
<br />
2011-10-16<br />
<br />
Please announce any changes you make to this document on public-ietf-w3c@w3.org.<br />
<br />
== Introduction ==<br />
<br />
Occasionally, W3C and IETF produce specifications in close cooperation, sometimes marked by a significant formal dependency beween the specifications. A recent example is the websockets protocol and API specifications produced by the IETF hybi and W3C web applications working groups.<br />
<br />
W3C and IETF have similar, but not identical processes; some stages have identical names ("Last Call" in particular), but come with different expectations.<br />
<br />
The processes referred to in this document are documented in:<br />
<br />
* [http://tools.ietf.org//html/rfc2026 RFC 2026], The Internet Standards Process, as updated <br />
* [http://tools.ietf.org/html/rfc2418 RFC 2418], IETF Working Group Guidelines and Procedures <br />
* [http://www.w3.org/2005/10/Process-20051014/ W3C Process Document]<br />
<br />
== Goals and Scope ==<br />
<br />
The goal of this document is to establish mutual review expectations and responsibilities for W3C and IETF specifications with close dependencies. The scope of this document is limited to the phases of the IETF process leading up to publication of a document as Proposed Standard, and to the phases of the W3C process leading up to publication of a document as Candidate Recommendation, or as Proposed Recommendation if the Candidate Recommendation step is skipped.<br />
<br />
Both of these process steps correspond to publication of a document for initial implementation. In both cases, WGs may decide to further iterate documents (possibly returning to Last Call and Candidate Recommendation several times), or to make certain changes as a result of implementation experience that are incorporated as a document proceeds further along the standards track. Where that is the case, groups should fail in favor of mutual review and transparency.<br />
<br />
This document collects current experience and provides guidance for WG chairs and other parties involved in work at the W3C and IETF on how to orchestrate the respective processes. It does not add new obligations to either process.<br />
<br />
== Context: The W3C/IETF liaison relationship ==<br />
<br />
Working groups on both the W3C and IETF side have WG chairs who are responsible for managing the day-to-day operation of the group.<br />
<br />
The liaison relationship between the IETF and the W3C is managed by the IAB and the W3C staff, respectively. Traditionally, the IAB assigns one or several individuals from the IETF community as IETF liaisons to the W3C, and one or several W3C staff members serve as the W3C's liaisons to the IETF. The relationship mostly operates through regular telephone conferences (typically in the run-up to major meetings), e-mail discussions on the public-ietf-w3c@w3.org mailing list, and through attendance of major meetings. Formal liaison statements are used under exceptional circumstances.<br />
<br />
The liaison telephone conferences are attended by the assigned liaisons from both sides. The IETF Application Area Directors and the W3C Director have standing invitations to join the liaison meetings. IAB members may join the meetings.<br />
<br />
Other individuals with specific expertise participate at the invitation of the liaisons.<br />
<br />
It is appropriate to copy the (archived) public-ietf-w3c@w3.org mailing list on relevant communications between IETF and W3C participants. The archives of this list serve to document agreements about review time lines, scopes, and issues.<br />
<br />
The W3C/IETF liaison team is generally involved in chartering negotiations that require mutual review. The liaison team keeps an online list of WGs to which the coordination expectations in this document apply at [[W3cIetfCoordinatedWGs]].<br />
<br />
<br />
== Working Group Coordination ==<br />
<br />
<br />
=== Specification Development before Last Call ===<br />
<br />
Working Group coordination is expected to be largely informal and on a technical level. Where groups have closely related deliverables, overlap between working groups and direct collaboration between document editors are useful instruments toward ensuring appropriate coordination.<br />
<br />
Responsibility for this day-to-day relationship lies with the respective Working Group chairs. The formal liaisons are available to facilitate introductions and enable chairs to discharge this responsibility appropriately.<br />
<br />
<br />
=== Moving to Last Call ===<br />
<br />
Where documents have dependencies that create mutual review expectations, Working Groups should align their Last Call time lines.<br />
<br />
In the IETF process, the decision to request IETF Last Call is often preceded by a Working Group Last Call; issuing a Working Group Last Call is at the discretion of the WG chair.<br />
<br />
In the W3C process, the decision to request W3C Last Call is often preceded by a cooling off period during which the WG has no particular open issues to work on, but leaves a window for participants to perform a final review.<br />
<br />
The goal of this document is to ensure that substantive technical cross-review occurs before IETF Last Call or W3C Last Call is requested, but at a stage where specifications are stable enough for outside review. When exactly that threshold is crossed is at the discretion of the WG chairs.<br />
<br />
Therefore, Working Group chairs work with their peers in the other organization to ensure that the respective specifications have received substantive mutual review before they request W3C and IETF<br />
Last Call.<br />
<br />
This goal can be achieved by requesting outside review during the equivalent of WG Last Call.<br />
<br />
Requests for review are most useful if they include pointers at the relevant drafts, set expectations about open issues and stability of the documents, and give a time line during which review comments will be expected.<br />
<br />
Working Group chairs cannegotiate other mechanisms and specific time lines (including joint meetings, joint editors, earlier review schedules, ...) that ensure the same goal of mutual review. To ensure useful coordination, such negotiations often involve the W3C and IETF liaison team, the W3C staff contacts, and the relevant Area Directors (or their designees).<br />
<br />
The chosen review mechanism is best documented in a note to public-ietf-w3c@w3.org; where a formal exchange of calls for review occurs between two groups, that call for review is appropriately copied to public-ietf-w3c@w3.org.<br />
<br />
Where mutual review leads to additional technical changes, it is the chairs' responsibility to ensure awareness by the other Working Group of these technical changes, and to negotiate time lines going forward with the assistance of the liaison team.<br />
<br />
<br />
=== Last Call and Beyond ===<br />
<br />
While Working Groups are welcome to exchange technical reviews during Last Call, this process is intended to produce a coherent set of specifications that permit joint external review prior to entering Last Call. Therefore, we expect major last call comments between W3C and IETF Working Groups to be a rare occurence that is to be avoided.<br />
<br />
In the W3C process, a W3C Last Call is ended by a Working Group requesting transition to Candidate Recommendation (or, in exceptional cases, Proposed Recommendation). A precondition to this transition is the availability of a disposition of comments that documents how the Working Group has taken Last Call comments into account. When changes made in response to Last Call comments would invalidate prior review, it is common for groups to iterate several Last Call cycles.<br />
<br />
A W3C last call comment period lasts at least three weeks.<br />
<br />
<br />
In the IETF process, the IESG takes comments from the IETF community for a period of at least two weeks, and can then request changes to the document, or further advance the document. (See section 8 of RFC 2418.) An IETF last call is not intended to serve as a vehicle for substantive comments.<br />
<br />
<br />
Where W3C and IETF documents have significant mutual dependencies, W3C and IETF Last Call announcements should be notified to the chairs of the respective Working Groups, copying public-ietf-w3c@w3.org.<br />
<br />
The IESG's publication of a document as a Proposed Standard and the W3C's publication of a document as Candidate Recommendation (or Proposed Recommendation) should be synchronized, and the time line planned in advance.<br />
<br />
This planning discussion appropriately occurs on an IETF/W3C liaison call that is attended by the relevant Area Directors and Working Group chairs.<br />
<br />
It is the responsibility of the Working Group chairs on both sides to request this agenda item in a note to the public-ietf-w3c@w3.org mailing list, as they plan for Last Call. The W3C and IETF liaisons will track these requests, and will ensure that the necessary participants attend the requisite liaison calls.</div>
Roessler
https://www.w3.org/wiki/index.php?title=MutualReviewExpectations&diff=56009
MutualReviewExpectations
2011-12-22T21:01:28Z
<p>Roessler: /* W3C/IETF mutual review expectations */</p>
<hr />
<div>= W3C/IETF mutual review expectations =<br />
<br />
Mark Nottingham <mnot@mnot.net>, Thomas Roessler <tlr@w3.org><br />
<br />
2011-10-16<br />
<br />
Please announce any changes you make to this document on public-ietf-w3c@w3.org.<br />
<br />
== Introduction ==<br />
<br />
Occasionally, W3C and IETF produce specifications in close cooperation, sometimes marked by a significant formal dependency beween the specifications. A recent example is the websockets protocol and API specifications produced by the IETF hybi and W3C web applications working groups.<br />
<br />
W3C and IETF have similar, but not identical processes; some stages have identical names ("Last Call" in particular), but come with different expectations.<br />
<br />
The processes referred to in this document are documented in:<br />
<br />
* [http://tools.ietf.org//html/rfc2026 RFC 2026], The Internet Standards Process, as updated <br />
* [http://tools.ietf.org/html/rfc2418 RFC 2418], IETF Working Group Guidelines and Procedures <br />
* [http://www.w3.org/2005/10/Process-20051014/ W3C Process Document]<br />
<br />
== Goals and Scope ==<br />
<br />
The goal of this document is to establish mutual review expectations and responsibilities for W3C and IETF specifications with close dependencies. The scope of this document is limited to the phases of the IETF process leading up to publication of a document as Proposed Standard, and to the phases of the W3C process leading up to publication of a document as Candidate Recommendation, or as Proposed Recommendation if the Candidate Recommendation step is skipped.<br />
<br />
Both of these process steps correspond to publication of a document for initial implementation. In both cases, WGs may decide to further iterate documents (possibly returning to Last Call and Candidate Recommendation several times), or to make certain changes as a result of implementation experience that are incorporated as a document proceeds further along the standards track. Where that is the case, groups should fail in favor of mutual review and transparency.<br />
<br />
== Context: The W3C/IETF liaison relationship ==<br />
<br />
Working groups on both the W3C and IETF side have WG chairs who are responsible for managing the day-to-day operation of the group.<br />
<br />
The liaison relationship between the IETF and the W3C is managed by the IAB and the W3C staff, respectively. Traditionally, the IAB assigns one or several individuals from the IETF community as IETF liaisons to the W3C, and one or several W3C staff members serve as the W3C's liaisons to the IETF. The relationship mostly operates through regular telephone conferences (typically in the run-up to major meetings), e-mail discussions on the public-ietf-w3c@w3.org mailing list, and through attendance of major meetings. Formal liaison statements are used under exceptional circumstances.<br />
<br />
The liaison telephone conferences are attended by the assigned liaisons from both sides. The IETF Application Area Directors and the W3C Director have standing invitations to join the liaison meetings. IAB members may join the meetings.<br />
<br />
Other individuals with specific expertise participate at the invitation of the liaisons.<br />
<br />
It is appropriate to copy the (archived) public-ietf-w3c@w3.org mailing list on relevant communications between IETF and W3C participants. The archives of this list serve to document agreements about review time lines, scopes, and issues.<br />
<br />
The W3C/IETF liaison team is generally involved in chartering negotiations that require mutual review. The liaison team keeps an online list of WGs to which the coordination expectations in this document apply at [[W3cIetfCoordinatedWGs]].<br />
<br />
<br />
== Working Group Coordination ==<br />
<br />
<br />
=== Specification Development before Last Call ===<br />
<br />
Working Group coordination is expected to be largely informal and on a technical level. Where groups have closely related deliverables, overlap between working groups and direct collaboration between document editors are useful instruments toward ensuring appropriate coordination.<br />
<br />
Responsibility for this day-to-day relationship lies with the respective Working Group chairs. The formal liaisons are available to facilitate introductions and enable chairs to discharge this responsibility appropriately.<br />
<br />
<br />
=== Moving to Last Call ===<br />
<br />
Where documents have dependencies that create mutual review expectations, Working Groups should align their Last Call time lines.<br />
<br />
In the IETF process, the decision to request IETF Last Call is often preceded by a Working Group Last Call; issuing a Working Group Last Call is at the discretion of the WG chair.<br />
<br />
In the W3C process, the decision to request W3C Last Call is often preceded by a cooling off period during which the WG has no particular open issues to work on, but leaves a window for participants to perform a final review.<br />
<br />
The goal of this document is to ensure that substantive technical cross-review occurs before IETF Last Call or W3C Last Call is requested, but at a stage where specifications are stable enough for outside review. When exactly that threshold is crossed is at the discretion of the WG chairs.<br />
<br />
Therefore, Working Group chairs work with their peers in the other organization to ensure that the respective specifications have received substantive mutual review before they request W3C and IETF<br />
Last Call.<br />
<br />
This goal can be achieved by requesting outside review during the equivalent of WG Last Call.<br />
<br />
Requests for review are most useful if they include pointers at the relevant drafts, set expectations about open issues and stability of the documents, and give a time line during which review comments will be expected.<br />
<br />
Working Group chairs cannegotiate other mechanisms and specific time lines (including joint meetings, joint editors, earlier review schedules, ...) that ensure the same goal of mutual review. To ensure useful coordination, such negotiations often involve the W3C and IETF liaison team, the W3C staff contacts, and the relevant Area Directors (or their designees).<br />
<br />
The chosen review mechanism is best documented in a note to public-ietf-w3c@w3.org; where a formal exchange of calls for review occurs between two groups, that call for review is appropriately copied to public-ietf-w3c@w3.org.<br />
<br />
Where mutual review leads to additional technical changes, it is the chairs' responsibility to ensure awareness by the other Working Group of these technical changes, and to negotiate time lines going forward with the assistance of the liaison team.<br />
<br />
<br />
=== Last Call and Beyond ===<br />
<br />
While Working Groups are welcome to exchange technical reviews during Last Call, this process is intended to produce a coherent set of specifications that permit joint external review prior to entering Last Call. Therefore, we expect major last call comments between W3C and IETF Working Groups to be a rare occurence that is to be avoided.<br />
<br />
In the W3C process, a W3C Last Call is ended by a Working Group requesting transition to Candidate Recommendation (or, in exceptional cases, Proposed Recommendation). A precondition to this transition is the availability of a disposition of comments that documents how the Working Group has taken Last Call comments into account. When changes made in response to Last Call comments would invalidate prior review, it is common for groups to iterate several Last Call cycles.<br />
<br />
A W3C last call comment period lasts at least three weeks.<br />
<br />
<br />
In the IETF process, the IESG takes comments from the IETF community for a period of at least two weeks, and can then request changes to the document, or further advance the document. (See section 8 of RFC 2418.) An IETF last call is not intended to serve as a vehicle for substantive comments.<br />
<br />
<br />
Where W3C and IETF documents have significant mutual dependencies, W3C and IETF Last Call announcements should be notified to the chairs of the respective Working Groups, copying public-ietf-w3c@w3.org.<br />
<br />
The IESG's publication of a document as a Proposed Standard and the W3C's publication of a document as Candidate Recommendation (or Proposed Recommendation) should be synchronized, and the time line planned in advance.<br />
<br />
This planning discussion appropriately occurs on an IETF/W3C liaison call that is attended by the relevant Area Directors and Working Group chairs.<br />
<br />
It is the responsibility of the Working Group chairs on both sides to request this agenda item in a note to the public-ietf-w3c@w3.org mailing list, as they plan for Last Call. The W3C and IETF liaisons will track these requests, and will ensure that the necessary participants attend the requisite liaison calls.</div>
Roessler
https://www.w3.org/wiki/index.php?title=MutualReviewExpectations&diff=56008
MutualReviewExpectations
2011-12-22T19:17:43Z
<p>Roessler: /* Introduction */</p>
<hr />
<div>= W3C/IETF mutual review expectations =<br />
<br />
Mark Nottingham <mnot@mnot.net>, Thomas Roessler <tlr@w3.org><br />
<br />
2011-10-16<br />
<br />
<br />
<br />
== Introduction ==<br />
<br />
Occasionally, W3C and IETF produce specifications in close cooperation, sometimes marked by a significant formal dependency beween the specifications. A recent example is the websockets protocol and API specifications produced by the IETF hybi and W3C web applications working groups.<br />
<br />
W3C and IETF have similar, but not identical processes; some stages have identical names ("Last Call" in particular), but come with different expectations.<br />
<br />
The processes referred to in this document are documented in:<br />
<br />
* [http://tools.ietf.org//html/rfc2026 RFC 2026], The Internet Standards Process, as updated <br />
* [http://tools.ietf.org/html/rfc2418 RFC 2418], IETF Working Group Guidelines and Procedures <br />
* [http://www.w3.org/2005/10/Process-20051014/ W3C Process Document]<br />
<br />
== Goals and Scope ==<br />
<br />
The goal of this document is to establish mutual review expectations and responsibilities for W3C and IETF specifications with close dependencies. The scope of this document is limited to the phases of the IETF process leading up to publication of a document as Proposed Standard, and to the phases of the W3C process leading up to publication of a document as Candidate Recommendation, or as Proposed Recommendation if the Candidate Recommendation step is skipped.<br />
<br />
Both of these process steps correspond to publication of a document for initial implementation. In both cases, WGs may decide to further iterate documents (possibly returning to Last Call and Candidate Recommendation several times), or to make certain changes as a result of implementation experience that are incorporated as a document proceeds further along the standards track. Where that is the case, groups should fail in favor of mutual review and transparency.<br />
<br />
== Context: The W3C/IETF liaison relationship ==<br />
<br />
Working groups on both the W3C and IETF side have WG chairs who are responsible for managing the day-to-day operation of the group.<br />
<br />
The liaison relationship between the IETF and the W3C is managed by the IAB and the W3C staff, respectively. Traditionally, the IAB assigns one or several individuals from the IETF community as IETF liaisons to the W3C, and one or several W3C staff members serve as the W3C's liaisons to the IETF. The relationship mostly operates through regular telephone conferences (typically in the run-up to major meetings), e-mail discussions on the public-ietf-w3c@w3.org mailing list, and through attendance of major meetings. Formal liaison statements are used under exceptional circumstances.<br />
<br />
The liaison telephone conferences are attended by the assigned liaisons from both sides. The IETF Application Area Directors and the W3C Director have standing invitations to join the liaison meetings. IAB members may join the meetings.<br />
<br />
Other individuals with specific expertise participate at the invitation of the liaisons.<br />
<br />
It is appropriate to copy the (archived) public-ietf-w3c@w3.org mailing list on relevant communications between IETF and W3C participants. The archives of this list serve to document agreements about review time lines, scopes, and issues.<br />
<br />
The W3C/IETF liaison team is generally involved in chartering negotiations that require mutual review. The liaison team keeps an online list of WGs to which the coordination expectations in this document apply at [[W3cIetfCoordinatedWGs]].<br />
<br />
<br />
== Working Group Coordination ==<br />
<br />
<br />
=== Specification Development before Last Call ===<br />
<br />
Working Group coordination is expected to be largely informal and on a technical level. Where groups have closely related deliverables, overlap between working groups and direct collaboration between document editors are useful instruments toward ensuring appropriate coordination.<br />
<br />
Responsibility for this day-to-day relationship lies with the respective Working Group chairs. The formal liaisons are available to facilitate introductions and enable chairs to discharge this responsibility appropriately.<br />
<br />
<br />
=== Moving to Last Call ===<br />
<br />
Where documents have dependencies that create mutual review expectations, Working Groups should align their Last Call time lines.<br />
<br />
In the IETF process, the decision to request IETF Last Call is often preceded by a Working Group Last Call; issuing a Working Group Last Call is at the discretion of the WG chair.<br />
<br />
In the W3C process, the decision to request W3C Last Call is often preceded by a cooling off period during which the WG has no particular open issues to work on, but leaves a window for participants to perform a final review.<br />
<br />
The goal of this document is to ensure that substantive technical cross-review occurs before IETF Last Call or W3C Last Call is requested, but at a stage where specifications are stable enough for outside review. When exactly that threshold is crossed is at the discretion of the WG chairs.<br />
<br />
Therefore, Working Group chairs work with their peers in the other organization to ensure that the respective specifications have received substantive mutual review before they request W3C and IETF<br />
Last Call.<br />
<br />
This goal can be achieved by requesting outside review during the equivalent of WG Last Call.<br />
<br />
Requests for review are most useful if they include pointers at the relevant drafts, set expectations about open issues and stability of the documents, and give a time line during which review comments will be expected.<br />
<br />
Working Group chairs cannegotiate other mechanisms and specific time lines (including joint meetings, joint editors, earlier review schedules, ...) that ensure the same goal of mutual review. To ensure useful coordination, such negotiations often involve the W3C and IETF liaison team, the W3C staff contacts, and the relevant Area Directors (or their designees).<br />
<br />
The chosen review mechanism is best documented in a note to public-ietf-w3c@w3.org; where a formal exchange of calls for review occurs between two groups, that call for review is appropriately copied to public-ietf-w3c@w3.org.<br />
<br />
Where mutual review leads to additional technical changes, it is the chairs' responsibility to ensure awareness by the other Working Group of these technical changes, and to negotiate time lines going forward with the assistance of the liaison team.<br />
<br />
<br />
=== Last Call and Beyond ===<br />
<br />
While Working Groups are welcome to exchange technical reviews during Last Call, this process is intended to produce a coherent set of specifications that permit joint external review prior to entering Last Call. Therefore, we expect major last call comments between W3C and IETF Working Groups to be a rare occurence that is to be avoided.<br />
<br />
In the W3C process, a W3C Last Call is ended by a Working Group requesting transition to Candidate Recommendation (or, in exceptional cases, Proposed Recommendation). A precondition to this transition is the availability of a disposition of comments that documents how the Working Group has taken Last Call comments into account. When changes made in response to Last Call comments would invalidate prior review, it is common for groups to iterate several Last Call cycles.<br />
<br />
A W3C last call comment period lasts at least three weeks.<br />
<br />
<br />
In the IETF process, the IESG takes comments from the IETF community for a period of at least two weeks, and can then request changes to the document, or further advance the document. (See section 8 of RFC 2418.) An IETF last call is not intended to serve as a vehicle for substantive comments.<br />
<br />
<br />
Where W3C and IETF documents have significant mutual dependencies, W3C and IETF Last Call announcements should be notified to the chairs of the respective Working Groups, copying public-ietf-w3c@w3.org.<br />
<br />
The IESG's publication of a document as a Proposed Standard and the W3C's publication of a document as Candidate Recommendation (or Proposed Recommendation) should be synchronized, and the time line planned in advance.<br />
<br />
This planning discussion appropriately occurs on an IETF/W3C liaison call that is attended by the relevant Area Directors and Working Group chairs.<br />
<br />
It is the responsibility of the Working Group chairs on both sides to request this agenda item in a note to the public-ietf-w3c@w3.org mailing list, as they plan for Last Call. The W3C and IETF liaisons will track these requests, and will ensure that the necessary participants attend the requisite liaison calls.</div>
Roessler
https://www.w3.org/wiki/index.php?title=MutualReviewExpectations&diff=56007
MutualReviewExpectations
2011-12-22T19:17:28Z
<p>Roessler: </p>
<hr />
<div>= W3C/IETF mutual review expectations =<br />
<br />
Mark Nottingham <mnot@mnot.net>, Thomas Roessler <tlr@w3.org><br />
<br />
2011-10-16<br />
<br />
<br />
<br />
== Introduction ==<br />
<br />
Occasionally, W3C and IETF produce specifications in close cooperation, sometimes marked by a significant formal dependency beween the specifications. A recent example is the websockets protocol and API specifications produced by the IETF hybi and W3C web applications working groups.<br />
<br />
W3C and IETF have similar, but not identical processes; some stages have identical names ("Last Call" in paritcular), but come with different expectations.<br />
<br />
The processes referred to in this document are documented in:<br />
<br />
* [http://tools.ietf.org//html/rfc2026 RFC 2026], The Internet Standards Process, as updated <br />
* [http://tools.ietf.org/html/rfc2418 RFC 2418], IETF Working Group Guidelines and Procedures <br />
* [http://www.w3.org/2005/10/Process-20051014/ W3C Process Document]<br />
<br />
<br />
== Goals and Scope ==<br />
<br />
The goal of this document is to establish mutual review expectations and responsibilities for W3C and IETF specifications with close dependencies. The scope of this document is limited to the phases of the IETF process leading up to publication of a document as Proposed Standard, and to the phases of the W3C process leading up to publication of a document as Candidate Recommendation, or as Proposed Recommendation if the Candidate Recommendation step is skipped.<br />
<br />
Both of these process steps correspond to publication of a document for initial implementation. In both cases, WGs may decide to further iterate documents (possibly returning to Last Call and Candidate Recommendation several times), or to make certain changes as a result of implementation experience that are incorporated as a document proceeds further along the standards track. Where that is the case, groups should fail in favor of mutual review and transparency.<br />
<br />
== Context: The W3C/IETF liaison relationship ==<br />
<br />
Working groups on both the W3C and IETF side have WG chairs who are responsible for managing the day-to-day operation of the group.<br />
<br />
The liaison relationship between the IETF and the W3C is managed by the IAB and the W3C staff, respectively. Traditionally, the IAB assigns one or several individuals from the IETF community as IETF liaisons to the W3C, and one or several W3C staff members serve as the W3C's liaisons to the IETF. The relationship mostly operates through regular telephone conferences (typically in the run-up to major meetings), e-mail discussions on the public-ietf-w3c@w3.org mailing list, and through attendance of major meetings. Formal liaison statements are used under exceptional circumstances.<br />
<br />
The liaison telephone conferences are attended by the assigned liaisons from both sides. The IETF Application Area Directors and the W3C Director have standing invitations to join the liaison meetings. IAB members may join the meetings.<br />
<br />
Other individuals with specific expertise participate at the invitation of the liaisons.<br />
<br />
It is appropriate to copy the (archived) public-ietf-w3c@w3.org mailing list on relevant communications between IETF and W3C participants. The archives of this list serve to document agreements about review time lines, scopes, and issues.<br />
<br />
The W3C/IETF liaison team is generally involved in chartering negotiations that require mutual review. The liaison team keeps an online list of WGs to which the coordination expectations in this document apply at [[W3cIetfCoordinatedWGs]].<br />
<br />
<br />
== Working Group Coordination ==<br />
<br />
<br />
=== Specification Development before Last Call ===<br />
<br />
Working Group coordination is expected to be largely informal and on a technical level. Where groups have closely related deliverables, overlap between working groups and direct collaboration between document editors are useful instruments toward ensuring appropriate coordination.<br />
<br />
Responsibility for this day-to-day relationship lies with the respective Working Group chairs. The formal liaisons are available to facilitate introductions and enable chairs to discharge this responsibility appropriately.<br />
<br />
<br />
=== Moving to Last Call ===<br />
<br />
Where documents have dependencies that create mutual review expectations, Working Groups should align their Last Call time lines.<br />
<br />
In the IETF process, the decision to request IETF Last Call is often preceded by a Working Group Last Call; issuing a Working Group Last Call is at the discretion of the WG chair.<br />
<br />
In the W3C process, the decision to request W3C Last Call is often preceded by a cooling off period during which the WG has no particular open issues to work on, but leaves a window for participants to perform a final review.<br />
<br />
The goal of this document is to ensure that substantive technical cross-review occurs before IETF Last Call or W3C Last Call is requested, but at a stage where specifications are stable enough for outside review. When exactly that threshold is crossed is at the discretion of the WG chairs.<br />
<br />
Therefore, Working Group chairs work with their peers in the other organization to ensure that the respective specifications have received substantive mutual review before they request W3C and IETF<br />
Last Call.<br />
<br />
This goal can be achieved by requesting outside review during the equivalent of WG Last Call.<br />
<br />
Requests for review are most useful if they include pointers at the relevant drafts, set expectations about open issues and stability of the documents, and give a time line during which review comments will be expected.<br />
<br />
Working Group chairs cannegotiate other mechanisms and specific time lines (including joint meetings, joint editors, earlier review schedules, ...) that ensure the same goal of mutual review. To ensure useful coordination, such negotiations often involve the W3C and IETF liaison team, the W3C staff contacts, and the relevant Area Directors (or their designees).<br />
<br />
The chosen review mechanism is best documented in a note to public-ietf-w3c@w3.org; where a formal exchange of calls for review occurs between two groups, that call for review is appropriately copied to public-ietf-w3c@w3.org.<br />
<br />
Where mutual review leads to additional technical changes, it is the chairs' responsibility to ensure awareness by the other Working Group of these technical changes, and to negotiate time lines going forward with the assistance of the liaison team.<br />
<br />
<br />
=== Last Call and Beyond ===<br />
<br />
While Working Groups are welcome to exchange technical reviews during Last Call, this process is intended to produce a coherent set of specifications that permit joint external review prior to entering Last Call. Therefore, we expect major last call comments between W3C and IETF Working Groups to be a rare occurence that is to be avoided.<br />
<br />
In the W3C process, a W3C Last Call is ended by a Working Group requesting transition to Candidate Recommendation (or, in exceptional cases, Proposed Recommendation). A precondition to this transition is the availability of a disposition of comments that documents how the Working Group has taken Last Call comments into account. When changes made in response to Last Call comments would invalidate prior review, it is common for groups to iterate several Last Call cycles.<br />
<br />
A W3C last call comment period lasts at least three weeks.<br />
<br />
<br />
In the IETF process, the IESG takes comments from the IETF community for a period of at least two weeks, and can then request changes to the document, or further advance the document. (See section 8 of RFC 2418.) An IETF last call is not intended to serve as a vehicle for substantive comments.<br />
<br />
<br />
Where W3C and IETF documents have significant mutual dependencies, W3C and IETF Last Call announcements should be notified to the chairs of the respective Working Groups, copying public-ietf-w3c@w3.org.<br />
<br />
The IESG's publication of a document as a Proposed Standard and the W3C's publication of a document as Candidate Recommendation (or Proposed Recommendation) should be synchronized, and the time line planned in advance.<br />
<br />
This planning discussion appropriately occurs on an IETF/W3C liaison call that is attended by the relevant Area Directors and Working Group chairs.<br />
<br />
It is the responsibility of the Working Group chairs on both sides to request this agenda item in a note to the public-ietf-w3c@w3.org mailing list, as they plan for Last Call. The W3C and IETF liaisons will track these requests, and will ensure that the necessary participants attend the requisite liaison calls.</div>
Roessler
https://www.w3.org/wiki/index.php?title=MutualReviewExpectations&diff=56006
MutualReviewExpectations
2011-12-22T19:14:52Z
<p>Roessler: /* Goals and Scope */</p>
<hr />
<div>= W3C/IETF mutual review expectations =<br />
<br />
Mark Nottingham <mnot@mnot.net>, Thomas Roessler <tlr@w3.org><br />
<br />
2011-10-16<br />
<br />
<br />
<br />
== Introduction ==<br />
<br />
Occasionally, W3C and IETF produce specifications in close<br />
cooperation, sometimes marked by a significant formal dependency<br />
beween the specifications. A recent example is the websockets protocol<br />
and API specifications produced by the IETF hybi and W3C web<br />
applications working groups.<br />
<br />
W3C and IETF have similar, but not identical processes; some stages<br />
have identical names ("Last Call" in paritcular), but come with<br />
different expectations.<br />
<br />
The processes referred to in this document are documented in:<br />
<br />
* [http://tools.ietf.org//html/rfc2026 RFC 2026], The Internet Standards Process, as updated <br />
* [http://tools.ietf.org/html/rfc2418 RFC 2418], IETF Working Group Guidelines and Procedures <br />
* [http://www.w3.org/2005/10/Process-20051014/ W3C Process Document]<br />
<br />
<br />
== Goals and Scope ==<br />
<br />
The goal of this document is to establish mutual review expectations<br />
and responsibilities for W3C and IETF specifications with close<br />
dependencies. The scope of this document is limited to the phases of<br />
the IETF process leading up to publication of a document as Proposed<br />
Standard, and to the phases of the W3C process leading up to<br />
publication of a document as Candidate Recommendation, or as Proposed<br />
Recommendation if the Candidate Recommendation step is skipped.<br />
<br />
Both of these process steps correspond to publication of a document<br />
for initial implementation. In both cases, WGs may decide to further<br />
iterate documents (possibly returning to Last Call and Candidate<br />
Recommendation several times), or to make certain changes as a result<br />
of implementation experience that are incorporated as a document<br />
proceeds further along the standards track. Where that is the case,<br />
groups should fail in favor of mutual review and transparency.<br />
<br />
== Context: The W3C/IETF liaison relationship ==<br />
<br />
Working groups on both the W3C and IETF side have WG chairs who are<br />
responsible for managing the day-to-day operation of the group.<br />
<br />
The liaison relationship between the IETF and the W3C is managed by<br />
the IAB and the W3C staff, respectively. Traditionally, the IAB<br />
assigns one or several individuals from the IETF community as IETF<br />
liaisons to the W3C, and one or several W3C staff members serve as the<br />
W3C's liaisons to the IETF. The relationship mostly operates through<br />
regular telephone conferences (typically in the run-up to major<br />
meetings), e-mail discussions on the public-ietf-w3c@w3.org mailing<br />
list, and through attendance of major meetings. Formal liaison<br />
statements are used under exceptional circumstances.<br />
<br />
The liaison telephone conferences are attended by the assigned<br />
liaisons from both sides. The IETF Application Area Directors and the<br />
W3C Director have standing invitations to join the liaison meetings.<br />
IAB members may join the meetings.<br />
<br />
Other individuals with specific expertise participate at the<br />
invitation of the liaisons.<br />
<br />
It is appropriate to copy the (archived) public-ietf-w3c@w3.org<br />
mailing list on relevant communications between IETF and W3C<br />
participants. The archives of this list serve to document agreements<br />
about review time lines, scopes, and issues.<br />
<br />
The W3C/IETF liaison team is generally involved in chartering<br />
negotiations that require mutual review. The liaison team keeps an<br />
online list of WGs to which the coordination expectations in this<br />
document apply at [[W3cIetfCoordinatedWGs]].<br />
<br />
<br />
== Working Group Coordination ==<br />
<br />
<br />
=== Specification Development before Last Call ===<br />
<br />
Working Group coordination is expected to be largely informal and on a<br />
technical level. Where groups have closely related deliverables,<br />
overlap between working groups and direct collaboration between<br />
document editors are useful instruments toward ensuring appropriate<br />
coordination.<br />
<br />
Responsibility for this day-to-day relationship lies with the<br />
respective Working Group chairs. The formal liaisons are available to<br />
facilitate introductions and enable chairs to discharge this<br />
responsibility appropriately.<br />
<br />
<br />
=== Moving to Last Call ===<br />
<br />
Where documents have dependencies that create mutual review<br />
expectations, Working Groups should align their Last Call time lines.<br />
<br />
In the IETF process, the decision to request IETF Last Call is<br />
often preceded by a Working Group Last Call; issuing a Working Group<br />
Last Call is at the discretion of the WG chair.<br />
<br />
In the W3C process, the decision to request W3C Last Call is often<br />
preceded by a cooling off period during which the WG has no particular<br />
open issues to work on, but leaves a window for participants to<br />
perform a final review.<br />
<br />
The goal of this document is to ensure that substantive technical<br />
cross-review occurs before IETF Last Call or W3C Last Call is<br />
requested, but at a stage where specifications are stable enough for<br />
outside review. When exactly that threshold is crossed is at the<br />
discretion of the WG chairs.<br />
<br />
Therefore, Working Group chairs work with their peers in the other<br />
organization to ensure that the respective specifications have<br />
received substantive mutual review before they request W3C and IETF<br />
Last Call.<br />
<br />
This goal can be achieved by requesting outside review during the<br />
equivalent of WG Last Call.<br />
<br />
Requests for review are most useful if they include pointers at the<br />
relevant drafts, set expectations about open issues and stability of<br />
the documents, and give a time line during which review comments will<br />
be expected.<br />
<br />
Working Group chairs cannegotiate other mechanisms and specific time<br />
lines (including joint meetings, joint editors, earlier review<br />
schedules, ...) that ensure the same goal of mutual review. To ensure<br />
useful coordination, such negotiations often involve the W3C and IETF<br />
liaison team, the W3C staff contacts, and the relevant Area Directors<br />
(or their designees).<br />
<br />
The chosen review mechanism is best documented in a note to<br />
public-ietf-w3c@w3.org; where a formal exchange of calls for review<br />
occurs between two groups, that call for review is appropriately<br />
copied to public-ietf-w3c@w3.org.<br />
<br />
Where mutual review leads to additional technical changes, it is the<br />
chairs' responsibility to ensure awareness by the other Working Group<br />
of these technical changes, and to negotiate time lines going forward<br />
with the assistance of the liaison team.<br />
<br />
<br />
=== Last Call and Beyond ===<br />
<br />
While Working Groups are welcome to exchange technical reviews during<br />
Last Call, this process is intended to produce a coherent set of<br />
specifications that permit joint external review prior to entering<br />
Last Call. Therefore, we expect major last call comments between W3C<br />
and IETF Working Groups to be a rare occurence that is to be avoided.<br />
<br />
In the W3C process, a W3C Last Call is ended by a Working Group<br />
requesting transition to Candidate Recommendation (or, in exceptional<br />
cases, Proposed Recommendation). A precondition to this transition is<br />
the availability of a disposition of comments that documents how the<br />
Working Group has taken Last Call comments into account. When changes<br />
made in response to Last Call comments would invalidate prior review,<br />
it is common for groups to iterate several Last Call cycles.<br />
<br />
A W3C last call comment period lasts at least three weeks.<br />
<br />
<br />
In the IETF process, the IESG takes comments from the IETF community<br />
for a period of at least two weeks, and can then request changes to<br />
the document, or further advance the document. (See section 8 of RFC<br />
2418.) An IETF last call is not intended to serve as a vehicle for<br />
substantive comments.<br />
<br />
<br />
Where W3C and IETF documents have significant mutual dependencies,<br />
W3C and IETF Last Call announcements should be notified to the chairs<br />
of the respective Working Groups, copying public-ietf-w3c@w3.org.<br />
<br />
The IESG's publication of a document as a Proposed Standard and the<br />
W3C's publication of a document as Candidate Recommendation (or<br />
Proposed Recommendation) should be synchronized, and the time line<br />
planned in advance.<br />
<br />
This planning discussion appropriately occurs on an IETF/W3C liaison<br />
call that is attended by the relevant Area Directors and Working Group<br />
chairs.<br />
<br />
It is the responsibility of the Working Group chairs on both sides to<br />
request this agenda item in a note to the public-ietf-w3c@w3.org<br />
mailing list, as they plan for Last Call. The W3C and IETF liaisons<br />
will track these requests, and will ensure that the necessary<br />
participants attend the requisite liaison calls.</div>
Roessler
https://www.w3.org/wiki/index.php?title=MutualReviewExpectations&diff=56005
MutualReviewExpectations
2011-12-22T19:14:25Z
<p>Roessler: Created page with "= W3C/IETF mutual review expectations = Mark Nottingham <mnot@mnot.net>, Thomas Roessler <tlr@w3.org> 2011-10-16 == Introduction == Occasionally, W3C and IETF produce speci…"</p>
<hr />
<div>= W3C/IETF mutual review expectations =<br />
<br />
Mark Nottingham <mnot@mnot.net>, Thomas Roessler <tlr@w3.org><br />
<br />
2011-10-16<br />
<br />
<br />
<br />
== Introduction ==<br />
<br />
Occasionally, W3C and IETF produce specifications in close<br />
cooperation, sometimes marked by a significant formal dependency<br />
beween the specifications. A recent example is the websockets protocol<br />
and API specifications produced by the IETF hybi and W3C web<br />
applications working groups.<br />
<br />
W3C and IETF have similar, but not identical processes; some stages<br />
have identical names ("Last Call" in paritcular), but come with<br />
different expectations.<br />
<br />
The processes referred to in this document are documented in:<br />
<br />
* [http://tools.ietf.org//html/rfc2026 RFC 2026], The Internet Standards Process, as updated <br />
* [http://tools.ietf.org/html/rfc2418 RFC 2418], IETF Working Group Guidelines and Procedures <br />
* [http://www.w3.org/2005/10/Process-20051014/ W3C Process Document]<br />
<br />
<br />
== Goals and Scope ==<br />
<br />
The goal of this document is to establish mutual review expectations<br />
and responsibilities for W3C and IETF specifications with close<br />
dependencies. The scope of this document is limited to the phases of<br />
the IETF process leading up to publication of a document as Proposed<br />
Standard, ad to the phases of the W3C process leading up to<br />
publication of a document as Candidate Recommendation, or as Proposed<br />
Recommendation if the Candidate Recommendation step is skipped.<br />
<br />
Both of these process steps correspond to publication of a document<br />
for initial implementation. In both cases, WGs may decide to further<br />
iterate documents (possibly returning to Last Call and Candidate<br />
Recommendation several times), or to make certain changes as a result<br />
of implementation experience that are incorporated as a document<br />
proceeds further along the standards track. Where that is the case,<br />
groups should fail in favor of mutual review and transparency.<br />
<br />
<br />
== Context: The W3C/IETF liaison relationship ==<br />
<br />
Working groups on both the W3C and IETF side have WG chairs who are<br />
responsible for managing the day-to-day operation of the group.<br />
<br />
The liaison relationship between the IETF and the W3C is managed by<br />
the IAB and the W3C staff, respectively. Traditionally, the IAB<br />
assigns one or several individuals from the IETF community as IETF<br />
liaisons to the W3C, and one or several W3C staff members serve as the<br />
W3C's liaisons to the IETF. The relationship mostly operates through<br />
regular telephone conferences (typically in the run-up to major<br />
meetings), e-mail discussions on the public-ietf-w3c@w3.org mailing<br />
list, and through attendance of major meetings. Formal liaison<br />
statements are used under exceptional circumstances.<br />
<br />
The liaison telephone conferences are attended by the assigned<br />
liaisons from both sides. The IETF Application Area Directors and the<br />
W3C Director have standing invitations to join the liaison meetings.<br />
IAB members may join the meetings.<br />
<br />
Other individuals with specific expertise participate at the<br />
invitation of the liaisons.<br />
<br />
It is appropriate to copy the (archived) public-ietf-w3c@w3.org<br />
mailing list on relevant communications between IETF and W3C<br />
participants. The archives of this list serve to document agreements<br />
about review time lines, scopes, and issues.<br />
<br />
The W3C/IETF liaison team is generally involved in chartering<br />
negotiations that require mutual review. The liaison team keeps an<br />
online list of WGs to which the coordination expectations in this<br />
document apply at [[W3cIetfCoordinatedWGs]].<br />
<br />
<br />
== Working Group Coordination ==<br />
<br />
<br />
=== Specification Development before Last Call ===<br />
<br />
Working Group coordination is expected to be largely informal and on a<br />
technical level. Where groups have closely related deliverables,<br />
overlap between working groups and direct collaboration between<br />
document editors are useful instruments toward ensuring appropriate<br />
coordination.<br />
<br />
Responsibility for this day-to-day relationship lies with the<br />
respective Working Group chairs. The formal liaisons are available to<br />
facilitate introductions and enable chairs to discharge this<br />
responsibility appropriately.<br />
<br />
<br />
=== Moving to Last Call ===<br />
<br />
Where documents have dependencies that create mutual review<br />
expectations, Working Groups should align their Last Call time lines.<br />
<br />
In the IETF process, the decision to request IETF Last Call is<br />
often preceded by a Working Group Last Call; issuing a Working Group<br />
Last Call is at the discretion of the WG chair.<br />
<br />
In the W3C process, the decision to request W3C Last Call is often<br />
preceded by a cooling off period during which the WG has no particular<br />
open issues to work on, but leaves a window for participants to<br />
perform a final review.<br />
<br />
The goal of this document is to ensure that substantive technical<br />
cross-review occurs before IETF Last Call or W3C Last Call is<br />
requested, but at a stage where specifications are stable enough for<br />
outside review. When exactly that threshold is crossed is at the<br />
discretion of the WG chairs.<br />
<br />
Therefore, Working Group chairs work with their peers in the other<br />
organization to ensure that the respective specifications have<br />
received substantive mutual review before they request W3C and IETF<br />
Last Call.<br />
<br />
This goal can be achieved by requesting outside review during the<br />
equivalent of WG Last Call.<br />
<br />
Requests for review are most useful if they include pointers at the<br />
relevant drafts, set expectations about open issues and stability of<br />
the documents, and give a time line during which review comments will<br />
be expected.<br />
<br />
Working Group chairs cannegotiate other mechanisms and specific time<br />
lines (including joint meetings, joint editors, earlier review<br />
schedules, ...) that ensure the same goal of mutual review. To ensure<br />
useful coordination, such negotiations often involve the W3C and IETF<br />
liaison team, the W3C staff contacts, and the relevant Area Directors<br />
(or their designees).<br />
<br />
The chosen review mechanism is best documented in a note to<br />
public-ietf-w3c@w3.org; where a formal exchange of calls for review<br />
occurs between two groups, that call for review is appropriately<br />
copied to public-ietf-w3c@w3.org.<br />
<br />
Where mutual review leads to additional technical changes, it is the<br />
chairs' responsibility to ensure awareness by the other Working Group<br />
of these technical changes, and to negotiate time lines going forward<br />
with the assistance of the liaison team.<br />
<br />
<br />
=== Last Call and Beyond ===<br />
<br />
While Working Groups are welcome to exchange technical reviews during<br />
Last Call, this process is intended to produce a coherent set of<br />
specifications that permit joint external review prior to entering<br />
Last Call. Therefore, we expect major last call comments between W3C<br />
and IETF Working Groups to be a rare occurence that is to be avoided.<br />
<br />
In the W3C process, a W3C Last Call is ended by a Working Group<br />
requesting transition to Candidate Recommendation (or, in exceptional<br />
cases, Proposed Recommendation). A precondition to this transition is<br />
the availability of a disposition of comments that documents how the<br />
Working Group has taken Last Call comments into account. When changes<br />
made in response to Last Call comments would invalidate prior review,<br />
it is common for groups to iterate several Last Call cycles.<br />
<br />
A W3C last call comment period lasts at least three weeks.<br />
<br />
<br />
In the IETF process, the IESG takes comments from the IETF community<br />
for a period of at least two weeks, and can then request changes to<br />
the document, or further advance the document. (See section 8 of RFC<br />
2418.) An IETF last call is not intended to serve as a vehicle for<br />
substantive comments.<br />
<br />
<br />
Where W3C and IETF documents have significant mutual dependencies,<br />
W3C and IETF Last Call announcements should be notified to the chairs<br />
of the respective Working Groups, copying public-ietf-w3c@w3.org.<br />
<br />
The IESG's publication of a document as a Proposed Standard and the<br />
W3C's publication of a document as Candidate Recommendation (or<br />
Proposed Recommendation) should be synchronized, and the time line<br />
planned in advance.<br />
<br />
This planning discussion appropriately occurs on an IETF/W3C liaison<br />
call that is attended by the relevant Area Directors and Working Group<br />
chairs.<br />
<br />
It is the responsibility of the Working Group chairs on both sides to<br />
request this agenda item in a note to the public-ietf-w3c@w3.org<br />
mailing list, as they plan for Last Call. The W3C and IETF liaisons<br />
will track these requests, and will ensure that the necessary<br />
participants attend the requisite liaison calls.</div>
Roessler
https://www.w3.org/wiki/index.php?title=IetfW3cLiaison&diff=56004
IetfW3cLiaison
2011-12-22T19:11:28Z
<p>Roessler: /* Current / Ongoing Issues */</p>
<hr />
<div>__NOTOC__<br />
= IETF/W3C Liaison =<br />
<br />
This page collects general information about the liaison between the IETF and the W3C.<br />
<br />
== W3C Details ==<br />
<br />
The [http://www.w3.org/ World Wide Web Consortium] is charged with "leading the Web to its full potential," and as part of that maintains several specifications that are used widely in the IETF, including HTML, the XML family of specifications, and SOAP. <br />
<br />
The current liaison representatives of the W3C are:<br />
* Philippe Le Hégaret - plh@w3.org<br />
* Thomas Roessler - tlr@w3.org<br />
<br />
The W3C's Process document details [http://www.w3.org/2005/10/Process-20051014/liaisons considerations regarding liaisons]; additionally, there is a [http://www.w3.org/2001/11/StdLiaison#IETF complete list of liaisons] that the W3C engages in.<br />
<br />
== IETF Details ==<br />
<br />
The [http://www.ietf.org/ Internet Engineering Task Force] maintains most Internet "core" standards (e.g., BGP, IP, TCP, DNS) and many Web-related "application" standards (e.g., HTTP, URI, Atom). <br />
<br />
The current liaison representatives of the IETF are:<br />
* Mark Nottingham - mnot@mnot.net<br />
<br />
See also the [http://www.ietf.org/liaisonActivities.html full list of IETF liaison activities], the [http://tools.ietf.org/html/rfc4052 IAB process for handling liaison relationships], and some [http://tools.ietf.org/html/rfc4691 informal guidance]. <br />
<br />
The IETF has a special mechanism for formal communication to other standards organisations, the [http://tools.ietf.org/html/rfc4053 Liason Statement]; see the [https://datatracker.ietf.org/public/liaisons.cgi current listing of liaison statements].<br />
<br />
== Liaison Mailing Lists ==<br />
<br />
Besides informal contact between the liaisons and others, there is a public mailing list, [http://lists.w3.org/Archives/Public/public-ietf-w3c/ public-ietf-w3c@w3.org], that liaison communication takes place on. It is expected that this list will usually be used to find the appropriate venue for discussions, rather than having substantive technical discussion happen there.<br />
<br />
Additionally, there is a private mailing list for administrative and confidential issues, available to the liaison representatives, IESG members, and W3C Team members. Contact your liaison representative for more information.<br />
<br />
== Liaison Meetings ==<br />
<br />
The liaison holds regular teleconferences. Upcoming calls include:<br />
<br />
* ?? ??? 09 (??:?? GMT) <br />
<br />
=== Meeting Minutes ===<br />
<br />
Meeting minutes are published after being approved. <br />
<br />
* [http://www.w3.org/mid/4E8CF5FA.4010802@stpeter.im 30 Sep 2011]<br />
* [http://www.w3.org/mid/4E263301.1040806@stpeter.im 18 Jul 2011]<br />
* [http://www.w3.org/mid/4DFB7645.4030301@stpeter.im 13 Jun 2011]<br />
* [http://www.w3.org/mid/8648AB68-F40C-47F1-B784-690B16F6ED59@mnot.net 21 Apr 2011]<br />
* [http://www.w3.org/mid/C78A1864-D262-4CD6-B227-C48593708322@mnot.net 11 Mar 2011]<br />
* [http://www.w3.org/2010/09/16-ietf-minutes.html 16 Sep 2010]<br />
* [http://www.w3.org/mid/CBD2D4D0-EC25-43E1-B223-BE879FF69FE1@mnot.net 09 Jul 2010]<br />
* [http://www.w3.org/mid/69E6AF3D-C275-441C-BE9B-13F802AF6771@mnot.net 02 Mar 2010]<br />
* [http://www.w3.org/mid/1255988270.16879.59.camel@chacal 08 Oct 2009]<br />
* [http://www.w3.org/mid/107519F1-6A91-4141-B281-C8D526F9B9F1@mnot.net 15 Jun 2009]<br />
* [http://www.w3.org/mid/EC58885A-7E9D-42EC-9ADA-725FB3D8B5D7@mnot.net 14 May 2009]<br />
* [http://www.w3.org/mid/1B2F0C79-3909-4F78-B205-DC2B3937EFDC@mnot.net 13 Mar 2009]<br />
* [http://www.w3.org/mid/0148D896-F2CE-4A89-B322-67115299E5D9@w3.org 6 Jan 2009]<br />
* [http://lists.w3.org/Archives/Public/public-ietf-w3c/2009Jan/0000.html 10 Jun 2008]<br />
* [http://lists.w3.org/Archives/Public/public-ietf-w3c/2007Jun/0000.html 7 Mar 2007]<br />
* [http://lists.w3.org/Archives/Public/public-ietf-w3c/2007Feb/0000.html 1 Nov 2006]<br />
* ...<br />
* [http://lists.w3.org/Archives/Public/public-ietf-w3c/2002Aug/0000.html June 2002]<br />
<br />
== Current / Ongoing Issues ==<br />
<br />
Notes on issues of interest to the liaison.<br />
<br />
* [[MutualReviewExpectations]]<br />
* [[UriIriIssues]]<br />
* [[WebNetTension]]<br />
* [[FriendlyRegistries]]</div>
Roessler
https://www.w3.org/wiki/index.php?title=IdentityCharter&diff=55107
IdentityCharter
2011-11-02T16:54:07Z
<p>Roessler: /* Web Cryptography Working Group Charter */</p>
<hr />
<div>=Web Cryptography Working Group Charter=<br />
'''This document is under informal review'''<br />
<br />
For informal discussion of the proposal, send comments and subscribe to public-identity@w3.org (public archives).<br />
<br />
The mission of this work is to improve the the ability of the browser to mediate high-value transactions. Use cases include authentication and identity systems on the web, and advanced protocols between web applications. To this end, the group will provide standards around key storage and cryptographic primitives that will provide capabilities that are currently difficult to do safely on the Web platform.<br />
<br />
<br />
* End date 30 December 2013 <br />
* Confidentiality Proceedings are Public <br />
* Chairs @@ (@@) <br />
* Team Contacts Harry Halpin (FTE %: @@), @@ <br />
<br />
<br />
Usual Meeting Schedule Teleconferences: topic-specific calls may be held, normally weekly. <br />
Face-to-face: We will meet during the W3C's annual Technical Plenary week; other additional F2F meetings may be scheduled <br />
<br />
==1. Scope==<br />
<br />
The mission of this work is to improve the the ability of the browser to mediate high-value transactions. Use cases include identity on the web and advanced protocols between web applications. To this end, the group will provide standards around key storage and cryptographic primitives that will provide capabilities that are currently difficult to do safely on the Web platform.<br />
<br />
This work will focus on increasing uniform support for asymmetric cryptography amongst browsers and in existing solutions although symmetric systems could be supported. One important goal is to permit client to serve as higher security component in a distributed ID system that is complementary to current server-side work. <br />
<br />
The Web Cryptography Working Group should aim to produce specifications that have wide deployment amongst end-users, and so should work carefully with as many major implementers as possible. The Web Cryptography Working Group should adopt, refine and when needed, extend, existing practices and community-driven draft specifications when possible. The cryptography work should integrate well with Web Applications and so should be developed in concert with Web Application developers and the Web Application Security and HTML Working Groups. Comprehensive test suites will be developed for the specification to ensure interoperability, and the Working Group will assist in the production of interoperability reports.<br />
<br />
==1.1 Success Criteria==<br />
<br />
In order to advance to Proposed Recommendation, each specification is expected to have two independent implementations of each of feature defined in the specification. <br />
<br />
==2. Deliverables==<br />
==2.1 Recommendation-Track Deliverables==<br />
<br />
The working group will deliver at least the following:<br />
<br />
<br />
* '''Use-cases and requirements''': In order to properly scope the cryptography API, the group will collect use-cases and requirements, with a focus on enabling distributed solutions around the improving the security of distributy identity solutions and the trust of mobile code. <br />
<br />
* '''Cryptography API''': Commonly-used cryptographic primitives should be made available to web application developers via a standardized API to facilitate common operations such as asymmetric encryption key pair generation, encryption, and generation, as well as symmetric encryption, hashing, and signature verification as well as an abstract model for safe key storage. This work can be based upon DOMCrypt, which has already been discussed in the W3C WebApps WG, HTML WG, and IETF Web Security WG.<br />
<br />
Each specification must contain a section detailing any known security implications for implementors, Web authors, and end users. The Web Cryptography WG will actively seek an open security review on all its specifications.<br />
<br />
To increase the convenience and security of deployment, these specifications may interact will take into account existing platform and operating system identity managers and so additional informative work in this area may be necessary.<br />
<br />
==2.1 Other Deliverables==<br />
Additionally, the Web Cryptography Working Group has as a goal to improve the deployment of secure client-side interactions around authentication and identity on the Web. This will be done via outreach and interaction with the larger security communtiy and the identity community and by participating in both industry and government-led joint efforts with other organizations. So other non-normative documents may be created such as:<br />
<br />
*Test suites for each specification;<br />
*Primer or Best Practice documents to support web developers when designing applications dealing with cryptography;<br />
<br />
Milestones Note: The group will document significant changes from this initial schedule on the group home page. <br />
Specification FPWD LC CR PR Rec <br />
<br />
Cryptography API December 2011 February 2012 July 2012 September 2012 November 2012 <br />
<br />
==2.1 Milestones==<br />
<br />
The production of the deliverables depends upon the resources available, and will change as new information and implementation experience is reported to the group. The most up-to-date timeline is available from the Web WG Publication Status page.<br />
<br />
==3. Dependencies and Liaisons==<br />
<br />
*Web Applications Working Group<br />
To co-ordinate with APIs and features around building Web Applications*Privacy Interest Group<br />
So that users have options to respect their privacy and can use a uniform cryptography API and key storage to help, the Web Cryptography working group should engage in any developments in privacy.<br />
<br />
* WebAppSec Working Group<br />
To co-ordinate with any security requirements and specifications arising from the security needs of Web Applications.<br />
So that users have options to respect their privacy as regards third-party tracking, the Web Identity Working Group may interact with preference expression mechanisms and technologies for selectively allowing or blocking tracking elements. <br />
Furthermore, the Web Identity Working Group expects to follow the following W3C Recommendations, Guidelines and Notes and, if necessary, to liaise with the communities behind the following documents: <br />
<br />
*Architecture of the World Wide Web, Volume I<br />
*Internationalization Technical Reports and Notes<br />
*QA Framework: Specification Guidelines<br />
<br />
==3.1 External Groups==<br />
<br />
The following is a tentative list of external bodies the Working Group should collaborate with: <br />
<br />
* Internet Engineering Task Force<br />
The IETF is responsible for defining robust and secure protocols for Internet functionality. A clear relationship with IETF is vital to assure the security and success of elements of Web Cryptography that supervenes upon protocol-level work. For example, security reviews should involve the IETF Web Security (WebSec) Working Group. In particular the JSON based cryptography formats being done in the IETF Web Object Encryption and Signing (JOSE) Working Group, =<br />
<br />
*ECMA Technical Committee 39 (TC39)<br />
This is the group responsible for ECMAScript standardization and related features. As the Web Cryptography Working Group may require additional features to ECMAScript, it should collaborate with TC39.<br />
<br />
* OASIS<br />
The Web Identity Working Group's work should enable higher-security deployment of the SAML family of specifications and monitor working group.<br />
<br />
* OpenID Foundation<br />
The Web Identity Working Group's work should enable higher-security and wider deployment of the OpenID family of specifications and trust frameworks that involve the client. <br />
<br />
==4. Participation==<br />
To be successful, the Web Cryptography Working Group is expected to have 10 or more active participants for its duration, and to have the participation of the industry leaders in fields relevant to the specifications it produces. The Chairs and specification Editors are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other Participants.<br />
<br />
The Web Cryptography Working Group will also allocate the necessary resources for building test suites for each specification.<br />
<br />
The Web Cryptography Working Group welcomes participation from non-Members. The group encourages questions and comments on its public mailing lists, as described in Communication. As needed, the group may also call for joint teleconferences and meetings with related organizations and standards bodies in the field of identity.<br />
<br />
The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy. The Working Group may also call for the formation of Community Groups or work in other standards bodies such as the IETF.<br />
<br />
==5. Communication==<br />
Most Web Identity Working Group Teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. At least one teleconference will be held per week.<br />
<br />
Most of the technical work of the group will be done through discussions on one of the group's public mailing lists, for which there is no formal requirement for participation:<br />
<br />
*public-webcryptography@w3.org (archive) for general discussion<br />
<br />
The group will use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a particular member requests such a discussion.<br />
<br />
Information about the group (for example, details about deliverables, issues, actions, status, participants) will be available from the Web Cryptography Working Group home page.<br />
<br />
==6. Decision Policy==<br />
As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available. <br />
<br />
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires. <br />
<br />
==7. Patent Policy== <br />
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. <br />
<br />
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation. <br />
<br />
==8. About this Charter==<br />
This charter for the Web Cryptography Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. <br />
<br />
<br />
<br />
--------------------------------------------------------------------------------<br />
<br />
Harry Halpin, <hhalpin@w3.org>, Team Contact <br />
@@, <@@>, Team Contact <br />
@@, @@, Chair <br />
@@, @@, Chair <br />
Copyright© 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved.<br />
<br />
$Date: 2011/09/19 22:35:38 $</div>
Roessler
https://www.w3.org/wiki/index.php?title=TPAC/2011/SessionIdeas&diff=55106
TPAC/2011/SessionIdeas
2011-11-02T16:52:15Z
<p>Roessler: /* Web Identity and Crypto API Chartering Discussion */</p>
<hr />
<div>= Plenary Sessions and Pre-Selected Breakouts =<br />
<br />
From among the proposals on this page the [[TPAC2011-Committee|TPAC Program Committee]] has chosen 2 plenary sessions and '''pre-selected''' 8 breakout sessions (meaning they are guaranteed space).<br />
<br />
Plenary sessions:<br />
<br />
<ul class="show_items"><br />
<li>Web and TV. Chair: Mark Vickers (Comcast)<br />
<li>Web Content Interoperability. Chair: Bryan Sullivan (ATT)<br />
</ul><br />
<br />
[[TPAC2011/PlenaryBreakouts|Pre-selected breakout sessions]]:<br />
<br />
<ul class="show_items"><br />
<li>[[TPAC2011/API Design Approaches and the Rationales for Them]]. Chair: Bryan Sullivan<br />
<li>[[TPAC2011/Semantic Syntaxes]]. Chair: Ben Adida<br />
<li>[[TPAC2011/Building Apps in the Cloud]]. Co-Chairs: Said Tabet (EMC) and Marlin Pohlman (EMC)<br />
<li>[[TPAC2011/Advances in Social Network Standardization]]. Chair: Harry Halpin (W3C)<br />
<li>[[TPAC2011/Web-based Digital Signage]]. Chair: Toru Kobayashi (NTT)<br />
<li>[[TPAC2011/HTML5 and Games]]. Chair: Ted Leung (Disney)<br />
<li>Revisiting how W3C creates standards. Co-Chairs: Marcos Caceres, Kai Scheppe (Deutsche Telekom)<br />
<li>W3C Publications Ecosystem. Co-Chairs: Philippe Le Hégaret (W3C), Robin Berjon<br />
</ul><br />
<br />
<p>The last two breakouts are the result of a merger of four proposed sessions; two related to publications process and two related to publishing ecosystem.</p><br />
<br />
= How sessions will be chosen the day of the meeting =<br />
<br />
See [[Session_Selection]]<br />
<br />
= TPAC 2011 Session Ideas =<br />
<br />
We encourage attendees to start brainstorming [[TPAC2011]] session ideas in advance of the meeting, both for cross-group plenary topics and for the breakout sessions. <br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (optional: name a desired session leader, can be yourself)<br />
* one sentence session summary<br />
* 1+ paragraph session description <br />
</ul><br />
<br />
<br />
For cross-group plenary session proposals, please also provide:<br />
<ul class="show_items"><br />
* type of session: (e.g.: talk, panel, open discussion, etc.)<br />
* additional speakers/panelists<br />
</ul><br />
<br />
==Ideas for Cross-Group Plenary Topics==<br />
<br />
These topics should be relevant to a significant number of W3C groups. They will be discussed in plenary (09:00-10:00). If your topic is not selected by the Program Committee as one of the two plenary topics, please consider leading it as a breakout session.<br />
<br />
===The W3C Publication Process is broken: lets fix it!===<br />
Proposed by: Marcos Cáceres<br />
The W3C process requiring static version of specs to be published to /TR/ is seriously broken. The labeling of specs are CR, LC, etc. is also broken: specifications don't follow a linear path to reach Recommendation (e.g., Last Call can come after CR, and Last Call documents can go straight to PR). Standards are *living documents* and trying to version them has led to serious fragmentation in the market, confusion from implementers, and confusion from other standards organizations that use W3C specs.<br />
<br />
Lets work together to come up with a workable solution to this problem. For a start, lets start taking Editor's draft seriously: for too long, some in the W3C community have pretended that Editor's draft have no official status, when in reality they are usually far ahead of anything in the /TR/ space. Making editor's drafts authoritative on the /TR/ space would overcome many of the problems listed above.<br />
<br />
* +1 [[User:Tantekelik|Tantek Çelik]]: I for one support an overhaul of the W3C specification process, focused more on pragmatism and implementation than on protocol and legal mumbo jumbo. The web works because in practice people code first, worry about lawsuits later. I'm willing to help contribute what we've learned with developing http://microformats.org/wiki/process<br />
* Ian Jacobs: I suggest combining with [[Experimental_specifications]]<br />
<br />
===API Design Approaches and the Rationales for Them===<br />
<br />
* Led by: Bryan Sullivan/proposed by Ileana Leuca<br />
<br />
What API design approaches are browser vendors seeking to promote, and what are the rationales for the choices? How can W3C help the wider Web community (including SDOs that want to Web-enable their standards-based service enablers, or extend the Web platform with new capabilities) follow a successful path to convergence with W3C? For example what are the rationales behind the following API design approaches?<br />
<br />
* declarative (via markup language features, e.g. HTML5's <video> tag)<br />
* Javascript (object/procedural interfaces ala window.open())<br />
* XHR/REST (using HTTP scheme URLs such as in conventional RESTful Web APIs, and non-HTTP scheme URLs handled by the browser or some local system-registered URL handler)<br />
<br />
[Robin Berjon] (My understanding based on the email was that we are to provide feedback inline — if I got that wrong please tell me and I'll fix it.) There are two completely different topics here: the one in the title and the one in the description. I would like to suggest that neither makes for a great plenary session topic. The question of work prioritisation cannot be solved in a plenary fashion. W3C is not a top-down organisation, there is no authority whatsoever that can force a given group to follow some form of release plan. The only way of prioritising a deliverable is to commit resources to provide technical solutions to its issues, edit the relevant documents, and experiment with implementations. The question of rationales and design decisions is certainly interesting, but I don't believe that it can usefully be debated in a plenary fashion either. It would be very useful to describe the tradeoffs one needs make between the listed design approaches, but that requires a lengthy, subtle document that does not currently exist (and is unlikely to be written between now and TPAC). In other words, it is more of a long-term TAG deliverable than a short group chat.<br />
<br />
[Bryan Sullivan] Corrected the title... and I agree that a TAG deliverable would probably be a useful result but we need to start a dialog on this with SMEs now, as TAG deliverables are long-term and our need to effectively collaborate on API designs is short-term, e.g. affecting our ability to deliver specifications from DAP.<br />
<br />
[Frederick Hirsch] See also http://lists.w3.org/Archives/Public/www-tag/2011Sep/0002.html<br />
<br />
[Bryan Sullivan] A draft session discussion outline is available at http://bkaj.net/w3c/TPAC-2011-API-Design-Patterns.html. Suggestions for inclusion in this outline are welcome. The intent is to have an interactive discussion, so the outline is brief, but other key aspects to consider or API design approach examples/pros/cons are welcome.<br />
<br />
===How can W3C promote convergence in installable Web application technologies?===<br />
<br />
* Proposed by: Ileana Leuca<br />
<br />
How can we harmonize the objectives, approaches, and capabilities of supporting installable Web applications via:<br />
<br />
* W3C widgets<br />
* HTML5's AppCache<br />
* Vendor-specific packaging/manifests, e.g. as used by Google Chrome Web Apps and Firefox Web Apps.<br />
<br />
[Robin Berjon] I agree that applications is one of the very big topics and strongly support having a session on this topic. However, I feel that the approach proposed here is far too restrictive for a plenary session. There are now more groups in W3C working on application-related technology than I can quote off the top of my head, and that's not speaking of listing all of their deliverables. I would suggest that we could usefully have a broad session that would try to cover the full landscape not at all in depth but at least trying to capture its breadth.<br />
<br />
[Bryan Sullivan] This specific topic could be part of a larger discussion on the effect of fragmentation on the Web applications market, and how to address it for key use cases such as installable Web applications. But it is an important topic for any initiative or service provider that is trying to build a business based upon installable Web application technologies.<br />
<br />
=== Component Model & XBL ===<br />
<br />
Discuss how to move forward with the [http://wiki.whatwg.org/wiki/Component_Model Component Model], a proposed replacement for XBL.<br />
<br />
=== Ensuring Privacy and Security in W3C Recommendations ===<br />
<br />
* proposed by: Nick Doty<br />
<br />
W3C has recently formed Working Groups and Interest Groups around security and privacy topics, but what about the many privacy and security issues that crop up in the many other specifications at W3C? Would a "Security Considerations" or "Privacy Considerations" section work for us? Would you like a group of experts to call on to help review privacy/security issues? Tools, checklists or guidelines for reviewing your own specifications for issues?<br />
<br />
===Web Content Interoperability Challenges===<br />
<br />
* Proposed and Led by: Bryan Sullivan<br />
<br />
<h4>The Challenge</h4><br />
<ul><br />
<li>There is a somewhat accurate perception among developers, that developing for the Web (especially for mobile devices) is <strong><em>freakin' hard</em></strong>, compared to developing for native platforms.</li><br />
<li>Web content interoperability issues are often at the core of developer difficulties.</li><br />
<li>Web content interoperability will greatly affect the potential of HTML5-based app ecosystems which target a wide diversity of devices and service contexts.</li><br />
<li>Such interoperability issues are a key inhibitor of the Web applications market, even without the performance and high-end graphics limitations of current Web user agents compared to native applications.</li></ul><br />
<br />
<h4>W3C Responds!</h4><br />
<ul><br />
<li>W3C is taking steps to address Web browser/content interoperability challenges, through the Web Testing Activity, which will include a combination of tactical focus on test documentation, test production, and testing frameworks, and strategic focus on the overall value of W3C testing for Web application ecosystems.</li><br />
<li>In this manner, the immediate needs of W3C for alignment and further development of test methodology can be combined with progress toward creating a living compliance testing environment which benefits a wide diversity of needs across the Web application ecosystem, including W3C, Web user agent and platform vendors, developers and developer initiatives, service providers, and supporting services (e.g. test/certification providers).</li></ul><br />
<br />
<h4>The goals for this discussion are:</h4><br />
<ul class="incremental"><br />
<li>Frame some overall objectives for Web content interoperability</li><br />
<li>Introduce how this relates to the proposed W3C Testing Activity</li><br />
<li>Start a dialog on how to collect key interoperability issues, ensuring participation of that all those that are impacted:<br />
<ul class="incremental"><br />
<li>Users</li><br />
<li>Developers and content providers</li><br />
<li>Web user agent and tooling vendors</li><br />
<li>Service providers</li></ul><br />
</li></ul><br />
<br />
[Vidhya Gholkar] +1 I think we need to understand what "developers" find difficult and how much can really be addressed by testing. Some of it comes down to education, knowledge base and skills. Also when it comes to content: "being everything to everybody" is a big task (i am referring to the changing fashions, devices, OSs etc etc)!<br />
<br />
[Bryan Sullivan] A draft intro and session discussion outline is available at http://bkaj.net/w3c/TPAC-2011-Web-Content-Interoperability-Challenges.html. Suggestions for inclusion in the discussion are welcome, especially any input on key content interoperability issues faced by developers.<br />
<br />
==Ideas for Breakout Sessions==<br />
<br />
Breakout sessions can cover a wide range of issues: technical issues, cultural issues, future work ideas, presentations of work, etc. <br />
<br />
===Open Web and Web Standards Developer Education and Evangelism===<br />
* Proposer/Leader: Molly E. Holzschlag<br />
* Type of session: discussion<br />
<br />
One of the recently emerging roles across companies, organizations and businesses worldwide is that of Developer Relations. In this role, individuals and entire teams work to educate and evangelize specific technologies as they pertain to the Open Web and Web Standards. Most browser and tool vendors have such teams, and many of us within the W3C are focused on relating internal messages to the external audiences. Open Web philosophy has an implicit goal of removing such barriers to information, and those of us within the W3C will benefit greatly from a discussion on topics such as:<br />
<br />
* Definining the evangelical/educator role<br />
* How do we coordinate messages across a broad range of technologies?<br />
* Is the creation of a task force or community group between external educators and evangelists who are also working within the W3C a helpful direction?<br />
* How do independent or underfunded leaders find support and resources to support their education goals?<br />
* What additional activities can we brainstorm that would increase a sense of community between developers and the W3C (for example, free online workshop/talks / demos, better promotion of talks and developer relation activities via social networks, better coordination between W3C and its advocates)<br />
* Add your ideas here, please!<br />
<br />
===Semantic Syntaxes===<br />
* Proposer: Tantek Çelik<br />
* Discussion Leader: Ben Adida<br />
* Type of session: discussion<br />
<br />
At the recent schema.org workshop, there was quite a bit of discussion of what syntax to use for adding semantic information to HTML documents from among: microdata, microformats, RDFa.<br />
<br />
Ben Adida presented on the evolution of RDFa 1.1 and RDF 1.1 lite, and noted how RDFa has based many simplifications on microformats' syntax.<br />
<br />
microdata itself has been evolving since it was first proposed, based on use-cases provided by RDFa proponents.<br />
<br />
microformats has also been evolving with [http://microformats.org/wiki/microformats-2 microformats 2], and most recently is proposing to use the "itemref" innovation of microdata over the previous "include-pattern"<br />
<br />
It was clear from the discussion in the room that multiple syntaxes are actively co-evolving and learning from/with each other.<br />
<br />
If you're interested in semantic syntaxes (microdata, microformats 2.0, RDFa) this session is for you. Topics:<br />
<br />
* How are syntaxes evolving?<br />
* What features are syntaxes borrowing from each other?<br />
* Is there a common (JSON?) data model that syntaxes are converging on?<br />
<br />
===Open Vocabulary Development===<br />
* Proposer/Leader: Tantek Çelik (but willing to defer to Dan Brickley or R.V. Guha)<br />
* Type of session: discussion<br />
<br />
How to best do open vocabulary development<br />
<br />
* The microformats community has been using the [http://microformats.org/wiki/process microformats process] and slowly but solidly developing about a couple of vocabularies a year (recent successes: hRecipe, hReview-aggregate)<br />
* The microdata community has mostly re-used well-used microformats vocabularies (hCard, hCalendar), and proposed a "Works" vocabulary.<br />
* Google's Rich Snippets proposed data-vocabulary.org where slightly changed versions of microformats vocabularies were published for microdata and RDFa<br />
* schema.org (Google, Bing) introduced 150+ new vocabularies<br />
<br />
Which of these (or combination thereof) is right/best and why?<br />
<br />
Can we work together to incorporate various communities needs and produce a common place/way for rapid open vocabulary development that's not just dominated by large companies?<br />
<br />
Some background:<br />
* http://tantek.com/2011/168/b1/practices-good-open-web-standards-development<br />
<br />
===Increasing Global Participation in W3C===<br />
<br />
* Proposer/Leader: Ann Bassetti (anyone else want to lead? or co-lead? eager to share)<br />
* Type of session: discussion<br />
What more can we do to help people participate comfortably with W3C? What are the barriers or inhibitors and how can we reduce them? Who else wants to participate and can't? Is the English requirement a problem? Are the cost of travel or long-distance calls a problem? Are there cultural differences we should be aware of? Please add to this list & come to the session!<br />
<br />
[Debbie Dahl] I thought about this proposal when I went to add my proposals and found the warning text, "If you do not want your writing to be edited mercilessly, then do not submit it here." I think this kind of language could be off-putting to people from cultures where merciless editing of other people's writing is considered disrespectful. That might well be an example of a cultural difference that we should be aware of.<br />
<br />
[Ann Bassetti] Good catch, Debbie! I bet that warning text is in the MediaWiki software -- not put in there by the W3C staff. I assume that statement is typical American geek goofiness, trying to be funny. I think it is simply a warning that the whole point of a wiki is collaborative editing. Thus, whatever you contribute may be changed, so you should not feel badly if it is. At the same time -- YOU can change someone else's work. I hope W3C participants will not be scared off nor insulted by that message, and that we will all help each other become comfortable with these new modes of working together.<br />
<br />
[Debbie Dahl] I'm sure you're right that this is just trying to be funny and warn contributors that their edits might be changed. My point is that not everyone is going to be clued into this kind of humor, especially people from non-American cultures. I think this is the kind of thing we should look out for.<br />
<br />
===Web in the World===<br />
* Proposer/Leader: Debbie Dahl<br />
Not so long ago, the only intelligent device in existence was a<br />
traditional desktop computer. The only way to interact with the Web<br />
was to sit at a desk in a fixed location. Now the Web is not just<br />
accessible from your desk, but, increasingly, the Web is available out<br />
in the world, either through mobile devices or through devices present<br />
in the environment. Sophisticated processing capabilities are<br />
available in many devices, most notably mobile phones and tablets, but<br />
also in cars, televisions, and household appliances. These new<br />
environments also connect with a rapidly increasing array of<br />
sophisticated capture devices, such as biometrics, scanners, and<br />
medical sensors. This session will discuss how existing standards can<br />
be used to support the Web in the world and what new standards are<br />
needed.<br />
<br />
=== Specification Production Ecosystem ===<br />
* Proposer/Leader: Robin Berjon<br />
There are many tools available to editors but they are often insufficiently known by their potential users. They also tend to duplicate features that could probably be shared (e.g. a references database). Furthermore, there have been a number of proposals (and at times implementations) for improvements to the way in which specifications are currently marked up, for instance to share more detectable semantics for specific structural items (warnings, notes...) or to make testable assertions extractable. The idea behind this session is to bring those who are interested in improving this ecosystem together, irrespective of their chosen tools, in order to share ideas and see if improvements may be made.<br />
<br />
=== Demos of Applications using W3C Standards ===<br />
* Proposer/Leader: Debbie Dahl<br />
This session would invite both implementers of W3C standards as well as<br />
developers who use the standards, to showcase creative, innovative, and<br />
useful W3C standards-based applications and explain how W3C standards made their applications possible.<br />
=== User Experience and Privacy for Microphone Access ===<br />
* Proposer: Cullen Jennings, Leader: Not Me<br />
<br />
Yes, browsers are going to be able to access your microphone and send the resulting media somewhere. The question is how to generate a reasonable level of security and privacy while at the same time having a user experience that is not awful. The idea of the session would be to bring together many of the people of that have thought about this, educate the new people on ideas and experiences from the past, and brainstorm reasonable ideas of how to approach this. Hopefully we would come up with ideas on, or at least educate people on existing ideas, around what access was provided when and what could be done with the resulting media.<br />
<br />
[Stefan Håkansson]: I think we should extend the topic to cover camera access as well.<br />
<br />
===What would make W3C more useful to developers?===<br />
<br />
* Proposed by: Ian<br />
<br />
I would like W3C to be more useful to developers. Community Groups should provide a more welcoming environment for spec development than we've had before. What else should we do? Some ideas:<br />
<br />
* Provide more useful documentation of "what really works on the Web". More useful might include "looks nicer" or "less geeky than the spec itself."<br />
* Provide software vendors with tools to help automate the maintenance of up-to-date information about support for standards.<br />
<br />
===Experimental specifications===<br />
<br />
Proposed by: Kai<br />
Leader: W3C staff<br />
<br />
One of the criticisms often directed towards W3C is being too slow. <br />
The fact that this is due to a detailed process that attempts to avoid errors or conflicts in the specifications is lost to the public at large.<br />
<br />
Would it be possible to open specifications much earlier, allowing early and truly live implementations, to get early feedback from the community?<br />
<br />
In part we are seeing this model with the HTML5 spec and it seems to work.<br />
<br />
* This would/could<br />
** allow implementers to start work with a given spec immediately<br />
** give clear and early indications of the public interest in a spec or parts thereof<br />
** provide rapid feedback on applicability to the intended goal<br />
** provide rapid feedback on potential problems<br />
** in long term increase specification quality<br />
<br />
* Issues for discussion<br />
** It would have to be ensured that feedback can and will just as rapidly be processed and lead to necessary changes in a spec.<br />
** Declaration of specific stages of a spec, giving implementers a certain assurance as to its stability<br />
** Provision of migration paths from one version to another must be mandatory<br />
** Provision of a clear and easy to understand process for giving credit to contributors (especially from the general public)<br />
<br />
<br />
===Making W3C more useful for business===<br />
<br />
Proposed by: Kai<br />
Leader: Alan Bird, Bernard Gidon, Jeff Jaffe<br />
<br />
I am not saying that W3C is not useful for business, but I think many don't see why that is so.<br />
<br />
<br />
Have you noticed how most hotels have discovered their conscience for the environment?<br />
<br />
They appeal to you, the guest, to not throw your towel on the floor, if it is not really disgustingly dirty. No mention of the fact that they, in fact, simply save money by not washing all those towels all the time.<br />
<br />
We play along. Let them save their money. Less detergent in the environment is in fact better too.<br />
<br />
<br />
Do business really care about standardization? <br />
<br />
I don't think so. Not as part of their DNA. <br />
<br />
I think they are interested in earning money, which is perfectly acceptable. If there is money to be made using standards then they are all for it.<br />
<br />
Therefore, can we make it appealing to businesses to use standards, to work with W3C developed technology?<br />
<br />
Can we find the "towel trick" for business?<br />
<br />
<br />
What are the key factors that businesses have found so far?<br />
<br />
What can we learn from that?<br />
<br />
Is there a way to create niche markets, based on technology, that does not have to be based on proprietary technology?<br />
<br />
If not, how can W3C help here?<br />
<br />
The businesses who are already members have decided, for various reasons, that it is good to participate. Why? What can they tell us?<br />
<br />
<br />
But what about the rest, the great masses out there?<br />
<br />
<br />
Which information can we give them, which examples can be shown to make it clear that it saves you money/earns you money if you use standardized, open technology?<br />
<br />
<br />
=== Building Apps in the Cloud ===<br />
<br />
Chaired by: [http://conference.xbrl.org/speakers/t#Said%20Tabet Said Tabet] and [http://www.biztechmarch.com/btsummit/speakers.html#Marlin%20Pohlman Marlin Pohlman], EMC<br />
<br />
Cloud computing is a major topic<br />
* potential speakers: Microsoft, Cisco, Force.com, Amazon?<br />
<br />
<br />
Cloud computing is changing the way companies procure IT infrastructure. Utility computing will also impact individual and company to company interactions.<br />
<br />
The session will explore and highlight current effort to deliver standards-based Cloud application development environments. We want to discuss new and emerging software development methods taking advantage of the elasticity and inherent virtualization capabilities of the Cloud, social software development, and methods such as REST APIs, Mashups, etc.<br />
<br />
We also suggest to have a panel discussion that will include application security as this is a major issue in Cloud adoption. The session will open up discussions with participants to discuss current standards activities at W3C that are relevant to Cloud and what new practical initiatives need to be explored by the membership.<br />
<br />
=== Advances in Social Network standardization ===<br />
<br />
Proposed by: Laurent-Walter Goix. Leader: Harry Halpin<br />
<br />
This session would invite both authors of relevant open specifications in the area of Social Networking as well as developers to discuss their experience on implementing these specifications. The goal of the session is to bring together the widest possible set of open initiatives focused on standardizing social networks at various levels (e.g. client-server protocols, data models, server-to-server federation, end-to-end integration, mobile optimization) through talks that illustrate their specification, current issues and roadmap. Developers may be involved to showcase demos & provide feedback.<br />
Ideally a final panel would discuss specific topics (e.g. user addressing, discovery) to better understand main issues and collaboration opportunities across these initiatives.<br />
<br />
Panel Speakers:<br />
* Status.Net/Federated Social Web<br />
* IETF OAuth WG<br />
* Google+<br />
* Mozilla <br />
* OpenSocial<br />
* OMA MobSocNet<br />
<br />
Discussion:<br />
* +1 I'd like to see this session happen. Some concerns: Which open specifications will be discussed? What do people consider "relevant"? How much time/focus will be spent on more academic/blue-sky social network standards vs. enterprise/oligopoly driven/focused standards vs. pragmatic/real-world-web/indie-web/long-tail focused/adopted open standards? [[User:Tantekelik|Tantek Çelik]] 21:05, 12 October 2011 (UTC)<br />
* ...<br />
<br />
=== Feedback from the World Wide Web Foundation ===<br />
<br />
Proposed by: Debbie Dahl Leader: TBD<br />
<br />
This session would provide an opportunity for staff from the World Wide Web Foundation to talk about their feedback on W3C standards based on their experiences in the developing world or other Foundation activities.<br />
<br />
(note from Ann Bassetti): I like this idea, Debbie! Has anyone alerted Web Foundation folks about this? We probably need to lay the groundwork, so one of them would be in attendance.<br />
<br />
(note from Debbie Dahl. I think this would have to be one of the predetermined sessions, so that we can make sure a Foundation person is in attendance. If there's interest in having this session, I think Steve Bratt should be contacted.)<br />
<br />
(note from Debbie Dahl) After discussing this idea with Steve Bratt, it looks like it's too early for the Foundation to have specific feedback on W3C standards from their perspective, so I'd like to withdraw this suggestion. Perhaps next year we can consider a session on this topic.<br />
<br />
=== HTML5 and Games ===<br />
<br />
Chaired by: Ted Leung, Disney<br />
<br />
This session will discuss issues that arise when trying to build games using HTML5. We may also discuss formation of a Community Group around this topic. <br />
What are the standardization needs?<br />
<br />
* sharing results of [http://openmediaweb.eu/2011/09/14/workshop-on-html-next-for-gaming/ "HTML.next for gaming" workshop] (to happen 24 Sept., in Varsaw)<br />
* note that the [http://www.newgameconf.com/ Newgame conference] is happening 1-2 Nov. in SF<br />
<br />
=== Practices for Developers on Web Privacy ===<br />
<br />
Proposed by: Thomas Roessler.<br />
<br />
=== The Next Privacy and Security Issues for the Web ===<br />
<br />
* Proposed by: Nick Doty<br />
* Could be merged with "Practices for Developers on Web Privacy" and/or "User Experience and Privacy for Microphone Access"<br />
<br />
What are the upcoming privacy and security issues for the Web beyond what we're already seeing today? What experiences have we had with privacy issues on mobile devices and mobile apps that would apply to new Web standards? What new security concerns should we be planning for?<br />
<br />
: If there's interest in this session ahead of TPAC, I'm happy to reach out to some experts who could kick things off, but I suspect that the group will have plenty of new ideas to share. [[User:Npdoty|Nick Doty]] 22:25, 3 October 2011 (UTC)<br />
<br />
=== Web Accessibility: Tips and Maps ===<br />
<br />
Proposed by: Shawn Henry, @@.<br />
<br />
Get tips for quickly checking that you've got the basics of web accessibility covered, e.g., colour contrast, structure markup, @@. We'll do short demos of tools and techniques, provide pointers for more info, and have time for Q&A and discussion.<br />
<br />
=== Declarative 3D Graphics on the Web ===<br />
<br />
* ''Proposers:'' Kristian Sons, Johannes Behr, Don Brutzman<br />
* ''Summary:'' the Declarative 3D Community Group invites other W3C groups to consider common requirements and use cases of shared interest.<br />
* ''Type of session:'' short talk followed by open discussion<br />
<br />
3D Graphics is an important media type that might have much greater impact on Web multimedia, benefiting both users and authors.<br />
<br />
The [http://www.w3.org/community/declarative3d Declarative 3D Community Group] is building requirements for integrating 3D capabilities with other W3C technologies by defining common [http://www.w3.org/community/declarative3d/wiki/Use_Cases_and_Requirements use cases].<br />
<br />
This group will present common use cases that define how [http://www.w3.org/community/declarative3d/wiki/Intersection_of_Declarative_3D_with_other_W3C_Groups_and_Technologies 3D might intersect and interact] with HTML5, DOM events, CSS, SVG, GeoLocation, Augmented Reality (AR), Efficient XML Interchange (EXI) and other key working groups. Certain complex data types and computations are also of mutual interest.<br />
<br />
We invite participation by people working in these other groups so that common ground can be defined, existing work can best be harmonized, and new requirements can be clearly identified.<br />
<br />
=== Adjusting to today’s explosion of input methods ===<br />
Proposed by Kim Patch<br />
<br />
Adjusting to today’s explosion of input methods<br />
<br />
Most of user interface development has assumed keyboard and/or mouse input. Three relative newcomers, however, promise to be increasingly important -- touch, speech and gesture. How important is it for the system to know whether the user is using touchscreen, keyboard, mouse, speech or gesture? How does a mix of input methods, whether or not each method is aware of the other, affect the browser and the user experience?<br />
<br />
The user experience can be very different depending on input method. For instance, it’s rare for a mouse user to have a focus-related issue even when system focus is badly implemented because the mouse user automatically changes focus to mouse location simply by using the mouse. This is different for keyboard and speech users.<br />
<br />
Another example is the single-key keyboard shortcuts that are increasingly popular for Web apps. It’s rare for a keyboard user to accidentally type more than a key or two in a situation where “a” archives a message and “n” goes to the next message, but if a speech user says a phrase in the wrong place, or if the speech system in correctly interprets a command as a phrase, several words worth of commands can be carried out instantly, and not easily reversed.<br />
<br />
What should the browser be aware of in terms of input methods? What should the user be able to adjust to make the browser more aware? What can we do to make sure users keep the control of the system despite increasingly complicated situation with input?<br />
<br />
* ...<br />
<br />
=== The W3C Publication Rules are broken! Let's fix them ===<br />
Proposed by/Leaders PLH & Ted<br />
<br />
Publishing a document in /TR requires lots of patience and zen. We'll like to reconsider the current set of rules imposed on documents published in /TR, as well as the current set of tools used to check those rules. Note that this discussion isn't intended to change the W3C Process document which is a separate and larger topic (and proposed in a different session). if you're a Chair, a team contact, an editor, or simply a user of those documents, we would welcome your feedback on this topic.<br />
<br />
RB: Should we merge this with "Specification Production Ecosystem"? They are quite related, and likely have an overlap in participations.<br />
<br />
* Ian Jacobs: I suggest combining with [[Specification_Production_Ecosystem]]<br />
<br />
=== Where the Web and TV are Headed ===<br />
(tentative title)<br />
<br />
Proposed by Kaz Ashimura<br />
<br />
(details tbd)<br />
<br />
Feedback: <br />
* Please provide a description. Thanks! - [[User:Tantekelik|Tantek Çelik]] 00:16, 15 October 2011 (UTC)<br />
* Please provide a proposed discussion leader. Thanks! - [[User:Tantekelik|Tantek Çelik]] 00:16, 15 October 2011 (UTC)<br />
* ...<br />
<br />
=== Web-based Digital Signage ===<br />
<br />
Leader: Toru Kobayashi<br />
<br />
Proposed: Toru Kobayashi, Shinji Ishii, Masayuki Ihara, and Craig Makino<br />
<br />
This session will discuss issues on the Web-based digital signage that can be used in the near future, for example as effective advertising media in public spaces, personal information displays such as a tablet device and etc. In this session, use cases of digital signage in Japan will be introduced so that it stimulates the discussion about the need of standardization of the Web-based digital signage and about the requirements from technical and business viewpoints.<br />
<br />
Agenda:<br />
* Opening Talk<br />
* Digital signage overview<br />
** what is digital signage?<br />
** market trends<br />
* Use Cases<br />
* Technical issues<br />
** architecture<br />
** technical requirements<br />
* Future plan<br />
* Discussion<br />
<br />
=== Merging video element from HTML5 and SVG ===<br />
<br />
* Proposer/Leader: Jan Lindquist (but willing to differ)<br />
* People interested in discussing: Giuseppe Pascale, Erik Dahlström<br />
* Type of session: Discussion<br />
<br />
<br />
There has been a lot of effort to develop HTML5 video element which has had many enhancments like timetracks, audio and media elements. SVG Tiny 1.2 also has a video element defined much earlier than HTML5. With all the effort on HTML5 what is the future of SVG's video element? Shall it be left as is, shall it be merged with HTML5's video element or other direction? It is important to clarify the direction of SVG video element to avoid misalingment. As the title suggest the recommendation is that they are merged.<br />
<br />
Note that this topic was raised from discussions in the Web and TV Interest Group - Media Piping Task Force. Most recently it was discussed in the webTV workshop held in Hollywood. Currently the requirement highlighting this issue is "[http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/VideoTagSupportMpeg2-ts Issue - 18]" under Implementation issue # 6. In order to meet the deadline this topic was raised prior to the requirement being finalized in the task force.<br />
<br />
=== Publishing and Linking on the Web ===<br />
<br />
* Proposed/Led by Dan Appelquist and Jeni Tennison<br />
* To discuss [http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb.html Publishing and Linking on the Web]<br />
<br />
Is linking to pirated content itself a crime? Can sites restrict through policy statements your ability to deep link? Is there a right to link? The TAG has been [http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb.html drafting a document] to provide some technical advice to legal and policy people regarding how publishing and linking on the Web works. This is a topic which straddles technical, legal, regulatory and policy issues. The idea of the session is to get some community feedback on the usefulness of this document.<br />
<br />
=== An End to End Review of the On Line Media Ecology: Proposed Panel Discussion ===<br />
* Proposed/Led by Janina Sajka<br />
<br />
The HTML 5 draft specifications extensively define media support and include<br />
state of the art input a11y support from the HTML-A11Y Task Force. Other W3C<br />
specifications, such as MultiModal's Architecture & Interfaces seem relevant.<br />
So, are we done? Or, are there still gaps we need to fill in support of an<br />
accessible and "any user friendly" experience of TV (and other media) over the<br />
web that is also well-positioned to meet emerging regulatory requirements in<br />
the U.S. (and elsewhere)?<br />
<br />
The purpose of this panel is to consider where we've adequately specified,<br />
where we've over-engineered, and where we still need specifications in support<br />
of this coming consumer, educational, and business media revolution.<br />
<br />
=== Internet of Things: How the Web can enable social applications of everyday devices ===<br />
* Proposed/Led by Dave Raggett<br />
<br />
Moore's law is seeding a revolution of devices, enabling more and more of them to be able to communicate and shake off their isolation and work collectively with us humans for joint social endeavor. This session will review the kinds of devices and communication technologies involved, and how Web technologies can be used to support distributed social applications of devices as a Web of things and people, including the challenges for privacy and security. This will be an open space for participatory discussion, and you are invited to come prepared with lightening presentations and demos of actual devices.<br />
<br />
=== Understanding the HTML Decision Policy ===<br />
* Proposed/Led by PLH & Michael(tm)<br />
<br />
Every so often, we keep getting questions on how operate the W3C HTML Working Group, how to react to bugs, and the decision policy. We'd like to help other individuals understanding how decisions are being made in the HTML Working Group and why it's important to understand the various deadlines assigned to the editors and group participants.<br />
<br />
=== Measuring the Web and its Worldwide Impact ===<br />
<br />
Proposed by: Steve Bratt Leader: Steve Bratt<br />
<br />
The Web Foundation (http://www.webfoundation.org/) is in the process of producing a new Index which aims to quantify the impact of the Web on people and countries. Given the diverse and deep experience of people in the W3C community, we would like your feedback on the concept, the data most useful to feed into the Index, plans for integrating data to compile the Index, how we can best make the data and results openly available, etc. Here is additional background on the Web Index in hopes that this entices you, at the very least, to want to learn more ...<br />
<br />
What is the Web Index? The Web Index will be the world’s first multi-dimensional measure of the Web and its impact on people in a large number of countries. It will result in one aggregate number for each country composed from a suite of measurements or indicator. This number will allow us to infer the extent of the Web’s contribution to the welfare of the people of that country (or the value of the Web to people), as defined by the underlying indicators. This is why the choice of underlying indicators (and data availability for around 100 countries) will be critical for the Index. The Index will look to some extent at infrastructure (e.g., fixed and mobile Internet, devices, policy, etc.). However, the most unique and valuable aspects will be its focus on Web content and activity (topics, languages, quantities, filtering, practices, demographics) and how use of the Web affects the economic, political and social fabric of each country. We are leveraging a grant from Google to start the Index, and invite other interested parties to participate.<br />
<br />
Why compile a Web Index? We do not fully comprehend how this complex and expanding Web of (as Tim has said) "humanity connected by technology" really works. This is a risk to the creative and responsible evolution of the Web, and its ability to have an even more positive impact around the world. The Index will allow for comparisons of trends over time and across borders. It will provide indications of technical conditions that are present or not present in a country that are at least coincidental with, if not related to, the political, economic and social impact of the Web. As a result, the Web Index could be a powerful tool of analysis for policy makers and investors, allowing them to make more effective and better targeted investment strategies. The Index will raise more questions than it answers, and motivate additional research into the Web as not just a technology, but as humanity connected by technology".<br />
<br />
Further background can be found at our Website ...<br />
<br />
- http://www.webfoundation.org/projects/the-web-index/<br />
<br />
=== JavaScript Library Author & Developer Needs from Web Standards ===<br />
* Proposed/Led by Yehuda Katz and Paul Irish<br />
<br />
The environments in which web app developers and web standards wonks operate in rarely overlap but everyone agrees more author input in the standards process would be welcome. Yehuda and Paul, both very plugged into the web developer community, will describe what web developers needs are, based on the results of surveys and hundreds of conversations. They will propose small potential changes to the spec process that would have enormous impact for developers. They'll also highlight what APIs and features are currently causing the most pain for developers. <br />
<br />
<br />
=== Working Group Fidelity to Schedule ===<br />
<br />
Proposed by : Jeff Jaffe Leader: Jeff Jaffe<br />
<br />
AC Charters contain schedules for recommendations. Often we achieve the schedule. Often we don't. When we don't there are negative consequences including less timeliness, cost, workload, opportunity costs, and reputation costs. In this complicated area, though, it is not all negative. It is better to be a little late than to proceed with an inappropriate standard, one that lacks implementation buy-in, or one that is not interoperable.<br />
<br />
At the TPAC Plenary, we will share some data about fidelity to schedule. The purpose of the breakout is to explore what (if any) steps should be taken to improve the situation.<br />
<br />
===Registry Options===<br />
<br />
Proposed by : Debbie Dahl Leader: TBD<br />
<br />
Registry references in W3C specs are useful for several purposes. For example, the information in a registry might be outside of the spec's scope to define or it is information that might change or be extended in the future. WG's have tried various options to address the need for this kind of information. Two recent examples are from EmotionML, which needed a registry for emotion vocabularies, and the Pronunciation Lexicon Specification (PLS) which needed a registry for pronunciation alphabets. Options include (1) find an appropriate external organization such as IANA, which can be a lengthy process, and sometimes it can be difficult to find an appropriate external organization (2) including the information directly in the spec, which ties the registry information to the spec (3) host the registry at the W3C, which requires maintenance(4) produce a WG Note that defines a de facto registry, and which can be updated on a different schedule from the spec. The PLS specification used the first strategy and the EmotionML specification used the fourth. This session will discuss these options and perhaps others with the goal of putting together some suggestions and best practices for WG's who need registry information.<br />
<br />
===Agile Standardization in the CSS Working Group===<br />
<br />
Led by: Fantasai, Tab Atkins, Tantek Çelik<br />
<br />
Presenters will share experiences from the CSS Working Group about how to maintain agility in the standards creation process within the current W3C Process.<br />
<br />
===Web Testing===<br />
<br />
Led by: PLH, Wilhelm<br />
<br />
Come and learn about the goals of the Web Testing activity, the W3C testing server, and how to do testing in W3C Working Groups properly. Tell us what the priorities for doing proper testing on the Web platform.<br />
<br />
===Web Identity and Crypto API Chartering Discussion===<br />
<br />
Led by: Harry Halpin, Thomas Roessler<br />
<br />
The purpose of this session is to continue work on a charter for Web Identity and Crypto API related work at W3C.<br />
<br />
The mission of this work is to improve the the ability of the browser to mediate high-value transactions. Use cases include identity on the web and advanced protocols between web applications. To this end, the group will provide standards around key storage and cryptographic primitives that will provide capabilities that are currently difficult to do safely on the Web platform.<br />
<br />
===next-generation HTTP authentication development ===<br />
Led by: Yutaka OIWA<br />
<br />
The purpose of this session is to introduce recent pre-WG IETF effort on fixing currently-broken HTTP-layer authentication.<br />
I would also going to present a specific proposal for really securing account authentication for the Web system, which can be used for e.g. a starting anchor for federated account managements.<br />
<br />
=Historial Notes=<br />
== How we plan to pre-select 2 plenary sessions and small number of breakouts ==<br />
<br />
<ul class="show_items"><br />
* There will be 2 "plenary" (all group) sessions and there are slots for 28 breakout sessions.<br />
* The [[TPAC2011 Program Committee]] will select from among the proposed plenary topics, and will also pre-select a certain number of breakout sessions. <br />
* Important dates<br />
** 1 October: Deadline for proposals for plenary topics<br />
** 19 October (was 12 October): Announcement of plenary topics<br />
** 19 October: Announcement of approximately 7 pre-selected breakout sessions. These sessions will be guaranteed slots during the meeting. <br />
* The remaining breakout session slots (approximately 21) will be chosen the day of the meeting. <br />
</ul></div>
Roessler
https://www.w3.org/wiki/index.php?title=TPAC/2011/SessionIdeas&diff=55105
TPAC/2011/SessionIdeas
2011-11-02T16:51:25Z
<p>Roessler: /* Web Identity Chartering Discussion */</p>
<hr />
<div>= Plenary Sessions and Pre-Selected Breakouts =<br />
<br />
From among the proposals on this page the [[TPAC2011-Committee|TPAC Program Committee]] has chosen 2 plenary sessions and '''pre-selected''' 8 breakout sessions (meaning they are guaranteed space).<br />
<br />
Plenary sessions:<br />
<br />
<ul class="show_items"><br />
<li>Web and TV. Chair: Mark Vickers (Comcast)<br />
<li>Web Content Interoperability. Chair: Bryan Sullivan (ATT)<br />
</ul><br />
<br />
[[TPAC2011/PlenaryBreakouts|Pre-selected breakout sessions]]:<br />
<br />
<ul class="show_items"><br />
<li>[[TPAC2011/API Design Approaches and the Rationales for Them]]. Chair: Bryan Sullivan<br />
<li>[[TPAC2011/Semantic Syntaxes]]. Chair: Ben Adida<br />
<li>[[TPAC2011/Building Apps in the Cloud]]. Co-Chairs: Said Tabet (EMC) and Marlin Pohlman (EMC)<br />
<li>[[TPAC2011/Advances in Social Network Standardization]]. Chair: Harry Halpin (W3C)<br />
<li>[[TPAC2011/Web-based Digital Signage]]. Chair: Toru Kobayashi (NTT)<br />
<li>[[TPAC2011/HTML5 and Games]]. Chair: Ted Leung (Disney)<br />
<li>Revisiting how W3C creates standards. Co-Chairs: Marcos Caceres, Kai Scheppe (Deutsche Telekom)<br />
<li>W3C Publications Ecosystem. Co-Chairs: Philippe Le Hégaret (W3C), Robin Berjon<br />
</ul><br />
<br />
<p>The last two breakouts are the result of a merger of four proposed sessions; two related to publications process and two related to publishing ecosystem.</p><br />
<br />
= How sessions will be chosen the day of the meeting =<br />
<br />
See [[Session_Selection]]<br />
<br />
= TPAC 2011 Session Ideas =<br />
<br />
We encourage attendees to start brainstorming [[TPAC2011]] session ideas in advance of the meeting, both for cross-group plenary topics and for the breakout sessions. <br />
<br />
Please provide:<br />
<ul class="show_items"><br />
* session name (as a === subhead === )<br />
* session proposer (optional: name a desired session leader, can be yourself)<br />
* one sentence session summary<br />
* 1+ paragraph session description <br />
</ul><br />
<br />
<br />
For cross-group plenary session proposals, please also provide:<br />
<ul class="show_items"><br />
* type of session: (e.g.: talk, panel, open discussion, etc.)<br />
* additional speakers/panelists<br />
</ul><br />
<br />
==Ideas for Cross-Group Plenary Topics==<br />
<br />
These topics should be relevant to a significant number of W3C groups. They will be discussed in plenary (09:00-10:00). If your topic is not selected by the Program Committee as one of the two plenary topics, please consider leading it as a breakout session.<br />
<br />
===The W3C Publication Process is broken: lets fix it!===<br />
Proposed by: Marcos Cáceres<br />
The W3C process requiring static version of specs to be published to /TR/ is seriously broken. The labeling of specs are CR, LC, etc. is also broken: specifications don't follow a linear path to reach Recommendation (e.g., Last Call can come after CR, and Last Call documents can go straight to PR). Standards are *living documents* and trying to version them has led to serious fragmentation in the market, confusion from implementers, and confusion from other standards organizations that use W3C specs.<br />
<br />
Lets work together to come up with a workable solution to this problem. For a start, lets start taking Editor's draft seriously: for too long, some in the W3C community have pretended that Editor's draft have no official status, when in reality they are usually far ahead of anything in the /TR/ space. Making editor's drafts authoritative on the /TR/ space would overcome many of the problems listed above.<br />
<br />
* +1 [[User:Tantekelik|Tantek Çelik]]: I for one support an overhaul of the W3C specification process, focused more on pragmatism and implementation than on protocol and legal mumbo jumbo. The web works because in practice people code first, worry about lawsuits later. I'm willing to help contribute what we've learned with developing http://microformats.org/wiki/process<br />
* Ian Jacobs: I suggest combining with [[Experimental_specifications]]<br />
<br />
===API Design Approaches and the Rationales for Them===<br />
<br />
* Led by: Bryan Sullivan/proposed by Ileana Leuca<br />
<br />
What API design approaches are browser vendors seeking to promote, and what are the rationales for the choices? How can W3C help the wider Web community (including SDOs that want to Web-enable their standards-based service enablers, or extend the Web platform with new capabilities) follow a successful path to convergence with W3C? For example what are the rationales behind the following API design approaches?<br />
<br />
* declarative (via markup language features, e.g. HTML5's <video> tag)<br />
* Javascript (object/procedural interfaces ala window.open())<br />
* XHR/REST (using HTTP scheme URLs such as in conventional RESTful Web APIs, and non-HTTP scheme URLs handled by the browser or some local system-registered URL handler)<br />
<br />
[Robin Berjon] (My understanding based on the email was that we are to provide feedback inline — if I got that wrong please tell me and I'll fix it.) There are two completely different topics here: the one in the title and the one in the description. I would like to suggest that neither makes for a great plenary session topic. The question of work prioritisation cannot be solved in a plenary fashion. W3C is not a top-down organisation, there is no authority whatsoever that can force a given group to follow some form of release plan. The only way of prioritising a deliverable is to commit resources to provide technical solutions to its issues, edit the relevant documents, and experiment with implementations. The question of rationales and design decisions is certainly interesting, but I don't believe that it can usefully be debated in a plenary fashion either. It would be very useful to describe the tradeoffs one needs make between the listed design approaches, but that requires a lengthy, subtle document that does not currently exist (and is unlikely to be written between now and TPAC). In other words, it is more of a long-term TAG deliverable than a short group chat.<br />
<br />
[Bryan Sullivan] Corrected the title... and I agree that a TAG deliverable would probably be a useful result but we need to start a dialog on this with SMEs now, as TAG deliverables are long-term and our need to effectively collaborate on API designs is short-term, e.g. affecting our ability to deliver specifications from DAP.<br />
<br />
[Frederick Hirsch] See also http://lists.w3.org/Archives/Public/www-tag/2011Sep/0002.html<br />
<br />
[Bryan Sullivan] A draft session discussion outline is available at http://bkaj.net/w3c/TPAC-2011-API-Design-Patterns.html. Suggestions for inclusion in this outline are welcome. The intent is to have an interactive discussion, so the outline is brief, but other key aspects to consider or API design approach examples/pros/cons are welcome.<br />
<br />
===How can W3C promote convergence in installable Web application technologies?===<br />
<br />
* Proposed by: Ileana Leuca<br />
<br />
How can we harmonize the objectives, approaches, and capabilities of supporting installable Web applications via:<br />
<br />
* W3C widgets<br />
* HTML5's AppCache<br />
* Vendor-specific packaging/manifests, e.g. as used by Google Chrome Web Apps and Firefox Web Apps.<br />
<br />
[Robin Berjon] I agree that applications is one of the very big topics and strongly support having a session on this topic. However, I feel that the approach proposed here is far too restrictive for a plenary session. There are now more groups in W3C working on application-related technology than I can quote off the top of my head, and that's not speaking of listing all of their deliverables. I would suggest that we could usefully have a broad session that would try to cover the full landscape not at all in depth but at least trying to capture its breadth.<br />
<br />
[Bryan Sullivan] This specific topic could be part of a larger discussion on the effect of fragmentation on the Web applications market, and how to address it for key use cases such as installable Web applications. But it is an important topic for any initiative or service provider that is trying to build a business based upon installable Web application technologies.<br />
<br />
=== Component Model & XBL ===<br />
<br />
Discuss how to move forward with the [http://wiki.whatwg.org/wiki/Component_Model Component Model], a proposed replacement for XBL.<br />
<br />
=== Ensuring Privacy and Security in W3C Recommendations ===<br />
<br />
* proposed by: Nick Doty<br />
<br />
W3C has recently formed Working Groups and Interest Groups around security and privacy topics, but what about the many privacy and security issues that crop up in the many other specifications at W3C? Would a "Security Considerations" or "Privacy Considerations" section work for us? Would you like a group of experts to call on to help review privacy/security issues? Tools, checklists or guidelines for reviewing your own specifications for issues?<br />
<br />
===Web Content Interoperability Challenges===<br />
<br />
* Proposed and Led by: Bryan Sullivan<br />
<br />
<h4>The Challenge</h4><br />
<ul><br />
<li>There is a somewhat accurate perception among developers, that developing for the Web (especially for mobile devices) is <strong><em>freakin' hard</em></strong>, compared to developing for native platforms.</li><br />
<li>Web content interoperability issues are often at the core of developer difficulties.</li><br />
<li>Web content interoperability will greatly affect the potential of HTML5-based app ecosystems which target a wide diversity of devices and service contexts.</li><br />
<li>Such interoperability issues are a key inhibitor of the Web applications market, even without the performance and high-end graphics limitations of current Web user agents compared to native applications.</li></ul><br />
<br />
<h4>W3C Responds!</h4><br />
<ul><br />
<li>W3C is taking steps to address Web browser/content interoperability challenges, through the Web Testing Activity, which will include a combination of tactical focus on test documentation, test production, and testing frameworks, and strategic focus on the overall value of W3C testing for Web application ecosystems.</li><br />
<li>In this manner, the immediate needs of W3C for alignment and further development of test methodology can be combined with progress toward creating a living compliance testing environment which benefits a wide diversity of needs across the Web application ecosystem, including W3C, Web user agent and platform vendors, developers and developer initiatives, service providers, and supporting services (e.g. test/certification providers).</li></ul><br />
<br />
<h4>The goals for this discussion are:</h4><br />
<ul class="incremental"><br />
<li>Frame some overall objectives for Web content interoperability</li><br />
<li>Introduce how this relates to the proposed W3C Testing Activity</li><br />
<li>Start a dialog on how to collect key interoperability issues, ensuring participation of that all those that are impacted:<br />
<ul class="incremental"><br />
<li>Users</li><br />
<li>Developers and content providers</li><br />
<li>Web user agent and tooling vendors</li><br />
<li>Service providers</li></ul><br />
</li></ul><br />
<br />
[Vidhya Gholkar] +1 I think we need to understand what "developers" find difficult and how much can really be addressed by testing. Some of it comes down to education, knowledge base and skills. Also when it comes to content: "being everything to everybody" is a big task (i am referring to the changing fashions, devices, OSs etc etc)!<br />
<br />
[Bryan Sullivan] A draft intro and session discussion outline is available at http://bkaj.net/w3c/TPAC-2011-Web-Content-Interoperability-Challenges.html. Suggestions for inclusion in the discussion are welcome, especially any input on key content interoperability issues faced by developers.<br />
<br />
==Ideas for Breakout Sessions==<br />
<br />
Breakout sessions can cover a wide range of issues: technical issues, cultural issues, future work ideas, presentations of work, etc. <br />
<br />
===Open Web and Web Standards Developer Education and Evangelism===<br />
* Proposer/Leader: Molly E. Holzschlag<br />
* Type of session: discussion<br />
<br />
One of the recently emerging roles across companies, organizations and businesses worldwide is that of Developer Relations. In this role, individuals and entire teams work to educate and evangelize specific technologies as they pertain to the Open Web and Web Standards. Most browser and tool vendors have such teams, and many of us within the W3C are focused on relating internal messages to the external audiences. Open Web philosophy has an implicit goal of removing such barriers to information, and those of us within the W3C will benefit greatly from a discussion on topics such as:<br />
<br />
* Definining the evangelical/educator role<br />
* How do we coordinate messages across a broad range of technologies?<br />
* Is the creation of a task force or community group between external educators and evangelists who are also working within the W3C a helpful direction?<br />
* How do independent or underfunded leaders find support and resources to support their education goals?<br />
* What additional activities can we brainstorm that would increase a sense of community between developers and the W3C (for example, free online workshop/talks / demos, better promotion of talks and developer relation activities via social networks, better coordination between W3C and its advocates)<br />
* Add your ideas here, please!<br />
<br />
===Semantic Syntaxes===<br />
* Proposer: Tantek Çelik<br />
* Discussion Leader: Ben Adida<br />
* Type of session: discussion<br />
<br />
At the recent schema.org workshop, there was quite a bit of discussion of what syntax to use for adding semantic information to HTML documents from among: microdata, microformats, RDFa.<br />
<br />
Ben Adida presented on the evolution of RDFa 1.1 and RDF 1.1 lite, and noted how RDFa has based many simplifications on microformats' syntax.<br />
<br />
microdata itself has been evolving since it was first proposed, based on use-cases provided by RDFa proponents.<br />
<br />
microformats has also been evolving with [http://microformats.org/wiki/microformats-2 microformats 2], and most recently is proposing to use the "itemref" innovation of microdata over the previous "include-pattern"<br />
<br />
It was clear from the discussion in the room that multiple syntaxes are actively co-evolving and learning from/with each other.<br />
<br />
If you're interested in semantic syntaxes (microdata, microformats 2.0, RDFa) this session is for you. Topics:<br />
<br />
* How are syntaxes evolving?<br />
* What features are syntaxes borrowing from each other?<br />
* Is there a common (JSON?) data model that syntaxes are converging on?<br />
<br />
===Open Vocabulary Development===<br />
* Proposer/Leader: Tantek Çelik (but willing to defer to Dan Brickley or R.V. Guha)<br />
* Type of session: discussion<br />
<br />
How to best do open vocabulary development<br />
<br />
* The microformats community has been using the [http://microformats.org/wiki/process microformats process] and slowly but solidly developing about a couple of vocabularies a year (recent successes: hRecipe, hReview-aggregate)<br />
* The microdata community has mostly re-used well-used microformats vocabularies (hCard, hCalendar), and proposed a "Works" vocabulary.<br />
* Google's Rich Snippets proposed data-vocabulary.org where slightly changed versions of microformats vocabularies were published for microdata and RDFa<br />
* schema.org (Google, Bing) introduced 150+ new vocabularies<br />
<br />
Which of these (or combination thereof) is right/best and why?<br />
<br />
Can we work together to incorporate various communities needs and produce a common place/way for rapid open vocabulary development that's not just dominated by large companies?<br />
<br />
Some background:<br />
* http://tantek.com/2011/168/b1/practices-good-open-web-standards-development<br />
<br />
===Increasing Global Participation in W3C===<br />
<br />
* Proposer/Leader: Ann Bassetti (anyone else want to lead? or co-lead? eager to share)<br />
* Type of session: discussion<br />
What more can we do to help people participate comfortably with W3C? What are the barriers or inhibitors and how can we reduce them? Who else wants to participate and can't? Is the English requirement a problem? Are the cost of travel or long-distance calls a problem? Are there cultural differences we should be aware of? Please add to this list & come to the session!<br />
<br />
[Debbie Dahl] I thought about this proposal when I went to add my proposals and found the warning text, "If you do not want your writing to be edited mercilessly, then do not submit it here." I think this kind of language could be off-putting to people from cultures where merciless editing of other people's writing is considered disrespectful. That might well be an example of a cultural difference that we should be aware of.<br />
<br />
[Ann Bassetti] Good catch, Debbie! I bet that warning text is in the MediaWiki software -- not put in there by the W3C staff. I assume that statement is typical American geek goofiness, trying to be funny. I think it is simply a warning that the whole point of a wiki is collaborative editing. Thus, whatever you contribute may be changed, so you should not feel badly if it is. At the same time -- YOU can change someone else's work. I hope W3C participants will not be scared off nor insulted by that message, and that we will all help each other become comfortable with these new modes of working together.<br />
<br />
[Debbie Dahl] I'm sure you're right that this is just trying to be funny and warn contributors that their edits might be changed. My point is that not everyone is going to be clued into this kind of humor, especially people from non-American cultures. I think this is the kind of thing we should look out for.<br />
<br />
===Web in the World===<br />
* Proposer/Leader: Debbie Dahl<br />
Not so long ago, the only intelligent device in existence was a<br />
traditional desktop computer. The only way to interact with the Web<br />
was to sit at a desk in a fixed location. Now the Web is not just<br />
accessible from your desk, but, increasingly, the Web is available out<br />
in the world, either through mobile devices or through devices present<br />
in the environment. Sophisticated processing capabilities are<br />
available in many devices, most notably mobile phones and tablets, but<br />
also in cars, televisions, and household appliances. These new<br />
environments also connect with a rapidly increasing array of<br />
sophisticated capture devices, such as biometrics, scanners, and<br />
medical sensors. This session will discuss how existing standards can<br />
be used to support the Web in the world and what new standards are<br />
needed.<br />
<br />
=== Specification Production Ecosystem ===<br />
* Proposer/Leader: Robin Berjon<br />
There are many tools available to editors but they are often insufficiently known by their potential users. They also tend to duplicate features that could probably be shared (e.g. a references database). Furthermore, there have been a number of proposals (and at times implementations) for improvements to the way in which specifications are currently marked up, for instance to share more detectable semantics for specific structural items (warnings, notes...) or to make testable assertions extractable. The idea behind this session is to bring those who are interested in improving this ecosystem together, irrespective of their chosen tools, in order to share ideas and see if improvements may be made.<br />
<br />
=== Demos of Applications using W3C Standards ===<br />
* Proposer/Leader: Debbie Dahl<br />
This session would invite both implementers of W3C standards as well as<br />
developers who use the standards, to showcase creative, innovative, and<br />
useful W3C standards-based applications and explain how W3C standards made their applications possible.<br />
=== User Experience and Privacy for Microphone Access ===<br />
* Proposer: Cullen Jennings, Leader: Not Me<br />
<br />
Yes, browsers are going to be able to access your microphone and send the resulting media somewhere. The question is how to generate a reasonable level of security and privacy while at the same time having a user experience that is not awful. The idea of the session would be to bring together many of the people of that have thought about this, educate the new people on ideas and experiences from the past, and brainstorm reasonable ideas of how to approach this. Hopefully we would come up with ideas on, or at least educate people on existing ideas, around what access was provided when and what could be done with the resulting media.<br />
<br />
[Stefan Håkansson]: I think we should extend the topic to cover camera access as well.<br />
<br />
===What would make W3C more useful to developers?===<br />
<br />
* Proposed by: Ian<br />
<br />
I would like W3C to be more useful to developers. Community Groups should provide a more welcoming environment for spec development than we've had before. What else should we do? Some ideas:<br />
<br />
* Provide more useful documentation of "what really works on the Web". More useful might include "looks nicer" or "less geeky than the spec itself."<br />
* Provide software vendors with tools to help automate the maintenance of up-to-date information about support for standards.<br />
<br />
===Experimental specifications===<br />
<br />
Proposed by: Kai<br />
Leader: W3C staff<br />
<br />
One of the criticisms often directed towards W3C is being too slow. <br />
The fact that this is due to a detailed process that attempts to avoid errors or conflicts in the specifications is lost to the public at large.<br />
<br />
Would it be possible to open specifications much earlier, allowing early and truly live implementations, to get early feedback from the community?<br />
<br />
In part we are seeing this model with the HTML5 spec and it seems to work.<br />
<br />
* This would/could<br />
** allow implementers to start work with a given spec immediately<br />
** give clear and early indications of the public interest in a spec or parts thereof<br />
** provide rapid feedback on applicability to the intended goal<br />
** provide rapid feedback on potential problems<br />
** in long term increase specification quality<br />
<br />
* Issues for discussion<br />
** It would have to be ensured that feedback can and will just as rapidly be processed and lead to necessary changes in a spec.<br />
** Declaration of specific stages of a spec, giving implementers a certain assurance as to its stability<br />
** Provision of migration paths from one version to another must be mandatory<br />
** Provision of a clear and easy to understand process for giving credit to contributors (especially from the general public)<br />
<br />
<br />
===Making W3C more useful for business===<br />
<br />
Proposed by: Kai<br />
Leader: Alan Bird, Bernard Gidon, Jeff Jaffe<br />
<br />
I am not saying that W3C is not useful for business, but I think many don't see why that is so.<br />
<br />
<br />
Have you noticed how most hotels have discovered their conscience for the environment?<br />
<br />
They appeal to you, the guest, to not throw your towel on the floor, if it is not really disgustingly dirty. No mention of the fact that they, in fact, simply save money by not washing all those towels all the time.<br />
<br />
We play along. Let them save their money. Less detergent in the environment is in fact better too.<br />
<br />
<br />
Do business really care about standardization? <br />
<br />
I don't think so. Not as part of their DNA. <br />
<br />
I think they are interested in earning money, which is perfectly acceptable. If there is money to be made using standards then they are all for it.<br />
<br />
Therefore, can we make it appealing to businesses to use standards, to work with W3C developed technology?<br />
<br />
Can we find the "towel trick" for business?<br />
<br />
<br />
What are the key factors that businesses have found so far?<br />
<br />
What can we learn from that?<br />
<br />
Is there a way to create niche markets, based on technology, that does not have to be based on proprietary technology?<br />
<br />
If not, how can W3C help here?<br />
<br />
The businesses who are already members have decided, for various reasons, that it is good to participate. Why? What can they tell us?<br />
<br />
<br />
But what about the rest, the great masses out there?<br />
<br />
<br />
Which information can we give them, which examples can be shown to make it clear that it saves you money/earns you money if you use standardized, open technology?<br />
<br />
<br />
=== Building Apps in the Cloud ===<br />
<br />
Chaired by: [http://conference.xbrl.org/speakers/t#Said%20Tabet Said Tabet] and [http://www.biztechmarch.com/btsummit/speakers.html#Marlin%20Pohlman Marlin Pohlman], EMC<br />
<br />
Cloud computing is a major topic<br />
* potential speakers: Microsoft, Cisco, Force.com, Amazon?<br />
<br />
<br />
Cloud computing is changing the way companies procure IT infrastructure. Utility computing will also impact individual and company to company interactions.<br />
<br />
The session will explore and highlight current effort to deliver standards-based Cloud application development environments. We want to discuss new and emerging software development methods taking advantage of the elasticity and inherent virtualization capabilities of the Cloud, social software development, and methods such as REST APIs, Mashups, etc.<br />
<br />
We also suggest to have a panel discussion that will include application security as this is a major issue in Cloud adoption. The session will open up discussions with participants to discuss current standards activities at W3C that are relevant to Cloud and what new practical initiatives need to be explored by the membership.<br />
<br />
=== Advances in Social Network standardization ===<br />
<br />
Proposed by: Laurent-Walter Goix. Leader: Harry Halpin<br />
<br />
This session would invite both authors of relevant open specifications in the area of Social Networking as well as developers to discuss their experience on implementing these specifications. The goal of the session is to bring together the widest possible set of open initiatives focused on standardizing social networks at various levels (e.g. client-server protocols, data models, server-to-server federation, end-to-end integration, mobile optimization) through talks that illustrate their specification, current issues and roadmap. Developers may be involved to showcase demos & provide feedback.<br />
Ideally a final panel would discuss specific topics (e.g. user addressing, discovery) to better understand main issues and collaboration opportunities across these initiatives.<br />
<br />
Panel Speakers:<br />
* Status.Net/Federated Social Web<br />
* IETF OAuth WG<br />
* Google+<br />
* Mozilla <br />
* OpenSocial<br />
* OMA MobSocNet<br />
<br />
Discussion:<br />
* +1 I'd like to see this session happen. Some concerns: Which open specifications will be discussed? What do people consider "relevant"? How much time/focus will be spent on more academic/blue-sky social network standards vs. enterprise/oligopoly driven/focused standards vs. pragmatic/real-world-web/indie-web/long-tail focused/adopted open standards? [[User:Tantekelik|Tantek Çelik]] 21:05, 12 October 2011 (UTC)<br />
* ...<br />
<br />
=== Feedback from the World Wide Web Foundation ===<br />
<br />
Proposed by: Debbie Dahl Leader: TBD<br />
<br />
This session would provide an opportunity for staff from the World Wide Web Foundation to talk about their feedback on W3C standards based on their experiences in the developing world or other Foundation activities.<br />
<br />
(note from Ann Bassetti): I like this idea, Debbie! Has anyone alerted Web Foundation folks about this? We probably need to lay the groundwork, so one of them would be in attendance.<br />
<br />
(note from Debbie Dahl. I think this would have to be one of the predetermined sessions, so that we can make sure a Foundation person is in attendance. If there's interest in having this session, I think Steve Bratt should be contacted.)<br />
<br />
(note from Debbie Dahl) After discussing this idea with Steve Bratt, it looks like it's too early for the Foundation to have specific feedback on W3C standards from their perspective, so I'd like to withdraw this suggestion. Perhaps next year we can consider a session on this topic.<br />
<br />
=== HTML5 and Games ===<br />
<br />
Chaired by: Ted Leung, Disney<br />
<br />
This session will discuss issues that arise when trying to build games using HTML5. We may also discuss formation of a Community Group around this topic. <br />
What are the standardization needs?<br />
<br />
* sharing results of [http://openmediaweb.eu/2011/09/14/workshop-on-html-next-for-gaming/ "HTML.next for gaming" workshop] (to happen 24 Sept., in Varsaw)<br />
* note that the [http://www.newgameconf.com/ Newgame conference] is happening 1-2 Nov. in SF<br />
<br />
=== Practices for Developers on Web Privacy ===<br />
<br />
Proposed by: Thomas Roessler.<br />
<br />
=== The Next Privacy and Security Issues for the Web ===<br />
<br />
* Proposed by: Nick Doty<br />
* Could be merged with "Practices for Developers on Web Privacy" and/or "User Experience and Privacy for Microphone Access"<br />
<br />
What are the upcoming privacy and security issues for the Web beyond what we're already seeing today? What experiences have we had with privacy issues on mobile devices and mobile apps that would apply to new Web standards? What new security concerns should we be planning for?<br />
<br />
: If there's interest in this session ahead of TPAC, I'm happy to reach out to some experts who could kick things off, but I suspect that the group will have plenty of new ideas to share. [[User:Npdoty|Nick Doty]] 22:25, 3 October 2011 (UTC)<br />
<br />
=== Web Accessibility: Tips and Maps ===<br />
<br />
Proposed by: Shawn Henry, @@.<br />
<br />
Get tips for quickly checking that you've got the basics of web accessibility covered, e.g., colour contrast, structure markup, @@. We'll do short demos of tools and techniques, provide pointers for more info, and have time for Q&A and discussion.<br />
<br />
=== Declarative 3D Graphics on the Web ===<br />
<br />
* ''Proposers:'' Kristian Sons, Johannes Behr, Don Brutzman<br />
* ''Summary:'' the Declarative 3D Community Group invites other W3C groups to consider common requirements and use cases of shared interest.<br />
* ''Type of session:'' short talk followed by open discussion<br />
<br />
3D Graphics is an important media type that might have much greater impact on Web multimedia, benefiting both users and authors.<br />
<br />
The [http://www.w3.org/community/declarative3d Declarative 3D Community Group] is building requirements for integrating 3D capabilities with other W3C technologies by defining common [http://www.w3.org/community/declarative3d/wiki/Use_Cases_and_Requirements use cases].<br />
<br />
This group will present common use cases that define how [http://www.w3.org/community/declarative3d/wiki/Intersection_of_Declarative_3D_with_other_W3C_Groups_and_Technologies 3D might intersect and interact] with HTML5, DOM events, CSS, SVG, GeoLocation, Augmented Reality (AR), Efficient XML Interchange (EXI) and other key working groups. Certain complex data types and computations are also of mutual interest.<br />
<br />
We invite participation by people working in these other groups so that common ground can be defined, existing work can best be harmonized, and new requirements can be clearly identified.<br />
<br />
=== Adjusting to today’s explosion of input methods ===<br />
Proposed by Kim Patch<br />
<br />
Adjusting to today’s explosion of input methods<br />
<br />
Most of user interface development has assumed keyboard and/or mouse input. Three relative newcomers, however, promise to be increasingly important -- touch, speech and gesture. How important is it for the system to know whether the user is using touchscreen, keyboard, mouse, speech or gesture? How does a mix of input methods, whether or not each method is aware of the other, affect the browser and the user experience?<br />
<br />
The user experience can be very different depending on input method. For instance, it’s rare for a mouse user to have a focus-related issue even when system focus is badly implemented because the mouse user automatically changes focus to mouse location simply by using the mouse. This is different for keyboard and speech users.<br />
<br />
Another example is the single-key keyboard shortcuts that are increasingly popular for Web apps. It’s rare for a keyboard user to accidentally type more than a key or two in a situation where “a” archives a message and “n” goes to the next message, but if a speech user says a phrase in the wrong place, or if the speech system in correctly interprets a command as a phrase, several words worth of commands can be carried out instantly, and not easily reversed.<br />
<br />
What should the browser be aware of in terms of input methods? What should the user be able to adjust to make the browser more aware? What can we do to make sure users keep the control of the system despite increasingly complicated situation with input?<br />
<br />
* ...<br />
<br />
=== The W3C Publication Rules are broken! Let's fix them ===<br />
Proposed by/Leaders PLH & Ted<br />
<br />
Publishing a document in /TR requires lots of patience and zen. We'll like to reconsider the current set of rules imposed on documents published in /TR, as well as the current set of tools used to check those rules. Note that this discussion isn't intended to change the W3C Process document which is a separate and larger topic (and proposed in a different session). if you're a Chair, a team contact, an editor, or simply a user of those documents, we would welcome your feedback on this topic.<br />
<br />
RB: Should we merge this with "Specification Production Ecosystem"? They are quite related, and likely have an overlap in participations.<br />
<br />
* Ian Jacobs: I suggest combining with [[Specification_Production_Ecosystem]]<br />
<br />
=== Where the Web and TV are Headed ===<br />
(tentative title)<br />
<br />
Proposed by Kaz Ashimura<br />
<br />
(details tbd)<br />
<br />
Feedback: <br />
* Please provide a description. Thanks! - [[User:Tantekelik|Tantek Çelik]] 00:16, 15 October 2011 (UTC)<br />
* Please provide a proposed discussion leader. Thanks! - [[User:Tantekelik|Tantek Çelik]] 00:16, 15 October 2011 (UTC)<br />
* ...<br />
<br />
=== Web-based Digital Signage ===<br />
<br />
Leader: Toru Kobayashi<br />
<br />
Proposed: Toru Kobayashi, Shinji Ishii, Masayuki Ihara, and Craig Makino<br />
<br />
This session will discuss issues on the Web-based digital signage that can be used in the near future, for example as effective advertising media in public spaces, personal information displays such as a tablet device and etc. In this session, use cases of digital signage in Japan will be introduced so that it stimulates the discussion about the need of standardization of the Web-based digital signage and about the requirements from technical and business viewpoints.<br />
<br />
Agenda:<br />
* Opening Talk<br />
* Digital signage overview<br />
** what is digital signage?<br />
** market trends<br />
* Use Cases<br />
* Technical issues<br />
** architecture<br />
** technical requirements<br />
* Future plan<br />
* Discussion<br />
<br />
=== Merging video element from HTML5 and SVG ===<br />
<br />
* Proposer/Leader: Jan Lindquist (but willing to differ)<br />
* People interested in discussing: Giuseppe Pascale, Erik Dahlström<br />
* Type of session: Discussion<br />
<br />
<br />
There has been a lot of effort to develop HTML5 video element which has had many enhancments like timetracks, audio and media elements. SVG Tiny 1.2 also has a video element defined much earlier than HTML5. With all the effort on HTML5 what is the future of SVG's video element? Shall it be left as is, shall it be merged with HTML5's video element or other direction? It is important to clarify the direction of SVG video element to avoid misalingment. As the title suggest the recommendation is that they are merged.<br />
<br />
Note that this topic was raised from discussions in the Web and TV Interest Group - Media Piping Task Force. Most recently it was discussed in the webTV workshop held in Hollywood. Currently the requirement highlighting this issue is "[http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/VideoTagSupportMpeg2-ts Issue - 18]" under Implementation issue # 6. In order to meet the deadline this topic was raised prior to the requirement being finalized in the task force.<br />
<br />
=== Publishing and Linking on the Web ===<br />
<br />
* Proposed/Led by Dan Appelquist and Jeni Tennison<br />
* To discuss [http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb.html Publishing and Linking on the Web]<br />
<br />
Is linking to pirated content itself a crime? Can sites restrict through policy statements your ability to deep link? Is there a right to link? The TAG has been [http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb.html drafting a document] to provide some technical advice to legal and policy people regarding how publishing and linking on the Web works. This is a topic which straddles technical, legal, regulatory and policy issues. The idea of the session is to get some community feedback on the usefulness of this document.<br />
<br />
=== An End to End Review of the On Line Media Ecology: Proposed Panel Discussion ===<br />
* Proposed/Led by Janina Sajka<br />
<br />
The HTML 5 draft specifications extensively define media support and include<br />
state of the art input a11y support from the HTML-A11Y Task Force. Other W3C<br />
specifications, such as MultiModal's Architecture & Interfaces seem relevant.<br />
So, are we done? Or, are there still gaps we need to fill in support of an<br />
accessible and "any user friendly" experience of TV (and other media) over the<br />
web that is also well-positioned to meet emerging regulatory requirements in<br />
the U.S. (and elsewhere)?<br />
<br />
The purpose of this panel is to consider where we've adequately specified,<br />
where we've over-engineered, and where we still need specifications in support<br />
of this coming consumer, educational, and business media revolution.<br />
<br />
=== Internet of Things: How the Web can enable social applications of everyday devices ===<br />
* Proposed/Led by Dave Raggett<br />
<br />
Moore's law is seeding a revolution of devices, enabling more and more of them to be able to communicate and shake off their isolation and work collectively with us humans for joint social endeavor. This session will review the kinds of devices and communication technologies involved, and how Web technologies can be used to support distributed social applications of devices as a Web of things and people, including the challenges for privacy and security. This will be an open space for participatory discussion, and you are invited to come prepared with lightening presentations and demos of actual devices.<br />
<br />
=== Understanding the HTML Decision Policy ===<br />
* Proposed/Led by PLH & Michael(tm)<br />
<br />
Every so often, we keep getting questions on how operate the W3C HTML Working Group, how to react to bugs, and the decision policy. We'd like to help other individuals understanding how decisions are being made in the HTML Working Group and why it's important to understand the various deadlines assigned to the editors and group participants.<br />
<br />
=== Measuring the Web and its Worldwide Impact ===<br />
<br />
Proposed by: Steve Bratt Leader: Steve Bratt<br />
<br />
The Web Foundation (http://www.webfoundation.org/) is in the process of producing a new Index which aims to quantify the impact of the Web on people and countries. Given the diverse and deep experience of people in the W3C community, we would like your feedback on the concept, the data most useful to feed into the Index, plans for integrating data to compile the Index, how we can best make the data and results openly available, etc. Here is additional background on the Web Index in hopes that this entices you, at the very least, to want to learn more ...<br />
<br />
What is the Web Index? The Web Index will be the world’s first multi-dimensional measure of the Web and its impact on people in a large number of countries. It will result in one aggregate number for each country composed from a suite of measurements or indicator. This number will allow us to infer the extent of the Web’s contribution to the welfare of the people of that country (or the value of the Web to people), as defined by the underlying indicators. This is why the choice of underlying indicators (and data availability for around 100 countries) will be critical for the Index. The Index will look to some extent at infrastructure (e.g., fixed and mobile Internet, devices, policy, etc.). However, the most unique and valuable aspects will be its focus on Web content and activity (topics, languages, quantities, filtering, practices, demographics) and how use of the Web affects the economic, political and social fabric of each country. We are leveraging a grant from Google to start the Index, and invite other interested parties to participate.<br />
<br />
Why compile a Web Index? We do not fully comprehend how this complex and expanding Web of (as Tim has said) "humanity connected by technology" really works. This is a risk to the creative and responsible evolution of the Web, and its ability to have an even more positive impact around the world. The Index will allow for comparisons of trends over time and across borders. It will provide indications of technical conditions that are present or not present in a country that are at least coincidental with, if not related to, the political, economic and social impact of the Web. As a result, the Web Index could be a powerful tool of analysis for policy makers and investors, allowing them to make more effective and better targeted investment strategies. The Index will raise more questions than it answers, and motivate additional research into the Web as not just a technology, but as humanity connected by technology".<br />
<br />
Further background can be found at our Website ...<br />
<br />
- http://www.webfoundation.org/projects/the-web-index/<br />
<br />
=== JavaScript Library Author & Developer Needs from Web Standards ===<br />
* Proposed/Led by Yehuda Katz and Paul Irish<br />
<br />
The environments in which web app developers and web standards wonks operate in rarely overlap but everyone agrees more author input in the standards process would be welcome. Yehuda and Paul, both very plugged into the web developer community, will describe what web developers needs are, based on the results of surveys and hundreds of conversations. They will propose small potential changes to the spec process that would have enormous impact for developers. They'll also highlight what APIs and features are currently causing the most pain for developers. <br />
<br />
<br />
=== Working Group Fidelity to Schedule ===<br />
<br />
Proposed by : Jeff Jaffe Leader: Jeff Jaffe<br />
<br />
AC Charters contain schedules for recommendations. Often we achieve the schedule. Often we don't. When we don't there are negative consequences including less timeliness, cost, workload, opportunity costs, and reputation costs. In this complicated area, though, it is not all negative. It is better to be a little late than to proceed with an inappropriate standard, one that lacks implementation buy-in, or one that is not interoperable.<br />
<br />
At the TPAC Plenary, we will share some data about fidelity to schedule. The purpose of the breakout is to explore what (if any) steps should be taken to improve the situation.<br />
<br />
===Registry Options===<br />
<br />
Proposed by : Debbie Dahl Leader: TBD<br />
<br />
Registry references in W3C specs are useful for several purposes. For example, the information in a registry might be outside of the spec's scope to define or it is information that might change or be extended in the future. WG's have tried various options to address the need for this kind of information. Two recent examples are from EmotionML, which needed a registry for emotion vocabularies, and the Pronunciation Lexicon Specification (PLS) which needed a registry for pronunciation alphabets. Options include (1) find an appropriate external organization such as IANA, which can be a lengthy process, and sometimes it can be difficult to find an appropriate external organization (2) including the information directly in the spec, which ties the registry information to the spec (3) host the registry at the W3C, which requires maintenance(4) produce a WG Note that defines a de facto registry, and which can be updated on a different schedule from the spec. The PLS specification used the first strategy and the EmotionML specification used the fourth. This session will discuss these options and perhaps others with the goal of putting together some suggestions and best practices for WG's who need registry information.<br />
<br />
===Agile Standardization in the CSS Working Group===<br />
<br />
Led by: Fantasai, Tab Atkins, Tantek Çelik<br />
<br />
Presenters will share experiences from the CSS Working Group about how to maintain agility in the standards creation process within the current W3C Process.<br />
<br />
===Web Testing===<br />
<br />
Led by: PLH, Wilhelm<br />
<br />
Come and learn about the goals of the Web Testing activity, the W3C testing server, and how to do testing in W3C Working Groups properly. Tell us what the priorities for doing proper testing on the Web platform.<br />
<br />
===Web Identity and Crypto API Chartering Discussion===<br />
<br />
Led by: Harry Halpin, Thomas Roessler<br />
<br />
The purpose of this session is to continue work on a charter for Web Identity and Crypto API work at W3C.<br />
<br />
The mission of this work is to improve the the ability of the browser to mediate high-value transactions. Use cases include identity on the web and advanced protocols between web applications. To this end, the group will provide standards around key storage and cryptographic primitives that will provide capabilities that are currently difficult to do safely on the Web platform.<br />
<br />
===next-generation HTTP authentication development ===<br />
Led by: Yutaka OIWA<br />
<br />
The purpose of this session is to introduce recent pre-WG IETF effort on fixing currently-broken HTTP-layer authentication.<br />
I would also going to present a specific proposal for really securing account authentication for the Web system, which can be used for e.g. a starting anchor for federated account managements.<br />
<br />
=Historial Notes=<br />
== How we plan to pre-select 2 plenary sessions and small number of breakouts ==<br />
<br />
<ul class="show_items"><br />
* There will be 2 "plenary" (all group) sessions and there are slots for 28 breakout sessions.<br />
* The [[TPAC2011 Program Committee]] will select from among the proposed plenary topics, and will also pre-select a certain number of breakout sessions. <br />
* Important dates<br />
** 1 October: Deadline for proposals for plenary topics<br />
** 19 October (was 12 October): Announcement of plenary topics<br />
** 19 October: Announcement of approximately 7 pre-selected breakout sessions. These sessions will be guaranteed slots during the meeting. <br />
* The remaining breakout session slots (approximately 21) will be chosen the day of the meeting. <br />
</ul></div>
Roessler
https://www.w3.org/wiki/index.php?title=IdentityCharter&diff=55104
IdentityCharter
2011-11-02T16:50:55Z
<p>Roessler: /* Web Cryptography Working Group Charter */</p>
<hr />
<div>=Web Cryptography Working Group Charter=<br />
'''This document is under informal review'''<br />
<br />
For informal discussion of the proposal, send comments and subscribe to public-identity@w3.org (public archives).<br />
<br />
The mission of this work is to improve the the ability of the browser to mediate high-value transactions. Use cases include identity on the web and advanced protocols between web applications. To this end, the group will provide standards around key storage and cryptographic primitives that will provide capabilities that are currently difficult to do safely on the Web platform.<br />
<br />
<br />
* End date 30 December 2013 <br />
* Confidentiality Proceedings are Public <br />
* Chairs @@ (@@) <br />
* Team Contacts Harry Halpin (FTE %: @@), @@ <br />
<br />
<br />
Usual Meeting Schedule Teleconferences: topic-specific calls may be held, normally weekly. <br />
Face-to-face: We will meet during the W3C's annual Technical Plenary week; other additional F2F meetings may be scheduled <br />
<br />
==1. Scope==<br />
<br />
The mission of this work is to improve the the ability of the browser to mediate high-value transactions. Use cases include identity on the web and advanced protocols between web applications. To this end, the group will provide standards around key storage and cryptographic primitives that will provide capabilities that are currently difficult to do safely on the Web platform.<br />
<br />
This work will focus on increasing uniform support for asymmetric cryptography amongst browsers and in existing solutions although symmetric systems could be supported. One important goal is to permit client to serve as higher security component in a distributed ID system that is complementary to current server-side work. <br />
<br />
The Web Cryptography Working Group should aim to produce specifications that have wide deployment amongst end-users, and so should work carefully with as many major implementers as possible. The Web Cryptography Working Group should adopt, refine and when needed, extend, existing practices and community-driven draft specifications when possible. The cryptography work should integrate well with Web Applications and so should be developed in concert with Web Application developers and the Web Application Security and HTML Working Groups. Comprehensive test suites will be developed for the specification to ensure interoperability, and the Working Group will assist in the production of interoperability reports.<br />
<br />
==1.1 Success Criteria==<br />
<br />
In order to advance to Proposed Recommendation, each specification is expected to have two independent implementations of each of feature defined in the specification. <br />
<br />
==2. Deliverables==<br />
==2.1 Recommendation-Track Deliverables==<br />
<br />
The working group will deliver at least the following:<br />
<br />
<br />
* '''Use-cases and requirements''': In order to properly scope the cryptography API, the group will collect use-cases and requirements, with a focus on enabling distributed solutions around the improving the security of distributy identity solutions and the trust of mobile code. <br />
<br />
* '''Cryptography API''': Commonly-used cryptographic primitives should be made available to web application developers via a standardized API to facilitate common operations such as asymmetric encryption key pair generation, encryption, and generation, as well as symmetric encryption, hashing, and signature verification as well as an abstract model for safe key storage. This work can be based upon DOMCrypt, which has already been discussed in the W3C WebApps WG, HTML WG, and IETF Web Security WG.<br />
<br />
Each specification must contain a section detailing any known security implications for implementors, Web authors, and end users. The Web Cryptography WG will actively seek an open security review on all its specifications.<br />
<br />
To increase the convenience and security of deployment, these specifications may interact will take into account existing platform and operating system identity managers and so additional informative work in this area may be necessary.<br />
<br />
==2.1 Other Deliverables==<br />
Additionally, the Web Cryptography Working Group has as a goal to improve the deployment of secure client-side interactions around authentication and identity on the Web. This will be done via outreach and interaction with the larger security communtiy and the identity community and by participating in both industry and government-led joint efforts with other organizations. So other non-normative documents may be created such as:<br />
<br />
*Test suites for each specification;<br />
*Primer or Best Practice documents to support web developers when designing applications dealing with cryptography;<br />
<br />
Milestones Note: The group will document significant changes from this initial schedule on the group home page. <br />
Specification FPWD LC CR PR Rec <br />
<br />
Cryptography API December 2011 February 2012 July 2012 September 2012 November 2012 <br />
<br />
==2.1 Milestones==<br />
<br />
The production of the deliverables depends upon the resources available, and will change as new information and implementation experience is reported to the group. The most up-to-date timeline is available from the Web WG Publication Status page.<br />
<br />
==3. Dependencies and Liaisons==<br />
<br />
*Web Applications Working Group<br />
To co-ordinate with APIs and features around building Web Applications*Privacy Interest Group<br />
So that users have options to respect their privacy and can use a uniform cryptography API and key storage to help, the Web Cryptography working group should engage in any developments in privacy.<br />
<br />
* WebAppSec Working Group<br />
To co-ordinate with any security requirements and specifications arising from the security needs of Web Applications.<br />
So that users have options to respect their privacy as regards third-party tracking, the Web Identity Working Group may interact with preference expression mechanisms and technologies for selectively allowing or blocking tracking elements. <br />
Furthermore, the Web Identity Working Group expects to follow the following W3C Recommendations, Guidelines and Notes and, if necessary, to liaise with the communities behind the following documents: <br />
<br />
*Architecture of the World Wide Web, Volume I<br />
*Internationalization Technical Reports and Notes<br />
*QA Framework: Specification Guidelines<br />
<br />
==3.1 External Groups==<br />
<br />
The following is a tentative list of external bodies the Working Group should collaborate with: <br />
<br />
* Internet Engineering Task Force<br />
The IETF is responsible for defining robust and secure protocols for Internet functionality. A clear relationship with IETF is vital to assure the security and success of elements of Web Cryptography that supervenes upon protocol-level work. For example, security reviews should involve the IETF Web Security (WebSec) Working Group. In particular the JSON based cryptography formats being done in the IETF Web Object Encryption and Signing (JOSE) Working Group, =<br />
<br />
*ECMA Technical Committee 39 (TC39)<br />
This is the group responsible for ECMAScript standardization and related features. As the Web Cryptography Working Group may require additional features to ECMAScript, it should collaborate with TC39.<br />
<br />
* OASIS<br />
The Web Identity Working Group's work should enable higher-security deployment of the SAML family of specifications and monitor working group.<br />
<br />
* OpenID Foundation<br />
The Web Identity Working Group's work should enable higher-security and wider deployment of the OpenID family of specifications and trust frameworks that involve the client. <br />
<br />
==4. Participation==<br />
To be successful, the Web Cryptography Working Group is expected to have 10 or more active participants for its duration, and to have the participation of the industry leaders in fields relevant to the specifications it produces. The Chairs and specification Editors are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other Participants.<br />
<br />
The Web Cryptography Working Group will also allocate the necessary resources for building test suites for each specification.<br />
<br />
The Web Cryptography Working Group welcomes participation from non-Members. The group encourages questions and comments on its public mailing lists, as described in Communication. As needed, the group may also call for joint teleconferences and meetings with related organizations and standards bodies in the field of identity.<br />
<br />
The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy. The Working Group may also call for the formation of Community Groups or work in other standards bodies such as the IETF.<br />
<br />
==5. Communication==<br />
Most Web Identity Working Group Teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. At least one teleconference will be held per week.<br />
<br />
Most of the technical work of the group will be done through discussions on one of the group's public mailing lists, for which there is no formal requirement for participation:<br />
<br />
*public-webcryptography@w3.org (archive) for general discussion<br />
<br />
The group will use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a particular member requests such a discussion.<br />
<br />
Information about the group (for example, details about deliverables, issues, actions, status, participants) will be available from the Web Cryptography Working Group home page.<br />
<br />
==6. Decision Policy==<br />
As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available. <br />
<br />
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires. <br />
<br />
==7. Patent Policy== <br />
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. <br />
<br />
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation. <br />
<br />
==8. About this Charter==<br />
This charter for the Web Cryptography Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. <br />
<br />
<br />
<br />
--------------------------------------------------------------------------------<br />
<br />
Harry Halpin, <hhalpin@w3.org>, Team Contact <br />
@@, <@@>, Team Contact <br />
@@, @@, Chair <br />
@@, @@, Chair <br />
Copyright© 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved.<br />
<br />
$Date: 2011/09/19 22:35:38 $</div>
Roessler