W3C WBS Home

Results of Questionnaire [Call for Objections] Definition of context

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: team-tracking-chairs@w3.org

This questionnaire was open from 2014-02-12 to 2014-02-26.

14 answers have been received.

Jump to results for question:

  1. Option A: Common controller and group identity
  2. Option B: Data controller with common branding
  3. Option C: Resources operated by one party
  4. Option D: No definition

1. Option A: Common controller and group identity

A context is a set of resources with a common data controller and a group identity that is easily discoverable by a user.

Note that this definition of context is intended to represent a typical user's expectations regarding the boundaries of a commonly branded Web site (i.e., what makes it distinct from sites with a different group identity) independent of the technology, domain names, or parties operating that site via one or more origin servers.

Details

Responder Option A: Common controller and group identity
Walter van Holst This notion of context is vague and therefore very ill-suited for usage within software.
Mike O'Neill I object to this option for the following reasons.

A data controller may have distinct privacy policies for data collected by servers for different sets of resources. A user may not agree that data collected under one policy can be linked to data collected under another, so the definition of context should reflect this.
It is also important that a means is available to indicate to a user, for a particular web interaction, what servers are collecting data and if tracking is occurring across multiple contexts. As the TPE is a technical document it is appropriate that the primitives used to convey this are spelled out in this definition.

Rob van Eijk I object, this definition does not help the definition of tracking. (1) On the contrary, it makes the meaning of tracking less clear. (2) It also lacks the granularity needed to distinguish different contexts between sets "of resources with a common data controller and a group identity that is easily discoverable by a user". E.g., a data controller with news magazine A (set of resources) and news magazine B (set of resources) could easily be one context under this definition.

The tracking-context combination reads: "Tracking is the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources with a common data controller and a group identity that is easily discoverable by a user."
Chris Pedigo
David Singer This is only acceptable if (as indicated) the definition of 'tracking' is merely for the purposes of informing the user roughly what it is they are turning off. Otherwise this is too loose to be testable or usable.
Chris Mejia I strongly object to Option A, as this definition clearly “bakes in” compliance policy that should not be found in a pure technical document. Furthermore, I generally object to the inclusion of ANY definitions in the TPE—all definitions should be found in a compliance spec that will accompany the TPE in practice.

As we had previously agreed to bifurcate the spec into two parts, technical and compliance, it would be most appropriate to define key terminology in the compliance spec. In deployment, the tech spec should always be married with a compliance spec, the two combined essentially becoming ONE single DNT spec. Accordingly, it would be most appropriate to define terminology in the compliance spec, especially if such terminology could be germane to compliance policy (in the case of the words “tracking” and “context”, those definitions are most certainly germane to compliance policy). There is no need to confuse things by introducing just some select definitions in the TPE, and then others in the compliance spec.

This working group has already approved the bifurcation, and has ratified the idea that there may be multiple compliance specs to choose from for companies deploying the DNT solution. Having definitions in the TPE, which is meant to be a PURE technical document (technical “plumbing” only), will likely lead to situations where there is direct conflict between the tech spec and a compliance spec.

