- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Tue, 13 Jun 2017 18:33:06 +0100
- To: <singer@apple.com>, <public-tracking@w3.org>
How the domains are allocated or categorised would often be a legally determined. A compliance document could describe this and another property (on the other-party object) could convey the category names. "other-party" refers to domains, so there will always need to be a "domain" property, and there are several of them so it needs to be an array (of objects). Other properties (on the object) can convey further information, depending on the jurisdiction or the requirements of the site or service. I think this definition strikes a reasonable balance between standardisation and flexibility. If we are allowed further time maybe others would agree to more detail? -----Original Message----- From: singer@apple.com [mailto:singer@apple.com] Sent: 13 June 2017 17:18 To: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org> Subject: Re: CFO Issue 22 I get that people would the tracking resource to say something useful about other parties, but I urge people to read the specification text proposed, and understand that it is so imprecise that it could contain a random list of sites. There’s nothing there that anyone can rely on. As Roy says, if someone else is going to write a crisper, actionable, clarification, then that specification could simply supply the whole definition. Instead of writing “The other-parties field MUST contain [x] and MUST NOT contain [y]” they write “the well-known resource is extended with a field other-parties, which…”. There is no value derived from, and a lot of potential problems caused by, us under-defining a field: it would be ‘polluted’ in practice, with unusable values, and no one would be able to rely on it for anything. David Singer Manager, Software Standards, Apple Inc.
Received on Tuesday, 13 June 2017 17:34:11 UTC