Re: ACTION-359: Add proposal for ISSUE-161 to allow an indicator of non-compliance within the tracking status value for testing and deployment

On Feb 6, 2013, at 8:44 AM, David Wainberg wrote:

> Hi Roy,
> 
> Following up from last week's discussion. What's the rationale for the additional requirements? If the implementation is non-compliant, incomplete, testing, whatever, then why not let that be the case without additional requirements? Also, doesn't it create a circular problem with trying to indicate non-compliance in a compliant way? Especially if the non-compliance includes not providing those elements?
> 
> An origin server that sends ! as a tracking status value must provide, in the corresponding tracking status representation, a valid first-party member; the origin server must also provide policy and control members if such information is not directly obtainable by performing a retrieval action on the first-party resource(s).

The purpose of this response is to provide more useful information
than no response at all.  Hence, there are additional requirements
to ensure that the response is worth receiving and to discourage
the sending of useless bytes.

> Moreover, can we change the name to something like "non-standard" rather than "non-compliant," since if they are providing this flag according to the spec then they are in fact compliant with the spec.

They are conformant to the syntax of this spec, but not compliant
with the requirements of the DNT protocol (which includes both specs).

> And I propose the following description of the "!" value: The origin server is unable or unwilling to claim that the designated resource conforms to [TRACKING-COMPLIANCE]. The server MAY provide additional details through a link in policy.

Useless bytes.

....Roy