Re: TPE last-call issues on my plate, summary

On Wed, Oct 8, 2014 at 6:16 PM, Sid Stamm <sstamm@mozilla.com> wrote:
> Adding Anne van Kesteren since he is not subscribed to the mailing list and had concerns about some of this.

Thanks Sid.


> On Oct 8, 2014, at 9:04 AM, David Singer (Standards) <singer@apple.com> wrote:
>> 1. <http://www.w3.org/2011/tracking-protection/track/issues/243> terminology
>>
>> agreed
>>
>> top-level origin -> top-level browsing context as defined in <http://www.w3.org/TR/html5/browsers.html#browsing-context>
>>
>> a target is the Host part of an HTTP URL as defined in <http://tools.ietf.org/html/rfc3986#page-18> from which a resource is requested
>>
>> document origin of a script -> effective script origin, so it now reads

No, effective script origin is wrong. That takes document.domain into
account, we most definitely do not want to do that for new features.
I'm not sure what you mean by target, is there an updated editor's
draft available?



>>> 2. It needs to return an string enum rather than a string. (With
>>> values "", "yes", and "no" or some such.)
>>
>> not agreed.  It should be documented at this level as being whatever would be sent in a DNT header, if anything.

Sure, but that can still be done as an enum. Just needs to consist of
"1" and "0" then. But it seems somewhat bad practice to compromise the
legibility of the API due to size concerns over the HTTP header.


>>> 3. It should not return null. No need to vary type.
>>
>> Not agreed. The meaning is that it is exactly what would be present in an HTTP DNT header.  If any string (including an empty string) is returned, then a DNT header with that value would be sent. The special value NULL indicates that no DNT header would be sent.

The empty string is not a valid value. If there's only three valid
states, returning different types makes for a very cumbersome API. Did
you talk to any JS developers?


>>> 4. It should be exposed in workers.
>>
>> Agreed.  Moving it (point 1) achieves this.

I guess this is not yet done in the editor's draft?


>>> within platform APIs we call "URI” URL
>>
>> Not agreed.  DNT is an HTTP extension.  URI is the correct term.

HTTP, at least in browsers, uses the same URL implementation as APIs
do. I guess I don't really care what you decide to call it now,
although it seems somewhat confusing with the other documents the W3C
publishes, but you'll be wrong long term.


>>> You have not defined cookie-like domain string.
>>
>> It is the cookie-domain defined in 5.2.3 of RFC 6265 <http://tools.ietf.org/html/rfc6265#section-5.2.3>

That seems like a bad idea. We should not propagate the broken model
of cookies further. New APIs must be origin-bound.


-- 
https://annevankesteren.nl/

Received on Thursday, 9 October 2014 07:32:19 UTC