Defining “context” and “tracking” is important, don’t get me wrong—but it’s equally important that their definitions fall in line with the rest of a compliance document’s policy. The push to define these terms in the TPE feels like a “back door” way to force certain overriding privacy constructs on compliance policies yet to be developed. That was not the intent of bifurcating the spec into two parts.
Brad Kulick I object to this option. I am not in favor of continuing to address compliance issues within the TPE. This should be left for the compliance document.
Alan Chapell I object to this option. The chairs have already opted to include a definition of Tracking in the TPE – over the objection of a majority of the working group. Part of the initial rationale for defining tracking in the TPE was to provide interested parties with a general idea of what we mean by tracking. And little by little, we’ve ported more and more compliance definitions into the TPE. Please – let’s stop our descent down this slippery slope. I object to continuing to address compliance issues within the TPE.
Shane Wiley I object to this approach as it is an overstatement of the previously agreed upon position the working group had arrived at within the Tracking Compliance & Scope document. Additionally, this is an attempt to pull compliance elements into the TPE which we've agreed not to do while immediately moving to work on the TCS post TPE "Last Call". If we are to truly contemplate a different 'party' definition than we currently hold in the most recent TCS, we need to revisit each of the discussion points we've already covered on branding, ownership, and easy discoverablility. Each of these areas is highly complex and could significantly impact the Internet as we know it today - possibly requiring deep and massively costly industry investment to come into compliance - an obvious barrier to adoption of this standard.
David Wainberg I object to porting compliance definitions into the TPE. This definition in particular is exceptionally vague. We should leave definitions like this out of the TPE.
Lee Tien At the very least, "data controller" needs to be defined or specified. As a US lawyer, I am not intimately familiar with the nuances of the EU concept. Does it make sense to not require that the commonness of the data control be "easily discoverable"? I also dislike (always have) the notion of "easily discoverable," at least without further specification; it's always seemed to me that the bottom line is whether the typical user "would understand." Put another way, "discoverability" seems intended to permit a key fact to NOT be in front of the user. As written there is no incentive to put it in front.
Jack Hobaugh I object to Option A.
In general, I object to the porting of a compliance-related definition into the technical specification (“TPE”). I feel strongly that the TPE should remain a pure protocol and technical specification document. Some have contended that compliance-related definitions are needed in the TPE in order for a consumer to understand his or her choice regarding the DNT signal. This is simply not the case. It is sufficient to present to a consumer the simple choice of whether to send or not send a DNT signal. A technical specification need only specify the requests and responses necessary for a DNT protocol to be implemented in a scalable and implementable solution across all browsers and the servers called. Moreover, the intended audience for the TPE is technical implementers such as software engineers, developers, and programmers, but not consumers. To be clear, the TPE should not take on the responsibility of informing consumers and attorneys regarding a policy or compliance choice but instead should inform the technical community on how to implement a technical solution. The compliance specification for the DNT signal should be left to the compliance regime, whether it is a national compliance regime, a W3C-based compliance regime or a self-regulatory compliance regime. Porting definitions from a particular compliance regime into the TPE only serves to provide an incomplete and conflicting picture to the software engineers, developers, and programmers who will be tasked with implementing the technical protocol together with a compliance policy.

Moreover, even if a definition were warranted for “context,” to be fair that definition should have been resolved prior to the call for objections that decided the definition for tracking, in which “context” is found.

Further, with each compliance-related definition that is added to the technical specification (TPE) comes an increased probability that the TPE will conflict with compliance definitions contained in a non-W3C compliance policy. As the potential for compliance-related conflicts between the TPE and a non-W3C compliance policy increase, so does the potential for non-adoption of the TPE for those entities that choose to implement a non-W3C compliance policy.

I also object to the extent that this definition suggests that privacy gains can only be obtained through common ownership. I incorporate by reference, the section “harm to competition” found at http://www.w3.org/2002/09/wbs/49311/datahygiene/results.
Rob Sherman
Roy Fielding I prefer this definition.

The comments by others regarding vagueness are once again failing to understand the point. This notion of context needs to be understood by the user regardless of a site's compliance, since it is being sent without regard to any specific site.

The suggestions that this term belongs in a compliance spec (or perhaps defined differently by different compliance specs) is just as absurd as defining the meaning of tracking in compliance specs. The user is not expected to read those specs. We are defining a user preference protocol. If we don't define what we mean in that protocol, then others will define it for us (inconsistently by browsers, or forcefully by regulators).

2. Option B: Data controller with common branding

A context is limited to the set of resources that share the same data controller, are covered by the same privacy policy, share a common branding, and whose host domains, other than that of the document origin, have been declared in the same-party property of the Tracking Resource.

Non-normative Note:

In case the same-party field is empty, then only the given site is considered to be the same context.

In order for a definition of context to be granular enough to distinguish one context from another, a set of cumulative criteria is proposed. The purpose of this definition is to reflect the user expectations that data collected for a specified purpose by one of those resources is available to all other resources within the same context. Data must not be shared between different contexts. Respect for context and purpose limitation within a context are important core principles for any use of (personal) data within that context. Within any particular network interaction within a context, a user can expect that session states and other data (strictly) necessary to support the activity will be retained or shared.

Details

