W3C home > Mailing lists > Public > public-tracking@w3.org > September 2012

Re: Meaning of the term "optional" in the TPE spec

From: <mts-std@schunter.org>
Date: Thu, 13 Sep 2012 09:58:22 -0700
Message-ID: <55ce2c8f45a89235300b3f7c6d4ead1f.squirrel@webmail.schunter.org>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: "Matthias Schunter" <mts-std@schunter.org>, "public-tracking@w3.org" <public-tracking@w3.org>
Hi Roy,

thanks for the clarification. It shows that you are a standards veteran
and it is great to have you on board!

For the rest of us, we need to double-check that there are no objections
to the fact that optional fields are purely optional, i.e., the only
member of the well-known resource that all sites MUST declare is the
tracking status.

Sites can then freely choose whether they want to provide additional
transparency by adding information through the other fields:
                *( vs extension )

Only for the "control" field, the spec mandates that a site SHOULD
populate it iff it uses out of band consent ("c").



However, the current spec does not mandate this additional transparency.

> On Sep 10, 2012, at 1:19 PM, Matthias Schunter wrote:
>> another potential clarification that we discovered is that we as a group
>> need to validate that we agree when the TPE spec uses the term OPTIONAL
>> (defined by RFC2119 as fields/features that are completely optional,
>> i.e., servers and user agents can freely choose to implement them or
>> not).
> The spec should already do that.  If a field is optional except under
> certain
> circumstances, then it should say that.  The fields that are purely
> optional
> do not have any dependent requirements yet.  If there is a mistake in the
> drafting, please note it as a bug.
>> I believe that this is the right meaning for some of the fields in the
>> TPE spec. An example is the extensions to the DNT header or the
>> third-party field of the tracking status resource.
>> However, we need to double-check that all fields that are declared
>> OPTIONAL are never needed for any critical use case.
>> If we are honest to ourselves, we should usually only claim that our
>> spec implements a use case iff this use case does not depend on such
>> optional fields.
> Yes, nobody has claimed otherwise.
>> fyi:  for the fields of the tracking status resource, I believe the
>> following to be true:
>> - we agreed that the third-party fields is truly optional (sites can
>> freely choose whether they may or may not declare third-parties)
>> - for the "same-party" field, this is less clear. Without this field,
>> user agents may be confused if multiple sites say "intended for 1st
>> party use" without declaring each other to be part of the same party.
> What do you mean by "it isn't clear"?  Right now, same-party is not
> required under any circumstances.  I think that's pretty clear.  The
> only reason it was proposed as optional is because it is an implementation
> burden on first party sites.
> In order to make it required, somebody in the WG (which includes the
> draft authors) needs to propose that it be required. Since nobody has
> done that yet, AFAIK, it isn't required.
> Are you making that proposal?  If so, please just do so and let the
> WG discuss.  If there are no objections, it goes in.  If there are
> objections, we make a call for consensus and the the chairs decide.
>> Did we overlook spec language that contains these requirements? If not,
>> how would you clarify this issue?
> I did not overlook it.  We simply haven't made it a requirement yet.
>> Should we go through the fields one-by-one and discuss which fields
>> should not be completely optional?
> I would hope that people are doing that while reviewing the document.
> ....Roy
Received on Thursday, 13 September 2012 16:57:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:00 UTC