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

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:
                same-party
                third-party
                audit
                policy
                *( vs extension )

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

Opinions?


Regards,
matthias


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