Responder Option B: Data controller with common branding
Walter van Holst This definition is suitable for implementation and use within software and is therefore preferable for the TPE.
Mike O'Neill I support this option.
Rob van Eijk
Chris Pedigo I object to this option because it is not workable and would cause many companies to not implement this DNT standard. For example, many companies have different privacy policies for each region/country where they have a presence in order to reflect and honor that region or country's unique laws. Under this Option, a company's site in one country would be a different context than the company's nearly-identical site in another country. Finally, I am concerned that the non-normative text contains several phrases - "Data must not be shared", "respect for context and purpose limitation", and "data (strictly) necessary" - that would be inappropriate for the TPE and are better suited for a compliance regime.
David Singer This seems very restrictive, and tends too far into the domain of the compliance specifications. It's too complex to explain to a user, as well.
Chris Mejia I strongly object to Option B, as this definition clearly “bakes in” compliance policy that should not be found in a pure technical document. Furthermore, I generally object to the inclusion of ANY definitions in the TPE—all definitions should be found in a compliance spec that will accompany the TPE in practice.

As we had previously agreed to bifurcate the spec into two parts, technical and compliance, it would be most appropriate to define key terminology in the compliance spec. In deployment, the tech spec should always be married with a compliance spec, the two combined essentially becoming ONE single DNT spec. Accordingly, it would be most appropriate to define terminology in the compliance spec, especially if such terminology could be germane to compliance policy (in the case of the words “tracking” and “context”, those definitions are most certainly germane to compliance policy). There is no need to confuse things by introducing just some select definitions in the TPE, and then others in the compliance spec.

This working group has already approved the bifurcation, and has ratified the idea that there may be multiple compliance specs to choose from for companies deploying the DNT solution. Having definitions in the TPE, which is meant to be a PURE technical document (technical “plumbing” only), will likely lead to situations where there is direct conflict between the tech spec and a compliance spec.

Defining “context” and “tracking” is important, don’t get me wrong—but it’s equally important that their definitions fall in line with the rest of a compliance document’s policy. The push to define these terms in the TPE feels like a “back door” way to force certain overriding privacy constructs on compliance policies yet to be developed. That was not the intent of bifurcating the spec into two parts.
Brad Kulick I object to this option. I am not in favor of continuing to address compliance issues within the TPE. This should be left for the compliance document.

This option, especially, is overly prescriptive for the TPE and, therefore, more than options A, B, and C should not be in the technical specification document. If context were to be defined in this manner, then it should be reviewed within the context of the compliance document.
Alan Chapell I object to this option as well. I am not in favor of continuing to address compliance issues within the TPE. This should be left for the compliance document.
Shane Wiley I STRONGLY OBJECT to this approach as it is a gross extension and overstatement of previously agreed upon positions with respect to party position. Additionally, this is an attempt to pull compliance elements into the TPE which we've agreed not to do while immediately moving to work on the TCS post TPE "Last Call". If we are to truly contemplate a different 'party' definition than we currently hold in the most recent TCS, we need to revisit each of the discussion points we've already covered on branding, ownership, and easy discoverablility. Each of these areas is highly complex and could significantly impact the Internet as we know it today - possibly requiring deep and massively costly industry investment to come into compliance - an obvious barrier to adoption of this standard.
David Wainberg I object to porting compliance definitions into the TPE.
Lee Tien Although I still am not sure what "data controller" means, this is the best of the options because it is more specific. The non-normative note also clarifies that the definition has the correct motivation -- to distinguish, rather than aggregate or blur, contexts. In particular, compared to C, a single party can operate different contexts and thus "track." This is a feature, not a bug.
Jack Hobaugh I object to Option B.
In general, I object to the porting of a compliance-related definition into the technical specification (“TPE”). I feel strongly that the TPE should remain a pure protocol and technical specification document. Some have contended that compliance-related definitions are needed in the TPE in order for a consumer to understand his or her choice regarding the DNT signal. This is simply not the case. It is sufficient to present to a consumer the simple choice of whether to send or not send a DNT signal. A technical specification need only specify the requests and responses necessary for a DNT protocol to be implemented in a scalable and implementable solution across all browsers and the servers called. Moreover, the intended audience for the TPE is technical implementers such as software engineers, developers, and programmers, but not consumers. To be clear, the TPE should not take on the responsibility of informing consumers and attorneys regarding a policy or compliance choice but instead should inform the technical community on how to implement a technical solution. The compliance specification for the DNT signal should be left to the compliance regime, whether it is a national compliance regime, a W3C-based compliance regime or a self-regulatory compliance regime. Porting definitions from a particular compliance regime into the TPE only serves to provide an incomplete and conflicting picture to the software engineers, developers, and programmers who will be tasked with implementing the technical protocol together with a compliance policy.

