The status-id exists so a server can signal in-transaction a particular TSR out of a tree of them. That and the qualifiers property is the only way to differentiate between reasons for a particular D response. If the only reason for a D is “we do not believe your browser sends valid DNT signals” then we do not need the qualifier. If there is more than one,  or an unlimited set of them, then for the sake of transparency and clarity for the user there has to be a way to identify the specific one, and the status-id will do it (albeit with another transaction to get the TSR).

If the D response lets third-parties claim compliance with DNT without offering a reason for ignoring the signal, then D should be abolished.

From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: 08 May 2014 19:39
To: Mike O'Neill
Cc: public-tracking@w3.org; 'Justin Brookman'; rob@blaeu.com; 'Jack Hobaugh'
Subject: Re: Issue-207

On May 6, 2014, at 11:14 AM, Mike O'Neill wrote:

Hi Justin,

Here is our agreed amended text, with reasons now in the plural as suggested, and also saying they should be listed in the privacy policy. The non-normative text is expanded to describe the TPE mechanism for signalling the particular reason (if there are several listed).

A party MUST provide information in its privacy policy listing the specific reasons for not honouring the user expression. The party's representation MUST be easy discoverable, clear and unambiguous.

That last sentence is non-testable and cannot be a MUST.

An "ought to be easily discoverable, ..." would be fine.

Non normative: In the interests of transparency, and especially if there are more than a single such reason listed, it is recommended that servers implement the [TRACKING-DNT] “status-id” mechanism so that the particular reason for not honouring the user expression is provided. The Tk response header can contain a status-id field identifying the relevant Tracking Status Resource whose qualifiers property contains a short token representing the particular reason. The User Agent can parse this and communicate the reason to the user.

"it is recommended ..." is a normative statement, but this is not how

the status-id is specified by the protocol.  Yes, a compliance document

can specify normative requirements on when qualifiers must be present,

but status-id is only used for resource-specific status.

We do not need to mention status-id here; we can just require certain

qualifiers to be present in the TSR (whether or not a resource-specific

TSR is necessary is already determined by the protocol requirements and

independent of any need for qualifiers).

....Roy