W3C home > Mailing lists > Public > public-tracking@w3.org > March 2013

RE: Proposed Resolution to ISSUE-151 : User Agent Requirement: Be able to handle an exception request

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Mon, 18 Mar 2013 16:14:35 +0000
To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <DCCF036E573F0142BD90964789F720E31366A005@GQ1-EX10-MB03.y.corp.yahoo.com>
Matthias,

For a balanced ecosystem with equal rights for publishers and user agents, I believe this should be a MUST.  Otherwise, as we've already begun to see in the real-world, network devices and appendages will begin to set DNT:1 outside of user control and in some cases, knowledge.  I also believe this is highly tied to Issue-143 which attempts to solve for a similar issue.

- Shane

-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: Monday, March 18, 2013 6:18 AM
To: public-tracking@w3.org (public-tracking@w3.org)
Subject: Proposed Resolution to ISSUE-151 : User Agent Requirement: Be able to handle an exception request

Hi Team,


After being off line with the flu, I now started post-processing my DNT queue.

For ISSUE-151, I read the minutes and the mailing list and it seems to me as if all arguments have been exchanged and we can now move towards deciding this issue.

My summary looks as follows:
1. We agreed that the dialogue between sites and user agents is key to the broad acceptance of DNT 2. We agreed that the new exception APIs is beneficial since it allows sites to store preferences
     and thus reduces the disruptiveness for visitors of a site 3. We agreed that to encourage user agents to implement this API, the spec should require the implementation 4. IMHO the browsers in the room plan to implement the API; thus for them there is no difference

The only open item was whether we should phrase this requirement as a "MAY",  "SHOULD", or a "MUST" (definitions of these terms below).

When comparing those options, I see the following arguments:

"MUST":
+ All user agents will have to implement this feature
- If a user agent is unable to implement this feature, it will not comply with our protocol
- User agents may be encouraged to "implement" the API by accepting calls without and storage
    (thus being compliant with the letter of the spec while violating the spirit)

"SHOULD":
+ All user agents are strongly encouraged to implement the API More 
+ flexibility: Allows also user agents that are technically unable
to implement the API
- There may evolve user agents without the exception API
+ No need to "pseudo-implement" the API

I suggest to resolve this potential split by go for the lighter-weight requirement "SHOULD" and studying emerging implementations. The to conduct this study with "SHOULD" is that if we decide for "MUST", then there is no leeway for the implementors and thus there should be no diversity of implementations to study.

If everyone can live with "SHOULD" as a proposed resolution, I will issue a formal call for consensus.

If not, I suggest to start our formal chairs decision procedure with the two following options
  (a) User agents "SHOULD" implement the exception API
  (b) User agents "MUST" implement the exception API

As always, feedback is welcome...


Regards,
matthias


> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>     definition is an absolute requirement of the specification.
>

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>     may exist valid reasons in particular circumstances to ignore a
>     particular item, but the full implications must be understood and
>     carefully weighed before choosing a different course.
Received on Monday, 18 March 2013 16:15:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:07 UTC