Moreover, even if a definition were warranted for “context,” to be fair that definition should have been resolved prior to the call for objections that decided the definition for tracking, in which “context” is found.

Further, with each compliance-related definition that is added to the technical specification (TPE) comes an increased probability that the TPE will conflict with compliance definitions contained in a non-W3C compliance policy. As the potential for compliance-related conflicts between the TPE and a non-W3C compliance policy increase, so does the potential for non-adoption of the TPE for those entities that choose to implement a non-W3C compliance policy.

I also object to the extent that this definition suggests that privacy gains can only be obtained through common ownership. I incorporate by reference, the section “harm to competition” found at http://www.w3.org/2002/09/wbs/49311/datahygiene/results.
Rob Sherman I'm concerned that Option B would cause parties to choose not to adopt the TPE, particularly on a global basis where adoption is especially important. Specifically, not all countries require privacy policies in the first instance, and even where privacy policies are adopted or customary many companies will choose to adopt different privacy policies for services that operate in different countries, recognizing the varying compliance obligations that exist in different jurisdictions. Requiring a party to satisfy not one but all of these tests is unrealistic and inconsistent with consumer expectations — for example, if it is expected that a U.S.-based service and a non-U.S. service should be able to interoperate but have different privacy policies because of differing legal obligations. Likewise, the Working Group has already decided to reject common branding, which is unduly restrictive and does not cover all possible scenarios, as the appropriate standard for the Compliance document; it should not be reintroduced here.

Even if this issue were addressed, Option B is inferior to other options because it is based on the premise — as reflected in the reference to including all same-context domains in the same-party attribute — that context and party are coextensive or overlapping. This adds needless complexity to the TPE and creates confusion with two definitions of a similar concept that are not clearly distinguished, when in fact the definition of "party" can do all of the necessary work.

Option B also is defective because it is inconsistent with the Working Group's consensus decision in Section 2.3 of the TPE that some resources may be operated by multiple parties, a concept that is not incorporated into Option B.

Finally, the non-normative text included in Option B purports to prescribe compliance obligations (“reflect user expectations,” “data collected for a specified purpose ... is available to all other resources within the same context,” “[d]ata must not be shared between different contexts,” “[r]espect for context and purpose limitation ... are important core principles for any use of ... data,” etc.) that are inappropriate for inclusion in the TPE. These concepts, and the normative text they interpret, should be deferred to the appropriate compliance regime.
Roy Fielding I object to this option. It is unworkable because it doesn't take into account changing policies over time or region, and assumes that the user is retrieving tracking status representations.

Privacy policies often differ by region and are associated with
data when it is collected, whereas a site might consist of many
regional websites that combine data with permission from other
regional sources (e.g., Twitter), combine older resources with
new resources that have an updated policy, or combine multiple
resources under the most restrictive union of those policies.
A user of such sites would still consider them a single context,
so we are better off not tying user expectations to the presence
of a single policy.

A single policy is not needed to preserve privacy. This has nothing to do with tracking. The data collector needs to adhere to the policies under which the data is collected regardless of DNT.

Furthermore, the non-normative note is filled with normative language (which is clearly inappropriate) and inaccurate statements about compliance that have nothing to do with TPE.

3. Option C: Resources operated by one party

A context is a set of resources that are controlled by the same party or parties.

Note: This refers back to the working group's definition of party

Details

Responder Option C: Resources operated by one party
Walter van Holst This definition is extremely vague and is therefore the most objectionable of all these options.
Mike O'Neill I object to this option for the same reasons as option A, in addition to it being far too broad. A subset of the parties may be involved in data collection in multiple web interactions so, under this definition, differentiating one context from another would be impossible.
Rob van Eijk I object, this definition does not help the definition of tracking. (1) On the contrary, it makes the meaning of tracking less clear. (2) It also lacks the granularity needed to distinguish different contexts between sets "of resources with a common data controller and a group identity that is easily discoverable by a user". E.g., a data controller with news magazine A (set of resources) and news magazine B (set of resources) could easily be one context under this definition.

