Meaning of the term "optional" in the TPE spec

Hi Roy,


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).

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.

 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.

Did we overlook spec language that contains these requirements? If not,
how would you clarify this issue?
 Should we go through the fields one-by-one and discuss which fields
should not be completely optional?


Regards,
matthias








However, for some of the other fields of the tracking status resource,
this is less clear. E.g., I believe that the third-party field is
optional in both ways while the "same-party" must be declared if a
same-party uses multiple domain-names that all indicate the "1"
(intended for 1st party use). As a consequence, the same-party field
must be sent under certain circumstances, i.e., is not optional in the
usage sense.

The current spec uses the term OPTIONAL (defined in RFC2119 as truly
optional, i.e., vendors may choose to not implement those fields). I
believe that


Regards,
matthias

Received on Monday, 10 September 2012 20:20:12 UTC