The tracking-context combination reads: "Tracking is the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources that are controlled by the same party or parties."
Chris Pedigo I believe Option C represents the best definition of context. This Option would link two important definitions on which the working group has already reached consensus – “tracking” and “party.” By doing so, the TPE would be a more cohesive document which is more likely to be understood by the general public and implemented by the business community.
David Singer This is very vague; it appears to allow one context to span multiple unconnected parties, which rather defeats the entire exercise. ("My imagined context is the set of resources controlled by all possible parties, and my data stays within that context, so I am not tracking.") This cannot work.
Chris Mejia To be clear, I am voting to SUPPORT Option D below: a definition for the word “context” is NOT required in this TPE as all definitions (including “context”) will be defined in this TPE’s accompanying compliance document, where such definitions will fall in logical line with that compliance document’s policy. That stated, IF we were forced into picking a definition for context from the limited set of choices found in this poll (which we should not be forced to do), I would vote for Option C from these limited choices. Noting this preference for Option C’s definition has nothing to do with my stated position that NO definitions should be found in the TPE part of this DNT spec. Accordingly, I object to Option C, not so much on the grounds that it represents a bad definition for “context”, but that the TPE is not the place for defining terms that will be germane to compliance.

Option C’s definition for the word context also “bakes in” compliance policy that should not be found in this pure technical spec. As stated above, I generally object to the inclusion of ANY definitions in the TPE—all definitions should be found in a compliance spec that will accompany the TPE in practice.

As we had previously agreed to bifurcate the spec into two parts, technical and compliance, it would be most appropriate to define key terminology in the compliance spec. In deployment, the tech spec should always be married with a compliance spec, the two combined essentially becoming ONE single DNT spec. Accordingly, it would be most appropriate to define terminology in the compliance spec, especially if such terminology could be germane to compliance policy (in the case of the words “tracking” and “context”, those definitions are most certainly germane to compliance policy). There is no need to confuse things by introducing just some select definitions in the TPE, and then others in the compliance spec.

This working group has already approved the bifurcation, and has ratified the idea that there may be multiple compliance specs to choose from for companies deploying the DNT solution. Having definitions in the TPE, which is meant to be a PURE technical document (technical “plumbing” only), will likely lead to situations where there is direct conflict between the tech spec and a compliance spec.

Defining “context” and “tracking” is important, don’t get me wrong—but it’s equally important that their definitions fall in line with the rest of a compliance document’s policy. The push to define these terms in the TPE feels like a “back door” way to force certain overriding privacy constructs on compliance policies yet to be developed. That was not the intent of bifurcating the spec into two parts.
Brad Kulick I am not in favor of continuing to address compliance issues within the TPE. This should be left for the compliance document.

However, if it will be added to the TPE instead of the compliance document, this is the best option. It is simple, straightforward, and conveys the meaning of context that is sufficient and easily understood. Furthermore, it builds on top of previously decided definitions, providing consistency. It is better than option A as they are similar except that A adds "group identity that is easily discoverable by a user", however, that is unnecessary since C (i.e. this option) uses the previously defined "party" definition which already includes that.

If we must add this to the TPE, this option is simple, complete, and consistent with the rest of the TPE.
Alan Chapell I object to this option as well. This option is perhaps the most objectionable because it is so vague. I am not in favor of continuing to address compliance issues within the TPE. This should be left for the compliance document.
Shane Wiley If the working group desires to transfer portions of the latest version of the Compliance document (TCS) into the TPE (something we agreed we were NOT going to do) then this would be the most reflective statement to maintain the consensus the group had arrived at in those discussions.
David Wainberg I object to porting compliance definitions into the TPE. This definition in particular is would be an absurd stretch beyond any reasonable understanding of the meaning of the term context. We should leave definitions like this out of the TPE.
Lee Tien This is unacceptable, since it would treat everything controlled by a large party as a giant context without regard to any user perception differences, party policies, etc. This does not even require that the user perceive that there is a single party in control. Unacceptable.
Jack Hobaugh I object to Option C.
In general, I object to the porting of a compliance-related definition into the technical specification (“TPE”). I feel strongly that the TPE should remain a pure protocol and technical specification document. Some have contended that compliance-related definitions are needed in the TPE in order for a consumer to understand his or her choice regarding the DNT signal. This is simply not the case. It is sufficient to present to a consumer the simple choice of whether to send or not send a DNT signal. A technical specification need only specify the requests and responses necessary for a DNT protocol to be implemented in a scalable and implementable solution across all browsers and the servers called. Moreover, the intended audience for the TPE is technical implementers such as software engineers, developers, and programmers, but not consumers. To be clear, the TPE should not take on the responsibility of informing consumers and attorneys regarding a policy or compliance choice but instead should inform the technical community on how to implement a technical solution. The compliance specification for the DNT signal should be left to the compliance regime, whether it is a national compliance regime, a W3C-based compliance regime or a self-regulatory compliance regime. Porting definitions from a particular compliance regime into the TPE only serves to provide an incomplete and conflicting picture to the software engineers, developers, and programmers who will be tasked with implementing the technical protocol together with a compliance policy.

Moreover, even if a definition were warranted for “context,” to be fair that definition should have been resolved prior to the call for objections that decided the definition for tracking, in which “context” is found.

Further, with each compliance-related definition that is added to the technical specification (TPE) comes an increased probability that the TPE will conflict with compliance definitions contained in a non-W3C compliance policy. As the potential for compliance-related conflicts between the TPE and a non-W3C compliance policy increase, so does the potential for non-adoption of the TPE for those entities that choose to implement a non-W3C compliance policy.

I also object to the extent that this definition suggests that privacy gains can only be obtained through common ownership. I incorporate by reference, the section “harm to competition” found at http://www.w3.org/2002/09/wbs/49311/datahygiene/results.
Rob Sherman I support and prefer option C. I also disagree with others who have submitted objections on Option C on the basis that it opens the door to multiple unconnected parties falling within the definition. This is not the case because Option C refers to the existing definition of "party," which includes a concrete consensus standard for when multiple parties operating a resource may be considered first parties.
Roy Fielding No objection. I prefer Option A because the group identity provisions of "party" only apply to multiple legal entities. In other words, this definition allows a single legal entity to treat all of their own websites as a single context even if they use completely different branding, even if they have been obtained through a later acquisition.

4. Option D: No definition

The notion of context is left undefined.

Details

Responder Option D: No definition
Walter van Holst This option is preferable over options A and C, but not better than option B.
Mike O'Neill Because the definition of tracking relies on this notion, it must be defined, so I object to this option. If this is chosen the definition of tracking should be left to the compliance document(s).
Rob van Eijk Now that we have a definition of tracking, it is essential to define tracking. The definition of tracking depends on the concept of context and should therefore not be left undefined.

The question that should come next is whether to port the definition combo of tracking-context to the TPE. Preferred would be not to port definitions of context and tracking to the TPE and leave compliance issues to the compliance document.
Chris Pedigo
David Singer This is only acceptable if the definition of tracking is used solely to inform the users roughly what it is that they have turned off. Even then, it is rather absurd for a definition to use a term that is both undefined and could be defined in such various ways. Fundamentally, this is pointing out we adopted a 'definition' which was anything but. Given a vague definition, the best we can do is to limit the damage done by that vagueness, and say that it's an informal definition meant to convey roughly what any compliance regime does (or needs to?) offer.
Chris Mejia I strongly SUPPORT this option. I’m quite sure that the terms “tracking” and “context” will be defined in every compliance spec that is submitted to work with this technical spec, and thus it is not required to define these terms here in the TPE. Furthermore, doing so will only lead to conflict between this TPE and compliance specs, creating unnecessary confusion which may ultimately lead a party to not adopt any DNT solution. The TPE is not meant to stand alone on it’s own—it should always be married with a compliance spec that will define the terms used.
Brad Kulick I support and prefer this option. It allows for the compliance document to specify the meaning of context. In earlier discussions, we decided to work on the TPE and minimize compliance related work. Simply put, defining context is not necessary to implement this technical specification.
Alan Chapell I support this option. Defining context is not necessary to implement the TPE.
Shane Wiley I strongly support this option as it provides the greatest latitude for a compliance specification to define how context should be applied with respect to compliance. Any attempt to define this within the TPE is an overt attempt to pull the compliance specification (TCS) into the technical specification (TPE), which we've agreed we would not do. As it stands, each Server can easily express to users what "context" means for their specific implementation.
David Wainberg I support this option.
Lee Tien This is simply unacceptable. No definition is better than a contentless definition.
Jack Hobaugh I strongly support Option D.
Rob Sherman
Roy Fielding I object to this option because undefined terms just let others define them for you, often resulting in unnecessary legal actions.

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Ian Fette <ifette@google.com>
  2. Michael[tm] Smith <mike@w3.org>
  3. Frank Wagner <frank.wagner@telekom.de>
  4. Edward O'Connor <eoconnor@apple.com>
  5. Bryan Sullivan <bs3131@att.com>
  6. Adrian Bateman <adrianba@microsoft.com>
  7. Carl Cargill <cargill@adobe.com>
  8. Jeff Jaffe <jeff@w3.org>
  9. Wendy Seltzer <wseltzer@w3.org>
  10. Ted Leung <ted.leung@disney.com>
  11. Mark Vickers <mark_vickers@cable.comcast.com>
  12. Kevin Trilli <ktrilli@truste.com>
  13. Nick Doty <npdoty@w3.org>
  14. Jing Wu <wujing@ritt.cn>
  15. Haakon Bratsberg <haakonfb@opera.com>
  16. Bil Corry <bcorry@paypal.com>
  17. Aleecia McDonald <w3c@aleecia.com>
  18. Kevin Smith <kevsmith@adobe.com>
  19. Amy Colando <acolando@microsoft.com>
  20. Sue Glueck <Sue.Glueck@microsoft.com>
  21. Justin Brookman <justin@cdt.org>
  22. John Simpson <john@consumerwatchdog.org>
  23. Heather West <heatherwest@google.com>
  24. Sean Harvey <sharvey@google.com>
  25. MeMe Rasmussen <meme@adobe.com>
  26. Paddy Underwood <paddy@fb.com>
  27. Elise Berkower <Elise.Berkower@nielsen.com>
  28. Joanne Furtsch <jfurtsch@truste.com>
  29. Sid Stamm <sid@mozilla.com>
  30. Jeffrey Chester <jeff@democraticmedia.org>
  31. Kennie Kwong <kk7992@att.com>
  32. caten tian <caten_12@163.com>
  33. Weihua Tao <taoweihua@360.cn>
  34. Vinay Goel <vigoel@adobe.com>
  35. Gerard Lewis <gerard_lewis@comcast.com>
  36. Jason Lenhart <jason_lenhart@comcast.com>
  37. Susan Israel <susan_israel@comcast.com>
  38. Dan Caprio <dcaprio@mckennalong.com>
  39. Dan Oseran <doseran@paypal.com>
  40. Simon Krauss <s.krauss@cablelabs.com>
  41. Euan Grant <Euan.Grant@microsoft.com>
  42. Yaso Córdova <yaso@nic.br>
  43. Matthias Schunter <matthias.schunter@intel.com>
  44. Erik Neuenschwander <erikn@apple.com>
  45. Hanrui Gao <gaohanrui@360.cn>
  46. Rudy Brioche <rudy_brioche@comcast.com>
  47. Rebecca Arbogast <rebecca_arbogast@comcast.com>
  48. Paul Glist <paulglist@dwt.com>
  49. Neil Bowman <neil.bowman@bbc.com>
  50. Daniel Jaffe <djaffe@ana.net>
  51. Keith Scarborough <kscarborough@ana.net>
  52. Dan Auerbach <dan@eff.org>
  53. Walter Michel <walt_michel@cable.comcast.com>
  54. Thomas Schauf <schauf@bvdw.org>
  55. Jessica Li <jessicadli@tencent.com>
  56. Ronan Heffernan <ronan.heffernan@nielsen.com>
  57. Bin Hu <BH526R@att.com>
  58. Yuanzhou Zhang <berneyzhang@tencent.com>
  59. Yue Min <minyue@baidu.com>
  60. Qu Chao <chappellqu@tencent.com>
  61. Chao Bian <chaobian@tencent.com>
  62. Vincent Toubiana <vtoubiana@cnil.fr>
  63. Xuemei Yan <lindayan@tencent.com>
  64. Horace Zhou <horacezhou@tencent.com>
  65. Yangguang Zhao <zhaoyangguang@mail.ritt.com.cn>

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.127 2015-02-04 08:52:34 carcone Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)